Re: oversized-header-chains: Receipt of illegal first-fragments

Fernando Gont <> Thu, 19 July 2012 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FABC11E80E0 for <>; Thu, 19 Jul 2012 16:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dTHQ7hN0hfCr for <>; Thu, 19 Jul 2012 16:46:06 -0700 (PDT)
Received: from ( [IPv6:2a00:d10:2000:e::3]) by (Postfix) with ESMTP id ECB8D11E80CA for <>; Thu, 19 Jul 2012 16:46:05 -0700 (PDT)
Received: from [2001:5c0:1400:a::12b] by with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <>) id 1Ss0Qq-00034R-Gm; Fri, 20 Jul 2012 01:46:56 +0200
Message-ID: <>
Date: Fri, 20 Jul 2012 00:46:13 +0100
From: Fernando Gont <>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: RJ Atkinson <>
Subject: Re: oversized-header-chains: Receipt of illegal first-fragments
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jul 2012 23:46:06 -0000

Hi, Ran,

On 07/19/2012 09:04 PM, RJ Atkinson wrote:
>> Should we make this latter bit (about this being configurable)
>> a MAY, or would you prefer to have non-RFC2119 language?
> I believe this configurability is really desirable.
> It isn't a big burden for an implementer, as it is
> simply an on/off flag, but we don't want to require it.
> So I would suggest either use "SHOULD support configuration of
> whether an ICMPv6 error/diagnostic message is sent" (edit to preference) 
> OR (more simply) avoid using RFC21109 ALL-CAPS wording and
> still urge that implementers support this as a configurable 
> setting as part of supporting "local operational policy".

Ok. I will craft some text, and post it to the list for review...

>>> 4) Security Considerations ought to note the importance of
>>>   deploying Source Address Forgery Prevention filters, in
>>>   order to reduce the threat of an adversary forging an
>>>   illegal packet with contains a victim/target's IP address
>>>   in the Source IPv6 Address field of the illegal packet.
>>>   [RFC-2827, RFC-3704]
>> I have no problem with this.
>> However, should we really elaborate on this topic,
>> since it applies to all ICMPv6 error messages and
>> hence is probably a topic belonging to e.g. RFC 4443?
> I think a brief reminder here is appropriate, in part 
> because this draft increases the attack surface a bit,
> by making illegal a previously-valid, if very odd, 
> IPv6 packet construct.

Ok. As with the above, I will craft some text and send it to the list
for review.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492