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

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