Subject: [Gen-art] Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05

From: Peter Yee <[email-masked]>
Date: Sat, 09 Mar 2013 00:13:34 -0800

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-intarea-nat-reveal-analysis-05
Reviewer: Peter Yee
Review Date: Mar-08-2013
IETF LC End Date: Mar-08-2013
IESG Telechat date: TBD

Summary: This draft is on the right track but has open issues, described in
      the review. [Ready with issues.]

This draft catalogs and analyzes various means of supplying a host
identifier to a

remote server when Carrier Grade NAT or similar host obscuring technology
is in use.

General: There were sentences in the draft that I could not parse even in
the context
of surrounding text.  That's primarily why I'm marking this draft as
"Ready with
issues".  These sentences are supplied below.  Mostly, the document has a
fair number
of nits.  The general concept is fine.

General: hyphenate uses of "address sharing" when it used as an adjective.
 For
example, "address-sharing device".

General: expand acronyms on first use except if they are really well known
in
our community (e.g., TCP/IP) or where they appear in the abstract.
Examples of
acronyms in need of expansion are HIP, XFF, Š.

General: You will probably want to resolve Internet Draft references to
something
more permanent.

General: The term "broken" should be replaced with something more specific
or useful.
I've made some suggestions below.

Section 1, 2nd paragraph, last sentence: delete "an" before "information".

Section 1, 3rd paragraph: change "are" to "include".

Section 1, 3rd paragraph: change "customers unsatisfaction" to "and
customers' dissatisfaction".

Section 2, 1st paragraph, 2nd sentence: delete "an" before "extra".
Change "than" to
"beyond".

Section 2, 1st paragraph, 3rd sentence: replace this sentence with "We
call this
information the HOST_ID."

Section 2, 2nd paragraph: add a serial comma after "subscriber".  Serial
comma use in
the draft was inconsistent.

Section 2, 3rd paragraph, 3rd sentence: I'm not sure why the HOST_ID and
public IP address would be "relatively" unique.  Assuming that HOST_IDs
are unique amongst
the hosts hidden behind the public IP address and the public IP address is
unique,
I would have thought that the combination was globally unique.  My
confusion may arise
from the 4th sentence which is incomplete.  Perhaps those two sentences
could be
rewritten for clarity.

Section 2, 4th paragraph, 1st sentence: change "put" to "conveyed".

Section 2, 4th paragraph, 2nd sentence: change "put" to "conveyed".

Section 3, 2nd paragraph, 1st sentence: considering using
"identifiability" instead of
"uniqueness".

Section 3, 2nd paragraph, 2nd sentence: replace "which" with "what".

Section 3,1, 4th paragraph: add a comma after "re-write".  Change
"re-write" to
"rewrite".

Section 3.1, 5th paragraph: I don't quite follow what's being said here.
Is the point that the address-sharing function should reveal the same
HOST_ID for any given host
regardless of what layer or mechanism that HOST_ID is being conveyed
across?  How does
this relate to interference between HOST_IDs?

Section 4.1.1, 1st paragraph, 1st sentence: delete "an" before
"information".

Section 4.1.1, 1st paragraph, 3rd sentence: insert ", there are" after
"hence".

Section 4.1.1, 4th paragraph, consider replacing with: "Address-sharing
devices using
this solution would be required to indicate that out of band, possibly
using a special
DNS record."

Section 4.1.2, 3rd paragraph, 2nd sentence: add a comma after "scenario".
Change "broken" to "ill-advised".

Section 4.2.1, 1st paragraph, 2nd sentence: add "A " at the beginning of
the sentence.

Section 4.2.1, 1st paragraph, 4th sentence: rewrite as "This IP option
allows the
   conveyance of an IPv4 address, an IPv6 prefix, a GRE key, an IPv6 Flow
Label, etc."

Section 4.2.1, 2nd paragraph: insert "an" before "IP".

Section 4.2.2, 1st paragraph, 1st sentence: change "for" to "to".

