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

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

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#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 <[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/