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

[Eric Rescorla <[e-mail]>]

On Sat, Mar 24, 2018 at 11:13 AM, Les Ginsberg (ginsberg) <
[e-mail]> wrote:

> Eric –
>
>
>
> Alissa’s comments were addressed – and we have been waiting for a response
> from her for nearly 3 months.
>
> See attached.
>
>
You need to take this up with Alissa.

-Ekr


>
   Les
>
>
>
>
>
> *From:* Eric Rescorla <[e-mail]>
> *Sent:* Saturday, March 24, 2018 3:40 AM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>
> *Cc:* David Mandelberg <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
>
> *Subject:* Re: secdir review of draft-ietf-spring-segment-routing-13
>
>
>
> 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/
>
>
>
>
> ---------- Forwarded message ----------
> From: Alvaro Retana <[e-mail]>
> To: "Les Ginsberg (ginsberg)" <[e-mail]>, Alissa Cooper <
> [e-mail]>, The IESG <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]"
> <[e-mail]>
> Bcc:
> Date: Thu, 11 Jan 2018 21:58:49 +0000
> Subject: RE: Alissa Cooper's Discuss on
> draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT)
> Alissa:
>
> Hi!
>
> Any thoughts on the update to this document?
>
> Thanks!
>
> Alvaro.
>
> On December 20, 2017 at 6:18:13 PM, Les Ginsberg (ginsberg) (
> [e-mail]) wrote:
>
> Alissa -
>
> Thanx for the review.
> V14 has been published and it attempts to address the Security concerns
> raised by you and others.
> Look forward to your feedback.
>
> Inline.
>
> > -----Original Message-----
> > From: Alissa Cooper [mailto:[e-mail]]
> > Sent: Wednesday, December 13, 2017 10:42 AM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13:
>
> > (with DISCUSS and COMMENT)
> >
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-spring-segment-routing-13: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I ended up reading draft-ietf-6man-segment-routing-header in tandem
> with
> > this document, and I have a question arising out of that. The trust
> model for
> > SRv6 outlined in this document appears to be one of reliance on the fact
> that
> > an SRH will only ever be inserted and appear within a single
> administrative
> > domain.
> > But Section 5.2.2 of draft-ietf-6man-segment-routing-header talks about
> an
> > SRH being inserted by a device outside of the segment routing domain.
> > Which is correct? I think this is an important question because the
> whole
> > trust model for the SR information seems to rely on out-of-band trust
> > between participating nodes.
> >
> > I also think this is important because there is no discussion in this
> document
> > of the impact of the inclusion of the SR metadata on the fingerprinting
> of the
> > device that inserted it. Section 5.1.4 of draft-ietf-6man-segment-routing-
>
> > header sort of alludes to this but seems to equate the capabilities of
> an
> > active attacker (who can conduct a traceroute) with a passive attacker
> who
> > could passively collect topology/fingerprinting information simply by
> > observing SRHes flowing by on the network. If the limitation to a single
> > administrative domain is meant to prevent such a passive attack (not
> sure if
> > that is really true, but perhaps the document assumes it?), that's
> another
> > reason that the existence of such a limitation needs to be clarified.
> >
> >
> [Les:] We share a common concern regarding trust issues. The architecture
> draft speaks to the default policy of only allowing trusted sources to
> insert SRH.
> The 6man draft currently discusses exceptions under the protection of
> authentication. I don’t see that as a contradiction.
> The risk/reward of allowing such exceptions can (and should) be discussed
> in the review of the 6man draft, but I am not convinced the architecture
> draft needs to speak to this since it is a clearly stated exception to the
> base trust model.
>
> The point that SR is intended to operate within a trusted domain has been
> clarified/reemphasized in the Security section changes.
>
> Les
>
>
>
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >
> > Per my DISCUSS comment, I think this document needs to include some
> > considerations concerning the additional metadata that SRv6 adds to the
> > packet.
> > This has implications not just for passive observers but also for any
> node that
> > logs the SRH.
> >
>
>
>