Last Call Review of draft-ietf-sidrops-ov-clarify-03

Request Review of draft-ietf-sidrops-ov-clarify
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-08-10
Requested 2018-07-27
Authors Randy Bush
Draft last updated 2018-08-04
Completed reviews Genart Last Call review of -03 by Brian Carpenter (diff)
Rtgdir Telechat review of -03 by Dhruv Dhody (diff)
Secdir Last Call review of -03 by Yoav Nir (diff)
Assignment Reviewer Yoav Nir 
State Completed
Review review-ietf-sidrops-ov-clarify-03-secdir-lc-nir-2018-08-04
Reviewed rev. 03 (document currently at 05)
Review result Ready
Review completed: 2018-08-04


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.

The document clarifies two things about RFC 6811: 

That all routes MUST be marked as Valid, Invalid, or NotFound unless policy specifically says not to do so. The original text in RFC 6811 said SHOULD (perform a lookup...) and MAY (provide configuration options...), so this interpretation seems to be already strongly implied by 6811.

That policy (such as rejecting invalid routes) MUST NOT be applied unless the operator specifically configured it. RFC 6811 already says, "An implementation MUST NOT exclude a route from the Adj-RIB-In or from consideration in the decision process as a side effect of its validation state, unless explicitly configured to do so." so I believe this is already stated in RFC 6811. Still, the text says that some implementers got it wrong.

So I think the claim in the security considerations section, that this document does not introduce any security considerations beyond those of 6811 is reasonable. The fact that the security policy suggested by RFC 6811 MUST NOT be turned on by default may have been pointed out more emphatically, but this perhaps should have to be done in 6811.