Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-nhdp-olsrv2-sec-05

[Ballot discuss]
This one ought to be pretty straightforward:

s9.1.1: If all the routers are sharing the same key, then all you know is that it's a valid router in the network not that it's a particular router?  I think that needs to be a bit clearer in s9.1.1.

[Ballot comment]
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?

[Ballot comment]
- 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.

[Ballot comment]

- 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

[Ballot comment]
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

[Ballot comment]
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.

[Ballot discuss]
I'm more than half-expecting this Discuss to be resolved by educating the non-RTG AD :-)

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?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-manet-nhdp-olsrv2-sec-03, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no
IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Integrity Protection for Control Messages in NHDP and OLSRv2) to Proposed Standard


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Integrity Protection for Control Messages in NHDP and OLSRv2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document specifies integrity and replay protection for the MANET
  Neighborhood Discovery Protocol (NHDP) and the Optimized Link State
  Routing Protocol version 2 (OLSRv2).  This protection is achieved by
  using an HMAC-SHA-256 Integrity Check Value (ICV) TLV and a timestamp
  TLV based on POSIX time.

  The mechanism in this specification can also be used for other
  protocols that use the generalized packet/message format described in
  RFC 5444.

  This document updates RFC 6130 and RFC xxxx by mandating the
  implementation of this integrity and replay protection in NHDP and
  OLSRv2.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-olsrv2-sec/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review
======
Hi Authors,

Thanks for this small but important addition to NHDP and OLSRv2. I
found the document pretty clear and have only one technical issue with
it.  The bunch of editorial comments below can be taken under
advisement, but I think that fixing them will make the document more
readable and will ease its passage through the next stages.

If you can turn around a new revision (or tell me that none of my
suggestions needs to be adopted) then I can kick of the IETF last call.

Thanks for the work,
Adrian

---

Technical issue...

I understand that this document specifies mandatory rules for NHDP (and
OLSRv2) and your use of "updates" is correct.  However, there are
obviously existing implementations of NHDP that are deployed.

I am searching for the backward compatibility description. An existing
implementation of NHDP may now receive messages containing the ICV or
timestamp TLVs.  But these will not be used by the legacy implementation
because they are unknown TLVs. 

How will they be processed by the legacy implementation? I think this
needs just a single statement and a pointer to the correct rule in 6130.

How will the way that a legacy implementation behaves change the
perception of security that the sender has?  This obviously depends on
the answer to the previous question, and can hopefully be stated very
briefly.

---

I think that this document will also update [OLSRv2] when it is
published as an RFC (even if that is simultaneous). Therefore, I
recommend to top the document with...

[RFC Editor note: Please replace "xxxx" throughout this document with
the RFC number assigned to [OLSRv2], and remove this note.]

Noting that the citation will be fixed by the RFC Editor in any case.

---

The line in the document header should read
"Updates: 6130, xxxx (if approved)"

---

The Abstract should mention
"This document updates RFC 6130 and RFC xxxx."

Additionally, I found the Abstract quite dense. Can I suggest some
re-wording.

OLD
  This document specifies integrity and replay protection for required
  implementation in the MANET Neighborhood Discovery Protocol (NHDP)
  and the Optimized Link State Routing Protocol version 2 (OLSRv2).
  This document specifies how an included integrity check value (ICV)
  and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
  OLSRv2 for countering a number of security threats.  The ICV TLV uses
  a SHA-256 based HMAC and one or more shared secret keys.  The
  timestamp TLV is based on POSIX time, and assumes that the clocks in
  all routers in the network can be synchronized with sufficient
  precision.  The mechanism in this specification can also be used for
  other MANET protocols using RFC5444.
NEW
  This document specifies integrity and replay protection for the MANET
  Neighborhood Discovery Protocol (NHDP) and the Optimized Link State
  Routing Protocol version 2 (OLSRv2).  This protection is achieved by
  using the Integrity Check value (ICV) and the Timestamp TLV.
 
  The mechanism in this specification can also be used for protocols
  that use the generalized packet/message format described in RFC 5444.

  This document updates RFC 6130 and RFC xxxx by mandating the
  implementation of integrity and replay protection in NHDP and OLSRv2.
END

---

The Introduction should also say something like:

  This document updates [RFC6130] and [OLSRv2] by mandating the
  implementation of integrity and replay protection in NHDP and OLSRv2.

---

In the Introduction, I had to read the following paragraph several times
and look at the figure in order to work out what you meant. At that point
it was obvious, but can I suggest re-wording:

OLD
  The mechanism specified in this document exists between NHDP's and
  OLSRv2's message processing/generation and the [RFC5444] packet
  parsing/generation, as illustrated in Figure 1.
NEW
  The mechanism specified in this document is placed in the packet-
  processing flow as indicated in Figure 1.  It exists between the
  packet parsing/generation function of [RFC5444], and the message
  processing/generation function of NHDP and OSLRv2.
END

---

Section 3

I found the following hard:
  o  Specifies an association of ICVs with messages, and for using
      missing or invalid ICVs as such an additional reason for rejecting
      a message as "badly formed and therefore invalid for processing".

