Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06

"Arjun Sreekantiah (asreekan)" <asreekan@cisco.com> Thu, 12 October 2017 21:56 UTC

Return-Path: <asreekan@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 D9E6A1321A0; Thu, 12 Oct 2017 14:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 6W5RZrN5FUbL; Thu, 12 Oct 2017 14:56:40 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00753132FB1; Thu, 12 Oct 2017 14:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7464; q=dns/txt; s=iport; t=1507845400; x=1509055000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HMnTWf8TmjKEd4/+nehE8qSq3JBHWoKTMaZBjy8oZKs=; b=KhDm0E0pglpdJLXRMcW8ySiduUQ2VY5jrWtuM2gUYDkA+ebl2zRUXcNx Xl9wXDaSrscDykRYZom3bqOsopAQueMdP2foqYXY1ZnzB6+khCjdcHCo6 KCYG39YX3sSCcwQ5rMD5HIqK+3Y1tQqbXgd331WU+FQfl/xTNTmD9xFkb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CbAAAN5N9Z/40NJK1VBgMZAQEBAQEBAQEBAQEHAQEBAQGDXYFSJweDc4ofjzKBdpYvDoIECoU7AhqEJT8YAQIBAQEBAQEBayiFHgEFIxEzEhACAQgYAgImAgICMBUQAgQBDQWKHqtwgieLOwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BDoIfggeBUYFqK4J/hFIBCAMHATYKJoJML4IyBaFEApRoDJMElT4CERkBgTgBHziBAwt4FVsBhQcBG4FndokTDxiBDIERAQEB
X-IronPort-AV: E=Sophos;i="5.43,368,1503360000"; d="scan'208";a="305319231"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2017 21:56:38 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v9CLucJ6017311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Oct 2017 21:56:38 GMT
Received: from xch-rcd-019.cisco.com (173.37.102.29) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Oct 2017 16:56:37 -0500
Received: from xch-rcd-019.cisco.com ([173.37.102.29]) by XCH-RCD-019.cisco.com ([173.37.102.29]) with mapi id 15.00.1320.000; Thu, 12 Oct 2017 16:56:37 -0500
From: "Arjun Sreekantiah (asreekan)" <asreekan@cisco.com>
To: "John G. Scudder" <jgs@juniper.net>, "Brian Weis (bew)" <bew@cisco.com>
CC: stefano previdi <stefano@previdi.net>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-idr-bgp-prefix-sid.all@ietf.org" <draft-ietf-idr-bgp-prefix-sid.all@ietf.org>, "Gaurav Dawra (gdawra)" <gdawra@cisco.com>
Thread-Topic: Secdir early review of draft-ietf-idr-bgp-prefix-sid-06
Thread-Index: AQHTAtRSCuBzILjiK0OIovgMdDR4U6JmcY0AgA7UdgCAYmpQgIAJcoSA
Date: Thu, 12 Oct 2017 21:56:37 +0000
Message-ID: <EE3AEB95-D7BC-4EFC-A79D-FDCCC8F24F62@cisco.com>
References: <150071889993.20425.5273428383173596948@ietfa.amsl.com> <6A05B578-F8DE-4197-97B8-82886089782B@previdi.net> <DF8D0539-FC7E-479E-8F42-7E980A45AFEF@cisco.com> <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net>
In-Reply-To: <13FD5BC6-69AD-46F1-8767-DE11740A49A0@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.161.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5C471B932F10164D81143DF31568733A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/404YB5ZXyE4oMISGo8gAc9B6W4I>
Subject: Re: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06
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: Thu, 12 Oct 2017 21:56:42 -0000

John,
We will make the minor revision you suggest below and re-post the draft.  

Thanks,
Arjun




On 10/6/17, 7:40 AM, "John G. Scudder" <jgs@juniper.net> wrote:

