Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ospf-security-extension-manual-keying-09.txt

["Acee Lindem (acee)" <[e-mail]>]

Hi Suresh,
Thanks much for your comments. See inline.

On 10/28/14, 3:22 PM, "Suresh Krishnan" <[e-mail]>
wrote:

>I have been selected as the General Area Review Team (Gen-ART)
>reviewer for this draft (for background on Gen-ART, please see
>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
>Please wait for direction from your document shepherd
>or AD before posting a new version of the draft.
>
>Document: draft-ietf-ospf-security-extension-manual-keying-09.txt
>Reviewer: Suresh Krishnan
>Review Date: 2013/10/28
>IESG Telechat date: 2013/10/30
>
>
>Summary: The draft is almost ready for publication as Proposed Standard
>but has some issues that need to be addressed.
>
>* Section 2
>
>-> There is no reference to snmpEngineBoots in the RFC4222 reference.
>Are you pointing to the wrong document here? I would suggest replacing
>the RFC4222 reference with a reference to RFC2574 Section 2.2 that talks
>about replay protection.

This was wrong. RFC 4222 is a reference that should have been used later
in the draft with respect to packet prioritization. I will update this
reference to RFC 2574.


>
>-> There is another change to the 64-bit authentication field that is
>not described in the text. The 0 field in the beginning is extended from
>16 bits to 24 bits. Can you please add this.

I will add this. 

>
>* Section 5
>
>-> It is unclear from this text what the exact change to the
>authentication trailer is. The only logical explanation I could come up
>with is that instead of initializing the field with Apad x times, we
>initialize with the IP source address x times. If my understanding is
>correct please reword the text. Suggested change below.
>
>OLD:
>    OSPF routers sending OSPF packets must initialize Apad to the value
>    of the IP source address that would be used when sending an OSPFv2
>    packet, repeated L/4 times, where L is the length of the hash,
>    measured in octets.  The basic idea is to incorporate the IP source
>    address from the IP header in the cryptographic authentication
>    computation so that any change of IP source address in a replayed
>    packet can be detected.
>
>NEW:
>    Instead of using the hexadecimal constant 0x878FE1F3, OSPF routers
>    following this specification MUST initialize Apad to the value
>    of the IP source address that would be used when sending an OSPFv2
>    packet, repeated L/4 times, where L is the length of the hash,
>    measured in octets.  The basic idea is to incorporate the IP source
>    address from the IP header in the cryptographic authentication
>    computation so that any change of IP source address in a replayed
>    packet can be detected.

Thanks much - this was wrong and should have been consistent with RFC
7166. Here is the updated text:

      OSPF routers sending OSPF packets must initialize the first 4 octets
      of Apad to the value of the IP source address that would be used when
      sending the OSPFv2 packet.  The remainder of Apad will contain
      the value of 0x878FE1F3 repeated (L - 4)/4 times, where L is the
      length of the hash, measured in octets.  The basic idea is to
      incorporate the IP source address from the IP header in the
      cryptographic authentication computation so that any change of IP
      source address in a replayed packet can be detected.


Thanks,
Acee 



>
>Thanks
>Suresh
>
>
>