Subject: [manet] Security documents for OLSRv2/NHDP

From: Ulrich Herberg <[email-masked]>
Date: Fri, 15 Mar 2013 13:51:11 -0400

Dear all,

The OLSRv2 authors have had a discussion with Stephen Farrell (Security AD)
and Adrian about how to resolve the remaining security related DISCUSS
on OLSRv2, and we agreed on a way forward that involves the following
steps:

1) Publication of:
http://tools.ietf.org/html/draft-herberg-manet-nhdp-olsrv2-sec-01

This document mandates (at least) implementation of HMAC/SHA2
integrity protection of OLSRv2 messages. Deployments of OLSRv2 should
use that mechanism unless they have a more appropriate solution (e.g.,
different cipher) for that particular deployment. This document also
updates NHDP and mandates to implement the same HMAC/SHA2 protection
for HELLO messages.

2) Publication of:
http://tools.ietf.org/html/draft-herberg-manet-rfc6622-bis-01

This document obsoletes RFC6622bis by fixing an oversight in RFC6622.
The differences are minor to RFC6622 and can be seen here:
http://tools.ietf.org/rfcdiff?url1=rfc6622&url2=draft-herberg-manet-rfc6622-bis
Essentially, RFC6622 does not protect the IP source address of the
interface over which the control message is sent. Since that address
is used to establish neighbors in NHDP (and therefore must be
protected), a new type extension 3 of the ICV TLV has been added to
the registry.

3) Publication of an update to OLSRv2, referencing the use of the
defined security mechanism, and resolving other smaller issues from
Stephen's DISCUSS.

In order to not hold up OLSRv2 further, and upon discussions with Stan
and Adrian, we would like to request WG adoption of these two new
documents - asking that the chairs will officially poll the WG on this
matter shortly. The documents are brief, and addresses issues
requested by the ADs, so we hope that processing them should also be a
brief affair.

Best regards
Ulrich

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 15 Mar 2013 19:04:14 +0000

Ulrich, 

Thanks for this email. OK, Working Group participants: Consider this a 1-week poll for adoption of these docs as WG documents. Polling period ends March 22. And, silence will be deemed to be agreement that the documents *should be* accepted as WG docs. 

Regards,
Stan

On Mar 15, 2013, at 1:51 PM, Ulrich Herberg wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 15 Mar 2013 22:09:03 +0100

Hi Ulrich,

Do I understand that publication 1 updates both RFC6130 and OLSRv2, or
do you mean only updates RFC6130,

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 15 Mar 2013 21:19:45 +0000

OLSRv2 will reference this draft, and therefore it's not an update in the technical sense in which the term is being used here, as a formal update to RFC 6130.

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 16 Mar 2013 21:53:53 +0100

I agreed to update of RFC6130 and have no objection of others, but
want to discuss/ask.

If IESG-DISCUSS was about OLSRv2 document why the process was to
update RFC6130 only? and if publication 1 mandates OLSRv2 messages,
then IMO it needs to update OLSRv2 document as well, or do you mean
the publication-3 is a new version -18 that includes the security of
OLSRv2 messaging and refers to publication-1.

AB

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This message is owned by the author and sent to IETF MANET address and
not sent to private mail-boxes. This message is an IETF input not
private input.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On 3/15/13, Christopher Dearlove <[email-masked]> wrote:
> OLSRv2 will reference this draft, and therefore it's not an update in the
> technical sense in which the term is being used here, as a formal update to
> RFC 6130.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 16 Mar 2013 22:42:49 -0000

Yes, I believe the plan is to add more security text to the OLSRv2 draft. The
choice of words is confusing :-)
"Update" has a general meaning: to update a draft means to make some revisions.
"Update" has a specific meaning: to update an RFC means to add a meta-data tag
formally noting that one RFC updates another.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Abdussalam Baryun
> Sent: 16 March 2013 20:54
> To: manet
> Subject: Re: [manet] Security documents for OLSRv2/NHDP
>

---

From: Ulrich Herberg <[email-masked]>
Date: Sat, 16 Mar 2013 19:46:44 -0400

AB,

