Re: [v6ops] Extension Headers / Impact on Security Devices

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Thu, 28 May 2015 19:01 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62281A1BDB for <v6ops@ietfa.amsl.com>; Thu, 28 May 2015 12:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 sbIckIuqvRQ5 for <v6ops@ietfa.amsl.com>; Thu, 28 May 2015 12:01:34 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13641A8032 for <v6ops@ietf.org>; Thu, 28 May 2015 12:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3246; q=dns/txt; s=iport; t=1432839666; x=1434049266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4QnAiNQMzpoXrThGAjpx6tDHI3EBipKgCqhLkEWWyNQ=; b=a9guqKuqOlHH3dnzJYH+se+u+2Zg0YAJfOk64BOxX+3piYPFWbOlDUkf a5qyC5QoQjHcQ4n6RJVOyxUdD1660XAGudUZzTup5Oiaha9iqPMT0PFcr n/7WmdtPllrOTlYFwpuOiuxJzsfpH8ajAP0xhXQYXS0q5JYuBxnuuQFqQ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ASBQDLZGdV/5xdJa1cDoMCVF4GvQiCPwqFdwKBTEwBAQEBAQGBC4QiAQEBAwEBAQELVwkLEAIBCBguJwslAgQOBYglCA3VSQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OEUzMHgxeBFgWMCoZ+iw+BKZItg1kjgWaBVD5vgUaBAQEBAQ
X-IronPort-AV: E=Sophos;i="5.13,513,1427760000"; d="scan'208";a="423442766"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 28 May 2015 19:01:06 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4SJ15gp025641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 May 2015 19:01:05 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.227]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 28 May 2015 14:01:05 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: Joe Touch <touch@isi.edu>
Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices
Thread-Index: AQHQjwOUSoUfhjfqOU2VSvc4/QdUh52O8gsqgABXE4CAAAaigIAABSaAgAAHmwCAAHnhgIACNimAgAANaACAAA0fAA==
Date: Thu, 28 May 2015 19:01:05 +0000
Message-ID: <3EBA13CE-8E8A-4969-86B7-CD8047F876F1@cisco.com>
References: <555AB8FA.2080405@si6networks.com> <F6AA9AEA-49F0-488C-84EA-50BE103987C8@nominum.com> <555B8622.5000806@isi.edu> <555BA184.8080701@gmail.com> <555BA43F.8010303@isi.edu> <5564FB74.5020303@gmail.com> <5564FE3F.4050102@isi.edu> <556503CF.4030101@gmail.com> <55650821.4060907@isi.edu> <55650E82.3090407@gmail.com> <20150527073943.GA54385@Space.Net> <D18CFF39.4C411%evyncke@cisco.com> <55675AEC.10602@isi.edu>
In-Reply-To: <55675AEC.10602@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.95.5]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9680E4CC1AAB1646BF38C170DBDD3E82@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-uIswisgf_CLlDnJhs2_3py2Tpw>
X-Mailman-Approved-At: Fri, 29 May 2015 09:56:19 -0700
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "Mark Townsley (townsley)" <townsley@cisco.com>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 19:01:35 -0000

On May 28, 2015, at 8:14 PM, Joe Touch <touch@isi.edu> wrote:

> 
> 
> On 5/28/2015 8:26 AM, Eric Vyncke (evyncke) wrote:
>> Segment Routing Header is currently drafted as another type of routing
>> header and are drafted to be inserted either by the source or by the
>> ingress router of a SR-configured domain (then being removed at the exit
>> of the SR-domain). Destination Option is not useful here as it is
>> inspected/processed only by the destination while the intent of SR is to
>> have this information processed by a couple of intermediate routers (which
>> have a specific configuration as SRH is not enabled by default).
> 
> Agreed, but note that some Dest Options can occur before the Routing
> Header options (RFC 2460 Sec 4.1), e.g., where those DOs are relevant to
> the next router as a "destination" - i.e., those DOs are processed
> before the RH.
> 
>> Of course, this causes MTU issues (pretty much like MPLS but at a
>> different layer) within one domain which is solvable
> 
> Which is slightly more problematic because the Frag Header comes *after*
> the Routing Headers, but - as you note - solvable using context.


the networking industry already faced the mtu "issue" more than 15 years ago with the introduction of the label stack. The reality of network operators infrastructure is such that the mtu is not really an issue.

s.


> 
> Joe
> 
>> The performance
>> issues need to be handled (as Joe wrote). But, as long as the pros/cons
>> balance is on the pro side, then it is valuable.
>> 
>> -éric
>> 
>> 
>> On 27/05/15 09:39, "Gert Doering" <gert@space.net> wrote:
>> 
>>> Hi,
>>> 
>>> On Wed, May 27, 2015 at 12:23:30PM +1200, Brian E Carpenter wrote:
>>>>> FWIW, I don't see anything that prohibits adding headers either.
>>>> 
>>>> "With one exception, extension headers are not examined or processed
>>>> by any node along a packet's delivery path, until the packet reaches
>>>> the node (or each of the set of nodes, in the case of multicast)
>>>> identified in the Destination Address field of the IPv6 header."
>>>> 
>>>> To me that clearly implies not adding (which is a form of processing).
>>> 
>>> So how do the SR folks handle that?  From what I heard, the intended
>>> deployment really is "inside your administrative domain, SR headers get
>>> added, processed, and when the packet leaves your domain, they can be
>>> (optionally) removed again to not upset your neighbours"...
>>> 
>>> Gert Doering
>>>       -- NetMaster
>>> -- 
>>> have you enabled IPv6 on something today...?
>>> 
>>> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>>> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
>>> Grundner-Culemann
>>> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>>> Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>