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

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

Hmmm...well if you look at https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ we see




Reviews

OPSDIR Last Call Review (of -13): Ready <https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-13-opsdir-lc-ersue-2017-12-19/>
SECDIR Last Call Review (of -13): Has Nits <https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-13-secdir-lc-mandelberg-2017-11-18/>
RTGDIR Telechat Review (of -13): Ready <https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-13-rtgdir-telechat-hardwick-2017-12-12/>




And then the SECDIR review link points to your review: https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-13-secdir-lc-mandelberg-2017-11-18/



So I don’t know what else needs to be done to clear this.



Bruno? Rob? Can you help here?



    Les



> -----Original Message-----

> From: David Mandelberg <[e-mail]>

> Sent: Friday, March 23, 2018 4:18 PM

> To: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];

> [e-mail]; [e-mail]

> Subject: Re: secdir review of draft-ietf-spring-segment-routing-13

>

> No worries about the delay. And I'm just a secdir reviewer, not an IESG member,

> so I can't do anything about a DISCUSS.

>

> On 03/23/2018 07:02 PM, Les Ginsberg (ginsberg) wrote:

> > 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]<mailto:[e-mail]>>

> >> Sent: Friday, March 23, 2018 3:57 PM

> >> To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>

> >>>> Sent: Friday, March 23, 2018 3:17 PM

> >>>> To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;

> >>>> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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#s

> >>>>> ec

> >>>>> 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]<mailto:[e-mail]>>

> >>>>>

> >>>>>    > Sent: Thursday, November 02, 2017 10:53 AM

> >>>>>

> >>>>>    > To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> >>>>> draft-ietf-spring-segment-

> >>>>>

> >>>>>    > [e-mail]<mailto:[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/

>

>

> --

> Freelance cyber security consultant, software developer, and more

> https://david.mandelberg.org/