we specified a integrity and replay security protection for OLSRv2, as
requested by Stephen. We could have added that directly in OLSRv2, but
since NHDP uses the same security mechanism, that would have been a
copy of the same text. So we decided to specify the mechanism in a new
draft, which is normatively referenced by OLSRv2, e.g.:
"A conformant implementation of OLSRv2 MUST, at minimum, implement the
security mechanisms specified in [draft-herberg-manet-nhdp-olsrv2-sec]
..."
At the same time this new draft "updates" (in the IETF sense) NHDP by
mandating to implement the security mechanism.

The new OLSRv2 revision (as well as new revisions of the two security
drafts) will be submitted in the next few days, we are just doing
final reviews amongst the authors.

Best regards
Ulrich

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sun, 17 Mar 2013 03:53:54 +0000

Ulrich, 

Just to be clear: Since the plan is to add a normative reference to OLSRv2, it (meaning the OLSRv2 draft) will be held up, pending WG adoption/acceptance/WGLC of this new draft…

(Taking my co-chair hat off, and speaking just as a WG participant): 
I would have preferred inserting the text directly into OLSRv2 (and NHDP if need be) instead of creating the normative reference. I think this is a tad late in the game to be doing such a thing. 

Regards,
Stan

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 17 Mar 2013 08:13:01 +0000

As Ulrich said, done that way we end up repeating a whole lot of text in both documents, which really isn't sensible, and introduces an editorial issue of keeping the two aligned. Putting it all together gives a much more coherent presentation.

As for late in the day, we worked on the assumption that what was good enough for NHDP was good enough for OLSRv2. We were, as you know, working towards security in the WG. However in effect a new security AD had a different view to an old security AD, that something had to be done now, before OLSRv2 was published, and held a DISCUSS accordingly. And as OLSRv2 security depends on NHDP security that needed doing too.

No one wants everything finished as soon as soon as possible more than I and the other authors do. But we are here, and doing the best we can.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 18 Mar 2013 11:41:38 +0000

The new versions are now submitted. OLSRv2 security (integrity) is at -02, RFC6622bis is at -02 and OLSRv2 is at -18.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ulrich Herberg
Sent: 16 March 2013 23:47
To: [email-masked]
Cc: manet
Subject: Re: [manet] Security documents for OLSRv2/NHDP

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

AB,

Best regards
Ulrich

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sat, 23 Mar 2013 18:57:36 +0000

WG Participants:

The polling period has passed, *without* negative opinions on accepting the documents as WG documents. Therefore, they have been submitted via the data-tracker, and you should get email on their posting. 

Regards,
Stan

---

From: Christopher Dearlove <[email-masked]>
Date: Sat, 23 Mar 2013 19:04:55 +0000

Thanks, Stan.

---

From: Ulrich Herberg <[email-masked]>
Date: Sat, 23 Mar 2013 17:19:30 -0700

Dear all,

as you have seen, we have submitted the two documents as WG documents (with
the same contents as the individual counterparts), and we have updated them
to a -01 revision.

Brief summary of changes (besides editorial changes) from -00 to -01:
1) nhdp-olsrv2-sec:
   - Stephen Farrell has caught one oversight in the OLSRv-18, which is
that we talk about "one single shared secret key" that is used in the
default use case of integrity and replay protection. As he pointed out,
there could be a small number of N shared keys that are all pre-deployed.
Using RFC6622-bis, it is straight-forward to select the index of the key
that is used within the MANET.
This led to a minimal update of both OLSRv2 and nhdp-olsrv2-sec

2) RFC6622-bis:
  - Stephen suggested to normatively cite this document from OLSRv2 (it is
already transitively cited via nhdp-olsrv2-sec anyway).
  - We added one subsection "changes to RFC6622" that describes the
differences to RFC6622

The authors believe that the two security documents are stable. Note in
particular that
   (i) nhdp-olsrv2-sec is the same mechanism that has been discussed in
draft-ietf-manet-nhdp-sec, just applied to both OLSRv2 and NHDP (and
updating RFC6130). nhdp-sec has been in the WG for a long time.
   (ii) RFC6622-bis has the same specification as RFC6622 with the