Section 4.2.2, 1st paragraph, 2nd sentence: use of the term "filter" in
this sentence
is not clear.  Do you mean that that routes and middleboxes remove the IP
options?  Or
that they remove packets with IP options?  Or that they take other actions
based on the
presence of IP options?  Please clarify.

Section 4.2.2, 2nd paragraph: replace "As a" with "In".  Define
"host-hint" somewhere.
Is it meant to be equivalent to HOST_ID?

Section 4.3.1, 3rd sentence: change "their" to "its" both places in the
sentence.
Insert "or" before "subscriber".

Section 4.3.2, 2nd paragraph, 2nd sentence: insert "a" before "HOST_ID"

Section 4.3.2, 2nd paragraph, 3rd sentence: change "in host" to "on the
host".  Insert
"the" before "address", and add a comma after "function".

Section 4.3.2, 1st bullet item: this is the IETF.  We don't need no
stinkin' OSI! :-)

Section 4.3.2, 1st bullet item, 2nd sentence: replace the sentence with
"Moreover, an
updated version of [I-D.wing-nat-reveal-option] no longer allows conveyance
of a full IP address as the HOST_ID is encoded in 16 bits."

Section 4.3.2, 2nd bullet item, 1st sentence: delete the comma after
"limited".

Section 4.3.2, 2nd bullet item, 4th sentence: delete the comma after "ACK".

Section 4.3.2, 2nd bullet item, 5th sentence: move "only" before "allows".
 Change
"to enclose" to "enclosing".

Section 4.3.2, 3rd bullet item, 3rd sentence: the characterization of
HOST_ID as
leaked information seems pejorative.  And how is a "communication leg"
defined?
Is this a standard term for communications between a CGN and a remote
server, or for
other backbone-carried communications?

Section 4.3.2, 4th bullet item, append a comma after "particular".

Section 4.3.2, 5th bullet item, 1st sentence: replace "to" with "the".
Change
"preserve" to "preservation of".

Section 4.3.2, 5th bullet item, 3rd sentence: change "to reveal" to
"revealing".

Section 4.4.1, 1st paragraph, 1st sentence: move "not" before "to".
Change "at" to
"within".  Change "which" to "that".

Section 4.4.1, 1st paragraph, 2nd sentence: change "This" to "The".
Append "of the
conveyed information" after "format".

Section 4.4.1, 2nd paragraph, 3rd sentence: change "their" to "its".

Section 4.4.1, 3rd paragraph: insert "the" before "X-Forwarded-For".

Section 4.4.2, 1st paragraph, 1st sentence: delete "the" before "address".

Section 4.4.2, 2nd paragraph, 1st sentence: specify by whom the initiative
was launched.

Section 4.4.2, 2nd paragraph, 2nd sentence: append "who are" after
"Wikipedia".

Section 4.4.2, 4th paragraph, 1st sentence: would "transited" be more
appropriate than
"crossed"?  Insert "the" before "Forwarded".

Section 4.4.2, 6th paragraph: change "implementation" to
"implementations".  And that
begs the question: implementations of what?  Delete "some" before
"parsing".  Insert
"an" before "XFF".

Section 4.4.2, 7th paragraph: why is this "may be broken"?  Either the
Forwarded header can be injected or it cannot.  Under encryption, the only
way I can see to insert the
header is if the encrypted TLS session is passing through a
man-in-the-middle proxy
that is spoofing both of ends of the communication in order to be able to
transparently
decrypt the traffic.

Section 4.5.1, 1st paragraph, 4th sentence: insert "The" before '"PROXY"'.

Section 4.5.2, 1st paragraph, last sentence: change "raise" to "arise".
Append a
comma after "firewalls".

Section 4.5.2, 2nd paragraph: change "broken" to "infeasible".  Change
"can not" to "cannot".

Section 4.6.1, 3rd paragraph: replace "do" with "are".  Change "require"
to "required".

Section 4.6.1, 4th paragraph: insert "an" before "option".

Section 4.6.2, 3rd paragraph: move "also" before "offering".  I presume
the "IP connectivity services" are those being offered to the host being
identified, but
that should be made clear in the text since the sentence is vague as to
which end
of the conversation is being reference.

