Last Call Review of draft-ietf-spring-segment-routing-13
review-ietf-spring-segment-routing-13-secdir-lc-mandelberg-2017-11-18-01

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 <david+work@mandelberg.org> >> Sent:
Friday, March 23, 2018 3:17 PM >> To: Les Ginsberg (ginsberg)
<ginsberg@cisco.com>; 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 <david@mandelberg.org> >>> >>> 
 > 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/