IETF Logo Mail Archive

Next steps for draft-gont-6man-predictable-fragment-id

Ole Troan <otroan@employees.org> Thu, 28 February 2013 19:51 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD88E21F87EA for <ipv6@ietfa.amsl.com>; Thu, 28 Feb 2013 11:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKuaaPcV5itN for <ipv6@ietfa.amsl.com>; Thu, 28 Feb 2013 11:51:47 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 967EA21F87AD for <ipv6@ietf.org>; Thu, 28 Feb 2013 11:51:42 -0800 (PST)
Received: from dhcp-10-61-97-83.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7B8255ECA for <ipv6@ietf.org>; Thu, 28 Feb 2013 11:51:40 -0800 (PST)
From: Ole Troan <otroan@employees.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Next steps for draft-gont-6man-predictable-fragment-id
Message-Id: <1D5AC9C6-2FC2-455D-930E-A8BA83C37D5B@employees.org>
Date: Thu, 28 Feb 2013 20:51:38 +0100
To: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 28 Feb 2013 19:51:49 -0000

Hi,

The draft-gont-6man-predictable-fragment-id document has been discussed a few times.
At the IETF84 (minutes attached below), and in the thread:
http://www.ietf.org/mail-archive/web/ipv6/current/msg15836.html

Could we get the working groups opinion on what to do with the document?

- Is there interest in working on it in 6man?
  (if yes, you must be willing to contribute, if no, then say why)

Best regards,
Ole & Bob



IETF84 minutes:
============
Fernando Gont presented the draft about Security Implications of
Predictable Fragment Identification Values,
(draft-gont-6man-predictable-fragment-id-02.txt)

Ole Troan wanted to make this document more generic and discuss the
implications of using predictable values in Internet
protocols. Fernando 

Bob Hinden wanted to see a longer list of OSs. He was also curious as
to whether this was problem that needed to be fixed in IETF or was
this already common knowledge.

Erik Kline wanted to know if there was an IAB document that
recommended the use of non-predictable values if there was an integer
field that did not need specific values.

Thomas Narten was not sure what to do with this. This fell under the
category of "don't do anything stupid". e.g. Why do a document for
IPv6 for things that were well known in IPv4?

Lorenzo Colitti thought that this work was not harmful and should be
pursued irrespective of any iab work.

Brian Haberman did not want to have a point solution for every field
and he would like to see a more general document applicable across the
IETF. Fernando was concerned on whether implementers would read this
generic document. Brian believed that this generic document could be
referred to in the node requirements document, thus ensuring that IPv6
implementers would read it.

Joel Jaeggli thought that it was a worthwhile activity to look at
existing implementations and flag this as a potential issue that was
common across multiple implementations. Thomas Narten and Erik Kline
agreed with Joel.

Dave mentioned that RFC4732 (Internet DOS considerations) talked about
using unpredictable values for session ids. Fernando talked about
other issues discovered after 4732 that still had this issue. Dave
believed that this sort of work needs to be done by the saag and if
this was included in a statement from saag as something to look for in
SecDir reviews, it would have the largest impact.

Chairs wanted to continue discussion on mailing list and requested
Fernando to discuss potential changes with Joel J.

v2.23.0 | Report a Bug | By Email