Section 4.7.1: delete "an" before "identity".

Section 4.7.2, 2nd paragraph, 1st sentence: insert "having" after "is".

Section 4.7.2, 2nd paragraph, 2nd sentence: delete "ported to be".

Section 4.8, title: insert "of" after "Use".

Section 4.8.1, 2nd paragraph, 2nd sentence: replace "differentiating" with
"host-identifying".

Section 4.8.2, 1st bullet item: insert "The" before "Address" and then
make "Address"
lower case.  I'm not sure what this sentence is trying to tell me, however.

Section 4.8.2, 2nd bullet item: replace "an" with "that the".

Section 4.8.2, 4th bullet item: delete "Some" before "implementation" and
then
capitalize "implementations".  Delete "to" before "delay" and append "of"
after "delay".
Change "receiving" to "receipt of".  Delete the comma after "Request".

Section 4.8.2, 5th bullet item: delete "may" before "receive" and then
change "receive"
to "receives".

Section 4.8.2, 8th bullet item: delete "a".

Section 4.8.2, 9th bullet item, 2nd sentence: change the first "are" to
"is".  Delete
"to be".

Section 4.9.1, 2nd paragraph, 2nd sentence: insert "the" before "address".
 Append a
comma after "IDENT".

Section 4.9.1, 2nd paragraph, 4th sentence: change "16 bit" to "16-bit".

Section 4.9.2, 1st bullet item, 2nd sentence: change "Alternatives" to
"Alternative".
Change "mechanism" to "mechanisms".  Change "design" to "designed".  I
don't think you
want the list of other transport mechanisms to include TCP since you've
already said
that IDENT is specific to TCP.

Section 4.9.2, 3rd bullet item, 1st sentence: insert "that" before "the
address".
Insert "the" before "IDENT".

Section 4.9.2, 4th bullet item, 2nd sentence: change "This" to "Such a".
Change
"deployable" to "feasible".  Delete "heavy and" unless you want to explain
what
heavy means.

Section 4.9.2, 5th bullet item: delete "Some" and capitalize
"implementations". 
Delete "to" before "delay" and append "of" after "delay".  Change
"receiving" to
"receipt of".  Delete the comma after "response".

Section 4.9.2, 6th bullet item: delete "a".

Section 4.9.2, 7th bullet item, 1st sentence: change "are" to "is".

Section 4.9.2, 7th bullet item, 2nd sentence: change "even" to "further".

Section 4.9.2, 9th bullet item: change "non legitimate" to "illegitimate".

Section 5, 1st paragraph after the Table 1 caption: append a comma after
"[Options]".
Insert ", and" before "ExtendTCP".

Section 5, 2nd paragraph after the Table 1 caption: change "Address" to
"address".

Section 5, 3rd paragraph after the Table 1 caption: change "to establish"
to
"for establishing".

Section 5, 4th paragraph after the Table 1 caption, 3rd sentence: change
"hold" to
"delay".  Change "receiving" to "receipt of".

Section 5, 4th paragraph after the Table 1 caption, 4th sentence: change
"at" to "on".

Section 5, 5th paragraph after the Table 1 caption, 3rd sentence: change
"hold" to "delay".  Change "receiving"
to "receipt of".  Insert "the" before "IDENT".

Section 5, 5th paragraph after the Table 1 caption, 4th sentence: change
"at" to "on".
Consider rewriting this sentence and the similar one in the previous
paragraph for even
greater clarity.

Section 7, 3rd paragraph: insert "used" before "to convey".

Section 8, 1st paragraph: append a comma after "Halpern".

Section 8, 2nd paragraph: append a comma after "Wing".

Section 8, 4th paragraph: change to "The privacy text was provided by A.
Cooper."

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 10 Mar 2013 13:43:09 -0400

Hi Peter,
  Thanks a lot for your review. I will ask the authors to address your
comments in the next version of the draft.

Regards
Suresh

On 03/09/2013 03:13 AM, Peter Yee wrote:
> acronyms in need of expansion are HIP, XFF, S.
>

