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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 18 June 2015 01:31 UTC

Return-Path: <brian.e.carpenter@gmail.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 BAE2F1A9051 for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 18:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX2fllDOjXOB for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 18:31:39 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01F31A906F for <v6ops@ietf.org>; Wed, 17 Jun 2015 18:31:38 -0700 (PDT)
Received: by pdjn11 with SMTP id n11so53848989pdj.0 for <v6ops@ietf.org>; Wed, 17 Jun 2015 18:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.70.96.65 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 mx.google.com with ESMTPSA id bn5sm5992309pbc.82.2015.06.17.18.31.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2015 18:31:37 -0700 (PDT)
Message-ID: <55821F7B.6010005@gmail.com>
Date: Thu, 18 Jun 2015 13:31:39 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
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 <furry13@gmail.com>
References: <20150515105406.GA3028@ernw.de> <87siav2m6p.fsf@stepladder-it.com> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <D17F4C51.4ABB0%evyncke@cisco.com> <20150611165858.GT39827@ernw.de> <CAFU7BAR7m0sZsU9Rc=fUao32zaRE1=9XMBWjiL0AukehdpVpWQ@mail.gmail.com> <5580CC33.2080503@gmail.com> <CAFU7BARv1QrhKihW=7ze+H1sFr1E5yGm1PTsnEH17Qus4vnhNA@mail.gmail.com>
In-Reply-To: <CAFU7BARv1QrhKihW=7ze+H1sFr1E5yGm1PTsnEH17Qus4vnhNA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/n5JVMNmrr0BMmlXcXLptRX8tomY>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ipv6-wg@ripe.net IPv6" <ipv6-wg@ripe.net>
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, 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
> <brian.e.carpenter@gmail.com> wrote:
>> On 17/06/2015 07:02, Jen Linkova wrote:
>>> https://tools.ietf.org/html/draft-wkumari-long-headers-03
>>>
>>> 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!

> it SHOULD
> 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.

    Brian

>> 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.
> 
>