Re: {Blocked Content} Overlapping fragments in IPv6 and firewalls

Doug Montgomery <> Wed, 30 July 2008 11:28 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3E0CC3A6AA9; Wed, 30 Jul 2008 04:28:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2E1728C1A0 for <>; Wed, 30 Jul 2008 04:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oOIEymBebCuC for <>; Wed, 30 Jul 2008 04:28:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A46563A67B7 for <>; Wed, 30 Jul 2008 04:28:53 -0700 (PDT)
Received: from [] ([]) by (8.13.1/8.13.1) with ESMTP id m6UBSiQR002415; Wed, 30 Jul 2008 07:28:46 -0400
Message-ID: <>
Date: Wed, 30 Jul 2008 07:28:51 -0400
From: Doug Montgomery <>
User-Agent: Thunderbird (Windows/20080708)
MIME-Version: 1.0
To: Suresh Krishnan <>
Subject: Re: {Blocked Content} Overlapping fragments in IPv6 and firewalls
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-NIST-MailScanner: Found to be clean
Cc: IETF IPv6 Mailing List <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

Suresh Krishnan wrote:
> Hi Folks,
>   This draft describes how to use overlapping fragments in IPv6 to 
> bypass firewalling restrictions. It recommends disallowing overlapping 
> fragments in IPv6.
> Thanks
> Suresh

The following two documents provide fairly detailed analysis of this (and other 
issues) that IPv6 Firewalls should consider:

Firewall Design Considerations for IPv6

A Filtering Strategy for Mobile IPv6

The first document covers other interesting issues with fragments, including the 
possibility of tunneled fragments being fragmented again ... header option 
ordering, etc.

As far as specsmanship to "prohibit" overlapping fragments, if the motivation is 
to change/ensure the behavior of all end nodes, updating 2460 (or some other 
vehicle) might make sense.

If the goal is to effect the behavior of firewalls, what we really need is a 
firewalls capability spec.  As far as I know, firewalls are not required to 
enforce all aspects of protocol correctness ... nor are they required to follow 
all aspects of end to end protocol specs.  So it is questionable if changing 
2460 will impact firewall behavior ... unless the firewall community decides on 
its own that it is a useful/necessary feature to implement.  Maybe it would some 
leverage that customers could use to lean on FW implementors .... but it would 
be indirect.

| Doug Montgomery       Manager, Internetworking Technologies Research Group |
| Advanced Network Technologies Division      WWW: |
| National Institute of Standards and Technology      Email: |
| 100 Bureau Drive                                    Voice: +1-301-975-3630 |
| Gaithersburg, MD 20899-8920 USA                     Fax:   +1-301-975-6238 |
| Key fingerprint =       3BCA EDD0 585D D068 CD46 E578 BD01 92A3 D1B0 04BB  |

IETF IPv6 working group mailing list
Administrative Requests: