NFD » NDN Specifications

High-level idea from Beichuan on 20140122:

The point-to-point UDP tunnel, as implemented in ccnx, is different from TCP tunnel. But we can make them similar. I think both TCP and UDP tunnels need an explicit, authenticated procedure for its creation, maintenance, and destruction. This can be achieved by the face registration protocol we're defining.

Basically the first UDP/TCP packet from a remote peer will trigger: (1) a connected socket to this peer, (2) the packet payload should be a signed interest requesting for the tunnel and it should be passed to the management module. If the request is verified and authorized, the management module will instruct the face factory or channel to create such a face. The registration protocol should have a disconnect command, and a periodical refresh (which can be simply sending the registration command again).

What about having keep-alive (from both sides?). This keepalive could be useful for both udp and tcp faces (keeping state at nat)

Target version = Version 2

Don't worry about it right now.

Yes, keep-alive should be part of this protocol.
Beichuan names it periodical refresh.

Mark Stapp and Marc Mosko suggest:

• DTLS handshake procedure considers gotchas in negotiating a security relationship.
• Without HMAC, nothing can stop packet injection.
• Replay attacks should be considered.

20150130 conference call discussed some problems:

• TLS or DTLS cannot be used directly with NDN certificates. They require X509 certificates. Same information is contained in NDN or X509 certificates, but certificate formats are different.
• Packet injection is a risk that is worth mitigating: Interest injection allows Interest flooding attack where source of such attack is hard to trace (without going into IP layers); Data injection makes cache poisoning easier.
• HMAC is useful but would cause a major overhead if SHA256 is used. Negotiating a HMAC algorithm is undesirable, because it usually leads to the server choosing the algorithm with minimum security. It's better to mandate a specific algorithm.
• SignedInterest can already prevent replay attacks.

I can think about a solution to reduce packet injection risk without using HMAC: sequence numbers.

• When the tunnel is over TCP, TCP sequence numbers prevent packet injection.
• When the tunnel is over UDP, prepend a hop-by-hop header that contains a sequence number. After initial handshake, the sender uses sequence numbers sequentially; the receiver maintains a sliding window of sequence numbers it can accept, and drop any packet with a sequence number out of this window.

This shall bring packet injection risk down to the same level as TCP sequence prediction attack.

Whether this solution is sufficient depends on the assumption of whether attacker is able to monitor traffic.

If the attacker is able to monitor traffic, both TCP sequence prediction attack and NDN packet injection (under the above solution) are very easy, because sequence numbers are readily available.

20150209 conference call rejects the idea in note-9.

Tunnel Authentication should be compared to VPN in IP world, so HMAC shouldn't be treated as expensive.

I think tunnel authentication has two parts:

• open, keep-alive, and close the tunnel: ideas in tunnel-auth_20141118.pptx can satisfy this part
• ensure all packets belong to the tunnel: this needs HMAC on every packet, which should be considered together with #2520

20160623 NFD call discussed this issue.

Although there is no immediate pressure for tunnel authentication, it is a needed feature. In the long run, we need an NDN-native way of securing the tunnel. However, to avoid design and implementation shortcomings from the home-grown DTLS-like implementation, we should try to use TLS/DTLS libraries to do the main crypto tasks.

Alex proposes to use DTLS with X509 certificates to provide one-way authentication (client authenticates the router) and establish secure tunnel, and then we can use NDN-based solution to authenticate the client before allowing other communication (similar to note-7 page-7).

Alex's idea is approved.

Beichuan agrees Junxiao can continue with the design.

Beichuan is soliciting a developer to take on the implementation.

I had a call with Eric on 20160708. Some discussions are:

DTLS without tunnel authentication can be useful: it prevents MITM injecting or modifying packets.

Tunnel authentication without DTLS is useless: see note-8.

We believe DTLS can handle keep-alives.
If that's the case, it's unnecessary to have "tunnel lifetime", "periodical re-authenticate", "explicit close" in tunnel authentication protocol.

To implement tunnel authentication in NFD, we need:

• a command in management to perform authentication
• a step in LinkService to drop non-tunnelauth packets on both directions before a tunnel has been authenticated

Junxiao Shi wrote:

We believe DTLS can handle keep-alives.

Are you talking about the Heartbeat Extension?

Davide Pesavento wrote:

Junxiao Shi wrote:

We believe DTLS can handle keep-alives.

Are you talking about the Heartbeat Extension?

I looked into the Heartbeat Extension and it seems to have the functionality we're looking for.

Davide,

I'm not certain if the issue title is up to date, given that it was last updated in early 2014. I wasn't working on the project then, but I think the scope of this issue has increase since then. Now, the purpose of the tunnel auth protocol is to create an authenticated and encrypted tunnel between two hosts.

Any thoughts on the current design?

In my meeting with Beichuan earlier this week, he reiterated the importance of getting something like this running on the testbed. The main justification he brought up was preventing malicious traffic from traversing the testbed by only allowing registered users to connect and send traffic on it. As such, he suggested focusing on the authentication aspect of the protocol, without tunnel encryption. In this case, traffic would traverse tunnels as cleartext, but would be signed by the connecting user's private key and verified on the other end of the first-hop link. It would also likely be used on intra-testbed UDP tunnels to prevent packet injection.

I develop core router by the day and play with microcontrollers at night. I hope this protocol would use HMAC signatures rather than ECDSA signatures, and the testbed to be deployed as such. In both core routers and microcontrollers, it would be prohibitively slow to sign/verify ECDSA on every link layer frame.

Junxiao Shi wrote:

I develop core router by the day and play with microcontrollers at night. I hope this protocol would use HMAC signatures rather than ECDSA signatures, and the testbed to be deployed as such. In both core routers and microcontrollers, it would be prohibitively slow to sign/verify ECDSA on every link layer frame.

Yes, actually packets shouldn't be signed with private keys. It would be better to negotiate a shared symmetric secret key on the link, which would then be used to generate and verify HMAC signatures in both directions. Perhaps TLS/DTLS could be used to secure the link, even though encryption is unnecessary? Private keys could still be used for authentication of the link.

Two nodes can negotiate a shared secret with ECDH algorithm, using their EC key pairs. This is supported in OpenSSL and micro-ecc uECC_shared_secret. The shared secret would be static if both nodes keep using the same key. To limit HMAC key exposure, the trust model shall allow either node to use a sub-key under its main testbed certificate, rather than the main key.