>Hi Brian and Stefano,
>
>I'm glad Stefano's comments satisfy Brian. It seems to me that this clarification would be worth adding to a new revision of the draft:
>
>>> (c) Security Considerations speaks of limiting BGP Prefix-SID within a
>>> “domain”. Is that intending to say an “SR domain”?
>> 
>> More generally, by domain we intend the set of AS under control of the same organization/operator.
>
>Seems as though the other nits were addressed with no change needed, or that's my understanding of the consensus between Brian and Stefano.
>
>Stefano or other authors, can you either make the minor revision indicated, or reply that you don't plan to?
>
>Thanks,
>
>--John
>
>> On Aug 4, 2017, at 7:46 PM, Brian Weis (bew) <bew@cisco.com> wrote:
>> 
>> Hi Stefano,
>> 
>> Thanks for your notes below, which make sense to me. I don’t have any more comments. 
>> 
>> Brian
>> 
>>> On Jul 26, 2017, at 6:18 AM, stefano previdi <stefano@previdi.net> wrote:
>>> 
>>> Hi Brian,
>>> 
>>> thanks for the review. Some comments here below.
>>> 
>>> 
>>>> On Jul 22, 2017, at 12:21 PM, Brian Weis <bew@cisco.com> wrote:
>>>> 
>>>> Reviewer: Brian Weis
>>>> Review result: Has Nits
>>>> 
>>>> 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.
>>>> 
>>>> This document describes a BGP extension to signal the BGP Prefix-SID use with
>>>> Segment Routing.  as well as the rules to originate, receive and handle error
>>>> conditions. The BGP extension defines a new type of BGP path attribute passed
>>>> within BGP, and does not change the security considerations of the BGP protocol
>>>> itself.
>>>> 
>>>> I consider this document “ready with nits”.
>>>> 
>>>> The Security Considerations section reasonably states that the use of this BGP
>>>> attribute “inherits the security considerations” of the BGP-4 RFC as well as
>>>> the RFC defining how labels are carried in BGP-4. As an aside, those documents
>>>> are quite old. For example, RFC 4271 says that the TCP-MD5 option is required
>>>> to implement for authentication, but this has been replaced by a much stronger
>>>> authentication method (TCP-AO). It would be nice if we had newer security
>>>> considerations for BGP-4 but that advice doesn’t belong in this document.
>>>> 
>>>> The Security Considerations might have said something about the how an AS would
>>>> protect itself against a peer sending the Prefix-SID attribute across AS
>>>> boundaries, but that text is contained in useful places elsewhere in the
>>>> document and seems sufficient.
>>>> 
>>>> I have only one nit, which is some confusion regarding scoping of the SID. The
>>>> document clearly states that a SID has a limited scope within the network, 
>>>> which is important because outside of that scope an SID value would have a
>>>> different meaning. This is a security  consideration, because accepting a SID
>>>> in the wrong scope could possibly cause a security issue if packets are
>>>> forwarded to the wrong identity (e.g, the packets were intended for a firewall
>>>> within the AS, not a service outside of the AS).
>>>> 
>>>> (a) Section 5.1 says it should not be advertised outside of an AS unless
>>>> “explicitly configured to do so”. It would be nice if the conditions for
>>>> explicitly configuring the SID to be advertised outside of the AS were
>>>> mentioned here.
>>> 
>>> 
>>> usually we don’t define these condition because they are related to each individual operator policy. What we want to be sure of is that any compliant implementation, by default, will not propagate the attribute outside the AS.
>>> 
>>> Under which conditions propagation is allowed is a local matter of the operator and how it is effectively achieved is a matter of local implementation.
>>> 
>>> 
>>>> (b) The last paragraph of Section 8 says it is applicable within an SR Domain
>>>> (i.e., more than an AS), and Security Considerations says something similar.
>>>> 
>>>> (c) Security Considerations speaks of limiting BGP Prefix-SID within a
>>>> “domain”. Is that intending to say an “SR domain”?
>>> 
>>> 
>>> More generally, by domain we intend the set of AS under control of the same organization/operator.
>>> 
>>>> I suspect whether an SID should be advertised outside of the AS depends on
>>>> whether an AS is part of an “SR domain” or not, and that there's likely never a
>>>> good case to advertise it outside of an AS unless it is part of an "SR domain".
>>>> But it would be good if there was some text clarifying  the conditions when it
>>>> is reasonable to share an SID between ASes.
>>> 
>>> 
>>> Well, I’m not sure that would be a good idea because the conditions may vary over time and we will never be exhaustive anyway.
>>> Thanks.
>>> s.
>>> 
>>> 
>>>> 
>>> 
>> 
>> -- 
>> Brian Weis
>> Security, CSG, Cisco Systems
>> Telephone: +1 408 526 4796
>> Email: bew@cisco.com
>> 
>