Re: [secdir] secdir review of draft-ietf-spring-segment-routing-13

["Les Ginsberg (ginsberg)" <[e-mail]>]

David -

Yes - IGP specs have this. See (for example):

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-15#section-2.2.1

If this suffices please clear your DISCUSS on the draft.

Again, apologies for the long delay in responding - it was not intentional.

    Les

> -----Original Message-----
> From: David Mandelberg <[e-mail]>
> Sent: Friday, March 23, 2018 3:57 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: secdir review of draft-ietf-spring-segment-routing-13
> 
> 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 <[e-mail]>
> >> Sent: Friday, March 23, 2018 3:17 PM
> >> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];
> >> [e-mail]; [e-mail]
> >> 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#sec
> >>> ti
> >>> 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 <[e-mail]>
> >>>
> >>>   > Sent: Thursday, November 02, 2017 10:53 AM
> >>>
> >>>   > To: [e-mail]; [e-mail]; draft-ietf-spring-segment-
> >>>
> >>>   > [e-mail]
> >>>
> >>>   > 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/