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

RJ Atkinson <> Thu, 19 July 2012 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F37E521F86D9 for <>; Thu, 19 Jul 2012 13:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.279
X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4lVUkzOyG5GZ for <>; Thu, 19 Jul 2012 13:03:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2BD8A21F869D for <>; Thu, 19 Jul 2012 13:03:19 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1957373qae.10 for <>; Thu, 19 Jul 2012 13:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ibYHnn1Op48+RT9MPuEq69flENHKQds1t1i1KrgE97Q=; b=IVai2IxOgXLmukge7IpatnAXZL+yCJfEvjI87kVebAq+O9bdNiMHH5/pA1y9cA9ZOU j+ILOLF4WcFVd0+1TniGHygmYS+edTg0RFLqnEf5gXxp5xdNNHDZl3ByaLv+XENOT7Js YbF04Jwwskgsp7mn1gQ7w5tFwT6iBIuLNrFCH6k7ww6R3TF0Zw5MiNO3B3Vzm3bTImIv K3dNlHtM5AF9DcPB4RxFyD46KnOqea1tiQEkK1cH5EQQZ4M06u/gv10Xsi8RYjWFRGGy R4PRsakD343rPDn5W+EFrOO+K2cFKXvEkQTgmhRsHDRIxQ40CVvKSdshfgglbXdVsh1F FgbQ==
Received: by with SMTP id p14mr1487152qct.93.1342728252716; Thu, 19 Jul 2012 13:04:12 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id he6sm3699306qab.13.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 13:04:12 -0700 (PDT)
Subject: Re: oversized-header-chains: Receipt of illegal first-fragments
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=iso-8859-1
From: RJ Atkinson <>
In-Reply-To: <>
Date: Thu, 19 Jul 2012 16:04:10 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.1278)
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 20:03:20 -0000

On 19  Jul 2012, at 15:20 , Fernando Gont wrote:
>> 1) I'd prefer this draft say that such illegal packets MUST 
>>   be dropped, but then also say that the device dropping the 
>>   packet MAY send an ICMPv6 Parameter Problem control message 
>>   back to the (alleged) sending node.  A brief sentence 
>>   suggesting, but not requiring, that implementations make 
>>   the sending of the ICMPv6 message configurable also would be 
>>   sensible.
> 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".

> 2) For the situation where an IPv6 packet is dropped for this
>>   specific reason, I'd suggest that the "Reason Code" registry 
>>   for an ICMPv6 "Type 4 - Parameter Problem" message be updated
>>   with a new focused reason code defined.  As a straw man, 
>>   I'd propose adding this new entry to that registry, 
>>   as part of this proposal:
>>     3      IPv6 Initial Fragment missing upper-layer protocol header
>>    Of course, this means an "IANA Considerations" section
>>    update for the I-D would be in order.
> I find your suggestion acceptable. Can others please weigh in?
> Minor note: May be the description for the error code should be along
> the lines of "IPv6 First Fragment missing entire IPv6 header chain"?
> (I'm just thinking of IPv6 packets with no upper layer protocol, which
> would remain legal, but would not have an "upper layer protocol header")

I don't object to the rephrasing of the name/description.
Ideally the name/description field is relatively short.

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

I would not object to including the phrase " with
all ICMPv6 error/diagnostic messages..." as part of that
brief description of the concern.