1. NFD Tunnel Authentication
Junxiao Shi and Eric Newberry,

2. 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?

3. Necessity

4. 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.

5. 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.

6. High-level Design

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. 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

14. Protocol Details

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

16. 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

17. 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.

18. 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.

19. 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)”

20. 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

21. Deployment Issues

22. 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.

23. 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).

24. Comparison to VPN

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

26. 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