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

[Eric Rescorla <[e-mail]>]

The DISCUSS on this document is being held by Alissa Cooper.
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ballot/

I would suggest responding to her points (there should be an associated
email thread)

-Ekr


On Fri, Mar 23, 2018 at 11:27 PM, Les Ginsberg (ginsberg) <
[e-mail]> wrote:

> 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]>
>
> > >> 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#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]>
>
> > >>>>>
>
> > >>>>>    > 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/
>
> >
>
> >
>
> > --
>
> > Freelance cyber security consultant, software developer, and more
>
> > https://david.mandelberg.org/
>