Last Call Review of draft-ietf-spring-segment-routing-13

Request Review of draft-ietf-spring-segment-routing
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-11-30
Requested 2017-11-01
Other Reviews Rtgdir Telechat review of -13 by Jonathan Hardwick (diff)
Opsdir Last Call review of -13 by Mehmet Ersue (diff)
Review State Completed
Reviewer David Mandelberg
Review review-ietf-spring-segment-routing-13-secdir-lc-mandelberg-2017-11-18
Posted at
Reviewed rev. 13 (document currently at 15)
Review result Has Nits
Draft last updated 2017-11-18
Review completed: 2017-11-18


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 summary of the review is Ready with nits.

This document affects routing within a trusted domain, and the security 
considerations section adequately talks about filtering at the border of 
a trusted domain.

I do have one question about something I didn't see in the document, 
what happens when SIDs change while packets are in transit? Here's a 
hypothetical situation that could be bad for security, but I'm not sure 
whether or not it could happen: 1. An internal node calculates an SR 
Policy and sends out a packet that will eventually egress towards a BGP 
peer. 2. Multiple links on the BGP router go down and then back up, but 
are allocated different PeerAdj SIDs than they had before. 3. The packet 
reaches the BGP router, but egresses to the wrong BGP peer because the 
original PeerAdj SID is now mapped to a different PeerAdj segment.

Freelance cyber security consultant, software developer, and more