[spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS)
Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Thu, 14 December 2017 03:55 UTC
Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F616126D74; Wed, 13 Dec 2017 19:55:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-segment-routing@ietf.org, aretana.ietf@gmail.com, spring-chairs@ietf.org, martin.vigoureux@nokia.com, spring@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151322370751.6222.4040293688172571956.idtracker@ietfa.amsl.com>
Date: Wed, 13 Dec 2017 19:55:07 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/NgEty5Uhfe5LtyCNd0ip3h0ZPpE>
Subject: [spring] Kathleen Moriarty's Discuss on draft-ietf-spring-segment-routing-13: (with DISCUSS)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 03:55:07 -0000
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.
- [spring] Kathleen Moriarty's Discuss on draft-iet… Kathleen Moriarty
- Re: [spring] Kathleen Moriarty's Discuss on draft… Les Ginsberg (ginsberg)
- Re: [spring] Kathleen Moriarty's Discuss on draft… Alvaro Retana
- Re: [spring] Kathleen Moriarty's Discuss on draft… Kathleen Moriarty
- Re: [spring] Kathleen Moriarty's Discuss on draft… Les Ginsberg (ginsberg)
- Re: [spring] Kathleen Moriarty's Discuss on draft… Alvaro Retana
- Re: [spring] Kathleen Moriarty's Discuss on draft… Kathleen Moriarty