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

Brian Haberman <brian@innovationslab.net> Tue, 09 December 2014 14:55 UTC

Return-Path: <brian@innovationslab.net>
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 3849A1A8738 for <ipv6@ietfa.amsl.com>; Tue, 9 Dec 2014 06:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5q2Bh8eZo7Ca for <ipv6@ietfa.amsl.com>; Tue, 9 Dec 2014 06:55:19 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0AD1A8727 for <ipv6@ietf.org>; Tue, 9 Dec 2014 06:55:15 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C1EFB880F5 for <ipv6@ietf.org>; Tue, 9 Dec 2014 06:55:15 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 6C2751368251 for <ipv6@ietf.org>; Tue, 9 Dec 2014 06:55:15 -0800 (PST)
Message-ID: <54870D4F.6000801@innovationslab.net>
Date: Tue, 09 Dec 2014 09:55:11 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01
References: <5485C0AF.5040708@innovationslab.net> <1126971815.6970452.1418084075254.JavaMail.yahoo@jws10612.mail.bf1.yahoo.com> <D4FE16E0-6F0F-4141-B004-E537E2463ECC@innovationslab.net>
In-Reply-To: <D4FE16E0-6F0F-4141-B004-E537E2463ECC@innovationslab.net>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="6QvhkXNJlUJtboKI2kWQU9kKtohKMSDI6"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/AuJt_zKepOMfZ6MUqKK7lEUJFds
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: Tue, 09 Dec 2014 14:55:24 -0000


On 12/8/14 9:48 PM, Brian Haberman wrote:
> 
> 
> 
> 
>> On Dec 8, 2014, at 7:14 PM, Mark ZZZ Smith
>> <markzzzsmith@yahoo.com.au> wrote:
>> 
>> 
>> 
>> 
>> 
>> ----- Original Message -----
>>> From: Brian Haberman <brian@innovationslab.net> To:
>>> ipv6@ietf.org Cc: Sent: Tuesday, 9 December 2014, 2:15 Subject:
>>> Re: 6MAN WG Last Call:
>>> draft-ietf-6man-predictable-fragment-id-01
>>> 
>>> Actually, this document should not be a BCP at all.
>> 
>> I was thinking that there are a number of RFCs/drafts recommending
>> unpredictable or less predictable field values, with probably more
>> coming because of RFC7258, "Pervasive Monitoring Is an Attack" (I
>> think I've come across two different drafts recommending similar
>> for DHCPv6 field values). So perhaps there should be a more general
>> IAB BCP advising that "Initial and Ongoing Field Values Should Be
>> Unpredictable By Default".
> 
> I had asked for such a document when I saw a similar draft discussing
> the TCP sequence number.

To clarify...

There are several fields in various headers that have the same type of
characteristic (e.g., should be randomly initialized).  A single
document should have been developed to discuss them all together rather
than per-field ST documents.

Regards,
Brian