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

Jen Linkova <furry13@gmail.com> Wed, 17 June 2015 16:55 UTC

Return-Path: <furry13@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 8D8881B2ADE for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 09:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 xSxnszYb2rOV for <v6ops@ietfa.amsl.com>; Wed, 17 Jun 2015 09:55:21 -0700 (PDT)
Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 6EB041B2AD7 for <v6ops@ietf.org>; Wed, 17 Jun 2015 09:55:20 -0700 (PDT)
Received: by ykfl8 with SMTP id l8so45020603ykf.1 for <v6ops@ietf.org>; Wed, 17 Jun 2015 09:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rrP7Af7srA6x9Zigh+RSFXR3oRJlX+8YLg8+tkIOatc=; b=BxzVXKzSMooTwd4T6CsaoxjhjtZ8hsvxYvcoVafXlo5abrl4FOXiusbmR4Q+S+K9u4 rDeHMdWg5/m3F5uYDQT0yY/TcVQrx5xz3MGJNd4OEpgHmN5z8qhhniITP6yvQe5j1dUA 08RX1h31BjtIAZE3loaBgdRr4Bb5ElyOAsC9zTPtF9l66xnc1nyOBExes9SeX8DesarQ 7oyPGRXH81xgNCcYnbydtlPsZk62bp4BkJYeXaGMORk4QJ/9R29RP6eGSgxfDVpVEEEo HCWM56wfhmXp5aiN7ZfQg1yySyJLuMlD+FKn7v/HOS7ajqbUWIjsxpsocrde7u9SWxbH 1swA==
X-Received: by 10.52.100.103 with SMTP id ex7mr5432812vdb.71.1434560119760; Wed, 17 Jun 2015 09:55:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.82.130 with HTTP; Wed, 17 Jun 2015 09:54:59 -0700 (PDT)
In-Reply-To: <5580CC33.2080503@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>
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 17 Jun 2015 18:54:59 +0200
Message-ID: <CAFU7BARv1QrhKihW=7ze+H1sFr1E5yGm1PTsnEH17Qus4vnhNA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/uGcxudTOjcUtN6eDDn4FW25P-Ug>
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: Wed, 17 Jun 2015 16:55:22 -0000

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

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

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, 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?

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


-- 
SY, Jen Linkova aka Furry