IETF Logo Mail Archive

Re: [secdir] secdir review of draft-ietf-spring-segment-routing-13

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 23 March 2018 10:34 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A76212D7F2; Fri, 23 Mar 2018 03:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vymOmNMHuc4T; Fri, 23 Mar 2018 03:34:19 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF374126BF0; Fri, 23 Mar 2018 03:34:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12356; q=dns/txt; s=iport; t=1521801259; x=1523010859; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cu1iOHaafo7/Nz02iExt9x+wQlFj70Ewf/whw2aKee4=; b=KnofrR+NzrmrzVRM+tHExs29oaMRpxlqzLLx/ht3JQK4mT6b7TLfh6MD Tx1jSHujy86DGf35FbkgSZQNWGttwbsy/iudd5fOZJ3vc3161SNMTGsTr bRsqjErO6iyKpifD9EKKW39txu2Sufl0h8imVRPYkSOAJymLeYYbZr/f1 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AuAQAV17Ra/4QNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJJdGFwKAqDUod/jQ+BdIERjWiEYoIGCyWBVoMKAhqDTCE0GAECAQEBAQEBAmsohSUBAQEDASMKUQcEAgEIEQQBASsCAgIwHQgCBAESCIQiXAgPqHGCIIhBghUFhS+CEYFUQIEMgwaDEwEBAgGBcoJqglQDlzsIAoVPiFaBN4NWhzKJEIY8AhETAYEkARw4gVJwFYJ9giEYjhZvAY4PK4EEgRYBAQ
X-IronPort-AV: E=Sophos; i="5.48,349,1517875200"; d="scan'208,217"; a="87737297"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2018 10:34:18 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w2NAYIXk011845 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Mar 2018 10:34:18 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 23 Mar 2018 05:34:17 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Fri, 23 Mar 2018 05:34:17 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: David Mandelberg <david@mandelberg.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-spring-segment-routing.all@ietf.org" <draft-ietf-spring-segment-routing.all@ietf.org>
Thread-Topic: secdir review of draft-ietf-spring-segment-routing-13
Thread-Index: AQHTVAN+h13Fy6LhA0quT26NkWnvTKPee6yw
Date: Fri, 23 Mar 2018 10:34:17 +0000
Message-ID: <e32e5f9bc00043e3a8b86205d434c35d@XCH-ALN-001.cisco.com>
References: <3b7c6cdc-0e9e-0a57-e030-ae3a715c6a03@mandelberg.org>
In-Reply-To: <3b7c6cdc-0e9e-0a57-e030-ae3a715c6a03@mandelberg.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.5.233]
Content-Type: multipart/alternative; boundary="_000_e32e5f9bc00043e3a8b86205d434c35dXCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-CkYrffzShdRdWABXBIqA9JFoas>
Subject: Re: [secdir] secdir review of draft-ietf-spring-segment-routing-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2018 10:34:21 -0000

David -



Apologies. It appears that I neglected to respond to this old review comment.

This was not intentional. Authors actively discussed your comment promptly and we did add text in V14 of the draft to address this point:



Please see: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15#section-3.4



o  Indication whether the Adj-SID is persistent across control plane

      restarts.  Persistence is a key attribute in ensuring that an SR

      Policy does not temporarily result in misforwarding due to

      reassignment of an Adj-SID.



Please let us know if this adequately addresses your comment.



Again, apologies for the long delay.



   Les



> -----Original Message-----

> From: David Mandelberg <david@mandelberg.org>

> Sent: Thursday, November 02, 2017 10:53 AM

> To: iesg@ietf.org; secdir@ietf.org; draft-ietf-spring-segment-

> routing.all@ietf.org

> Subject: secdir review of draft-ietf-spring-segment-routing-13

>

> I have reviewed this document as part of the security directorate's ongoing

> effort to review all IETF documents being processed by the IESG.  These

> comments were written primarily for the benefit of the security area directors.

> Document editors and WG chairs should treat these comments just like any

> other last call comments.

>

> The summary of the review is Ready with nits.

>

> This document affects routing within a trusted domain, and the security

> considerations section adequately talks about filtering at the border of a trusted

> domain.

>

> I do have one question about something I didn't see in the document, what

> happens when SIDs change while packets are in transit? Here's a hypothetical

> situation that could be bad for security, but I'm not sure whether or not it could

> happen: 1. An internal node calculates an SR Policy and sends out a packet that

> will eventually egress towards a BGP peer. 2. Multiple links on the BGP router go

> down and then back up, but are allocated different PeerAdj SIDs than they had

> before. 3. The packet reaches the BGP router, but egresses to the wrong BGP

> peer because the original PeerAdj SID is now mapped to a different PeerAdj

> segment.

>

> --

> Freelance cyber security consultant, software developer, and more

> https://david.mandelberg.org/

v2.23.0 | Report a Bug | By Email