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

RJ Atkinson <rja.lists@gmail.com> Thu, 19 July 2012 18:33 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 B1DB721F8690 for <ipv6@ietfa.amsl.com>; Thu, 19 Jul 2012 11:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.2
X-Spam-Level:
X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=0.400, 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 BCwc9q1u3rnU for <ipv6@ietfa.amsl.com>; Thu, 19 Jul 2012 11:33:05 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA321F864E for <ipv6@ietf.org>; Thu, 19 Jul 2012 11:33:04 -0700 (PDT)
Received: by qcac10 with SMTP id c10so2061577qca.31 for <ipv6@ietf.org>; Thu, 19 Jul 2012 11:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=e/PRjJqDN0To4PZjCCYHgoxqo3nbS7XDAdWd63T0WHo=; b=Ds8Rces80AK1Ud79NiUwJ5TwYDN5W87FTvzHf49OD3u+maquUJbPeu0/+OalX9D7EO XY6odbmfIwdNVwmeXrZvj7KP8MDjo2fm/JUK1NLTjZh9fn7z41Pi9tWXjP2dRQmrUpfQ f+mWz/0gaFfo1XbkKl+acFoVMLuS10e7iG6TYF9kHirqkayN6wAFnhl7Pzuto/1owJxk ibDrBnmaA5bynLsqTDOhSlc3S+POhkg8jlqf9wTXZDTtXpO1TtEwSXlpsXFpkxtMS1OR bUQN1l+9O+7ifkwWVOx1W38VAZAOE1Y29pOAgp9fftBEFGi+2Mz0wrXT6/5e6F4AUnCn 8QRw==
Received: by 10.224.174.143 with SMTP id t15mr5501793qaz.15.1342722838386; Thu, 19 Jul 2012 11:33:58 -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 f14sm3535062qak.20.2012.07.19.11.33.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 11:33:57 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: oversized-header-chains: Receipt of illegal first-fragments
Date: Thu, 19 Jul 2012 14:33:55 -0400
Message-Id: <C8E82E61-8AD2-4471-80AF-00B29EA72A32@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
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 18:33:05 -0000

OPINION/BELIEF:

I concur with Fred Baker's analysis of "SHOULD" versus "MUST".

I think the requirement that a packet that violates the
proposed oversized-heacer-chain rule be dropped "silently" 
is too strong and lacks operational flexibility.

A device ought to be allowed, but not required, to send 
an ICMPv6 Parameter Problem message if/when it drops 
such a packet.

In some situations, it might be desirable for a device
to drop the packet AND also generate an ICMPv6 
"Parameter Problem" message for the packet originator.  


ACTIONABLE SUGGESTIONS:

So....

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.

and

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.

and

3) I'd also suggest a sentence or two clarifying that the
   ICMPv6 "Parameter Problem" with the new Reason Code
   is the appropriate message to send -- if the device dropping
   the packet with oversized-header-chain sends an ICMPv6
   message.  One would hope this would be obvious, but being
   very clear is good.

and

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]

Yours,

Ran