Subject: [spring] Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS and COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Wed, 13 Dec 2017 10:41:54 -0800

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.

----------------------------------------------------------------------
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: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 14 Dec 2017 23:22:05 +0000

Alissa -

I think I am properly understanding your question - but as you reference two non-existent sections in 
https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-07

<snip>
Section 5.2.2 of draft-ietf-6man-segment-routing-header...
...
Section 5.1.4 of draft-ietf-6man-segment-routing-header
<end snip>

I want to be sure.
Could you provide corrected references and/or the precise text which raises your concern?

Thanx.

    Les

> -----Original Message-----
> From: Alissa Cooper [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 10:42 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Alissa Cooper's Discuss on draft-ietf-spring-segment-routing-13:
> (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 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.
> 
> 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.
> 
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 15 Dec 2017 09:43:49 -0500

> On Dec 14, 2017, at 6:22 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> Alissa -
> 

My apologies, for some reason I was looking at draft-ietf-6man-segment-routing-header-05 instead of -07 when writing up my ballot.

s/5.1.4/6.1.4/

s/5.2.2/6.2.2/

Thanks,
Alissa

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 20 Dec 2017 23:18:10 +0000

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.

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
[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