Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08

Tobias Gondrom <> Thu, 17 October 2013 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7052111E810B for <>; Thu, 17 Oct 2013 01:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -95.102
X-Spam-Status: No, score=-95.102 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TzPVlKxwsmCr for <>; Thu, 17 Oct 2013 01:17:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 20F9321F9A50 for <>; Thu, 17 Oct 2013 01:17:00 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=kqxKUvjnrWJnjMCyCM3sYdUAD7HpJW3t5zHprbwI8EhZN+UsVupo4Om1TZAlbVwHCkPNoXA1T4FqY1ugz25Zit5WYw2Ezaqqk1JYE8uZFwxWIRFG66QHOP8LV5POPKtc; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 1143 invoked from network); 17 Oct 2013 10:16:57 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Oct 2013 10:16:57 +0200
Message-ID: <>
Date: Thu, 17 Oct 2013 09:16:56 +0100
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Oct 2013 08:17:08 -0000

Thank you for your answers.
All the best, Tobias

On 17/10/13 01:59, Fernando Gont wrote:
> On 10/16/2013 07:34 PM, Tobias Gondrom wrote:
>>>> 1. A question, less from a security, but interoperability perspective:
>>>> is there any deplyoment data on any potential backwards compatibility
>>>> issues with current IPv6 deployments? Namely are there noteworthy
>>>> deployments with large IPv6 header chains beyond the first fragment
>>>> currently in deployment?
>>> No.
>> Does this "No" mean:
>> (1) there are no noteworthey deployments or does it only mean
>> (2) we have no data at all and therefore don't know what we will break
>> with the update?
> There are no specified use cases for such oversized header chains (for
> instance, look at the extension header types and options specified so far).
> Besides, what I've seen and what others have indicated is the same: with
> the addition that any intentional use of extension headers typically
> leads to packet drops (see draft-ietf-6man-ext-transmit-05.txt).
>>>> 2. section 5 third paragraph:
>>>> I wonder whether we should be more strict and replace the "MAY" with a
>>>> "SHOULD"?
>>>> This would make intermediate behavior consistent with the host from the
>>>> previous paragraph and should avoid inconsistencies within the network
>>>> topology?
>>> IIRC, the "intermmediate systems MAY drop" is so that intermmediate
>>> systems are not required to process the entire header chain. -- i.e.:
>>> "If you want to drop such packets, you're free to... but we don't
>>> require e.g. routers to process the entire IPv6 header chain to find
>>> whether the entire header chain is present and then decide whether to
>>> drop or not".
>>> OTOH, the "MAY send an ICMPv6 error message" could be changed to "if you
>>> drop, you SHOULD send an ICMPv6 error message", I guess.
>>> Thanks,
>> I see. Actually I meant both, but let's look at them separately:
>> 1. "intermmediate systems MAY drop"
>> Actually a "SHOULD" does not require them either, but substantially
>> encourages more than the "MAY".
> An implementation that does not follow SHOULDs is said to be
> "conditionally complaint" where in our case, we deem a middle-box that
> doesn't drop such packets as fully-cumpliant  hence the "MAY".
> If a middle-box does not really need to look at the upper-layer header,
> then requiring (SHOULD) it to look at the header chain just to drop the
> offending packets is rather overkill.
>> Question: I assume from your answer,
>> most intermediate systems just pass through without checking that the
>> header conform to updated 2460,
> Well, packets that do not contain the entire IPv6 header chain in the
> first fragment are currently RFC2460-compliant -- that's exactly why
> we're pushing this document.
>> 2. For the ICMPv6 error message, you are right that should be a "SHOULD"
>> not a "MAY" as it is on the condition of the dropped packet.
> I will change this unless anyone objects (or points out something I may
> have missed).
> Thanks!
> Best regards,