Last Call Review of draft-ietf-mpls-ldp-hello-crypto-auth-05
review-ietf-mpls-ldp-hello-crypto-auth-05-secdir-lc-sheffer-2014-05-22-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document proposes to add cryptographic authentication to LDP "all
routers" Hello messages, which are transported as unicast UDP.

Summary

The document may be ready to publish, but this reviewer has major
issues with the selected solution.

Details

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


• Managing the 32-bit SAID manually in a large network is extremely 


onerous. So in practice keys would be rarely on never changed.




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

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






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

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

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

Thanks,
	Yaron