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

RJ Atkinson <rja.lists@gmail.com> Thu, 19 July 2012 20:03 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37E521F86D9 for <ipv6@ietfa.amsl.com>; Thu, 19 Jul 2012 13:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.279
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lVUkzOyG5GZ for <ipv6@ietfa.amsl.com>; Thu, 19 Jul 2012 13:03:19 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD8A21F869D for <ipv6@ietf.org>; Thu, 19 Jul 2012 13:03:19 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1957373qae.10 for <ipv6@ietf.org>; Thu, 19 Jul 2012 13:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.229.136.14 with SMTP id p14mr1487152qct.93.1342728252716; Thu, 19 Jul 2012 13:04:12 -0700 (PDT)
Received: from [10.30.20.12] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id he6sm3699306qab.13.2012.07.19.13.04.11 (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 <rja.lists@gmail.com>
In-Reply-To: <50085DE8.2060906@si6networks.com>
Date: Thu, 19 Jul 2012 16:04:10 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <AA19CADB-923D-45AF-A7E2-D604DD2D299C@gmail.com>
References: <C8E82E61-8AD2-4471-80AF-00B29EA72A32@gmail.com> <50085DE8.2060906@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.1278)
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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:
>> 
>>   CODE     NAME/DESCRIPTION
>>     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 "...as with
all ICMPv6 error/diagnostic messages..." as part of that
brief description of the concern.

Cheers,

Ran