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

Joe Touch <touch@isi.edu> Wed, 27 May 2015 17:24 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 7A9711A883C for <v6ops@ietfa.amsl.com>; Wed, 27 May 2015 10:24:50 -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 09Ap5QWlONHP for <v6ops@ietfa.amsl.com>; Wed, 27 May 2015 10:24:49 -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 736601A8834 for <v6ops@ietf.org>; Wed, 27 May 2015 10:24:49 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4RHO1R1025079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2015 10:24:01 -0700 (PDT)
Message-ID: <5565FDB1.2070307@isi.edu>
Date: Wed, 27 May 2015 10:24:01 -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: 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>
In-Reply-To: <20150527073943.GA54385@Space.Net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t4RHO1R1025079
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/69xjfRA-FHTNsrY0VSc__HQOSHY>
Cc: v6ops@ietf.org
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: Wed, 27 May 2015 17:24:50 -0000


On 5/27/2015 12:39 AM, Gert Doering 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"...

AFAICT, SR headers are destination options, and aren't supposed to be
modified by anything but the endpoints (where each addressed hop in such
a route is such an endpoint).

So I would think that they MUST NOT be added to IPv6 datagrams except by
the source.

In many of the cases we're discussing, the nodes inside an AD act "on
behalf" of a source or sink, and that's the logic by which they are
allowed such modification. HOWEVER, whenever you act on behalf of a
source or sink, you ARE effectively a source or sink and thus beholden
to the source/sink requirements, not merely router requirements.

I.e., if you want the performance of a router, act like a router and
nothing more. If you want to act like a host, you need will have the
performance of a host.

Joe