ietf
[Top] [All Lists]

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

2016-02-01 13:16:11
Ted,

On 02/02/2016 06:54, Ted Hardie wrote:
On Sat, Jan 30, 2016 at 11:10 AM, Brian E Carpenter <
brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> 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