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

Brian E Carpenter <> Tue, 26 May 2015 23:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 021CF1B32F5 for <>; Tue, 26 May 2015 16:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TF0VU2Sh_xfG for <>; Tue, 26 May 2015 16:06:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80DF31B32F3 for <>; Tue, 26 May 2015 16:06:22 -0700 (PDT)
Received: by pacwv17 with SMTP id wv17so103411429pac.2 for <>; Tue, 26 May 2015 16:06:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rp9ZDxrtmNstj7VV77NgAcYnU+4Zc1hJe0bKQtH4oHQ=; b=k6HgjYGHMcQ1ZvrMUzcmgz2hoh3eoFATsWPMSp68Mr7ri0x9t6swi1JdFoaUxbkUep UjkrZq6p2RHebkDx9CMw2ix9gg7ZyZtsdj6CGMClk4CSV2dh/wlhAzaQGOD68JzzuLO2 Vmu9oLK9CjESZxT5c6S9z9w2adzkmbIx3kv5EtsHt2P89W0IiK+8uocnSSbSdjvhZ8a4 ol/xng8dReKOkEjcOpOzlgOm3Lj+Es7enDhFPqInhwoXbADFF6W204l+lPF1Iqx5OWL9 iOVdaGrpKwje9uiMuFMt7Js02LdMyt/53DgEXGh4fiLUVu4gW4YOCW3wUnOtBV5Nv8oJ rOzA==
X-Received: by with SMTP id qt6mr53727323pbb.160.1432681582245; Tue, 26 May 2015 16:06:22 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by with ESMTPSA id da3sm14142484pdb.8.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 May 2015 16:06:21 -0700 (PDT)
Message-ID: <>
Date: Wed, 27 May 2015 11:06:20 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Mark ZZZ Smith <>, "Eric Vyncke (evyncke)" <>, Tim Chown <>, Joe Touch <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 May 2015 23:06:25 -0000

On 26/05/2015 17:27, Mark ZZZ Smith wrote:
> ________________________________
> From: Eric Vyncke (evyncke) <>
> To: Tim Chown <>uk>; Joe Touch <> 
> Cc: "" <> 
> Sent: Wednesday, 20 May 2015, 22:28
> Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
> On 20/05/15 10:14, "Tim Chown" <> wrote:
>> The other question is what existing work is being done that relies on the
>> correct (desired) operation of EHs? The two that would spring out would
>> be segment routing and sfc, at least one of which is using the existing
>> Routing Header. If such protocols are constrained to specific
>> administrative domains then their successful operation I would assume is
>> down to specific EH handling in the equipment in that domain, and its
>> capabilities, rather than (undesired) operator filtering somewhere
>> between sender and receiver.
> The primary use case of segment routing is indeed within a single
> administrative domain, so, EH does not cause a problem.

I've lost track of who wrote that (Tim?), but it's only true if
all middleboxes respect RFC 7045, especially the bits about what
needs to be configurable and what the factory defaults should be.

> OTOH, this whole discussion is pretty close to having a discussion on
> whether an ISP should block everything which is neither UDP nor TCP? Or
> block currently-unallocated TCP/UDP ports? (and I appreciate that there
> are differences of course).

Again: all these choices need to be configurable, so that providers
can make their own choices and decide what to break. I assume that
discussion belongs in opsec.


> / +1
> / In my opinion a huge amount of security context is missing from this discussion, to the point where the question has been simplified to a too simplistic and binary EHs or not question, and there is never going to be consensus on that question.
> / There seems to be an underlying and unstated set of assumptions behind the sorts of "block EHs","must be able to look at TCP/UDP headers in the network" questions/statements : 
> / (a) the network is the only place that network, host and application security can and must be done, implying that hosts and applications do nothing to protect themselves
> / (b) that the contents of packets will always remain transparent to the network, allowing them to be inspected in the network
> / and (c) that all traffic to and from a host/application will always traverse a single inspection/choke point in the network and will always use the same Internet protocol.
> / I think all of the above assumptions were true up until about the mid 1990s (if I remember well enough). Since then, they've all become false to varying degrees. Consequently, a choke point in the network may not be the best place to perform all network, host and application security measures, and in some cases persisting with that model will cause security failures. (For example, it seems that hosts aren't the lowest hanging fruit for network delivered malware any more, it is residential CPE itself - the device that is supposed to be so effective at providing "security" (including implicitly via NAT) that theoretically downstream hosts don't need firewalls at all.)
> To Enno's original point: it is fair for a destination domain to handle
> (permit, drop, log, inspect) incoming (or outgoing BTW) packets based on
> layer-4 ports, layer-4 protocols or extension headers. This is their own
> responsibility
> -éric
> _______________________________________________
> v6ops mailing list
> _______________________________________________
> v6ops mailing list