Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01

Ole Troan <otroan@employees.org> Mon, 08 December 2014 18:16 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A191A879A for <ipv6@ietfa.amsl.com>; Mon, 8 Dec 2014 10:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ir1ZOf1ST75F for <ipv6@ietfa.amsl.com>; Mon, 8 Dec 2014 10:16:33 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF651A877E for <ipv6@ietf.org>; Mon, 8 Dec 2014 10:16:33 -0800 (PST)
Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 9442E6088; Mon, 8 Dec 2014 10:16:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=127k5gDUMxti6fhE3sG8zXA8E7g=; b=JMsjgToV8DPL2ztLLH xdeJIB54+CN+r4753LD0R20CKh3ccD2FEu1JR0Rm+HMX6d/ocpgxVQFBKifTHIQG t1HtkhCic0OEpqQSxlVGxova19IrXs/VpKxXe0AxQHNpb2GcNm8EhwdfH2HaLCoD ZgHWuFWWmjFpnqkV0pZaPuOAs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=Afwytg80B9crAM4QKI32udGnfBrVr+meY8QfohGCM2B7phyEFOb Ovy7R46Zex6Y7FAsNw8plFoTCS8tHkTJaqmInmM6RY3HgvxKD4DIEtD/8t189Ru9 qUAxqES4Fnlqzd+dK9znpEsSFGee1uWVelRV1A94UfIV1OeyCEWJ6T1o=
Received: from gomlefisk.localdomain (unknown [195.159.234.46]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 231186028; Mon, 8 Dec 2014 10:16:31 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by gomlefisk.localdomain (Postfix) with ESMTP id B31273A98DB2; Mon, 8 Dec 2014 19:16:25 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CC2EE99E-475C-4DB5-9E7F-ED00B4D48561@employees.org>
Date: Mon, 08 Dec 2014 19:16:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <86F24DAC-C017-4D09-9431-0C33134B55C2@employees.org>
References: <CC2EE99E-475C-4DB5-9E7F-ED00B4D48561@employees.org>
To: 6man WG <ipv6@ietf.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/O_Xz7ZO4e_WVFEKFHS3c9bz0bic
Cc: 6man Chairs <6man-chairs@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 08 Dec 2014 18:16:35 -0000

<nohat>

let me offer a contrarian view.
I don't think we should publish this document. why? because I don't think it is worth the effort required by the community. I think we've pushed the needle too far in publishing 'micro updates'.

RFC2460 does not have normative language in how the Identification value should be generated. therefore I see no need to update RFC2460.

I think the advice may be useful, I'd be happy to see it in an RFC2460 update, or an update to the IPv6 Node requirement document. or more generally you could see a document in intarea titled "IP protocol fields must not be predictable.".

in any case I don't think publishing this particular document as an RFC is good use of our time.

</nohat>

cheers,
Ole


> On 04 Dec 2014, at 9:07 , Ole Troan <otroan@employees.org> wrote:
> 
> This message starts a two week 6MAN Working Group Last Call on advancing:
> 
>     Title           : Security Implications of Predictable Fragment Identification Values
>     Authors     : Fernando Gont
>     Filename   : draft-ietf-6man-predictable-fragment-id-01.txt
>     Pages        : 16
>     Date           : 2014-04-30
> 
>      http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id-01
> 
> as a Best Current Practice Document.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on December 18, 2014.
> 
> Note: While the document has expired, we didn't consider it necessary to refresh it purely for the sake of initiating the working group last call.
> 
> Regards,
> 
> Bob Hinden & Ole Trøan
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------