Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07

Martin Stiemerling <mls.ietf@gmail.com> Thu, 04 February 2016 15:43 UTC

Return-Path: <mls.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A7B1B31C5 for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 07:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 iZz6xl52znr6 for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 07:43:32 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2EE91B31C4 for <ietf@ietf.org>; Thu, 4 Feb 2016 07:43:31 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id 128so32973675wmz.1 for <ietf@ietf.org>; Thu, 04 Feb 2016 07:43:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=+r0E0vtW2dFMzT6hRBPsz66dx9N7bkbJG4K7etxvXVc=; b=er9Sd4Qs23/iBosfznJ/atnWCWD6ure/9ZefmoPm113mXOARQCxNWokNLg+1o824Q3 nqqy8M3NMRoCGce12G+8a/RQaABhXl7c9yaIrZMyZBjz7DxjR3bRtgk6AKXWng7OdKIl G7bUIqG7GfxO8ZV++4fVhmbOWJFgdam/ATRM/Or7AvZaavsuZPY9ncHFri+IlU7mhN1G Rqh294fV5qD/YQ1I6oEulQT2KKzq6tKE0r7I35gf/aD44bsoLrMEXzGKKsjl3bOw5ine 0TnfbXaxf3RMOb2CPvMvbQf53k91tHl0PlQP64utDRQHn3iG6tJgTCtpB480V63n+9o/ E4Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=+r0E0vtW2dFMzT6hRBPsz66dx9N7bkbJG4K7etxvXVc=; b=FI5VYklqNYR/cRDTJl+FQtiwqEth/naYMmGBQmsqd8iCWfe8JktSOrfvICu90Hm38I TI2O92WXwJEXTrakYp0DdZKj0HtsMxsKH9ZQzks7xbbEjNgRtyGabbnY0ZGbSoa9UWr1 KL0spl8PuA0uCCi4M08Xk98e76yP6lEXsKcKMjXdRuRSYPUZGJNSiGvLak/luuC0Y+pw F45kFzDpQjwt119RkPX3Za40uSA93wnNkdhDjL8tVX1TYSPrwGzp43NER1iWGjwIK/T+ QsgLHPIyfaOtCoPP7W7h9AYu9FK8I+1P4r7lt/hrNOaNTosV4xBX3H6onuROBjP3zMBp 59gw==
X-Gm-Message-State: AG10YORxgQ5zqhnMk9ApT5hXp1RoMCsxvWHgwnEqlWawoLCh3Qt13IoBpWvIx0KWWYWNCA==
X-Received: by 10.28.182.136 with SMTP id g130mr4460078wmf.10.1454600610511; Thu, 04 Feb 2016 07:43:30 -0800 (PST)
Received: from Martins-MacBook-Pro-2.fritz.box ([2001:1a80:280c:b900:3dfb:f040:3498:4f15]) by smtp.googlemail.com with ESMTPSA id jc7sm11888182wjb.33.2016.02.04.07.43.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 07:43:29 -0800 (PST)
Subject: Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07
To: Harald Alvestrand <harald@alvestrand.no>, ietf@ietf.org
References: <20160125231333.27786.50459.idtracker@ietfa.amsl.com> <56A897AE.9060900@alvestrand.no>
From: Martin Stiemerling <mls.ietf@gmail.com>
Message-ID: <56B371A0.1080200@gmail.com>
Date: Thu, 04 Feb 2016 16:43:28 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A897AE.9060900@alvestrand.no>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/qCe0e7CFspTmQ3jkQWy6HPwtQ_A>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 15:43:34 -0000

Hi Harald, all,

draft-williams-exp-tcp-host-id-opt has been twice with the IESG for an 
RFC 5742 conflict review: on the 2015-05-28 and 2016-01-21 telechats.

Both IESG conflict reviews resulted in this response:
"The IESG has concluded that this document violates IETF procedures 
about pervasive monitoring (RFC 7258) and should therefore not be 
published without IETF review and IESG approval. This work is related to 
IETF work done in the INTAREA WG."

The IESG provided a number of detailed comments during the reviews:
https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/ballot/422704/
https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/ballot/450848/

