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

Brian E Carpenter <> Thu, 18 June 2015 01:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BAE2F1A9051 for <>; Wed, 17 Jun 2015 18:31:41 -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 KX2fllDOjXOB for <>; Wed, 17 Jun 2015 18:31:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D01F31A906F for <>; Wed, 17 Jun 2015 18:31:38 -0700 (PDT)
Received: by pdjn11 with SMTP id n11so53848989pdj.0 for <>; Wed, 17 Jun 2015 18:31:38 -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=HxM3TIbXLjKMN/8DSOkTCYOjvlFhzjCFx5pR10mVcAo=; b=KPGqwMbrWa94I6IJy17g3/IbzrvC/ZGdm1dcUSBxJA3S9Vr/5a6tmsmXNjw0wVRgBz Ry1ZCouR5fFfTf3ZdnlzuzVDTRraVllu6uLylQwGBTfD02hbAtq+L5q5Cbvuc3yMOOFk 8Bz5lN3EWI9dKnoHIJxMdYCkvQEv5t73JMkvs/D5rriPDL/6kNUt5qqHI97l81AXJNFz MRrVjuRyr9JQ01i+aRA9TCXjenO8pwfTdlGkv4qTpc3CXdjiXmVQy5FJDVyM1V4URlol X2OmdR8WrVxL6r87FagDJC3jxzSDxJ2BKipm/ligioN6FFkagUMvD0U+o48lgVZ4xI6V 6EvA==
X-Received: by with SMTP id dq1mr16413107pdb.79.1434591098531; Wed, 17 Jun 2015 18:31:38 -0700 (PDT)
Received: from ?IPv6:2406:e007:64d6:1:28cc:dc4c:9703:6781? ([2406:e007:64d6:1:28cc:dc4c:9703:6781]) by with ESMTPSA id bn5sm5992309pbc.82.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 18:31:37 -0700 (PDT)
Message-ID: <>
Date: Thu, 18 Jun 2015 13:31:39 +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: Jen Linkova <>
References: <> <> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, " IPv6" <>
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: Thu, 18 Jun 2015 01:31:41 -0000

On 18/06/2015 04:54, Jen Linkova wrote:
> On Wed, Jun 17, 2015 at 3:24 AM, Brian E Carpenter
> <> wrote:
>> On 17/06/2015 07:02, Jen Linkova wrote:
>>> Comments are appreciated...
>> In REQ-2 on HbH headers, you say:
>>>  The forwarder MUST
>>>  process each option as specified in Section 4.2 of [RFC2460].
>> That aspect of RFC 2460 was fundamentally changed by RFC 7045.
> Oh, very good point. Thanks for pointing this out. Looks like it does
> cover our REQ2 (but requires different behavior).
> So,  Section 2.1 RFC7045 says about *all* EHs:
> "If a forwarding node discards a packet containing a standard IPv6
>    extension header, it MUST be the result of a configurable policy and
>    not just the result of a failure to recognise such a header. "
> and then, in Section 2.1 for HbH:
> "The IPv6 Hop-by-Hop Options header SHOULD be processed by
>    intermediate forwarding nodes as described in [RFC2460].  However, it
>    is to be expected that high-performance routers will either ignore it
>    or assign packets containing it to a slow processing path. ".
> I read this as 'if a router does not recognize/parse the HbH header,
> it MUST not discard it unless there is an explicit policy configured.
> It may just ignore it or send for "special processing" via slow path.
> So it assumes that it is always safe to ignore HbH header (as if all
> options in the header had highest-order two bits set to '00') while
> our draft proposed quite different approach ("drop and send ICMP
> back").

Right. And we can have that discussion, of course, but IMNSHO a firewall
should either let stuff through or drop it for a congigured reason; dropping
it because the product development manager made a lazy choice is not OK.

> Ignoring HbH header seems to be reasonable and safe if we are sure
> that every single existing or to be developed HbH option can be safely
> ignored (or options which could be ignored must be in the very
> beginning of the header...).

Well, we can't know today what sort of crazy option might be invented in
future; so the thinking behind draft-ietf-opsec-ipv6-eh-filtering
seems right to me. Maybe that's a draft you need to be tracking.

To be honest what I was thinking when we added discussion of HbH to
RFC 7045 was not so much fixing the slow routers, but warning the community
that "hop-by-hop" does not mean every hop. Fred would like to fix that
with his 6man draft, and I don't mean to attack that idea.

> In the light of RFC7045 it looks to me that one possible approach for
> REQ2 might be:
> - if a forwarder can not parse the HbH header and there is no
> explicitly configurable policy, 

AND if the forwarder is trying to be a firewall or otherwise
wants to interfere. If not, just forward the packet, already!

> either:
>    -- if the forwarder can not parse any of options or if all parsed
> options have highest-order two bits set to '00') - ignore the header;
>    -- if the forwarder was able to parse some of options and at least
> one of the options has highest-order two bits set to smth except '00'
> - discard the packet and send ICMPv6 message if Section 4.2 of RFC
> 2460 requires so (sending ICMPv6 MAY be subject to a configurable
> policy)
> or send it to slow path for full header processing (subject to a
> configurable policy).
> How does that sound?

As I said: if the forwarder insists on doing something, OK.

But we have to think for a typical use case: does it matter if a
forwarder simply ignores the HbH header? For example, for the
IntServ/RSVP case, it just makes that router transparent to
RSVP. That doesn't break RSVP; discarding the packet does. That
was the thinking behind RFC 7045.


>> I'm sure other things in the long-headers draft need revising as a
>> result of RFC 7045, since its whole topic is the handling of extension
>> headers ("This document updates RFC 2460 to clarify how intermediate
>> nodes should deal with such extension headers and with any that are
>> defined in the future.")
> Yes, we'll revise it, thanks for the comment.
>> Y'all also need to take account of RFC 7112, which forbids fragmented
>> header chains.
> We do mention 7112 but I agree, we should explicitly mention that
> header chain is limited by a packet size...Will update the doc.