Subject: Re: [OSPF] WG Last Call (EXTENDED) for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trailer-ospfv3-04.txt

From: Abhay Roy <[email-masked]>
Date: Tue, 10 May 2011 09:09:49 -0700

Working Group last call has ended. We got a couple of editorial comments 
which authors have already agreed to change in the next revision..

Regards,
-Abhay

On 4/27/11 8:54 AM, Abhay Roy wrote:
> There has been much discussion on the list, and one significant change 
> was made to -03 version. Cryptographic Sequence Number has changed 
> from 32 bit to 64 bits.
>
> We would like to extend the Last Call till 5pm PST, May 9th 2011.
>
> Please review the changes from 03 -> 04 version. Diff can be found here:
>
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-ospf-auth-trailer-ospfv3-04.txt
>
> -Abhay/Acee
>
>
>
> On 4/11/11 9:19 AM, Abhay Roy wrote:
>> We are starting the Working Group Last Call of this revision of the 
>> subject draft.
>>
>> This drafts is intended to be a Proposed Standard. The OSPF WG last call
>> will begin today and will end at 5pm PST,  April 25th, 2011.
>>
>> Abhay/Acee
>>
>> -------- Original Message --------
>> Subject: 	I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt
>> Date: 	Sat, 19 Feb 2011 12:00:02 -0800
>> From: 	[email-masked]
>> Reply-To: 	[email-masked]
>> To: 	[email-masked]
>> CC: 	[email-masked]
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF.
>>
>>
>> 	Title           : Supporting Authentication Trailer for OSPFv3
>> 	Author(s)       : M. Bhatia, et al.
>> 	Filename        : draft-ietf-ospf-auth-trailer-ospfv3-03.txt
>> 	Pages           : 20
>> 	Date            : 2011-02-19
>>
>> Currently OSPFv3 uses IPsec for authenticating protocol packets.
>> However, there are some environments, e.g., Mobile Ad-hoc Networks
>> (MANETs), where IPsec is difficult to configure and maintain, and
>> this mechanism cannot be used.  This draft proposes an alternative
>> mechanism that can be used so that OSPFv3 does not depend upon IPsec
>> for authentication.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-auth-trailer-ospfv3-03.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>    
>
>
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 May 2011 12:44:37 -0400

All,

We've posted http://www.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-05.txt containing updates for all the WG last call comments.

Editorial Comments.

  1. Comment from Acee: Clarify that Apad is only placed in the variable authentication data portion of the Authentication Trailer (AT) during the message digest calculation.
  2. Comment from Alan Davey: Clarify that the Authentication Trailer length includes the length of the entire AT (not just the variable data).
  3. Comment from Acee: Consistently use "octets" rather than a combination of "octets" and "bytes".

Functional Comment:

  1. Comment from Uma Chunduri: Protect IPv6 source address in message digest calculation.
     The associated changes are the addition of section 2.3:

2.3.  IPv6 Source Address Protection

   While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors,
   the IPv6 source address is learned from OSPFv3 hello packets and
   copied into the neighbor data structure [RFC5340].  Hence, OSPFv3 is
   susceptible to Man-in-the-Middle attacks where the IPv6 source
   address has been modified.  To thwart such attacks, the IPv6 source
   address will be included in the message digest calculation and
   protected by OSPFv3 authentication.  Refer to Section 4.4 for
   details.  This is different than the procedure specified in [RFC5709]
   but consistent with [I-D.ietf-ospf-security-extension-manual-keying].

  And, the update of the definition of Apad in section 4.4:

   Apad is a value which is the same length as the hash output or
   message digest.  The first 16 octets contain the IPv6 source address
   followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times.
   This implies that hash output is always a length of at least 16
   octets.

We'd appreciate feedback on the updated draft.

Thanks,
Acee, Manav, and Vishwas

On May 10, 2011, at 12:09 PM, Abhay Roy wrote:

Working Group last call has ended. We got a couple of editorial comments which authors have already agreed to change in the next revision..

Regards,
-Abhay

On 4/27/11 8:54 AM, Abhay Roy wrote:
There has been much discussion on the list, and one significant change was made to -03 version. Cryptographic Sequence Number has changed from 32 bit to 64 bits.

-Abhay/Acee

On 4/11/11 9:19 AM, Abhay Roy wrote:
We are starting the Working Group Last Call of this revision of the subject draft.

Abhay/Acee

-------- Original Message --------
Subject:        I-D Action:draft-ietf-ospf-auth-trailer-ospfv3-03.txt
Date:   Sat, 19 Feb 2011 12:00:02 -0800
From:   [email-masked]<mailto:[email-masked]>
Reply-To:       [email-masked]<mailto:[email-masked]>
To:     [email-masked]<mailto:[email-masked]>
CC:     [email-masked]<mailto:[email-masked]>

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf