Re: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call

Hi Alan,
The authors agree - in the next revision, the Auth Data Length will include the length of the entire Authentication Trailer. 
Thanks,
Acee 
On May 9, 2011, at 5:51 AM, Alan Davey wrote:

> Folks
> 
> One minor point on the draft; it is not clear to me if the Auth Data Len field is the inclusive length of the entire authentication trailer, or just the length of the Authentication Data.
> 
> I think that the inclusive length of the authentication trailer is preferable.  
> 
> Either way, the text in section 4.1 could be made specific by changing "message digest" to "authentication trailer" or "Authentication Data".
> 
> Regards
> Alan Davey
> 
> Network Technologies Division
> Metaswitch Networks
> alan.davey@metaswitch.com
> +44 (0) 20 8366 1177
> www.metaswitch.com
> 
> 
> 
> 
> -----Original Message-----
> From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
> Sent: 05 May 2011 13:35
> To: OSPF List
> Cc: Vishwas Manral
> Subject: [OSPF] OSPFv3 Authentication Trailer (AT) Draft WG Last Call
> 
> All, 
> 
> We will make these editorial changes as part of the WG last call ending on May 9. We will not issue an 05 version of the draft until the WG last period has ended. Please review the document by May 9th, if you intend to do so. 
> 
> 
> Clarification: 
> 
> ***************
> *** 308,314 ****
>    Trailer is very similar to how it is done in case of [RFC2328].  The
>    only difference between the OSPFv2 authentication trailer and the
>    OSPFv3 authentication trailer is that information in addition to the
> !    message digest is included.
> 
>    Consistent with OSPFv2 cryptographic authentication [RFC2328], both
>    OSPFv3 header checksum calculation and verification are omitted when
> --- 308,317 ----
>    Trailer is very similar to how it is done in case of [RFC2328].  The
>    only difference between the OSPFv2 authentication trailer and the
>    OSPFv3 authentication trailer is that information in addition to the
> !    message digest is included.  The additional information in the OSPFv3
> !    Authentication Trailer is included in the message digest computation
> !    and, therefore, protected by OSPFv3 cryptographic authentication as
> !    described herein.
> 
>    Consistent with OSPFv2 cryptographic authentication [RFC2328], both
>    OSPFv3 header checksum calculation and verification are omitted when
> ***************
> 
> 
> Correction: 
> 
> ***************
> *** 623,631 ****
> 
>    2.  First Hash
> 
> !        First, the OSPFv3 packet's Authentication Trailer (which is very
> !        similar to the appendage described in RFC 2328, Section D.4.3,
> !        Page 233, items(6)(a) and (6)(d)) is filled with the value Apad.
> 
>        Then, a First-Hash, also known as the inner hash, is computed as
>        follows:
> --- 623,632 ----
> 
>    2.  First Hash
> 
> !        First, the OSPFv3 packet's Authentication Data field in the
> !        Authentication Trailer (which is very similar to the appendage
> !        described in RFC 2328, Section D.4.3, Page 233, items(6)(a) and
> !        (6)(d)) is filled with the value Apad.
> 
>        Then, a First-Hash, also known as the inner hash, is computed as
>        follows:
> ***************
> *** 635,643 ****
>        Implementation Notes:
> 
>           Note that the First-Hash above includes the Authentication
> !           Trailer containing the Apad value, as well as the OSPFv3
> !           packet, as per RFC 2328, Section D.4.3 and, if present, the
> !           LLS block[RFC5613].
> 
>        The definition of Apad (above) ensures it is always the same
>        length as the hash output.  This is consistent with RFC 2328.
> --- 636,643 ----
>        Implementation Notes:
> 
>           Note that the First-Hash above includes the Authentication
> !           Trailer, as well as the OSPFv3 packet, as per RFC 2328,
> !           Section D.4.3 and, if present, the LLS block[RFC5613].
> 
>        The definition of Apad (above) ensures it is always the same
>        length as the hash output.  This is consistent with RFC 2328.
> ***************
> 
> Thanks,
> Acee
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf