Re: [manet] Security documents for OLSRv2/NHDP

[Abdussalam Baryun <[e-mail]>]

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

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

AB

On 3/24/13, Ulrich Herberg <[e-mail]> wrote:
> 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 <
> [e-mail]> wrote:
>
>> Thanks, Stan.
>>
>> --
>> Christopher Dearlove
>> [e-mail] (iPhone)
>> [e-mail] (home)
>>
>> On 23 Mar 2013, at 18:57, "Stan Ratliff (sratliff)" <[e-mail]>
>> wrote:
>>
>> > 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
>> >
>> > On Mar 15, 2013, at 3:04 PM, Stan Ratliff (sratliff) wrote:
>> >
>> >> 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:
>> >>
>> >>> 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
>> >>> _______________________________________________
>> >>> manet mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/manet
>> >>
>> >> _______________________________________________
>> >> manet mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/manet
>> >
>> > _______________________________________________
>> > manet mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/manet
>>
>