---

From: <[email-masked]>
Date: Mon, 11 Mar 2013 11:12:16 +0100

Dear Peter,

Many thanks for the review. 

A new version with your suggested changes is now online. See the diff available here: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06.

This version includes also the comments raised by SM here: http://www.ietf.org/mail-archive/web/ietf/current/msg77273.html.

Cheers,
Med 

>-----Message d'origine-----
>De : Peter Yee [mailto:[email-masked]] 
>Envoyé : samedi 9 mars 2013 09:14
>À : [email-masked]
>Cc : [email-masked]; [email-masked]
>Objet : Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05
>

---

From: <[email-masked]>
Date: Thu, 21 Mar 2013 10:03:29 +0100

Dear Peter, SM,

I didn't received any explicit answer from your side whether the changes in -06 solve your concern.

I would appreciate if you can check the new revision. For your convenience the diff is available here: http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06

Thanks. 
Cheers,
Med

>De : BOUCADAIR Mohamed OLNC/OLN 
>Envoyé : lundi 11 mars 2013 11:12
>À : 'Peter Yee'; 'SM'
>Cc : [email-masked]; [email-masked]; 
>[email-masked]
>Objet : RE: Gen-ART review of draft-ietf-intarea-nat-reveal-analysis-05
>
>Dear Peter,
>
>A new version with your suggested changes is now online. See 
>the diff available here: 
>http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-
>analysis-06.
>
>This version includes also the comments raised by SM here: 
>http://www.ietf.org/mail-archive/web/ietf/current/msg77273.html.
>
>Cheers,
>Med 
>

---

From: SM <[email-masked]>
Date: Thu, 21 Mar 2013 19:51:30 -0700

Hi Med,
>changes in -06 solve your concern.

Sorry, it was IETF week.

>I would appreciate if you can check the new revision. For your 
>convenience the diff is available here: 
>http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06

There was the following in Section 2:

   "HOST_ID does not reveal the identity of a user, a subscriber or an
    application."

That was changed to state that HOST_ID is not designed to reveal the 
identity of a user.  The question is whether it can be used to reveal 
the identity of the user.  I don't see an explanation for that in 
draft-ietf-intarea-nat-reveal-analysis-06.

The layering issue for Forwarded header (Section 4.4.1) is still in 
draft-ietf-intarea-nat-reveal-analysis-06.

In Section 4.4.2:

   "Injecting Forwarded header also introduces some implementations
    complexity if the HTTP message is at or close to the MTU size."

I don't know how much breakage will occur with this.

I would leave it to the document shepherd to decide whether to 
discuss all this in the working group.  It could be used to override 
the concern if everyone looks the other way. :-)

Regards,
-sm

---

From: <[email-masked]>
Date: Fri, 22 Mar 2013 07:37:38 +0100

Hi SM,

Please see inline.

Cheers,
Med 

>De : SM [mailto:[email-masked]] 
>Envoyé : vendredi 22 mars 2013 03:52
>À : BOUCADAIR Mohamed OLNC/OLN; Peter Yee
>Cc : [email-masked]; Brian Haberman; Suresh Krishnan; 

Med: The text in -06 says:

   HOST_ID is not designed to reveal the identity of a user, a
   subscriber, or an application.  HOST_ID is designed to identify a
   host under a shared IP address.

To prevent HOST_ID to be used to track a host, Section 3 discusses that aspect. 
In particular, the text says "Address-sharing function should not use
      permanent HOST_ID values."

>I don't know how much breakage will occur with this.

Med: Me too. This issue was reported by a wg participant.

---

From: SM <[email-masked]>
Date: Thu, 21 Mar 2013 23:50:58 -0700

Hi Med,
>       permanent HOST_ID values."

I saw that. :-)

I consider my comments as addressed.

Regards,
-sm

---

From: <[email-masked]>
Date: Fri, 22 Mar 2013 07:59:19 +0100

Re-,

Thank you for reviewing the document. Much appreciated. 

Cheers,
Med 

>Envoyé : vendredi 22 mars 2013 07:51