How about:
  o  Specifies an association of ICVs with protocol messages, and
      specifies how to use a missing or invalid ICV as an reason to
      reject a message as "badly formed and therefore invalid for
      processing".

---

Section 3

  o  Specifies the implementation of an ICV Message TLV, defined in
      [RFC6622bis], using a SHA-256 based HMAC applied to the
      appropriate message contents (and for HELLO messages also
      including the IP datagram source address).  Deployments of
      [RFC6130] and [OLSRv2] using this framework should use an HMAC/
      SHA-256 ICV TLV, but may use different algorithms if more
      appropriate in a deployment.  An implementation may also use more
      than one ICV TLV in a message, as long as they each use a
      different algorithm to calculate the ICV.

There is a "should" and two "may"s in this text. Given the use of 2119
language higher up the section and in the next bullet, I wondered
whether you wanted this in 2119-speak as well.

---

I think the RFC Editor would ask you for help determining the
consistency of case in "timestamp TLV" and "TIMESTAMP TLV".  Can you
check you are happy with what you have.

---

The last sentence of Section 4 says:

  This framework specifies that a
  message MUST be rejected if the ICV Message TLV is absent, or its
  value cannot be verified.

This is equivalent to saying that a sender MUST include an ICV Message
TLV in every message it sends. Initially, it seemed to me that this
contradicted the statements about optional use in deployments: e.g.
(from the introduction),
 
  A deployment may choose
  to use no such security mechanisms, but this is not recommended.


So I think that what you are saying is actually:

  This framework specifies that an implementation conforming to this
  specification and with security enabled, MUST reject a received
  message if the ICV Message TLV is absent, or its value cannot be
  verified.

---

Section 5

When you say "silently discarded" do you intend to preclude raising an
alert or incrementing a count? It seems likely that over-age messages
are indicative of something (like a replay attack, or an echo, or long
delays, or a misconfigured constant) and some log of the fact might be
useful. The usual way to handle this is "An implementation MAY log or
count such events, but SHOULD be careful to avoid logging storms caused
by a replay attack."

---

Section 5

  However it should also be noted that, in
  the ideal case, the parameters SHOULD be significantly less than
  those bounds.

Some smart-arse on the IESG is going to ask what "significantly" means.
Is there any way you can quantify this: e.g., 27.5%

---

Section 7

Should this section also note that routers should be able to be
configured to use (or not use) the mechanisms described in this
document, and that implementations should make use of these mechanisms
the default?

---

Section 9.1.2

Will the readership know what is meant by Link Spoofing or should you
give a reference?

(1) The request is to publish this document as a Standards Track RFC,
and this is indicated in the document header.

(2) Document Announcement Write-Up.

Technical Summary

The abstract of this document is included below.

This document specifies integrity and replay protection for required implementation in the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This document specifies how an included integrity check value (ICV) and a timestamp TLV, defined in RFC6622bis, are used by NHDP and OLSRv2 for countering a number of security threats.  The ICV TLV uses a SHA-256 based HMAC and one or more shared secret keys.  The timestamp TLV is based on POSIX time, and assumes that the clocks in all routers in the network can be synchronized with sufficient precision.  The mechanism in this specification can also be used for other MANET protocols using RFC5444.


Working Group Summary

Working group consensus behind the document is observed as strong. There are numerous authors and contributors that feel this document is ready to proceed.


Document Quality

The document has received careful review. There are several implementations of the document.

Personnel

The Document Shepherd is Joseph Macker (jpmacker@gmail.com); the
responsible Area Directors are Adrian Farrel and Stewart Bryant.

(3) The document Shepherd has participated in review both in the Working
Group, and has run the "idnits" tool against the draft.

(4) The Document Shepherd has no concerns about the reviews of the
document; they have been thorough.

(5) The authors do not believe that additional reviews are required,
aside from the usual directorate reviews during IETF last call.

(6) The Document Shepherd has no concerns with the document.

(7) All authors have confirmed that they are unaware of any IPR needing
disclosure; there are no known IPR claims related to this document.

(8) No IPR disclosures have been filed, as none are required.

(9) WG consensus appears to be strong.

(10) Nobody has threatened an appeal or otherwise indicated extreme discontent.

(11) There is one minor nit:

  == The 'Updates: ' line in the draft header should list only the _numbers_
    of the RFCs which will be updated by this document (if approved); it
    should not include the word 'RFC' in the list.
   
    This will be corrected in the next revision of the draft (together with changes as consequence of AD review, directorate reviews, IETF LC etc.).

(12) MIB Doctor, media type, and URI reviews are not required.

(13) There are only normative references.

(14) Of the normative references, two drafts are not yet RFCs:
      i) draft-ietf-manet-olsrv2 is waiting in the RFC editor queue for this document and for draft-ietf-manet-rfc6622-bis
      ii) draft-ietf-manet-rfc6622-bis, which has already passed WG LC without objections from the WG, and which is currently proceeding to AD review.
     
(15) There are no downward normative references in the document.

(16) Publication of this document will not change the status of any existing RFCs.

(17) This document has no actions for IANA.

(18) There is no impact on IANA registries.

(19) There are no sections written in a formal language, such as XML code, BNF rules, MIB definitions, etc.