Skip to main content

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