Dear SM, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : S Moonesamy [mailto:sm+ietf@xxxxxxxxxxxx] > Envoyé : samedi 30 janvier 2016 21:48 > À : Brandon Williams; BOUCADAIR Mohamed IMT/OLN; Dan Wing > Cc : rfc-ise@xxxxxxxxxxxxxx; ietf@xxxxxxxx > Objet : Review of draft-williams-exp-tcp-host-id-opt-07 > > Hello, > > I am reviewing draft-williams-exp-tcp-host-id-opt-07 for the > Independent Stream. > > Overall, the document is well-written. [Med] Thank you. I suggest reviewing the usage > of the RFC 2119 key words as it makes the document look like a > document about compliance. The intended status of the document is > "Experimental". How long will this experiment last? [Med] The document includes a dedicated section for the experiments goals (https://tools.ietf.org/html/draft-williams-exp-tcp-host-id-opt-07#section-1.2). The implicit exit criteria is when the refinements mentioned in that section are met. > > The Abstract states that "proposals discussed in the IETF [which] > have identified benefits to more distinctly identifying the hosts > that are hidden behind a shared address/prefix sharing device or > application-layer proxy". Is the sentence: > > (i) misleading > > (ii) one-sided > > (iii) any other alternative > > I'll choose (ii) as the sentence mentions benefits only. I did not > see any mention of "IETF" in Section 1. Why is "IETF" mentioned in > the Abstract? I looked at the proposals referenced in > draft-williams-exp-tcp-host-id-opt-07 and they are from one of the > authors of this draft and from the same companies. Isn't that self- > citation? [Med] There are a variety of documents that were discussed within IETF about revealing the original IP address. Some examples are listed below: * https://tools.ietf.org/html/rfc6967 (which cites other documents) * https://tools.ietf.org/html/rfc7239 (Standards Track) * https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-06 Saying that, if you think that the text is not neutral we are open to reword it. > > From Section 1 of the draft: > > "The purpose of this document is to describe a TCP HOST_ID option > that is currently deployed on the Internet using the TCP > experimental option codepoint including discussion of related > design, deployment, and privacy considerations." > > I suggest focusing on the above if that is the purpose of the > document. Could the authors please explain which of the bullet > points in Section 2 of RFC 4846 is applicable to this document? > [Med] Bullet 11 is applicable to this document, IMO. Bullet 1 and 3 would work too. > "Specification of multiple option formats to serve the purpose of > host identification increases the burden for potential implementers > and presents interoperability challenges as well. This document > defines a common TCP option format that supersedes all three of the > above proposals." > > Does that mean that Akamai, Cisco and France Telecom have agreed on a > common TCP option format and have implemented that? [Med] Having multiple formats of a TCP option that is targeting a similar problem is not a good signal for interoperability. The format in the specification is what we agreed among three of us. Pointers to the initial format proposals are included in the draft. > > "The option defined in this document uses the TCP experimental option > codepoint sharing mechanism defined in [RFC6994] and is intended to > allow broad deployment of the mechanism on the public Internet." > > Is it the opinion of the authors of this draft that it isn't > worthwhile to get IETF Consensus on a mechanism for broad deployment > on the public Internet? [Med] We tried that path...You may check tcpm archives, fwiw. > > In Section 1.2: > > "In particular, documentation of the mechanism is expected to provide > opportunities for engagement with a broader range of both application > and middleware implementations in order to develop a more complete > picture of how well the option meets the use-case requirements." > > How does publication in the Independent Stream provide "opportunities > for engagement"? [Med] An RFC is ideal for stable and permanent publication. Having such permanent access is an opportunity for engagement. > > In Section 4.1: > > "The HOST_ID option value MUST correlate to IP addresses and/or TCP > port numbers that were changed by the inserting host/device (i.e., > some of the IP address and/or port number bits are used to generate > the HOST_ID)." > > The above is a requirement for "fingerprinting". The document then > provides examples that satisfy the requirement. I suggest making the > requirement clear instead of taking a "requirement by example" approach. [Med] One of the goals of this effort is to help tweaking which values can (not) be included in the option. This is why we are listing those as examples. > > In Section 6: > > "The content of the HOST_ID option SHOULD NOT be used for purposes > that require a trust relationship between the sender and the receiver > (e.g. billing and/or subscriber policy enforcement)." > > Why shouldn't the HOST_ID be used for purposes that require trust > relationships? The sentence which follows the quoted text (see > above) states that the "SHOULD" is a requirement. From what I > understand, the paragraph is explaining the difference between > "SHOULD" and "MUST". I got lost in reading the Security > Considerations Section. [Med] The reason is that the option is not reliable: a device in the path can alter its content or an illegitimate node can spoof the IP address and the content of the host_id option. Relying on the option for billing purposes, for instance, when both the entity that injects the option and the one that consumes it are not within the same administrative domain is not recommended. We didn't use MUST because that limitation may not be valid for intra-domain deployments. > > Section 7 states that NAT "is sometimes specifically intended to > provide anonymity". Are there any references for that? [Med] see https://www.eff.org/issues/open-wireless for an example. > > "The HOST_ID option MUST NOT provide client identification information > that was not publicly visible in IP packets for the TCP flows > processed > by the inserting host, such as subscriber information linked to the IP > address." > > Why is the above a RFC 2119 "MUST NOT"? [Med] This is the limit we fixed for this option by design: the option cannot reveal information that was not revealed by the originating host. > > Why is Section 8 relevant? This draft is not intended to be an IETF > specification. [Med] Because PM is a recurrent comment we receive. It is fair to include such discussion to avoid misinterpretations. Even with that section, we are still receiving comments saying that the document is asking for a globally unique identifier... which is not true! Also, we wanted to clarify that this document does not make things worse than IPv6. > > "Fance" is misspelled. [Med] Thank you for catching that. > > Regards, > S. Moonesamy