ietf
[Top] [All Lists]

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

2016-02-04 09:43:52
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