Subject: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS)

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 13 Dec 2017 19:55:07 -0800

Kathleen Moriarty 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:
----------------------------------------------------------------------

While I understand the assumption that following the capabilities of existing
protocols that incorporate similar functionality is okay, I'd like to walk
through the security properties left off in the security considerations section
to prevent tampering and see what can be done to correct that or minimally to
list out the considerations.

There's a few places in the security considerations section to call out
specifically.

Section 8.1:
   "The received information is validated using
   existing control plane protocols providing authentication and
   security mechanisms.  Segment Routing does not define any additional
   security mechanism in existing control plane protocols."

For MPLS what "security mechanisms" are referred to in this text?  It would be
helpful to list any properties explicitly or drop this phrase if there are no
additional security mechanisms.  Since segment routing lists an explicit list
of segments (I see that this can be done with MPLS labels and you note it is
already exposed), why is there no mention of integrity protection and origin
authentication to prevent tampering?  I think EKR's comment is already hinting
at this with his comments on IPv6, but I'd like to see explicit text to
preferably fix this gap in the architecture, but minimally to document it and
the associated security threats that result from this gap for MPLS and IPv6.

Section 8.2:

   "From a network protection standpoint, there is an assumed trust model
   such that any node adding an SRH to the packet is assumed to be
   allowed to do so.  Therefore, by default, the explicit routing
   information MUST NOT be leaked through the boundaries of the
   administered domain.  Segment Routing extensions that have been
   defined in various protocols, leverage the security mechanisms of
   these protocols such as encryption, authentication, filtering, etc."

This document focuses on the same threats as the MPLS use cases with no mention
of tampering or mitigations.  Text should be added to describe how origin
authentication and integrity are provided in the source routing header for IPv6
with the associated threats or to describe this gap if a solution does not
exist.  I have not read the draft referred to at the start of this section, so
I don't know if it addresses the concern or not.  In any case, this document
isn't complete without some text on tampering considerations within your
trusted domain.

Thank you.

---

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

Kathleen -

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: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 7:55 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-
> 13: (with 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.)
> 
> 
> protocols that incorporate similar functionality is okay, I'd like to walk through
> the security properties left off in the security considerations section to
> prevent tampering and see what can be done to correct that or minimally to
> For MPLS what "security mechanisms" are referred to in this text?  It would
> be helpful to list any properties explicitly or drop this phrase if there are no
> additional security mechanisms.  Since segment routing lists an explicit list of
> segments (I see that this can be done with MPLS labels and you note it is
> authentication to prevent tampering?  I think EKR's comment is already
> hinting at this with his comments on IPv6, but I'd like to see explicit text to

[Les:] We have reemphasized that SR is designed to be used within a trusted domain. As such, any attacker who sees a segment list already has breached the domain protections.

> This document focuses on the same threats as the MPLS use cases with no
> mention of tampering or mitigations.  Text should be added to describe how
> origin authentication and integrity are provided in the source routing header
> for IPv6 with the associated threats or to describe this gap if a solution does
> not exist.  I have not read the draft referred to at the start of this section, so I
> don't know if it addresses the concern or not.  In any case, this document
[Les:] The architecture draft is NOT proposing support of SRH introduced outside the domain of trust. Such support is an exception to the architecture. When done the use of origin authentication would be appropriate, but such an exception is not being described nor advocated in this document.

   Les