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

From: Ted Hardie <[email-masked]>
Date: Mon, 1 Feb 2016 09:54:38 -0800

On Sat, Jan 30, 2016 at 11:10 AM, Brian E Carpenter <
[email-masked]> wrote:

> Ted,
>
> On 30/01/2016 21:28, Eliot Lear wrote:
> ...
> > On 1/27/16 4:50 PM, Ted Hardie wrote:
> ...
> >> ​Yes, and we have historically said that publishing things in
> >> the ISE stream when they counter IETF specifications can
> >> only be done when the IESG deems there to be no conflict
> >> with IETF specifications.
>
> Not so. What the community has said (in RFC 4846) is that such a conflict
> is a legitimate ground for the IESG to object to publication, with the IETF
> procedures around this documented in BCP 92. It is then the ISE's
> prerogative
> to decide whether to publish or not, after reviewing the IESG's objection
> and any other relevant input.
>
> That includes, but is not limited to, input from the Editorial Board, of
> which
> I am a member.

​Brian,

You are right; I wrote in haste and should have said can only be
done after consultation with the IESG on delay or commentary.

The larger point is that we have tried to make sure that there is
a flow of communication between the IESG (and IETF) and the
ISE about the relationship of work brought to the ISE and ongoing work,
as well as on what John called the question of whether a particular
candidate document is 'dumb or dangerous'.

It is on this latter point that  I hope that the editorial board and
ISE spend their time.  The document before the ISE represents
an example of a pattern of behavior that is deeply inimical to privacy
on the network: identifying metadata insertion by middleboxes
("The information conveyed in the HOST_ID option is intended to uniquely
identify the sending host
​").  It is certainly not the first time we have
seen this pattern nor the first time it has been documented in an RFC.
But supporting it again, as an option to TCP itself, carries a very high
risk.
That risk is that users' trust in the network, already eroded by government
action, will erode further or fail.  If this document flatly described what
is being done or spoke in depth about the risks, it might still be worth
publishing.  It does not.  It speaks about this in terms of an experiment,
which it is
not, and it speaks about the value in terms far more laudatory than are
warranted.
That is the point of danger I believe the IESG saw clearly, and that is the
point
on which I support their recommendation.

If the ISE and the editorial board remain conflicted on this point, I note
that
the ISE may ask for further advice from the IAB:

   The RFC Editor or the author may request that the IAB review the
   IESG's request to delay or not publish the document and request that
   the IAB provide an additional opinion.  Such a request will be made
   public via the RFC Editor Web site.  As with the IESG review itself,
   the IAB's opinion, if any, will be advisory.  And, as with author
   requests for an IAB technical review (see Section 4.5
<https://tools.ietf.org/html/rfc4846#section-4.5>), the IAB is
   not obligated to perform this type of review and may decline the
   request.

While I do not speak for the IAB on this point, I would personally work to
see that it
did not decline and provided a response promptly, should the ISE request
one.

As noted above, this would be advisory and it may well not be
necessary given the review no doubt being done now by the advisory board.

regards,

Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Feb 2016 08:15:49 +1300

Ted,

> on which I support their recommendation.

Speaking personally, I have detested the idea of a non-cryptographic host ID
since it was first mooted:
https://mailarchive.ietf.org/arch/msg/int-area/Fd0Y0cX3_Ed8NAv75h0J8Z1Y5hI

In IPv6-land we've been working quite hard over the years to reduce privacy
risks without destroying end-to-end properties, e.g. RFC 4941, RFC 7217, 	
draft-ietf-6man-ipv6-address-generation-privacy and draft-ietf-6man-default-iids.
I would be unhappy to see a TCP option that nullifies these efforts in
widespread use.

However, in fairness to the draft in question, I think people do need to
re-read RFC 6967 (IETF stream) and RFC 7620 (Independent stream) first.
The draft wasn't written in a vacuum.

   Brian

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 Feb 2016 16:43:28 +0100

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
>>
>>
>>
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 04 Feb 2016 08:15:43 -0800

FWIW, the reason I'm pushing on this is that it feels like the IESG is 
violating the spirit of RFC 5742 by saying "The IETF doesn't want to 
work on this draft, so you should not publish it". That removes a lot of 
the independence from the ISE.

> 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.

To reiterate what some others have said on this thread: please specify 
how this draft "violates" RFC 7258. My reading of that RFC and the 
discussion that lead to it, comes to a very different conclusion.

> http://mailarchive.ietf.org/arch/msg/tcpm/lM9-Frq945LP12GKbp02hnynuWw

Note that this is a pointer to a message about a much-earlier version of 
the draft that has less explanatory text than the one being reviewed by 
the ISE. To me, this is an indicator that the draft needed fixing in 
order to meet the requirements of RFC 7258 of documenting the design 
decisions, and that the authors may have done so between -04 and -07.

> There have been also other places in the IETF where this draft was 

If that's true, why did the IESG say that this draft is related to work 
in INTAREA? I interpreted that as a request that the authors take this 
draft to INTAREA, but now you're saying because the draft was

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 4 Feb 2016 17:29:23 +0000

Hi Paul,

> the independence from the ISE.

That wasn't the IESG's conclusion but see below...

> discussion that lead to it, comes to a very different conclusion.

"violates" comes from 5742, option #4.

I think one could indeed argue that the formal IESG response text
isn't at all clear, but it's one of the 5742 options - we don't have
an option for "this extends an IETF protocol in ways that require
IETF review, and it has in fact already had such review (though
not an IETF LC) which rejected progressing with the work, so there
doesn't seem to be any point in sending it back to the IETF, but
since we think this does conflict with BCP188 as well, we're formally
going with option 4."

But I think all of that is clear from the comments and other links
that Martin sent, isn't it? I hope, and assume, it's clear to
the ISE. (Who was cc'd on much of the IESG email on this by the
tracker.)

I should also point out that 5742 email responses to the ISE do
always include pointers to the tracker comments, and do ask the ISE
to consider those, so while the formal response text is I agree
so terse as to be misleading, one has to also read the comments
etc. in the tracker to get the context here.

> decisions, and that the authors may have done so between -04 and -07.

So that brings up an independent problem for the IESG with this, which
is the one about which we hope to chat with the ISE: It seems wrong to
ask the IESG to do a full IESG review of the modifications that the
authors have made after a first DNP response was sent, for text that
has not had an IETF LC. If the IESG do such a review, then this
basically becomes an IETF stream document as the DNP ends up the same
as a DISCUSS with the IESG and authors haggling about the text
(possibly via the ISE).

So, since the document obviously hadn't undergone major change, I
(and I think other ADs) felt that we had to re-send the same response.
Doing otherwise would I think be damaging to the independence of the
ISE.

Note though that we have had one other 5742 review recently where we
sent a DNP, but where the fix (to remove text about extending IKEv1)
was simple and obvious. In that case we didn't go around the full 5742
review again. So there's stuff to chat about to make that bit of
process work  better I reckon, or at least so folks have the same
expectations of what'll happen with a returning item, after a DNP
response.

> draft to INTAREA, but now you're saying because the draft was

(Was your mail truncated?) Anyway, the intent was not to say "please
send this to the IETF" as explained above.

Cheers,
S.