exception of one additional type extension for the ICV TLV that has the
same TLV value structure, but includes the IP source address of the IP
datagram, when calculating the ICV.
  (iii) OLSRv2-19 has normative references to both security documents; it
will not be published as RFC as long as these two documents are not
finished.

Therefore, I hope that we can initiate a first WG LC on both security
documents very soon.

Thanks
Ulrich

On Sat, Mar 23, 2013 at 12:04 PM, Christopher Dearlove <
[email-masked]> wrote:

> > The polling period has passed, *without* negative opinions on accepting
> the documents as WG documents. Therefore, they have been submitted via the
> data-tracker, and you should get email on their posting.
> >
> > Regards,
> > Stan
> >
> >> Thanks for this email. OK, Working Group participants: Consider this a
> 1-week poll for adoption of these docs as WG documents. Polling period ends
> March 22. And, silence will be deemed to be agreement that the documents
> *should be* accepted as WG docs.
> >>
> >> Regards,
> >> Stan
> >>

---

From: Henning Rogge <[email-masked]>
Date: Sun, 24 Mar 2013 05:33:36 +0100

Just to state it,

using timestamps and synchronized clocks in Mesh networks can be a real mess.

We did it a couple of years ago when using SNMPv3 and it gave us all
kinds of headaches. But maybe the ubiquitous presence of GPS (and with
this a global clock) can help.

Including a 32 byte checksum into each OLSRv2 message is something
between overkill and insanity. I hope people keep in mind that you can
get a similar protection by using linklayer based security on the mesh
interface (WPA2 for example).

Henning Rogge

On Sun, Mar 24, 2013 at 1:19 AM, Ulrich Herberg <[email-masked]> wrote:
>    - Stephen Farrell has caught one oversight in the OLSRv-18, which is that
> we talk about "one single shared secret key" that is used in the default use
> case of integrity and replay protection. As he pointed out, there could be a
> small number of N shared keys that are all pre-deployed. Using RFC6622-bis,
> it is straight-forward to select the index of the key that is used within
> the MANET.
>    (ii) RFC6622-bis has the same specification as RFC6622 with the exception
> of one additional type extension for the ICV TLV that has the same TLV value
> structure, but includes the IP source address of the IP datagram, when
> calculating the ICV.
> On Sat, Mar 23, 2013 at 12:04 PM, Christopher Dearlove
> <[email-masked]> wrote:
>>
>> Thanks, Stan.
>>
>> --
>> Christopher Dearlove

-- 
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Henning Rogge <[email-masked]>
Date: Sun, 24 Mar 2013 10:05:39 +0100

On Sun, Mar 24, 2013 at 9:42 AM, Christopher Dearlove
<[email-masked]> wrote:
> We are of course not designing only to run over IEEE 802.11.

WPA2 was just an example. I think there are quite a few IP capable
radio technologies with their own linklayer encryption, both
commercial and military.

> But if you have appropriate link-layer security then you can use it instead, and still be fully compliant, because all the words about usage say you can do something else. You can even do nothing, but this is not recommended. However it became a security requirement to include something for when you do need it. (Our later security discussions were not "do you need authentication?", but "do you need automatic key management?" - hence the detailed argument why we don't.)

Maybe we should suggest opening "autoconf" again and increasing the
scope to manet key management? ;)
(No, this is not meant serious)

> Otherwise we'd still be blocked in the IESG.

I know...

> I'm also aware of potential cases where the question is not "is this too much?" but rather "is this enough?". So then the opposite of overkill, and definitely not insanity. And I think you need not to think of it as a checksum. This is not protection against accidental corruption (for which it would be overkill, I agree), this is protection against deliberate attack. And to get 128 bits of protection (close to the minimum for any serious use) you need something this size (256 bits).

I disagree with you on this point, but its not worth delaying the RFC
longer over this.

the "can implement something else that works better" rescues the
document in my opinion.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 24 Mar 2013 12:54:34 +0100

> Therefore, I hope that we can initiate a first WG LC on both security

Please give me chance to review and comment, I will need one month at
least but  two preferable, for the new documents,

AB