Early Review of draft-ietf-rift-rift-04
review-ietf-rift-rift-04-secdir-early-kelly-2019-04-11-00
Request | Review of | draft-ietf-rift-rift-04 |
---|---|---|
Requested revision | 04 (document currently at 24) | |
Type | Early Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2019-03-22 | |
Requested | 2019-03-03 | |
Requested by | Jeff Tantsura | |
Authors | Tony Przygienda , Jordan Head , Alankar Sharma , Pascal Thubert , Bruno Rijsman , Dmitry Afanasiev | |
I-D last updated | 2019-04-11 | |
Completed reviews |
Intdir Telechat review of -21
by Dave Thaler
(diff)
Rtgdir Last Call review of -20 by Loa Andersson (diff) Secdir Early review of -04 by Scott G. Kelly (diff) Rtgdir Early review of -06 by Russ White (diff) Genart Early review of -08 by Robert Sparks (diff) Secdir Early review of -08 by Scott G. Kelly (diff) Opsdir Early review of -08 by Nagendra Kumar Nainar (diff) Rtgdir Early review of -08 by Jonathan Hardwick (diff) |
|
Comments |
This is to request an early review. RIFT is an entirely new protocol, designed from scratch, I assume we will have many iterations to get it to the level that would make security folks happy. Thanks! |
|
Assignment | Reviewer | Scott G. Kelly |
State | Completed | |
Request | Early review on draft-ietf-rift-rift by Security Area Directorate Assigned | |
Reviewed revision | 04 (document currently at 24) | |
Result | Has issues | |
Completed | 2019-04-11 |
review-ietf-rift-rift-04-secdir-early-kelly-2019-04-11-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. The summary of the review is ready with issues From the abstract, this document outlines a specialized, dynamic routing protocol for Clos and fat-tree network topologies. (should that read CLOS?) Following is a brief summary of comments and questions by section. 5.4.1 includes this sentence: The most security conscious operators will want to have full control over which port on which router/switch is connected to the respective port on the "other side", which we will call the "port-association model" (PAM) achievable e.g. by pairwise-key PKI. What is "pairwise-key PKI"? Secion 5.4.2 says "Low processing overhead and efficiency messaging are also a goal." I suggest replacing efficiency with efficient It also says "Message privacy achieved through full encryption is a non-goal" I suggest saying "Message confidentiality is a non-goal" instead. Section 5.4.3 "Length of Fingerprint: 8 bits. Length in 32-bit multiples of the following fingerprint not including lifetime or nonces. It allows to navigate the structure when an unknown key type is present. To clarify a common cornercase a fingerprint with length of 0 bits is presenting this field with value of 0." Does length 0 mean no fingerprint is present (i.e. fingerprints are not provided)? I don't understand that last sentence. The definition for "Security Fingerprint" includes this sentence: "If the fingerprint is shorter than the significant bits are left aligned and remaining bits are set to 0." I don't understand this sentence. I think you mean that if the fingerprint bit length is not an even multiple of 32, then it is left-aligned, and the rightmost unused bits are set to 0. But that's just a guess. 5.4.4 "Any implementation including RIFT security MUST generate and wrap around local nonces properly" I see the term "nonce" used elsewhere, but because it can wrap (and therefore repeat with regularity), I think this is a poor choice for naming this field. It seems to be more of a counter. I think most security folks would agree that a nonce used for security purposes should, by definition, repeat only with negligible probability. On a related note, does this really provide anti-replay protection? Elsewhere in the document (e.g. section 5.4.4) it says that implementations could go up to 5 minutes without incrementing nonces. Can they send multiple packets with the same nonce during this interval? If so, what prevents replay of a captured packet within that interval? Also, because wrapping (of this 16 bit value) is supported, it's also possible that an earlier packet could be replayed (assuming the peer nonce also aligned), right? The odds of this seem low, but could the protocol/endpoint states be manipulated to improve the odds? Not sure. But if you are assuming this can't happen, this security-relevant assumption should be called out. 5.4.7 says "If an implementation supports disabling the security envelope requirements while sending a security envelope an implementation could shut down the security envelope procedures while maintaining an adjacency and make changes to the algorithms on both sides then re enable the security envelope procedures but that introduces security holes during the disabled period." Aside from the fact that this needs word-smithing, should this be called out in the security considerations section? This eeems to be saying that it's not a good idea to temporarily maintain adjacency while disabling security, so is this a SHOULD NOT? section 8.4 flodding -> flooding section 8.4 also says It is expected that an implementation detecting too many fake losses or misorderings due to the attack on the number would simply suppress its further processing. what are "fake losses"? I am not a routing expert, so there may be additional concerns that someone better versed in routing would raise.