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

[Brian E Carpenter <[e-mail]>]

Ted,

On 02/02/2016 06:54, Ted Hardie wrote:
> On Sat, Jan 30, 2016 at 11:10 AM, Brian E Carpenter <
> [e-mail]> 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.

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

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