Last Call Review of draft-ietf-ospf-security-extension-manual-keying-09
review-ietf-ospf-security-extension-manual-keying-09-genart-lc-krishnan-2014-10-28-00

Request Review of draft-ietf-ospf-security-extension-manual-keying
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-10-17
Requested 2014-10-08
Authors Manav Bhatia, Sam Hartman, Dacheng Zhang, Acee Lindem
Draft last updated 2014-10-28
Completed reviews Genart Last Call review of -09 by Suresh Krishnan (diff)
Genart Last Call review of -11 by Suresh Krishnan
Secdir Last Call review of -09 by Shaun Cooley (diff)
Opsdir Last Call review of -09 by Linda Dunbar (diff)
Assignment Reviewer Suresh Krishnan
State Completed
Review review-ietf-ospf-security-extension-manual-keying-09-genart-lc-krishnan-2014-10-28
Reviewed rev. 09 (document currently at 11)
Review result Almost Ready
Review completed: 2014-10-28

Review
review-ietf-ospf-security-extension-manual-keying-09-genart-lc-krishnan-2014-10-28

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