Last Call Review of draft-ietf-ospf-rfc6506bis-01
review-ietf-ospf-rfc6506bis-01-opsdir-lc-kuarsingh-2013-11-28-00

Request Review of draft-ietf-ospf-rfc6506bis
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2013-12-03
Requested 2013-11-11
Authors Manav Bhatia, Vishwas Manral, Acee Lindem
Draft last updated 2013-11-28
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 Victor Kuarsingh
State Completed
Review review-ietf-ospf-rfc6506bis-01-opsdir-lc-kuarsingh-2013-11-28
Reviewed rev. 01 (document currently at 05)
Review result Ready
Review completed: 2013-11-28

Review
review-ietf-ospf-rfc6506bis-01-opsdir-lc-kuarsingh-2013-11-28

IESG, OPS-DIR and Authors,

I reviewed "Supporting Authentication Trailer for OSPFv3"  (draft-ietf-ospf-rfc6506bis-02) for operational impact.


Intended Status: Standards Track

Current Draft Status: IESG Last Call

Summary:  This document defines an alternative mechanism to authenticate OSPFv3 protocol packets using an Authentication Trailer (versus using IPSec). The document also outlines mechanism allowing implementations supporting this authentication method to operate with older implementations not supporting this authentication method.




This document is set to replace RFC6506 providing updates and includes Errata items.

I do not see any operational impact with publication based on what is currently specified in this draft.




Summary Feedback Points:

(1) The document addresses Errata items from RFC6506 and provides updated text around invalid keys usage and backward compatibility

(2) The document does address, to a greater extent then RFC6506 backward compatibility with older OSPFv3 implementations not supporting this newer authentication method (outlined in section 5)




(3) Section 5 provides a well described list of behaviours necessary by routers implementing the new authentication method to be backwards compatible with older implementations that do not support the new functions (This is important to operators as transitionary functionally is very important)




(4) If implemented as specified, this helps operators further secure their environments while supporting transition often needed for network implementation

(5)  I do not see any issues from an operational perspective to publication




Additional Feedback:

(6) Given that implementations of this new authentication method can exist for long periods of time in environments where at least one router may not support the new methods, some additional text in the security section may be beneficial to describe that exposure (this is not necessary since this point can be gleaned by the reader who is operationally aware , but just an option)




Optional Text that can be added in security section (Section 6) if desired:

<text>

Deployments supporting a transitionary state which interoperate with routers that do not support this authentication method may be exposed to unauthenticated data during the transition period.




</text>

regards,

Victor Kuarsingh