NFD Tunnel Authentication Junxiao Shi and Eric Newberry, 2016-11-02

Outline Why is tunnel authentication necessary? Which faces need tunnel authentication? At high level, how does tunnel authentication work? What packets are used by tunnel authentication? How does client and server operate? Are there any deployment issues? How does NFD tunnel authentication compare to IP-based VPN solutions?

Necessity

Overlay Tunnel needs Authentication You don't want to allow anyone in the world to gain connectivity through your router. Analogy in IP world: You don't want to open up your VPN server to everyone.

Authentication is for Tunnels Only Multicast faces do not need authentication: local area network is trusted. Backbone overlay links (eg. between testbed routers) SHOULD have mutual tunnel authentication.

High-level Design

Feature Overview TLS/DTLS must be enabled before tunnel authentication can be requested Tunnel opening is explicit: tunnel authentication request and reply. Other packet exchanges are rejected before this sequence is done. Authentication is mutual. Keep-alive is done through the TLS/DTLS Heartbeat mechanism. Tunnel closing can be explicit: tunnel closure request and reply. Tunnel closing can also be implicit: failure to keep-alive closes the tunnel.

Packet Injection Mitigation Tunnel authentication protocol does not mitigate packet injection and MITM attacks. NDNLP may provide mitigation through "packet injection prevention" feature, although this requires a careful security protocol design. Existing TLS/DTLS can be used to provide mitigation.

TLS/DTLS + Tunnel Authentication Client connects to server using TLS/DTLS. Client authenticates server's X509 certificate (one-way authentication), and establishes a secure tunnel. Server disallows all NDN communication from the client except NDN tunnel authentication commands. Client and server authenticate each other through NDN tunnel authentication. Server allows full NDN communication from the client.

Tunnel Lifetime Tunnel lifetime is requested by client and granted by server. Tunnel lifetime MUST NOT be less than 2000ms, to ensure correct protocol operations. Server MAY grant a TunnelLifetime that is less than client's request. Recommended default lifetime: 600s Client perceives the tunnel to be open for negotiated lifetime since the moment it sends tunnel authentication request. Server perceives the tunnel to be open for negotiated lifetime since the moment it sends tunnel authentication reply.

Keep-Alive and Implicit Closing At some random point between 50% and 75% of tunnel lifetime, a TLS/DTLS Heartbeat request is sent by the client. Upon receipt of a valid request, the server will respond with a Heartbeat response. If a Heartbeat request does not arrive by the end of tunnel lifetime as perceived by the server, the tunnel is implicitly closed. If a Heartbeat response reply does not arrive by the end of tunnel lifetime as perceived by the client, the tunnel is implicitly closed.

Explicit Closing C-S: tunnel closure request S-C: tunnel closure reply Interest signed by client's key seize to send other packets; accept incoming packets S-C: tunnel closure reply Data signed by server's key Tunnel is closed. This sequence works on the other direction as well. Each party SHOULD first send other pending packets, wait for a short duration for them to be delivered, then send the tunnel closure request/reply.

States Initial DTLS Tunnel Established Client Requests NDN Tunnel Request Tunnel Client Requests NDN Tunnel Reject Success NDN Tunnel Established Close NDN Tunnel Closure Requested

Protocol Details

TLS/DTLS Keys Key sizes of at least 2048 bits will be required to ensure the security of TLS/DTLS connections.

Requesting a TLS/DTLS Link Establish a TCP/UDP link through standard methods C: Create TLS stream over existing socket and send an LpPacket containing the StartTls header (through non- TLS socket). S: Create TLS stream over existing socket and reply with LpPacket containing StartTls header (through non-TLS socket). Fail transport if no handshake initiated within a configurable timeout period (default: 15,000ms). C: Initiate TLS handshake If successful: Link creation successful on both hosts. Allow creation of tunnels and direct all future traffic through TLS streams If failed: Link creation failed on both hosts

TLS/DTLS Keepalive The TLS Heartbeat Extension will be used for keepalive. Keepalives are bi-directional (sent by both client and server) Upon failure of a Heartbeat, a second attempt will be made before failing the transport. Tunnel Authentication relies on TLS/DTLS for keepalive functionality. Upon failure of TLS/DTLS heartbeat, the tunnel will fail as well. Once a tunnel is created, the heartbeat interval will be set to 50% to 75% of the tunnel lifetime.

Tunnel Authentication Mechanics A link must have TLS/DTLS in use before Tunnel Authentication can be configured. On faces that require Tunnel Authentication, all non- tunnel auth network packets will be dropped before tunnel auth is enabled. Once authentication is completed, all network packets will be allowed. Once a tunnel is closed, the face will only accept tunnel auth network packets. Link-layer packets are below the purview of Tunnel Authentication and will not be affected by the state of authentication.

Requesting Tunnel Authentication C: Send SignedInterest w/ Name /localhop/nfd/tunnels/create containing TunnelLifetime (milliseconds) in ExpirationPeriod ControlParameter S: Verify SignedInterest and reply with signed network packet If successful, send signed ControlResponse w/ StatusCode=200 and TunnelLifetime in <body>. Also allow non-tunnel auth network packets If failed, generated signed producer Nack C: Verify SignedData If TunnelLifetime from server acceptable, set TunnelLifetime to <body> from ControlResponse. Allow non-tunnel auth network packets If not acceptable, initiate “Explicitly Closing Tunnel (Client)”

Explicitly Closing Tunnel C/S: Disallow transmission of new packets and send all pending packets. C/S: Send SignedInterest w/ Name /localhop/nfd/tunnels/close S/C: Upon receipt of SignedInterest, disallow transmission of new packets and send all pending packets. S/C: Send signed ControlResponse with StatusCode=200 S/C: Close socket C/S: Upon receipt of ControlResponse, close socket

Deployment Issues

Existing Links Existing links (like those on the NDN testbed) will need to be configured to use TLS/DTLS and Tunnel Authentication Network downtime while NFD is upgraded and Tunnel Authentication is configured Hosts that wish to use transport methods that require Tunnel Authentication will need to be issued trusted certificates.

NFD Version mismatch Pre-Tunnel Authentication versions of NFD will not be able to communicate with newer versions (unless an option is added that allows an administrator to explicitly disable Tunnel Authentication).

Comparison to VPN

Similarities to VPN Encrypted traffic increases security (TLS/DTLS) Authentication system

Differences from VPN Encryption and authentication are separate TLS/DTLS does not automatically create a tunnel (however, tunnel auth requires TLS/DTLS to be configured) Vs unified system of authentication and encryption in VPNs