Re: [Status] Status of Spring

Jari Arkko <jari.arkko@piuha.net> Thu, 10 October 2013 21:03 UTC

Return-Path: <jari.arkko@piuha.net>
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 73B3111E80E2 for <status@ietfa.amsl.com>; Thu, 10 Oct 2013 14:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.276
X-Spam-Level:
X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, 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 ZhGOWZjSj-IM for <status@ietfa.amsl.com>; Thu, 10 Oct 2013 14:03:50 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3B72021E808F for <status@ietf.org>; Thu, 10 Oct 2013 14:03:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 328562CC95; Fri, 11 Oct 2013 00:03:46 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-hWO1TOUMJ1; Fri, 11 Oct 2013 00:03:45 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 7F6752CC48; Fri, 11 Oct 2013 00:03:45 +0300 (EEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <5256F76D.9080905@cisco.com>
Date: Fri, 11 Oct 2013 00:03:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <16DFA9F1-B523-4A14-B270-FC77B0A1DD43@piuha.net>
References: <52569169.20404@cisco.com> <CA+b+ERmj13sz4yi+aQXwGKuu7boOKkz6CbcB9pYXqHV-_FMhSw@mail.gmail.com> <5256F76D.9080905@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1510)
Cc: Joel Jaeggli <joelja@bogus.com>, "John G. Scudder" <jgs@bgp.nu>, Alvaro Retana <aretana@cisco.com>, Benoit Claise <bclaise@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>, "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] Status of Spring
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Thu, 10 Oct 2013 21:03:55 -0000

Thanks Stewart and others.

I wanted to add one clarification and some more technical discussion.

> Jari who is the main discuss holder will work with us over
> the next couple of days to try to get some text that will allow
> us to go forward. 

I would really like to work with you to get this resolved. I see the issue, as I think do others, but I need your help in the WG to figure out what to do about it. I do not currently have a good idea, but I am sure we'll resolve it somehow. Some of you have already offered help - thanks. 

To provide a bit more context why just saying that we'll use it in closed networks is unlikely to work:

The MPLS case was easy because these networks are naturally restricted to specific areas, and there is no way for a random person in some other part of the Internet to send you packets with MPLS labels.

The basic problem with IP is that when someone defines a new source-routing header solution and applies it in network X, it does not affect just X. The code will be on various devices - with RH0 we had it on BSD, Linux, various brands of routers, maybe even on hosts, etc. Often turned on by default, leaving vulnerabilities open in many networks.

We could say that the feature MUST be by default off and can only be enabled upon explicit request from the network manager. However, if I have a thousand devices in my network I start to worry that at least one of them has accidentally enabled the feature. So now that device could potentially reflect traffic sent to it from the outside to an internal destination. This could be used to subvert firewall policies, DoS attacks on nodes not visible from the Internet, etc. As a result of this worry I now have to turn on filtering on the border of my network for the new routing header. Is there a way around this?

Also, the charter is clear that you are wishing for at least an eventual inter-AS solution. That raises the bar.

In any case, I could completely off base with the above - I have not read your proposed solutions and maybe you are thinking of something completely different, or have already found the clever solutions to the problem. I'm happy to learn more :-)

Jari