Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06

Stewart Bryant <stbryant@cisco.com> Fri, 11 October 2013 18:52 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 A85D311E818C; Fri, 11 Oct 2013 11:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.504
X-Spam-Level:
X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 wzEDzf7flR0f; Fri, 11 Oct 2013 11:52:35 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 57ED411E81A2; Fri, 11 Oct 2013 11:52:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1649; q=dns/txt; s=iport; t=1381517550; x=1382727150; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iEdF2EOfQEP4OTuuL/7c6+9tCEDnPBKgu2jVnqpbRuA=; b=agavlJ2yb7iNY3WvEK9Ro6y5CQZhlP3b7UeVLoq0ZdUmQ3u9yjrnu4O4 LLUJFKVlsfOaEfmf+Esr5ObhVJ9rkFtILXH6oE9Hehc7SVl+Tq19vstS0 RGb8thXoaWAcPDvMAi3n7517NyH8yDSgMQE7tpUM6LdTxNUKKszsvewpb Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAANIWFKQ/khR/2dsb2JhbABagwe/YYMDgSUWdIIlAQEBBDg8BAEQCxgJFg8JAwIBAgFFBg0BBwEBF4dru0uPRweEIwOYBZICgyU
X-IronPort-AV: E=Sophos;i="4.93,477,1378857600"; d="scan'208";a="18223637"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 11 Oct 2013 18:52:27 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9BIqM5o029653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Oct 2013 18:52:23 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r9BIqHk6002696; Fri, 11 Oct 2013 19:52:18 +0100 (BST)
Message-ID: <525848E1.3000806@cisco.com>
Date: Fri, 11 Oct 2013 19:52:17 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Hannes Gredler <hannes@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net>
In-Reply-To: <20131011183222.GA30073@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <narten@us.ibm.com>, Jari Arkko <jari.arkko@piuha.net>, "iesg@ietf.org" <iesg@ietf.org>, "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
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: Fri, 11 Oct 2013 18:52:40 -0000

On 11/10/2013 19:32, Hannes Gredler wrote:
> On Fri, Oct 11, 2013 at 04:11:53PM +0300, Jari Arkko wrote:
> | After some off-line chatting, I have a proposal for text to be added to the charter:
> |
> | There are a number of serious security concerns with source routing at the IP layer [RFC 5095].  As a part of its work, the working group will define the new IPv6-based routing header in way that blind attacks are never possible, i.e., attackers will be unable to send source routed packets that get successfully processed, without being part of the negations for setting up the source routes or being able to eavesdrop legitimate source routed packets. In some networks this base level security may be complemented with other mechanisms, such as packet filtering, cryptographic security, etc.
> |
> | Would this work for people? FWIW from what I can tell, the above should be relatively easily doable, short cookies in headers, etc. It would remove my main concern of accidentally turned on devices becoming a security hole. It would also help deployment, as firewalls might otherwise default to blocking all kinds of routing headers.
>
> jari,
>
> i do not think that packet-filtering is feasible on the default-free-zone
> on the internet. - can you take off packet-filtering in favour of security cookies ?
>
Packet filtering is prefixed by such as. In some cases it may be 
feasible and better
that a cookie. I can add cookies to the list without requiring any 
particular solution
be picked at this stage. The list is just, I believe to provide 
confidence that a solution
is feasible in the various contexts.

Stewart