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

Joe Touch <touch@isi.edu> Thu, 28 May 2015 18:15 UTC

Return-Path: <touch@isi.edu>
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 42BD91B2C3A for <v6ops@ietfa.amsl.com>; Thu, 28 May 2015 11:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ehn1N-DozFCg for <v6ops@ietfa.amsl.com>; Thu, 28 May 2015 11:15:14 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E6561B2CA5 for <v6ops@ietf.org>; Thu, 28 May 2015 11:15:11 -0700 (PDT)
Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4SIE4oH003871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 May 2015 11:14:04 -0700 (PDT)
Message-ID: <55675AEC.10602@isi.edu>
Date: Thu, 28 May 2015 11:14:04 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Gert Doering <gert@space.net>, Brian E Carpenter <brian.e.carpenter@gmail.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>
In-Reply-To: <D18CFF39.4C411%evyncke@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-MailScanner-ID: t4SIE4oH003871
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/TrCCZj8VNVGnoTUvJPB_NJEeN90>
Cc: "Mark Townsley \(townsley\)" <townsley@cisco.com>, "v6ops@ietf.org" <v6ops@ietf.org>, "Stefano Previdi \(sprevidi\)" <sprevidi@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 18:15:16 -0000


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.

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
>