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

From: Alvaro Retana <[email-masked]>
Date: Thu, 11 Jan 2018 13:57:16 -0800

Kathleen:

Hi!

Any thoughts on the update to this document?

Thanks!

Alvaro.

On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg) (
[email-masked]) wrote:

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

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

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

> Thank you.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 12 Jan 2018 13:58:20 -0500

Hi, Alvaro!

Thanks for bringing this to my attention, the message from Les slipped
through the cracks.

On Thu, Jan 11, 2018 at 4:57 PM, Alvaro Retana <[email-masked]> wrote:
> On December 20, 2017 at 6:42:02 PM, Les Ginsberg (ginsberg)
> ([email-masked]) wrote:
>
> Kathleen -
>
> Thanx for the review.
>> Subject: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-
>> 13: (with DISCUSS)
>>
>> 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
>> for IPv6 with the associated threats or to describe this gap if a solution
>> does

Here I'm asking about tampering within the trusted domain, not just a
statement that this is expected to occur within a trusted domain.  If
there are no mitigations, that is a security consideration that should
be stated explicitly as a risk and it's fine if you tie it to your
assumed trust model.

So describing the gap in the text as requested in one of the options
to address the discuss seems like the approach needed here.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 12 Jan 2018 23:06:22 +0000

Kathleen -

I propose the following addition to the end of Section 8.

"The use of best practices to reduce the risk of tampering within 
the trusted domain is important. Such practices are discussed in
[RFC4381] and are applicable to both SR-MPLS and SRv6."

    Les

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Friday, January 12, 2018 10:58 AM
> To: Alvaro Retana <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; The IESG
> <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-spring-
> [email-masked]; [email-masked]
> Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-spring-segment-
> routing-13: (with DISCUSS)
> 
> Hi, Alvaro!
> 
> > V14 has been published and it attempts to address the Security
> > concerns raised by you and others.
> >> Cc: [email-masked];
> >> [email-masked]; [email-masked];
> >> [email-masked]; [email-masked]
> >> 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
> >> 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."
> >>
> >> 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.
> >>
> >