Re: Papers on IPv6 fragmentation

"Vishwas Manral" <vishwas.ietf@gmail.com> Mon, 23 June 2008 06:01 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 21EFC3A68AB; Sun, 22 Jun 2008 23:01:51 -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 9BF233A67A6 for <ipv6@core3.amsl.com>; Sun, 22 Jun 2008 23:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 cVyXUXGf3Ndd for <ipv6@core3.amsl.com>; Sun, 22 Jun 2008 23:01:49 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id CDD7B3A68AB for <ipv6@ietf.org>; Sun, 22 Jun 2008 23:01:49 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so2110015wfd.31 for <ipv6@ietf.org>; Sun, 22 Jun 2008 23:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=CXJvcRr8jyValQ8Dtq2Tu3RpJO84zBuv2GqBuLbNc0c=; b=BtbkKTMb/NyBgey/dTDHvy5MAx9xXfPvcQ86eZQpcYwTkfN/uGYKjJ9KO1ZtzwQFCV R7B8JjFAn0807RS2hQZT4/sYWvuQqlpBZjaRzYSeJmfon7HwTMYLJkgvk2psuHNommfU LI5LN8SR2w4oDTlydyaaYO1XOWV5YEt1wXUuo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BpT5LQ3vPA4jlm1Jzvo3iu+t9+GYtyyxwxhwJulqIo290BgXz7InkJq8RBHRrrSqjM k4Dqe61j+QUxLZfIEX9WnGX4CEL3+bMokWbyaxvKLperXJLebcsGmGtkFQK7+9zYZmdP 8KZ9X1NUbizCUxPMFqjsnAmDSaWeHOQyKQUMM=
Received: by 10.142.222.21 with SMTP id u21mr3227965wfg.67.1214200907757; Sun, 22 Jun 2008 23:01:47 -0700 (PDT)
Received: by 10.143.9.18 with HTTP; Sun, 22 Jun 2008 23:01:47 -0700 (PDT)
Message-ID: <77ead0ec0806222301i2a94d048vc0a22073baaf456e@mail.gmail.com>
Date: Mon, 23 Jun 2008 16:01:47 +1000
From: "Vishwas Manral" <vishwas.ietf@gmail.com>
To: "Fernando Gont" <fernando@gont.com.ar>
Subject: Re: Papers on IPv6 fragmentation
In-Reply-To: <200806230453.m5N4rLQj008912@venus.xmundo.net>
MIME-Version: 1.0
Content-Disposition: inline
References: <200806221050.m5MAoF76005376@venus.xmundo.net> <77ead0ec0806220422v79d8e775n864772131b45b47b@mail.gmail.com> <200806230321.m5N3LP1j004622@venus.xmundo.net> <77ead0ec0806222144o6135b4b3gf57b53659098873@mail.gmail.com> <200806230453.m5N4rLQj008912@venus.xmundo.net>
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi Fernando,

RFC4842 - Section 2.1.9.5 has the details you may be looking for. We
could certainly add additional details like adding the information in
my draft too.

Thanks,
Vishwas


On Mon, Jun 23, 2008 at 2:50 PM, Fernando Gont <fernando@gont.com.ar>; wrote:
> 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
--------------------------------------------------------------------