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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Mar 2018 10:34:17 +0000

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#section-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 <[email-masked]>

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

> To: [email-masked]; [email-masked]; draft-ietf-spring-segment-

> [email-masked]

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

---

From: David Mandelberg <[email-masked]>
Date: Fri, 23 Mar 2018 18:17:14 -0400

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:
> 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#section-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./
> 
> //
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Mar 2018 22:43:44 +0000

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

> From: David Mandelberg <[email-masked]>
> Sent: Friday, March 23, 2018 3:17 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> 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.
>

---

From: David Mandelberg <[email-masked]>
Date: Fri, 23 Mar 2018 18:56:48 -0400

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Mar 2018 23:02:13 +0000

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

> Sent: Friday, March 23, 2018 3:57 PM
> 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.
> 
> > 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
> >
> >>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#sec
> >>> ti
> >>> on-3.4
> >>>

---

From: David Mandelberg <[email-masked]>
Date: Fri, 23 Mar 2018 19:18:15 -0400

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Mar 2018 23:27:30 +0000

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

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

> 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.

> > https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions

> > -15#section-2.2.1

> >> From: David Mandelberg <[email-masked]<mailto:[email-masked]>>

> >> To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> >> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> >> 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.

> >>> 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

> >>>> From: David Mandelberg <[email-masked]<mailto:[email-masked]>>

> >>>> To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;

> >>>> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> >>>> 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.

> >>>>> Apologies. It appears that I neglected to respond to this old

> >>>>> review comment.

> >>>>> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#s

> >>>>> ec

> >>>>> /o  Indication whether the Adj-SID is persistent across control

> >>>>> plane/

> >>>>> /      restarts.  Persistence is a key attribute in ensuring that

> >>>>> an SR/

> >>>>>    > From: David Mandelberg <[email-masked]<mailto:[email-masked]>>

> >>>>>    > To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

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

> >>>>>    > [email-masked]<mailto:[email-masked]>

> >>>>>    > 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

> >>>>>    > This document affects routing within a trusted domain, and

> >>>>> the security

> >>>>>    > considerations section adequately talks about filtering at

> >>>>> the border of a trusted

> >>>>>    > 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

> >>>>>    > Freelance cyber security consultant, software developer, and

> >>>>> more

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Mar 2018 10:39:50 +0000

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) <
[email-masked]> 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/
>
>
>
> member,
> > >>>>>    > To: [email-masked]; [email-masked];
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 24 Mar 2018 11:13:59 +0000

Eric –

Alissa’s comments were addressed – and we have been waiting for a response from her for nearly 3 months.
See attached.

   Les

From: Eric Rescorla <[email-masked]>
Sent: Saturday, March 24, 2018 3:40 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: David Mandelberg <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: secdir review of draft-ietf-spring-segment-routing-13

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) <[email-masked]<mailto:[email-masked]>> wrote:

Reviews

    Les

> From: David Mandelberg <[email-masked]<mailto:[email-masked]>>

> https://david.mandelberg.org/

Subject: RE: Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT)
From: Alvaro Retana <[email-masked]>
To: "Les Ginsberg (ginsberg)" <[email-masked]>, Alissa Cooper <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 11 Jan 2018 21:58:49 +0000

Alissa:

Hi!

Any thoughts on the update to this document?

Thanks!

Alvaro.

On December 20, 2017 at 6:18:13 PM, Les Ginsberg (ginsberg) ([email-masked]<mailto:[email-masked]>) 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.

> From: Alissa Cooper [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Wednesday, December 13, 2017 10:42 AM
> To: The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> 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.
>

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Mar 2018 11:39:06 +0000

> from her for nearly 3 months.
You need to take this up with Alissa.

-Ekr

   Les
>
>
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Saturday, March 24, 2018 3:40 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* David Mandelberg <[email-masked]>; [email-masked];
> *Subject:* Re: secdir review of draft-ietf-spring-segment-routing-13
>
>
>
> ---------- Forwarded message ----------
> To: "Les Ginsberg (ginsberg)" <[email-masked]>, Alissa Cooper <
> [email-masked]>, The IESG <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]"
> <[email-masked]>
> Bcc:
> Subject: RE: Alissa Cooper's Discuss on
> draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT)
> Alissa:
>
> Hi!
>
> On December 20, 2017 at 6:18:13 PM, Les Ginsberg (ginsberg) (
> [email-masked]) wrote:
>
> Alissa -
>
> Thanx for the review.
> > From: Alissa Cooper [mailto:[email-masked]]
> > To: The IESG <[email-masked]>
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> [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
>
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Mar 2018 10:33:48 -0500

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

FWIW, you should be able to edit the secdir review's summary
evaulation by going into the dattracker (while logged in), finding
the "my reviews" item from either the sidebar or the <username>
dropdown in the top, selecting the given review request from the
list, and using the "correct review" button.  I don't know that we
have a huge amount of experience with doing this, whether you can
change the reviewed revision as well, etc., so don't feel like you
have to do this.  (But if you do, please report back to the secdir
list how it went!)

Thanks,

Ben

---

From: David Mandelberg <[email-masked]>
Date: Wed, 28 Mar 2018 15:09:46 -0400

> have to do this.  (But if you do, please report back to the secdir

I edited it, so the state is now Ready. One thing that surprised me 
though, is that adding a new review version changed the review link 
("posted at") and status for the old review version.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Mar 2018 14:21:29 -0500

> ("posted at") and status for the old review version.

Perhaps that's a function of editing the existing review request
instead of creating a new review object for the new version.  Maybe
Tero understands this better than I do and wants to say something
about the expected/desired workflow...

Thanks for circling back,

Ben

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Mar 2018 00:38:34 +0300

> ("posted at") and status for the old review version.

"Correct review" is meant to be used when you want to correct some
mistke in your review. For example link points to wrong location or
version does not match.

You can also use it to fix the "review summary" if it is incorrect for
some reason, but it is not really meant to be used to mark whether the
discussion triggered by the review caused the issues to be fixed.
I.e., if the issues found in review are fixed, you do not edit the
review, but simply reply to the review thread in mailing lists saying
that "Yes, this solves my issues" or similar, so when ADs check the
thread they will see that as final email in the thread and know that
issues have been solved.

Perhaps we should make #2217 higher priority, so reviewers could enter
unsolicited reviews themselves. 

[1] https://trac.tools.ietf.org/tools/ietfdb/ticket/2217
-- 
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Mar 2018 19:46:33 -0500

Hi Tero,

> thread they will see that as final email in the thread and know that

Thanks for the clarification!

> [1] https://trac.tools.ietf.org/tools/ietfdb/ticket/2217

It's not entirely clear how often the situation comes up, so I'll
not try to influence the tools team's prioritization.  It will
probably be fine to just tell document authors who want to see a
"clean secdir review" that the system is set up to work differently.

-Ben

---

From: David Mandelberg <[email-masked]>
Date: Thu, 29 Mar 2018 00:26:57 -0400

> Thanks for the clarification!

Ditto. Should I change the link and status back to what they were before?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Mar 2018 06:53:08 -0500

> Ditto. Should I change the link and status back to what they were before?

I wouldn't bother -- we can just go forward with the results we've
learned from the experiment.

-Ben