And the deliberations in the telechats are public, e.g, for the last 
time at:
https://www.ietf.org/iesg/minutes/2016/narrative-minutes-2016-01-07.html

The TCP option detailed in draft-williams-exp-tcp-host-id-opt is 
extending an IETF protocol, and a very important IETF protocol, i.e., 
TCP, that requires IETF review and consensus. Furthermore, the proposed 
mechanism allows middleboxes to tag TCP connections with additional 
identifiers that persistently can mark users. Therefore, the IESG 
concluded that this draft violates RFC 7258, and does so while extending 
an IETF protocol.

The draft was reviewed in the TCPM working group and received negative 
feedback:
http://mailarchive.ietf.org/arch/msg/tcpm/lM9-Frq945LP12GKbp02hnynuWw

There have been also other places in the IETF where this draft was 
presented and rejected.

The IESG is also in discussion with the RFC Independent Stream Editor 
(ISE) on how to deal with drafts in a RFC 5742 review that iterate 
between the authors, the ISE and the IESG.

Regards,

   Martin (on behalf of the IESG)

Am 27.01.16 um 11:10 schrieb Harald Alvestrand:
> This one surprised me a bit.
>
> Asking for blockage of an ind-sub is a fairly unusual thing.
> I kind of expected to find in the IESG review would explain the nature
> of the conflict, but the totality of the review is:
>
> "The IESG has concluded that this document violates IETF procedures about
> pervasive monitoring (RFC 7258) and should therefore not be published
> without IETF review and IESG approval. This work is related to IETF work
> done in the INTAREA WG."
>
> The procedures I could find described in RFC 7258 are these:
>
>     Those developing IETF specifications need to be able to describe how
>     they have considered PM, and, if the attack is relevant to the work
>     to be published, be able to justify related design decisions.  This
>     does not mean a new "pervasive monitoring considerations" section is
>     needed in IETF documentation.  It means that, if asked, there needs
>     to be a good answer to the question "Is pervasive monitoring relevant
>     to this work and if so, how has it been considered?"
>
>     In particular, architectural decisions, including which existing
>     technology is reused, may significantly impact the vulnerability of a
>     protocol to PM.  Those developing IETF specifications therefore need
>     to consider mitigating PM when making architectural decisions.
>     Getting adequate, early review of architectural decisions including
>     whether appropriate mitigation of PM can be made is important.
>     Revisiting these architectural decisions late in the process is very
>     costly.
>
> The draft in question does have a "Pervasive Monitoring Considerations",
> so the issue has certainly been considered by the authors. One may agree
> or disagree with their conclusions, but one can't argue that they didn't
> consider it.
>
> Armchair lawyers will also note that the procedure refers to "IETF
> specifications". An independent-submission RFC is *not* an IETF
> specification.
>
> Note: I'm not arguing that this particular idea is bad or good.
>
> I'm saying that the IESG's justification for recommending it not be
> published needs to be more explicit about what the problem is, and why
> requesting an IESG note to be added saying "this is a Bad Idea" isn't a
> better IESG response.
>
> Harald
>
>
> Den 26. jan. 2016 00:13, skrev The IESG:
>> The IESG has completed a review of draft-williams-exp-tcp-host-id-opt-07
>> consistent with RFC5742.
>>
>>
>> The IESG recommends that 'Experimental Option for TCP Host
>> Identification' <draft-williams-exp-tcp-host-id-opt-07.txt> NOT be
>> published as an Experimental RFC.
>>
>>
>> The IESG has concluded that this document violates IETF procedures about
>> pervasive monitoring (RFC 7258) and should therefore not be published
>> without IETF review and IESG approval. This work is related to IETF work
>> done in the INTAREA WG.
>>
>> The IESG would also like the Independent Submissions Editor to review the
>> comments in the datatracker related to this document and determine
>> whether or not they merit incorporation into the document. Comments may
>> exist in both the ballot and the history log.
>>
>> The IESG review is documented at:
>> https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/
>>
>> A URL of the reviewed Internet Draft is:
>> https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/
>>
>> The process for such documents is described at
>> https://www.rfc-editor.org/indsubs.html
>>
>> Thank you,
>>
>> The IESG Secretary
>>
>>
>>
>