Subject: [spring] Adam Roach's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 13 Dec 2017 09:58:41 -0800

Adam Roach has entered the following ballot position for
draft-ietf-spring-segment-routing-13: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who put in work on this document. I do note that the list of
authors is over the five-author recommended limit. I checked both the ballot
and the shepherd write-up, and was a little surprised not to find an
explanation of why this document is exceptional in this regard.

I have one major comment and a handful of editorial comments.

The major comment regards the treatment of trust assumptions in the security
section. The SR-MPLS section asserts: "[T]here is an assumed trust model such
that any node imposing a label stack on a packet is assumed to be allowed to do
so"; the SRv6 section has a similar assertion: "[T]here is an assumed trust
model such that any node adding an SRH to the packet is assumed to be allowed
to do so."

I leave it to the security area directors to speak to whether it is okay in
2017 to publish documents that forego integrity protection of source routing
information based on assumptions of perfectly secured networks. Irrespective of
the answer to that question, I'm perplexed that the security section does not
go into detail about the consequences that arise when these assumptions are
violated. I think a clear description of these consequences is relevant and
necessary to include, as it informs the level of care that is appropriate for
both implementation and deployment of these protocols.

I want to be clear that I consider this a major flaw in the document, and am on
the fence regarding whether it should constitute a blocking DISCUSS. I would
support anyone else in issuing a DISCUSS on this topic.

Editorial comments follow.

Section 2 contains the following text:

   Active Segment: the segment that MUST be used by the receiving router
   to process the packet.

I really don't think you want to use normative language in the terminology
section. I strongly recommend moving this requirement down to a section that
bears more directly on implementation.

Section 3.4.2:

   These extensions are defined in IGP SR extensions documents.

Please add a citation to the relevant documents.

Section 3.5:

   ABRs G and J will propagate the prefix and its SIDs into the backbone
   area by creating a new instance of the prefix according to normal
   inter-area/level IGP propagation rules.

Please expand the term "ABR" on first use.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 13 Dec 2017 13:34:55 -0500

On December 13, 2017 at 9:58:42 AM, Adam Roach ([email-masked]) wrote:

Adam:

Hi!

Thanks to everyone who put in work on this document. I do note that the
list of
authors is over the five-author recommended limit. I checked both the ballot

This document, and most of the spring-related ones, has really been a group
effort with important contributions from a significant number of people.
You will notice that in most cases I have exercised my discretion in
allowing more than 5 authors in the front page, while many contributors
have been moved to their own section, precisely because of the level and
significance of the contributions.

Thanks!

Alvaro.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Dec 2017 11:27:27 +0100

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/
Btw, there are more occurrences than this one.

    SR Local Block (SRLB): local property of an SR node.  If a node
    participates in multiple SR domains, there is one SRLB for each SR
    domain.  In SR-MPLS, SRLB is a set of local labels reserved for local
    segments.  In SRv6, SRLB is a set of local IPv6 addresses reserved
    for local SRv6 SID's.  In a controller-driven network, some
    controllers or applications MAY use the control plane to discover the
    available set of local segments.

Regards, Benoit
> .

---

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

Adam -

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: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 9:59 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Adam Roach's No Objection on draft-ietf-spring-segment-routing-
> 13: (with 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.)
> 
> 
> Thanks to everyone who put in work on this document. I do note that the list
> of authors is over the five-author recommended limit. I checked both the
> ballot and the shepherd write-up, and was a little surprised not to find an
> The major comment regards the treatment of trust assumptions in the
> security section. The SR-MPLS section asserts: "[T]here is an assumed trust
> model such that any node imposing a label stack on a packet is assumed to be
> allowed to do so"; the SRv6 section has a similar assertion: "[T]here is an
> assumed trust model such that any node adding an SRH to the packet is
> assumed to be allowed to do so."
> 
> information based on assumptions of perfectly secured networks.
> Irrespective of the answer to that question, I'm perplexed that the security
> section does not go into detail about the consequences that arise when
> these assumptions are violated. I think a clear description of these
> consequences is relevant and necessary to include, as it informs the level of
> care that is appropriate for both implementation and deployment of these
> protocols.
> 
[Les:] SR is to be deployed within a trusted domain. This point has been emphasized/clarified in the Security section changes.
We have also provided a few examples of the problems which could occur should appropriate protection not be implemented/fail.

> I want to be clear that I consider this a major flaw in the document, and am
> on the fence regarding whether it should constitute a blocking DISCUSS. I
> would support anyone else in issuing a DISCUSS on this topic.
> 
> section. I strongly recommend moving this requirement down to a section
> that bears more directly on implementation.
> 
[Les:] Fixed

> Please add a citation to the relevant documents.

[Les:] There is a citation to the IGP documents in Section 3. I did not see the necessity to repeat it in the sub-sections.

> Please expand the term "ABR" on first use.
[Les:] Fixed.

   Les

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Dec 2017 17:40:02 -0600

Thanks! The one thing that I'd suggest for improvement is in section 8.2:

>     Problems which may arise when the above behaviors are not done
>     include:

The issue isn't isolated to just the behaviors, but also to failures of 
the assumed trust model. I might suggest something more like:

>     Problems which may arise when the above behaviors are not implemented
>     or when the assumed trust model is violated (e.g., through a security
>     breach) include:

/a

---

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

Benoit –

The incorrect use of normative language in the SRLB definition has been corrected.
Thanx for catching this.

   Les

From: Benoit Claise (bclaise)
Sent: Thursday, December 14, 2017 2:27 AM
To: Adam Roach <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Adam Roach's No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

COMMENT:

to do so."

   to process the packet.

Regards, Benoit

Section 3.4.2:

Section 3.5:

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 21 Dec 2017 00:07:01 +0000

Adam -

Thanx for the quick response.

> Sent: Wednesday, December 20, 2017 3:40 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> The issue isn't isolated to just the behaviors, but also to failures of the
> assumed trust model. I might suggest something more like:
> 

[Les:] Looks good to me. Will incorporate into the next revision - which will occur after the New Year.

  Les