[secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03

[Brian Weis <[e-mail]>]

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