Re: Papers on IPv6 fragmentation

Fernando Gont <fernando@gont.com.ar> Mon, 23 June 2008 05:06 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FF33A684A; Sun, 22 Jun 2008 22:06:26 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF7A3A6803 for <ipv6@core3.amsl.com>; Sun, 22 Jun 2008 21:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, SARE_RECV_SPEEDY_AR=0.808]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAVMIeFC1R2a for <ipv6@core3.amsl.com>; Sun, 22 Jun 2008 21:53:39 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id DE4543A680E for <ipv6@ietf.org>; Sun, 22 Jun 2008 21:53:37 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 760DC6B668D; Mon, 23 Jun 2008 01:53:42 -0300 (ART)
Received: from notebook.gont.com.ar (201-254-44-225.speedy.com.ar [201.254.44.225] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.13.8) with ESMTP id m5N4rLQj008912; Mon, 23 Jun 2008 01:53:22 -0300
Message-Id: <200806230453.m5N4rLQj008912@venus.xmundo.net>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 23 Jun 2008 01:50:31 -0300
To: "Vishwas Manral" <vishwas.ietf@gmail.com>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: Papers on IPv6 fragmentation
In-Reply-To: <77ead0ec0806222144o6135b4b3gf57b53659098873@mail.gmail.com >
References: <200806221050.m5MAoF76005376@venus.xmundo.net> <77ead0ec0806220422v79d8e775n864772131b45b47b@mail.gmail.com> <200806230321.m5N3LP1j004622@venus.xmundo.net> <77ead0ec0806222144o6135b4b3gf57b53659098873@mail.gmail.com>
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 23 Jun 2008 01:53:42 -0300 (ART)
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

At 01:44 a.m. 23/06/2008, Vishwas Manral wrote:

> > * Your documents talk about specifying a minimum size for non-last
> > fragments. Actually, I think one should be concerned only about the *first*
> > fragment. That's the one that's used to create state at firewalls, etc.
>This is the more liberal approach you adopt to achieve the same thing.
>by having a more conservative approach we reduce the attack vectors
>further.

Maybe you should clarify this in the draft?


> > * I don't think imposing such a requirement will, by itself, help to ensure
> > that you have in the first packet all the information you need to apply
> > firewalls rules. It would be trivial for an attacker to comply with such a
> > requirement, but still do not provide all the relevant information that
> > would be needed by the firewall to apply its rules. The attacker could just
> > add one or several extension headers, with lots of PadN options. Thus, it
> > would comply with your requirement, but still avoid sending e.g. the TCP
> > source and destination ports.
>Fernando, that is correct. However we intend to put limitations
>separately on that.

I think that both requirements should be in the same document, or 
that at least you should explicitly state that the goal cannot be met 
unless there are restriction on the maximum number of bytes allowed 
for Extension Headers.


>Suresh probably had a draft regarding the same.

Any pointers?

Kind regards,

--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------