Thanks, I didn't know it was in the IGP specs. If the usage you describe would be clear to anybody using this, then I think you've fully addressed my original comment. On 03/23/2018 06:43 PM, Les Ginsberg (ginsberg) wrote: > David - > > Thanx for the very prompt response. > > If a controller (for example) is defining a SID stack for an SR Policy, it can choose to use an Adj-SID which is advertised as Persistent and be confident that the SID will not be reused for some other purpose no matter what happens on the owning node. > > BTW, the flag isn’t new - it has been part of the IGP specifications for quite a long while. It just wasn't mentioned in the SR Architecture in earlier versions. > > HTH > > Les > >> -----Original Message----- >> From: David Mandelberg >> Sent: Friday, March 23, 2018 3:17 PM >> To: Les Ginsberg (ginsberg) ; iesg@ietf.org; >> secdir@ietf.org; draft-ietf-spring-segment-routing.all@ietf.org >> Subject: Re: secdir review of draft-ietf-spring-segment-routing-13 >> >> Hi, >> >> How will the indication of persistence be used? I scanned the changes from -13 >> to -15, but I didn't notice any other text about the new flag. >> >> On 03/23/2018 06:34 AM, Les Ginsberg (ginsberg) wrote: >>> David - >>> >>> Apologies. It appears that I neglected to respond to this old review >>> comment. >>> >>> This was not intentional. Authors actively discussed your comment >>> promptly and we did add text in V14 of the draft to address this point: >>> >>> Please see: >>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#secti >>> on-3.4 >>> >>> /o  Indication whether the Adj-SID is persistent across control plane/ >>> >>> /      restarts.  Persistence is a key attribute in ensuring that an >>> SR/ >>> >>> /      Policy does not temporarily result in misforwarding due to/ >>> >>> /      reassignment of an Adj-SID./ >>> >>> // >>> >>> Please let us know if this adequately addresses your comment. >>> >>> Again, apologies for the long delay. >>> >>>    Les >>> >>> > -----Original Message----- >>> >>> > From: David Mandelberg >>> >>> > Sent: Thursday, November 02, 2017 10:53 AM >>> >>> > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-spring-segment- >>> >>> > routing.all@ietf.org >>> >>> > Subject: secdir review of draft-ietf-spring-segment-routing-13 >>> >>> > >>> >>> > 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 >>> >>> > https://david.mandelberg.org/ >>> >> >> >> -- >> Freelance cyber security consultant, software developer, and more >> https://david.mandelberg.org/ -- Freelance cyber security consultant, software developer, and more https://david.mandelberg.org/