[secdir] secdir review of draft-ietf-rift-rift-04

["Scott G. Kelly" <[e-mail]>]

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.