XIA Mobility and Intrinsic Security
Security is intrinsic to the XIA architecture. Each network, host and service is backed by a public-key crypto key-pair. The corresponding NID, HID and SID identifiers are hashes of their public keys. This allows each of those XIA entities to sign messages that the receiver can trust by verifying against their public key. The content identifiers (CIDs) are hashes of the actual content they represent so the content must match the identifier. This allows a CID receiver to verify the content it received. XIA allows all principal types to have 160-bit identifiers and most are backed by cryptography based keys to support intrinsic security.
These cryptography based identifiers serve as building blocks for a number of intrinsic security mechanisms used within XIA stack. Routers can challenge any new hosts trying to send messages through them to deter source-address spoofing attacks. Services can exchange messages that the corresponding endpoints can trust. For example, we are able to migrate streaming sessions on a mobile device to a new network, by sending an updated address signed by the SID of the mobile host.
The following sections provide implementation details of intrinsic security mechanisms we mentioned above.
The host level intrinsic security implementation is based on the Accountable Internet Protocol (AIP) paper. When a router facing end hosts receives a packet for the first time from a host, it drops the packet and sends a challenge back to the host. The host in turn responds by signing the challenge with its private key and including its public key with the response. The router verifies the host's response and adds it to the whitelist of allowed hosts. Challenge includes - srcHID, dstHID, interface, Hash_of_pkt, HMAC_using_router_secret where,
- srcHID - HID of the host that sent the packet being challenged.
- dstHID - destination HID of the packet that was challenged.
- interface - Router's network interface on which the packet was received.
- HMAC_using_router_secret - Router generates HMAC using a secret known only to the router and includes it in the challenge. This allows the router to not maintain any state for challenges it sends.
The response includes - Challenge, Challenge_signature, Public_key where,
- Challenge - the original challenge as sent by the router.
- Challenge_signature - sign the Challenge using the host's private key.
- Public_key - the host's public key. Must match its HID and usable to verify the signature.
On receiving the response, the router performs a number of checks including:
- Verify HMAC to ensure this response is in response to a challenge sent by this router.
- Verify Hash of public key in response matches the sending host's HID.
- Verify the Signature using the public key of the sender.
If all the checks are valid, the sending host's HID is added to a whitelist of senders allowed to send packets through this router.
Notes:
- There is no challenge-response between routers.
- The original packet that was challenged is dropped immediately by the router. It is the host's responsibility to retransmit that packet after the verification if needed.
We have a limited session level intrinsic security implementation that was needed to allow for verification of session migration messages. The prototype currently (Feb'2017) does not do a TLS like handshake between session/service endpoints to set up a secure session.
Please see the section Mobile service migration using rendezvous service below for a description of intrinsic security as it pertains to the rendezvous service.
The fast and secure association with mobile networks provided by the Network Joining Protocol allows XIA devices to move between various networks on a number of available interfaces. Once the layer-2 and layer-3 setup is completed by Network Joining Protocol the XIA stack supports the transitioning of any existing sessions or making existing services available from the new network.
We implement support for mobility in the XIA prototype at two levels. First, active session migration supports migration of a session between two endpoints as a device/host hosting one of the sessions migrates to a new network. Our approach is fundamentally similar to that described in An End-to-End Approach to Host Mobility. Second, we provide a Rendezvous service for clients to reach a mobile service. This allows a client to reach a service that has moved to a different network after registering itself with the name service using its old address.
For active stream sessions, if a host running the client or the service moves to a new network, the following actions take place:
- Network joining deaemon receives a new network announcement.
- If a decision is made to join the new network, a network joining handshake is completed.
- This establishes layer-2 and layer-3 connectivity between the mobile host and the new network.
- After the handshake is completed, all active stream sessions are migrated to the new network:
- The transport includes a MIGRATE option in messages going out to each remote endpoint for each active stream session. MIGRATE option will be retransmitted using the same reliable stream protocol that is used for data packets.
- The remote ends respond with MIGRATEACK option in their stream packets indicating receipt of the MIGRATE request.
The MIGRATE option contains - newSrcDAG, dstDAG, timestamp, signature, SID_public_key where,
- newSrcDAG - updated source DAG with the new AD that was joined.
- dstDAG - DAG of the remote endpoint.
- timestamp - current timestamp to discourage replay attacks.
- signature - Signature using the SID private key for each stream session.
- SID_public_key - Public key matching the SID that can be used to verify the signature.
The MIGRATEACK option contains - migratedDAG, timestamp, signature, Fixed_host_SID_public_key
- migratedDAG - same as newSrcDAG in the migrate option.
- timestamp - same as in the migrate option.
- signature - Signature using the SID private key at the fixed host that did not move.
- Fixed_host_SID_public_key - public key of the SID that did not move.
Notes:
- The MIGRATE and MIGRATEACK options are included in regular stream packets and may be retransmitted as needed.
- DATA transmission is only suspended on the migrated host. The other end can start sending DATA packets to the migrated host as soon as it receives and verifies the MIGRATE message.
- If both ends moved, they would have to use the rendezvous service to maintain active connection. See below.
Here are the key differences in our implementation from the Snoeren paper on which this work is based:
- Key registration is optional in the paper but our keys are a result of intrinsic security in XIA and are always used to verify migration messages.
- A special Migrate-OK flag is set in SYN and SYNACK messages for negotiation of migration capability. We allow migration as a default with MIGRATE/MIGRATEACK options in our streaming protocol (XSP).
- Sequence number in migrate SYN messages is used for supporting migration in the paper, but we use the MIGRATE and MIGRATEACK options with signatures and timestamp for verification in XSP transport header.
We use a rendezvous service to allow migration of hosts running mobile services. The mobile service registers a DAG with a fallback to a rendezvous service. The name service then presents the registered DAG to any clients that wish to connect with the mobile service. If the mobile service is not in its home network, SYN packets take a fallback and reach the rendezvous service. The rendezvous service rewrites the primary path in the SYN packet's destination DAG to reflect the latest known location of the mobile service. The "last" pointer is reset and the packet is sent on the network like a new SYN packet. The mobile service receives the SYN request and notices that it went through a rendezvous service. It verifies the changes in the DAG and returns a SYNACK with a signature confirming that the corresponding client can use this modified new DAG for future packets to the mobile service.
Here is a more detailed, step by step description of the rendezvous process:
- Mobile host maintains a per-interface configuration with rendezvous service control and data plane DAGs.
- Mobile service can request DAGs for all interfaces by calling Xgetifaddrs() API.
- DAGs backed by a Rendezvous service will have the XIFA_RVDAG flag set.
- The mobile service can then construct a DAG with a rendezvous service fallback by calling Xgetaddrinfo().
- It registers this DAG with the name service.
- At this point, the mobile service is free to migrate to a new AD as long as the rendezvous service is available.
- On migration to a new network, the network joining daemon triggers a notification to the rendezvous service of the new AD via a control message signed by the HID private key - HID, newMobileHostDAG, timestamp. This control message is currently a datagram message that is transmitted once. It should be sent periodically instead. (TODO)
On receiving the control message, the rendezvous service:
- Verifies the sender's public key included in control message matches the sender's HID.
- Verifies that the signature is valid, using the public key in the message.
- Verifies that the timestamp is newer than the last seen timestamp from that sender.
- Record the new AD that the mobile host has migrated to.
At this point, if a client tries to connect to a mobile service on the migrated host:
- It looks up the mobile service DAG from the name service.
- The name service returns the DAG with the rendezvous fallback.
- The client sends a SYN packet to the mobile service with this DAG as the destination.
- Since the mobile service is not at its home network, the packet takes the fallback path to rendezvous.
The SYN packet now arrives at the host running the rendezvous service:
- The transport on the rendezvous service host delivers the raw packet to the rendezvous service.
- The rendezvous service looks up the destination HID from the mobile service destination DAG.
- It then finds the latest AD known for that mobile host.
- It replaces the original AD in the destination DAG with the latest known AD for the mobile host.
- The "last" pointer that indicates the last node traversed in the DAG is reset to start from the beginning.
- The modified raw packet is then sent back on the network.
On the mobile host:
- The modified SYN packet arrives at the mobile host and is destined to the mobile service.
- The transport notices that the destination DAG in the packet is different from the one the service bound to.
- The transport knows the current AD and the AD used for binding().
- If the only change between SYN dest DAG and the bound DAG is the current AD vs. bound AD, the DAG is accepted.
- A new DAGinfo state is created for the connection pair and a signed SYNACK message is generated.
- The SYNACK contains, the modified DAG, timestamp, signature and public key of the mobile service SID. This is essentially the same as Active Service Migration described in the section above.
- This special SYNACK with the signed payload is then sent to the client.
On the client:
- A SYNACK is received from a DAG different from the one that the SYN was sent to.
- The client looks for the signed payload and retrieves its contents for verification.
- It verifies that the public key matches the mobile service SID.
- That the signature is valid using the public key included in the SYNACK.
- If the signature is valid, the new DAG is accepted as the remote destination.
- All future packets for this connection go to the new AD where the mobile host is residing. Note: The SYNACK is essentially a MIGRATE message in this case and is processed as such.
Notes:
- If the mobile service host moves before a SYN packet reaches it after rendezvous service modification, the SYN packet will return to the rendezvous service for another modification as long as the TTL doesn't expire.
- If the TTL does expire the SYN retransmissions on the client may still allow for connection to mobile services that are offline for a short duration of time.
- The rendezvous service can modify any transport packet, not just SYN. It just turns out that is the only packet that goes through the rendezvous service in practice.
- In the unlikely event that both the host and service are mobile AND both migrate to a new network at the same time, the active session migration messages won't work but the rendezvous service may be able to help sustain the connection. This has not been tested but should be possible.