Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-nhdp-olsrv2-sec-05
Yes
(Adrian Farrel)
No Objection
(Jari Arkko)
(Richard Barnes)
Note: This ballot was opened for revision 03 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-08-12 for -03)
Unknown
I agree with Brian's comment: given that olsrv2 already has a reference to this document, the "updates" metadata is entirely unnecessary.
Brian Haberman Former IESG member
No Objection
No Objection
(2013-08-12 for -03)
Unknown
I fully support the publication of this document, but I am a little confused by its relationship with draft-ietf-manet-olsrv2. The base OLSRv2 spec references OLSRv2-sec and says it SHOULD be used. It is unclear why OSLRv2-sec is UPDATING draft-ietf-manet-olsrv2 given this forward reference.
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-08-12 for -03)
Unknown
Seems like the opportunity for replay attacks is particularly acute around startup/bootstrapping.
Pete Resnick Former IESG member
No Objection
No Objection
(2013-08-14 for -03)
Unknown
- Agree with Barry and Brian that this document does not update OLSRv2. That document already requires the use of this document. No change, no update. - Section 3, third bullet: I suggest changing "but MAY use different algorithms if more appropriate" to "except when use of a different algorithm is more appropriate". The mixture of the MAY and the prior SHOULD is wrong. Additionally, strike "also" from the next sentence. - Section 4, second bullet: I think it's worth changing "but not with" to "but MUST NOT use". That's an important interoperability point. - Section 6.1: I suggest changing, "In addition, in order to conform to this framework, each message MUST contain:" to "In addition, messages that conform to this framework will contain:". I don't see how the MUST is calling something useful to the attention of the implementer.
Richard Barnes Former IESG member
No Objection
No Objection
(for -04)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-08-14)
Unknown
s1: Is the 1st paragraph all about explaining what mandatory to implement means? I also don't think it's a framework it's a mechanism (as mentioned in the 2nd paragraph). Maybe the first paragraph could be amended as follows: This specification updates [RFC6130] and [OLSRv2] by defining the mandatory to implement security mechanisms (for integrity and replay protection). A deployment of these protocols may choose to employ alternative(s) to these mechanisms, in particular it may choose to protect packets rather than messages, it may choose to use an alternative integrity check value (ICV) with preferred properties, and/or it may use an alternative timestamp. A deployment may choose to use no such security mechanisms, but this is not recommended. s3: r/specifies a security framework/Specifies a security mechanism X2 actually I'd just replace framework with mechanism everywhere. s3: I think this is really a MUST here no? And, it's a MUST implement not should use? Deployments of [RFC6130] and [OLSRv2] using this framework MUST support a SHA-256 based HMAC ICV TLV. s3: ditto on the timestamp: Deployments of [RFC6130] and [OLSRv2] MUST support the POSIX time based timestamp, if the clocks in all routers in the network can be synchronized with sufficient precision. s4: This is a bit pedantic, but if an implementation doesn't include this specification doesn't mean that it will be ignored - isn't it that if the HMAC mechanism is used then it will be ignored ... Note that this means that routers whose implementation of NHDP and/or OLSRv2 does not include this specification will be ignored by routers using this framework, and these two sets of routers will, by design, form disjoint MANETs. s6.1: I think this a little bit confusing like in s3 (as noted by Pete): MUST support the following version of the ICV TLV, but other versions MAY be used instead, or in addition, in a deployment, if more appropriate: s9.1: r/alleviated/mitigated?
Spencer Dawkins Former IESG member
(was Discuss)
No Objection
No Objection
(2013-08-12 for -03)
Unknown
Thank you for helping me work through my Discuss, and best wishes. (inserting Ulrich's response for reference) > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm more than half-expecting this Discuss to be resolved by educating the > non-RTG AD This is what am I trying to do in this email > > I'm not familiar with MANET protocols beyond the handwaving level, but I > took a quick look at > http://tools.ietf.org/html/draft-ietf-manet-olsrv2-19, and thought I > understood that this protocol was using either IP or UDP for transport. > > I think I'm seeing in Section 6.2. "Message Generation" that integrity > protection is adding TLVs. > > I'm looking at this text: > > 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to > the Message TLV Block. The message size and Message TLV block > size are updated accordingly. > > 4. A TLV of type ICV, as specified in Section 6.1, is added to the > Message TLV Block. The message size and Message TLV block size > are updated accordingly. > > 5. All ICV TLVs that were temporary removed in step 1, are restored. > The message size and Message TLV Block size are updated > accordingly. > > Am I understanding that the message is getting longer as you add TLVs? > > If so, is it possible for IP fragmentation to occur as a result of adding > TLVs? We are considering here messages that are created within the framework of RFC 5444, that ultimately produces packets that are passed (usually via UDP) to IP. The only fragmentation possibility is at the IP level. An implementation of the RFC 5444 multiplexing process that puts messages together in packets is likely to be constrained so as to not unnecessarily create over-long packets that need fragmentation. (That is not actually a requirement, but the multiplexer has a free hand, and that is how a sensible implementation would behave.) That therefore means that the issue can be reduced to one of overlong messages. So to answer your question, yes, adding such TLVs increases the length slightly, and therefore makes handing a message that forces fragmentation to the RFC 5444 multiplexer more likely. But not much more likely. In practice this is not actually an issue because OLSRv2 messages are much shorter than any fragmentation limit. Messages under a hundred octets are common. To get a message of even several hundred octets requires very large, very dense networks, because the size of the messages is dictated by how many neighbors a router has. Having a hundred neighbors would leave you under an expected fragmentation limit, and a hundred neighboring routers is fantastically high. If it really is an issue, then NHDP and OLSRv2 have mechanisms for so-called "incomplete" (i.e., incremental) messages that can handle this. Best regards Ulrich
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-08-14 for -03)
Unknown
- intro: does figure 1 imply that an outbound message for which no good key exists is supposed to be dropped? It does give that impression. If that's not intended then maybe move the "(failed check)" arrow to the right hand side of the figure? - Section 3 almost but not quite says that HMAC-SHA-256 is MTI (mandatory to implement). I think you mean that it is, but it'd be better to be clear about it here. (Section 4 does say HMAC-SHA-256 verification is MTI though, so this is a nit unless you think someone might only implement checking and not generation of ICVs.) - Section 3 says that all ICVs MUST use a different algorithm. That seems a bit wrong, I think you mean that a different algorithm or key MUST be used - otherwise how could you handle different nodes that have different keys but all implementing HMAC-SAH-256? (The same phrase is used in section 4, so that might be two tweaks needed.) - The secdir review [1] notes that the granulatity of the timestamp is one second. I think that's a good point - is that really ok for MANETs? Even if so, I think you should mention it. - section 9.2: I do recall that we discussed this a good bit, in particular why bcp107's AKM requirements don't apply here. Text justfiying that is in oslrv2, section 23.6 so I'd say a pointer from the end of section 9 to that text would be good. - For completeness, I do agree that this spec is ok to not include AKM on the basis justified in oslrv2 so I'm not balloting DISCUSS for that this time, since we handled that before (see above) even though the secdir reviewer also quite understandably raised the point. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04123.html