Last Call Review of draft-ietf-ospf-rfc6506bis-01
review-ietf-ospf-rfc6506bis-01-secdir-lc-weis-2013-12-05-00

Request Review of draft-ietf-ospf-rfc6506bis
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-03
Requested 2013-10-31
Authors Manav Bhatia, Vishwas Manral, Acee Lindem
Draft last updated 2013-12-05
Completed reviews Genart Last Call review of -01 by Brian Carpenter (diff)
Genart Telechat review of -03 by Brian Carpenter (diff)
Secdir Last Call review of -01 by Brian Weis (diff)
Opsdir Last Call review of -01 by Victor Kuarsingh (diff)
Assignment Reviewer Brian Weis
State Completed
Review review-ietf-ospf-rfc6506bis-01-secdir-lc-weis-2013-12-05
Reviewed rev. 01 (document currently at 05)
Review result Has Nits
Review completed: 2013-12-05

Review
review-ietf-ospf-rfc6506bis-01-secdir-lc-weis-2013-12-05

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document replaces (obsoletes) RFC 6506, which defines an Authentication Trailer for OSPFv3. It makes modest changes to the original specification, apparently as a result of deployment experience. It includes a positive security improvement in requiring that expired keys no longer be used rather than recommending that the expired key be used indefinitely. The specification is generally ready to publish.

I would suggest one rewording. The Introduction of RFC 6505 was published with the following justification as to why ESP sometimes cannot be used, and this was not changed in this draft:

   Since there is no deterministic way to differentiate between
   encrypted and unencrypted ESP packets by simply examining the packet,
   it could be difficult for some implementations to prioritize certain
   OSPFv3 packet types, e.g., Hello packets, over the other types.

But now RFC 5879 ("Heuristics for Detecting ESP-NULL Packets") has been published, which does describe some techniques to deterministically detect an unencrypted ESP packet. It may be still be difficult to prioritize certain OSPFv3 packets, but the justification is no longer precisely accurate. I would suggest something like the following rewording:

   Implementations desiring to prioritize certain OSPFv3 packet types, 
   e.g., Hello packets, over the other types, often perform the 
   prioritization prior to decryption. Parsing ESP packets is problematic 
   when the prioritization code does not know whether the ESP packets 
   include an encryption algorithm, or are instead ESP-NULL packets [RFC2410]. 
   Techniques exist to identify ESP packets using ESP-NULL packets 
   [RFC5879], which would allow these packets to be examined  and 
   prioritized. However, the techniques may not be practically applied 
   within the prioritization code.    

Brian