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

Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> Mon, 11 March 2013 07:17 UTC

Return-Path: <achatz@forthnetgroup.gr>
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 4F83821F8992 for <ipv6@ietfa.amsl.com>; Mon, 11 Mar 2013 00:17: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQaLBwbzzGMe for <ipv6@ietfa.amsl.com>; Mon, 11 Mar 2013 00:17:49 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 472D221F898A for <ipv6@ietf.org>; Mon, 11 Mar 2013 00:17:49 -0700 (PDT)
Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id r2B7Hlvc010282 for <ipv6@ietf.org>; Mon, 11 Mar 2013 09:17:47 +0200
Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r2B7HlQK015174 for <ipv6@ietf.org>; Mon, 11 Mar 2013 09:17:47 +0200
Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r2B7HbXk006344; Mon, 11 Mar 2013 09:17:38 +0200
Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN)
Message-ID: <513D8512.2050407@forthnetgroup.gr>
Date: Mon, 11 Mar 2013 09:17:38 +0200
From: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Organization: Forthnet
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
MIME-Version: 1.0
To: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>
Subject: Re: Next steps for draft-gont-6man-predictable-fragment-id
References: <1D5AC9C6-2FC2-455D-930E-A8BA83C37D5B@employees.org>
In-Reply-To: <1D5AC9C6-2FC2-455D-930E-A8BA83C37D5B@employees.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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: Mon, 11 Mar 2013 07:17:50 -0000

I believe the doc describes nicely the possible security issues of predictable fragment ids in IPv6.
Although the attack scenarios aren't so common/easy as in IPv4 and various operating systems have fixed most of them, i still find urgent to need to standardize this behavior, now that IPv6 is still not thoroughly exposed to the wild. Thinking some years ahead, the internet of things multiplies the chances of something bad happening due to this.
I'm having a doubt about the title though, because "Security Implications of Predictable Fragment Identification Values" gives the impression of a BCP or informational.

Lastly,  i would also vote for another doc giving general directions for usage of such fields (ids, sequence numbers, ports, etc) in future protocols. It feels strange to meet the same issues again and again.

PS: it would be good to find a way to somehow authenticate/verify ICMPv6 PTB messages; then many fragment-related issues would probably be solved in advance.

--
Tassos

Ole Troan wrote on 28/02/2013 21:51:
> 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.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>