IETF Logo Mail Archive

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

神明達哉 <jinmei@wide.ad.jp> Wed, 10 December 2014 18:53 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 BA3801A870D for <ipv6@ietfa.amsl.com>; Wed, 10 Dec 2014 10:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 UrkhY01ixkHd for <ipv6@ietfa.amsl.com>; Wed, 10 Dec 2014 10:53:10 -0800 (PST)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578351A8A4F for <ipv6@ietf.org>; Wed, 10 Dec 2014 10:53:10 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id b13so4460563wgh.31 for <ipv6@ietf.org>; Wed, 10 Dec 2014 10:53:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Eo0s2kMGzWITMuPUM/ZXbMnO4gxQ9e8YyQpPHQ9yHGA=; b=XQPgRElxJSOUbk8bIDKX7M5gOE62wnHdNaAZ+/d1guGn+JEaY2bskQMjOZRdcDfj19 UaMa7wJrJaJfgzqyyn/pPiamDmudI2Jt6XeQwbP22iASeuk1YhmsdLnk0j5SmIwAPMqN Oj4iTnPSqh7I8OuNlmA5JbxiNJ18HtHoA6BJEajMUavGby+8LuJzhFu/qut/LS/WBkMO 4efQCfYmUw+OhxIuBwqW4tkrZXiPp3RmeWyv6yVouHlkU5M0AkrGfvV/BDkEpnTCE0Wc HWH/nXYt9//KR22sjI6qomfJ9cajkSImCaKE2h2QWGIkmkXOh4764iseFrUFrGA7BNhj yuFw==
MIME-Version: 1.0
X-Received: by 10.194.48.109 with SMTP id k13mr9372107wjn.7.1418237588820; Wed, 10 Dec 2014 10:53:08 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.44.66 with HTTP; Wed, 10 Dec 2014 10:53:08 -0800 (PST)
In-Reply-To: <5486BF69.4020606@gont.com.ar>
References: <CC2EE99E-475C-4DB5-9E7F-ED00B4D48561@employees.org> <CAJE_bqdwrG6nGvJCQG4gpYR6hSpVBe-Pi=+XozCv4L-RJ1=URg@mail.gmail.com> <5486BF69.4020606@gont.com.ar>
Date: Wed, 10 Dec 2014 10:53:08 -0800
X-Google-Sender-Auth: riuJEGFsETGMwx2X0_kX5btrXyU
Message-ID: <CAJE_bqemeeiRPNdhvXhB8F-_vEJLqwr9gL5o4JC_Ea36O4cV+Q@mail.gmail.com>
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-predictable-fragment-id-01
From: 神明達哉 <jinmei@wide.ad.jp>
To: Fernando Gont <fernando@gont.com.ar>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/PBZr8bPa8NS4ulJiuRzSwoHmB-4
Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG <ipv6@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: Wed, 10 Dec 2014 18:53:11 -0000

At Tue, 09 Dec 2014 14:56:58 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> >>> - Section 4:
> >>>
> >>>    The Identification value of the Fragment Header MUST NOT be
> >>>    predictable by an off-path attacker.
> >>>
> >>>   'MUST NOT be predictable' sounds vague to me, especially with the
> >>>   RFC2119 keyword.  I'm not sure if there's a precedent of the use of
> >>>   this word with a normative keyword, but even if there's, I would
> >>>   personally still like to see a clearer term here.
> >>
> >> FWIW, RFC6056 (port randomization) says:
[...]
> >> OTOH, RFC6528 (TCP SEQ randomization) says:
[...]
> > By referring to these, do you mean you think the current text of the
> > draft is good enough? (asking simply because I'm not sure about the
> > intent).
>
> No. I'm just noting how it was specified in other cases, to check if you
> like those options better (FWIW, when you raised the issue, I wondered
> myself "how did we specify this for...?")

These existing ones look equally vague to me, but I don't have any
good specific suggestion.  Maybe just removing the RFC2119 is the most
realistic choice, just as suggested in other messages of this thread
(for a different, but possibly related) reason.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email