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