Re: [secdir] SecDir review of draft-ietf-mpls-ldp-hello-crypto-auth-05

["Bhatia, Manav (Manav)" <[e-mail]>]

Hi Yaron,

Thanks for the comments. My comments inline.

> 
> • The main issue is that only a symmetric crypto option is defined.
> IMHO, adding a public-key based scheme would be invaluable. Public keys
> do not necessarily imply certificates, and can be used with little
> added
> complexity compared to the current proposal. As far as I can see, the
> current use is not so performance constrained to preclude public key
> operations. And public keys would enable much easier and more secure
> deployment in many cases:
> 	∘ Different organizations can accept messages from one another,
> without
> needing to share the same keys. So even if groups keys are used (which
> is certainly not the best practice), public keys have an advantage.
> 	∘ Revocation is much simpler: to be able to revoke each
> individual
> sender (e.g. when a router is decomissioned), you need N**2 SAs in the
> symmetric case, vs. N keys when public keys are used.

The idea behind this draft is to bring LDP HELLO's security to at least the same level as the routing protocols running in the same networks today. All IGPs are currently using a symmetric crypto option and we think it is ok at this point in time to continue with the same for LDP.

With SDN principles its possible that the key distribution becomes quite simple with a central controller distributing the keys to all the nodes in the network along with the other information. This also seems to be one of the thoughts behind not pursuing an automated key management protocol for IGPs (something that we were supposed to take up as part of the Phase 2 in the KARP WG -- you can look at RFC 6518 for more details).

Given this I would like to continue with what we have and look at other mechanisms once we have more clarity on the direction which we seem to be heading towards.

Also finally note that this security is always within a providers network -- there isnt a need to involve different organizations.

> • Managing the 32-bit SAID manually in a large network is extremely
> onerous. So in practice keys would be rarely on never changed.

Ok, so whats the point?

> 
> • 2.2: the authentication algorithm and the authentication key are not
> "independent", because the algorithm normally determines the key
> length.

This is nit-picking and sure we can remove the word "independent". When defining the Authentication Key we do mention that it depends on the algo.

Authentication Key

      This value denotes the cryptographic authentication key associated
      with the LDP SA.  The length of this key is variable and depends
      upon the authentication algorithm specified by the LDP SA.

> 
> • 2.2: the various time values included in the SA essentially require
> (rough) time synchronization between the nodes. If this is the case,
> time values could have been used for replay protection, which would
> have
> been much simpler to implement than the 64-bit sequence number which
> needs to persist across reboots.

The various timers are only associated if somebody wants to rollover the keys. The granularity of these timers can be coarse (implementation specific) and will not be secure enough to use for anti replay protection.

Moreover, without the 64 bit sequence numbers, its very difficult to protect against inter-session replay attacks (RFC 6862)

> 
> • 5.1: Redefining HMAC (RFC 2104) is an extremely bad idea. This
> reviewer does not have the appropriate background to critique the
> proposed solution, but there must be an overwhelming reason to reopen
> cryptographic primitives.

This is a decision that was taken by Sec Ads when we were doing the crypto protection for the IGPs based on some feedback from NIST. This mathematics is not new and has been done for all IGPs and has been approved and rather encouraged by the Security ADs.

> 
> • 7: 128-bit keys are OK (or overkill) for some algorithms, but too
> short for others. In general, the recommended key length is not
> constant. It depends on the algorithm.

This needs to be punched on each router console. For an internal network, do you think 128 bit isnt good enough?
> 
> • "The mechanism described herein is not perfect and does not need to
> be
> perfect." This is kind of vague, and would be better replaced by your
> security goals.

I think we can just delete this! :-)

Cheers, Manav

> 
> Thanks,
> 	Yaron