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

From: Suresh Krishnan <[email-masked]>
Date: Tue, 28 Oct 2014 18:22:15 -0400

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.

-> 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.

* 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
Suresh

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Oct 2014 12:58:24 +0200

Thanks for your review, Suresh.

I agree that the two issues from Section 2 should be fixed. Authors?

Jari

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Oct 2014 16:07:02 +0000

Hi Suresh, Jari, 
I am traveling this week and fully engaged in other activities. We plan to
address comments next week.
Thanks,
Acee