Re: [Status] SPRING Charter
Stewart Bryant <stbryant@cisco.com> Wed, 16 October 2013 17:17 UTC
Return-Path: <stbryant@cisco.com>
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47BF11E8182; Wed, 16 Oct 2013 10:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.522
X-Spam-Level:
X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ummdBGzL2oBU; Wed, 16 Oct 2013 10:17:14 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 645EF11E81A4; Wed, 16 Oct 2013 10:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4842; q=dns/txt; s=iport; t=1381943825; x=1383153425; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wsRrem2aQ0RCSKVRf4CXomDM7/n5hxu0dR0nAtF4DV8=; b=ZGac8YsnhKL8hm5iAv482g1YqAcA/doRNzGQh5PslQoXAv8YT+ZrDjvU 0RTC4N79Bz3X8GRRgGIttRdRqnnN0P+z8VDRTDGp5QW9wJAsjdSKf5rq+ Id7b0s21xup6DSLXrUpCHQ881g5ed3rPRrYGIr57Wrx6bR5X13DJVs+yA E=;
X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="18797683"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 16 Oct 2013 17:17:03 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9GHGvVh007022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 17:16:59 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9GHGtmu025998; Wed, 16 Oct 2013 18:16:56 +0100 (BST)
Message-ID: <525ECA07.2070207@cisco.com>
Date: Wed, 16 Oct 2013 18:16:55 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
In-Reply-To: <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Benoit Claise <bclaise@cisco.com>, Jari Arkko <jari.arkko@piuha.net>, "status@ietf.org" <status@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:status-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:status@ietf.org>
List-Help: <mailto:status-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:status-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 17:17:20 -0000
On 15/10/2013 14:46, Thomas Narten wrote: > Looking at the most recent charter proposal (-15), I have the > following questions/observations: > >> The SPRING working group will define procedures that >> will allow a node to steer a packet along an explicit >> route using information attached to the packet and >> without the need for per-path state information to be >> held at transit nodes. > Who adds these "segment routes" (or whatever we call them -- I'll call > the SRs in this message)? Can an originating end node add them, or is > their an assumption that only network nodes add them? My assumption is that only a "trusted" node can add them. A few months ago I would have said that only a router could add the SR, but the interest in network virtulazation is blurring the line between routers and hosts. However the architecture will need to include the facility to segregate trusted and untrusted traffic, and my assumption has always been that untrusted traffic will need to be encapsulated on entry to an SR network to ensure that any band intent is appropriately neutralized. > My assumption is that it is network nodes (not the originating hosts) > that do that. Certainly, that is the case in MPLS and for many of the > use cases (as I understand them). That is what I have seen. > When it comes to IPv6, however, the question of who is capable of > adding these "segment routes" becomes very significant. If the > originating end node can add SRs, the attack surface for exploiting > SRs becomes much more complicated and hard to defend against. And if > end nodes can add these SRs, its hard for me not to see this problem > as equivalent to source routes as IPv6 originally had them and then > deprecated. We really have two types of node - trusted nodes an untrusted nodes. Consider an example other than NFV. Would it be OK of a provider's radius server to issue such packets inside the network. This is certainly a trusted node and it would be difficult to justify the complexity of an intermediate router to put the encap on. On the other hand you would be insane to allow a BYOD on the guest network to also do so. > Also, architecturally, having middle boxes (including for > SR purposes) add/modify/remove headers raises pretty significant > architectural issues. Well tunnel headers are certainly OK, but modifying the client header causes all sorts of problems. > IPv6 had generally not done this and frowned on > doing so. Having network nodes *add* SRs would raise questions in this > regard. In the native header I agree. > On the other hand, if only network nodes can add SRs, it also raises > the question of whether the right way to do this is by adding SRs to > the *original* packet as originated by an end host, or whether a new > outer header should be added, in which case we are tunneling within a > region where SRs are in use. A tunneling approach changes the attack > surface considerably, and probably makes it much easier to ensure that > SRs can only be originated within the domain in which they are used. We agree on this point. > I think it would be good to clarify this in the charter, given that > the IPv6 and MPLS assumptions are so different. Looking at John's note > "There is an assumed trust model such that any node > imposing an explicit route on a packet is assumed to > be allowed to do so, however administrative and trust > boundaries may strip explicit routes from a packet." > > Some hosts may be part of the trust domain. Others may not. Could we perhaps say: "There is an assumed trust model such that any node imposing an explicit route on a packet is assumed to be allowed to do so. Some hosts may be part of the trust domain, but others may not. SPRING must provide the means to distinguish between these two classes of host and prevent untrusted hosts from imposing a route on its packets. Administrative and trust boundaries may strip explicit routes from a packet." > Also, this item: > >> Definition of requirements and/or any new data plane The deliverable should actually be "Definition of requirements for any new data plane" >> encodings and procedures, required to implement >> the use cases. Such procedures must include the >> necessary security considerations. > Suggests to me that SPRING is being given the go ahead to define IPv6 > mechanisms to do SR. IMO, any IPv6 protocol work should be done in > 6MAN. SPRING should do requirements, etc., but IMO IPv6 protocol work > needs to be done where the IPv6 expertise is. Or at the very least > with very close coordination. Yes - Stewart > > Thomas > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
- Re: [Status] SPRING Charter Stewart Bryant
- [Status] SPRING Charter Stewart Bryant
- Re: [Status] SPRING Charter Stewart Bryant
- Re: [Status] SPRING Charter Benoit Claise
- Re: [Status] SPRING Charter Benoit Claise
- Re: [Status] SPRING Charter Stewart Bryant
- Re: [Status] SPRING Charter Thomas Narten
- Re: [Status] SPRING Charter John G. Scudder
- Re: [Status] SPRING Charter Thomas Narten
- Re: [Status] SPRING Charter Mark Townsley
- Re: [Status] SPRING Charter Alvaro Retana (aretana)
- Re: [Status] SPRING Charter Stewart Bryant
- Re: [Status] SPRING Charter John G. Scudder
- Re: [Status] SPRING Charter Alvaro Retana (aretana)
- Re: [Status] SPRING Charter Jari Arkko
- Re: [Status] SPRING Charter Robert Raszuk
- Re: [Status] SPRING Charter Jari Arkko
- Re: [Status] SPRING Charter Robert Raszuk