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
> [email protected]
> +44 (0) 20 8366 1177
> www.metaswitch.com
> 
> 
> 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ospf
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ospf

_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to