Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments
draft-ietf-intarea-nat-reveal-analysis-10

[Ballot comment]
Thanks for addressing my DISCUSS.

Two comments left:
The text in Section 2 looks lost in that place and would be better placed in Section 4.3 (TCP):
  HOST_ID mechanisms need to be aware of E2E issues and avoid
  interfering with them. One example of such interference would be
  injecting or removing TCP options of transited packets; another such
  interference involves terminating and re-originating TCP connections
  not belonging to the transit device.

Please expand E2E to end-to-end.

[Ballot discuss]
Updated based on the discussions as of 4/11

Here are my DISCUSS issues:

1) I still disagree with the text, but I can see that this might depend on the content provider. Moved to the comments.

2)Fixed.

3) moved to the comments section.


4)
Section 4.3.1., paragraph 1:

>    HOST_ID may be conveyed in a dedicated TCP Option.  An example is
>    specified in [I-D.wing-nat-reveal-option].  This option encloses the
>    TCP client's identifier (e.g., the lower 16 bits of its IPv4 address,
>    its VLAN ID, VRF ID, or subscriber ID).  The address-sharing device
>    inserts this TCP Option into the TCP SYN packet.

  Adding a TCP option somewhere in the e2e path is contradicting the
  e2e approach of TCP -- this is an architectural concern that cannot
  be easily addressed.
My suggestion here:
Add to Section 4.3.2., bullet "Injecting the ..." this text: "Middleboxes of any type are not supposed to add or remove any TCP options." This will count for the fact that this memo is documenting what's being proposed, but makes clear that this is not a valid option.


5) fixed.

[Ballot comment]
  This draft is proposing, or at least elaborating, a lot of hacks in
  order to determine specific hosts behind a NAT (irrespectively if it
  is a CGN or not). However, I do not see any viable approach in
  this that can be deployed in a wider scale, as each solution has
  its severe limitations.

1)
Section 1., paragraph 3:

>    The risk of not mitigating these issues include: OPEX (Operational
>    Expenditure) increase for IP connectivity service providers (costs
>    induced by calls to a hotline), revenue loss for content providers
>    (loss of users audience) and customers' dissatisfaction (low quality

  Content providers usually do not have issues with NATs, as the did
  get used to it in the last 15 years (or so). For instance, you can
  run your favorite social media site and move between private and
  public IP addresses, even move between IP address versions, and
  they can exactly identify you. So this is a non issue here. They
  have HTTP cookies, browser finger printing, web bugs, URL signing
  etc. It is very limited to HTTP, but that's where most of the
  content is flowing over, isn't it?

2)
4.3.  Define a TCP Option

  This section is referring to a number of individual drafts that
  describe some solution approaches that have not tested in wider
  deployments, nor do they have received adequate community
  review in my opinion. E.g., wing-nat-reveal-option and
  abdo-hostid-tcpopt-implementation.

[Ballot discuss]
Updated based on the discussions as of 4/11

Here are my DISCUSS issues:

1) I still disagree with the text, but I can see that this might depend on the content provider. Moved to the comments.

2)Fixed.

3) moved to the comments section.


4)
Section 4.3.1., paragraph 1:

>    HOST_ID may be conveyed in a dedicated TCP Option.  An example is
>    specified in [I-D.wing-nat-reveal-option].  This option encloses the
>    TCP client's identifier (e.g., the lower 16 bits of its IPv4 address,
>    its VLAN ID, VRF ID, or subscriber ID).  The address-sharing device
>    inserts this TCP Option into the TCP SYN packet.

  Adding a TCP option somewhere in the e2e path is contradicting the
  e2e approach of TCP -- this is an architectural concern that cannot
  be easily addressed.
My suggestion here:
Add to Section 4.3.2., bullet "Injecting the ..." this text: "Middleboxes of any type are not supposed to add or remove any TCP options." This will count for the fact that this memo is documenting what's being proposed, but makes clear that this is not a valid option.


5)
Section 5., paragraph 5:

>    Provided success ratio figures for TCP and IP options are inspired
>    from the results documented in [Options],
>    [I-D.abdo-hostid-tcpopt-implementation], [ExtendTCP].

  Can you please explain how you come to 99 % success ratio for TCP
  with new options? The latest data in [ExtendTCP] does not support
  your figures. The reference [Options] is outdated, as it is dated
  2005 and the network has changed a lot.

My suggestion in this case: Please remove the success ratio numbers in the table and solely indicate a level of expected success ratio. For instance, high for TCP options. The issue is that on some paths the chance of new TCP options to survive is high while on others it might be not that high. The test are not convincing and the resulting 99 % are not convincing and not "transferable" to all Internet paths.

[Ballot comment]

  This draft is proposing, or at least elaborating, a lot of hacks in
  order to determine specific hosts behind a NAT (irrespectively if it
  is a CGN or not). However, I do not see any viable approach in
  this that can be deployed in a wider scale, as each solution has
  its severe limitations.

1)
Section 1., paragraph 3:

>    The risk of not mitigating these issues include: OPEX (Operational
>    Expenditure) increase for IP connectivity service providers (costs
>    induced by calls to a hotline), revenue loss for content providers
>    (loss of users audience) and customers' dissatisfaction (low quality

  Content providers usually do not have issues with NATs, as the did
  get used to it in the last 15 years (or so). For instance, you can
  run your favorite social media site and move between private and
  public IP addresses, even move between IP address versions, and
  they can exactly identify you. So this is a non issue here. They
  have HTTP cookies, browser finger printing, web bugs, URL signing
  etc. It is very limited to HTTP, but that's where most of the
  content is flowing over, isn't it?

2)
4.3.  Define a TCP Option

  This section is referring to a number of individual drafts that
  describe some solution approaches that have not tested in wider
  deployments, nor do they have received adequate community
  review in my opinion. E.g., wing-nat-reveal-option and
  abdo-hostid-tcpopt-implementation.

[Ballot discuss]
Updated based on the discussions as of 4/11

Here are my DISCUSS issues:

1)
Section 1., paragraph 3:

>    The risk of not mitigating these issues include: OPEX (Operational
>    Expenditure) increase for IP connectivity service providers (costs
>    induced by calls to a hotline), revenue loss for content providers
>    (loss of users audience) and customers' dissatisfaction (low quality

  Content providers usually do not have issues with NATs, as the did
  get used to it in the last 15 years (or so). For instance, you can
  run your favorite social media site and move between private and
  public IP addresses, even move between IP address versions, and
  they can exactly identify you. So this is a non issue here. They
  have HTTP cookies, browser finger printing, web bugs, URL signing
  etc. It is very limited to HTTP, but that's where most of the
  content is flowing over, isn't it?
  I would suggest to remove the content provider part.

2)
Section 4.2.1., paragraph 1:

>    A solution alternative to convey the HOST_ID is to define an IP
>    option [RFC0791].  A HOST_ID IP option can be inserted by the
>    address-sharing function to uniquely distinguish a host among those
>    sharing the same IP address.  An example of such option is documented
>    in [I-D.chen-intarea-v4-uid-header-option].  This IP option allows
>    the conveyance of an IPv4 address, an IPv6 prefix, a GRE (Generic
>    Routing Encapsulation) key, an IPv6 Flow Label, etc.

  The description and also the analysis is neglecting any MTU issue:
  If some middlebox is adding an IP option to a packet, the packet
  might just to big for the path MTU.
  Further, what happens if the
  options space in the IP header is already occupied by other options?
  Please document the issues as you did also for the other approaches.



3)
moved to the comments section.


4)
Section 4.3.1., paragraph 1:

>    HOST_ID may be conveyed in a dedicated TCP Option.  An example is
>    specified in [I-D.wing-nat-reveal-option].  This option encloses the
>    TCP client's identifier (e.g., the lower 16 bits of its IPv4 address,
>    its VLAN ID, VRF ID, or subscriber ID).  The address-sharing device
>    inserts this TCP Option into the TCP SYN packet.

  Adding a TCP option somewhere in the e2e path is contradicting the
  e2e approach of TCP -- this is an architectural concern that cannot
  be easily addressed.
  Further, what should the middlebox do, if the TCP option space is
  already fully occupied by other options in a packet? Not insert the
  HOST_ID option, let the TCP connection fail, or remove some
  other TCP option?

FIXED & done:
  The MTU issues can also be present in TCP SYNs if at any future time
  TCP SYNs carry already user data, see also
  draft-ietf-tcpm-fastopen-03.



5)
Section 5., paragraph 5:

>    Provided success ratio figures for TCP and IP options are inspired
>    from the results documented in [Options],
>    [I-D.abdo-hostid-tcpopt-implementation], [ExtendTCP].

  Can you please explain how you come to 99 % success ratio for TCP
  with new options? The latest data in [ExtendTCP] does not support
  your figures. The reference [Options] is outdated, as it is dated
  2005 and the network has changed a lot.

[Ballot comment]
  This draft is proposing, or at least elaborating, a lot of hacks in
  order to determine specific hosts behind a NAT (irrespectively if it
  is a CGN or not). However, I do not see any viable approach in
  this that can be deployed in a wider scale, as each solution has
  its severe limitations.

4.3.  Define a TCP Option

  This section is referring to a number of individual drafts that
  describe some solution approaches that have not tested in wider
  deployments, nor do they have received adequate community
  review in my opinion. E.g., wing-nat-reveal-option and
  abdo-hostid-tcpopt-implementation.

[Ballot comment]
No objection on the publication of this document, but please engage the discussion on my COMMENT.

From the abstract
  The host identifier must be unique to each host under the same
  shared IP address.

And later on:
  Because HOST_ID is used by a remote server to sort out the packets by
  sending host, HOST_ID must be unique to each host under the same IP
  address.

Shouldn't the HOST_ID be unique across IPv4 and IPv6, so unique per host, as the name implies?
I have in mind a scenario such a MultiPath TCP with two addresses, IPv4 and IPv6.

If agreed, this following sentence is not correct

  The volatility of the HOST_ID information is similar to that of the
  internal IP address: a distinct HOST_ID may be used by the address-
  sharing function when the host reboots or gets a new internal IP
  address.

If disagreed, I believe that the term HOST-ID is wrong. What you speak about is actually a HOST-IPADDRESS-ID, or mabye a HOST-NAT-ID.

[Ballot comment]
4.4

You talk about HTTP here, which more or less has the same mechanism as SIP, but you don't really go into SMTP. SMTP can do similar things, but the mechanisms are going to be much different than HTTP or SIP. It's not even alluded to in section 5. I'd say either analyze SMTP properly, say something like, "Related mechanisms could be developed for other application-layer protocols, but the discussion in this document is limited to HTTP and similar protocols", or drop it from the discussion completely.

4.5.1

  The solution, referred to as Proxy Protocol [Proxy], does not require
  any application-specific knowledge.  The rationale behind this
  solution is to prepend each connection with a line reporting the
  characteristics of the other side's connection as shown in the
  example depicted in Figure 2.  The header line shown in this example
  is for a TCP over IPv4 connection received from 192.0.2.1:56324 and
  destined to 192.0.2.15:443.  The "PROXY" string is used to identify
  the Proxy Protocol while "\r\n" indicates CRLF.
 
You wouldn't know what the above was talking about unless you read the Proxy document. I suggest:

  The solution, referred to as Proxy Protocol [Proxy], does not require
  any application-specific knowledge.  The rationale behind this
  solution is to insert identification data directly into the
  application data stream prior to the actual protocol data being sent,
  regardless of the protocol. Every application protocol would begin
  with a textual string of "PROXY", followed by some textual
  identification data, ending with a CRLF, and only then the would the
  application data be inserted. Figure 2 shows and example of a line of
  data used for this, in this case for  a TCP over IPv4 connection
  received from 192.0.2.1:56324 and destined to 192.0.2.15:443.

[Ballot comment]
4.4

You talk about HTTP here, which more or less has the same mechanism as SIP, but you don't really go into SMTP. SMTP can do similar things, but the mechanisms are going to be much different than HTTP or SIP. It's not even alluded to in section 5. I'd say either analyze SMTP properly, say something like, "Related mechanisms could be developed for other application-layer protocols, but the discussion in this document is limited to HTTP and similar protocols", or drop it from the discussion completely.

4.5.1

  The solution, referred to as Proxy Protocol [Proxy], does not require
  any application-specific knowledge.  The rationale behind this
  solution is to prepend each connection with a line reporting the
  characteristics of the other side's connection as shown in the
  example depicted in Figure 2.  The header line shown in this example
  is for a TCP over IPv4 connection received from 192.0.2.1:56324 and
  destined to 192.0.2.15:443.  The "PROXY" string is used to identify
  the Proxy Protocol while "\r\n" indicates CRLF.
 
You wouldn't know what the above was talking about unless you read the Proxy document. I suggest:

  The solution, referred to as Proxy Protocol [Proxy], does not require
  any application-specific knowledge.  The rationale behind this
  solution is to insert identification data directly into the application
  data stream prior to the actual protocol data being sent, regardless of
  the protocol. Every application protocol would begin with a textual
  string of "PROXY", followed by some textual identification data, ending
  with a CRLF, and only then the would the application data be inserted.
  Figure 2 shows and example of a line of data used for this, in this case
  for  a TCP over IPv4 connection received from 192.0.2.1:56324 and
  destined to 192.0.2.15:443.

[Ballot comment]
This title of this document suggests that it is scoped to all address-sharing models, but in fact the text about host identifiers only accurately relates to DS-Lite.  I think the document is relevant to all address-sharing models, but really reads as if it were written specifically with DS-Lite in mind.

I'm just throwing this comment out to see what reaction it gets; I'm not convinced that there's an action item here.  If the authors really do intend to address all address-sharing models, some tweaking of the wording in section 2 would help, and maybe a mention in section 3 that in a MAP or lw4over6 scenario, port set allocation is mandatory and host identities don't need to be revealed at all—only the HG identity is actually revealed.

[Ballot comment]
A few minor revisions:

In Section 1. Adding a comma to "application proxies or A+P" would help clarify that the two are not equivalent.

In Section 3.1. The sentence after "Interference between HOST_IDs" didn't really parse for me.  Suggested revision: "If an address sharing system can inject multiple types of HOST_ID value at different layers, then all injected HOST_ID values must reference the same underlying data.  For example, one might reference a full IP address, while another references the lower 16 bits."

In Section 4.2.2.  Change "host-hint" to "HOST_ID".

In Section 4.3.2., Second bullet.  It might also be worth noting that including the HOST_ID in the ACK would interfere with TCP Fast Open.  If the server wanted to deliver different data based on HOST_ID, then it would have to wait for the ACK before transmitting.


In Section 4.6.1.  It could be helpful to reference some current BEHAVE-related work here:



In Section 4.8.2., next-to-last bullet.  It might be more helpful to reference the NAT-specific logging documents being developed in BEHAVE:
http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging
http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging

[Ballot discuss]
  This draft is proposing, or at least elaborating, a lot of hacks in
  order to determine specific hosts behind a NAT (irrespectively if it
  is a CGN or not). However, I do not see any viable approach in
  this that can be deployed in a wider scale, as each solution has
  its severe limitations.

Here are my DISCUSS issues:

1)
Section 1., paragraph 3:

>    The risk of not mitigating these issues include: OPEX (Operational
>    Expenditure) increase for IP connectivity service providers (costs
>    induced by calls to a hotline), revenue loss for content providers
>    (loss of users audience) and customers' dissatisfaction (low quality

  Content providers usually do not have issues with NATs, as the did
  get used to it in the last 15 years (or so). For instance, you can
  run your favorite social media site and move between private and
  public IP addresses, even move between IP address versions, and
  they can exactly identify you. So this is a non issue here. They
  have HTTP cookies, browser finger printing, web bugs, URL signing
  etc. It is very limited to HTTP, but that's where most of the
  content is flowing over, isn't it?
  I would suggest to remove the content provider part.

2)
Section 4.2.1., paragraph 1:

>    A solution alternative to convey the HOST_ID is to define an IP
>    option [RFC0791].  A HOST_ID IP option can be inserted by the
>    address-sharing function to uniquely distinguish a host among those
>    sharing the same IP address.  An example of such option is documented
>    in [I-D.chen-intarea-v4-uid-header-option].  This IP option allows
>    the conveyance of an IPv4 address, an IPv6 prefix, a GRE (Generic
>    Routing Encapsulation) key, an IPv6 Flow Label, etc.

  The description and also the analysis is neglecting any MTU issue:
  If some middlebox is adding an IP option to a packet, the packet
  might just to big for the path MTU.
  Further, what happens if the
  options space in the IP header is already occupied by other options?



3)
4.3.  Define a TCP Option

  This section is referring to a number of individual drafts that
  describe some solution approaches that have not tested in wider
  deployments, nor do they have received adequate community
  review in my opinion. E.g., wing-nat-reveal-option and
  abdo-hostid-tcpopt-implementation.


4)
Section 4.3.1., paragraph 1:

>    HOST_ID may be conveyed in a dedicated TCP Option.  An example is
>    specified in [I-D.wing-nat-reveal-option].  This option encloses the
>    TCP client's identifier (e.g., the lower 16 bits of its IPv4 address,
>    its VLAN ID, VRF ID, or subscriber ID).  The address-sharing device
>    inserts this TCP Option into the TCP SYN packet.

  Adding a TCP option somewhere in the e2e path is contradicting the
  e2e approach of TCP -- this is an architectural concern that cannot
  be easily addressed.
  Further, what should the middlebox do, if the TCP option space is
  already fully occupied by other options in a packet? Not insert the
  HOST_ID option, let the TCP connection fail, or remove some
  other TCP option?
  The MTU issues can also be present in TCP SYNs if at any future time
  TCP SYNs carry already user data, see also
  draft-ietf-tcpm-fastopen-03.



5)
Section 5., paragraph 5:

>    Provided success ratio figures for TCP and IP options are inspired
>    from the results documented in [Options],
>    [I-D.abdo-hostid-tcpopt-implementation], [ExtendTCP].

  Can you please explain how you come to 99 % success ratio for TCP
  with new options? The latest data in [ExtendTCP] does not support
  your figures. The reference [Options] is outdated, as it is dated
  2005 and the network has changed a lot.

[Ballot comment]
Section 4.4.2., paragraph 7:

>    Injecting Forwarded header for all encrypted HTTP traffic is
>    infeasible.

  What is encrypted in this case?
  Anyhow, more and more traffic is carried over TLS, basically
  eliminating this option right from the beginning.

[Ballot comment]

- abstract: saying "is used" makes the reader think that you
will provide a preferred solution, but since you're not going
to, "could be used" would be better.

- abstract: Saying "a remote server" without qualification is
odd - do you mean any other host on the Internet and do you
really mean a server only? Maybe an "authorized remote host"
would be better?

- section 2: it might be clearer if you clarify that you still
mean a host when that host is one computer in a home behind a
DSL modem. I think that's implied, when you say that HOST_ID
is not designed to reveal the identity of a subscriber, but
it'd be good to be extra clear on that.

- section 3: shouldn't possible solutions say if they allow
for some control somewhere as to which remote hosts can or
cannot freely access the HOST_ID? In particular some of the
possible solutions seem to differ in how the user's ISP could
or could not control some of that on behalf of the user.

- section 3: similarly the solutions differ as to whether or
not middleboxes or just the remote hosts with which a user
wants to interact can track users and that's also a
consideration esp. if TLS were used.

- section 3: a HOST_ID can also expose location information
depending on how its done. (And without any geopriv style
protection.) I think that should get a mention here too and
also be considered by HOST_ID specification documents.  I
think that also warrants a mention in 3.1.

- section 3: Shouldn't the honest end-user also be given some
element of control too? I think adding a design consideration
that different end-user preferences should be supported would
be good.

- section 3.1: I think all the above points on section 3 would
be fine additions to 3.1 (of course:-)

- section 5: I think "encrypted traffic" here means encryption
via TLS or above, is that right? What about IPsec? Anyway a
note on that would be good.

- section 5: the "success ratio" figures don't seem to
correlate that well with the earlier "analysis" sections which
surprised me. (just a comment)

- the end: ...is very abrupt:-) I guess the WG just couldn't
reach even a rough consensus on something to recommend? If so,
it might be worth saying a bit about that if its not too
controversial as that might help future readers know what to
do with this document.

[Ballot comment]
Comments about the shepherd writeup:

"This document does not define a protocol. Hence there are no implementations of this document."

Well, but the document "analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used."  There certainly could be implementations of some or all of these solution candidates, and it would be useful to know about those.

"In particular, as a result of WG consensus, this version of the
draft does not make any recommendations as to a preferred solution
among those analyzed."

I would have appreciated a brief summary explaining why the working group did not want to make any recommendations -- that would have been a useful part of the working group discussion for the shepherd to summarize, especially given the answer to question 9 (and my former DISCUSS, because I didn't understand).

------------------------------------------------------------------------------
On the document:

-- Section 1 --

Total nit: in paragraph 1, "SPAM" is not an acronym, and the custom is to spell it with no caps, as "spam".  The canned meat is "SPAM" or "Spam", and those are trademarked.

-- Section 2 --

  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.

I understand that it's not *designed* to reveal the identity of a user.  Nevertheless, it's *likely* to reveal the identity of users often.  Because you address privacy issues in Section 3, I think this paragraph needs a forward reference to that section.

-- Section 3 --

  The proposals considered in this document add a measure of
  identifiability back to hosts that share a public IP address.  The
  extent of that uniqueness depends on what information is included in
  the HOST_ID.

The extent of what uniqueness?  Do you mean "the extent of that identifiability"?

  The volatility of the HOST_ID information is similar to the source IP
  address:

Later in the paragraph you say "internal IP address".  For clarity, you should be consistent in how you refer to the IP addresses on either side of the NAT.  Also fixing a nit, I think this should be, "The volatility of the HOST_ID information is similar to that of the internal IP address:".

-- Section 3.1 --

  Uniqueness of identifiers in HOST_ID:  It is recommended that
      HOST_IDs be limited to providing local uniqueness rather than
      global uniqueness.

I don't understand how that matters at all: as you point out above, if the HOST_ID is locally unique, the combination of it and the external IP address is globally unique.  Perhaps an explanation of what you're actually recommending and why might make this clearer.

In fact, I think that's true of all four items in this section: I'm having trouble understanding the real point of any of them, so a bit more explanation of what they're really trying to say, and including "why", would really help.

-- Section 4.1.1 --

You cite RFC 6864 here, and that document consistently refers to the field you're talking about as "the IPv4 ID field".  You're calling it "the IP-ID field".  Wouldn't it make sense to make your usage consistent with that of the document you're citing?

  Note that this field is not altered by some NATs; hence,
  there are some side effects such as counting hosts behind a NAT

Not altered: isn't that the point?  I thought the whole *point* of this was to provide a HOST_ID that survives the NAT and can be inspected outside.  Now I'm confused.

  Address-sharing devices using this solution would be required to
  indicate that out of band, possibly using a special DNS record.

What is the antecedent of "that"?  This seems very odd in a paragraph all on its own.

-- Section 4.1.2 --

  Complications may arise if the packet is fragmented before reaching
  the device injecting the HOST_ID.  To appropriately handle those
  packets, the address-sharing function will need to maintain a lot of
  state.

"The packet" and "those packets" disagree in number, making this confused.  Perhaps you mean, "To appropriately handle the multiple packets created by fragmentation, ..." ?

  one can argue this coordinated NAT scenario is not a typical
  deployment scenario but still using IP-ID as a channel to convey a
  HOST_ID is ill-advised.

I can't parse this, and don't know what you're trying to say (though I do get that the end result is that this is ill-advised).  Perhaps you need some punctuation?

  The risk to experience session failures due to handling a new TCP
  Option is low as measured in [Options].
  [I-D.abdo-hostid-tcpopt-implementation] provides a detailed
  implementation and experimentation report of a HOST_ID TCP Option.
  [I-D.abdo-hostid-tcpopt-implementation] investigated in depth the
  impact of activation HOST_ID on the host, the address-sharing
  function, and the enforcement of policies at the server side.
  [I-D.abdo-hostid-tcpopt-implementation] reports a failure ratio of
  0.103% among top 100000 websites.

I strongly suggest that you re-word this paragraph.  Having three citations to the same document in three consecutive sentences is really awkward, and the whole thing is choppy and hard to follow.

-- Section 5 --

  o  "Success ratio" indicates the ratio of successful communications
      with remote servers when the HOST_ID is injected using a candidate
      solution.

Measured how?  So these are actually coded and people did experiments?  Are there raw numbers that we can look at?

Ah, I see that you kinda-sorta try to answer this below the table.  Please re-organize the text (or maybe just use a "see below" reference) so that it's clearer what this row of the table means and where it comes from.  (Mostly, I'm sensing that it's a "wild guess", rather than anything remotely real.)

    (7)  The solution is a theoretical construct.

In other words, this is just an idea that someone threw out, which isn't completely baked?  It would have been *really* nice to have said that up in Sections 4.1, 4.6, and 4.7, rather than only including it as a note in this table!

-- Section 7 --

You should refer to Section 3 in here.  Perhaps insert a new third paragraph that says something like, "For more discussion of privacy issues related to HOST_ID, see Section 3."

[Ballot discuss]
The shepherd writeup says this:
"In particular, as a result of WG consensus, this version of the
draft does not make any recommendations as to a preferred solution
among those analyzed."

But as I read the document, I see this:

- Section 4.1 is about using the IP Identification field, and concludes that "using IP-ID as a channel to convey a HOST_ID is ill-advised."

- Section 4.2 is about using an IP option, and concludes that "using an IP option to convey a host-hint is not viable."

- Section 4.4 is about using message headers at the application layer, and concludes that this doesn't work at all for some protocols and is problematic for others.

- Section 4.5 is about using something called "Proxy Protocol", and concludes that "this solution is infeasible and can not be recommended."

In what sense are these not making recommendations?  Does this mean that the document does not, in fact, reflect WG consensus, because it's making recommendations?

[Ballot discuss]
The shepherd writeup says this:
"In particular, as a result of WG consensus, this version of the
draft does not make any recommendations as to a preferred solution
among those analyzed."

But as I read the document, I see this:
- Section 4.1 is about using the IP Identification field, and concludes that "using IP-ID as a channel to convey a HOST_ID is ill-advised."
- Section 4.2 is about using an IP option, and concludes that "using an IP option to convey a host-hint is not viable."
- Section 4.4 is about using message headers at the application layer, and concludes that this doesn't work at all for some protocols and is problematic for others.
- Section 4.5 is about using something called "Proxy Protocol", and concludes that "this solution is infeasible and can not be recommended."

In what sense are these not making recommendations?  Does this mean that the document does not, in fact, reflect WG consensus, because it's making recommendations?

[Ballot comment]
Comments about the shepherd writeup:

"This document does not define a protocol. Hence there are no implementations of this document."

Well, but the document "analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used."  There certainly could be implementations of some or all of these solution candidates, and it would be useful to know about those.

"In particular, as a result of WG consensus, this version of the
draft does not make any recommendations as to a preferred solution
among those analyzed."

I would have appreciated a brief summary explaining why the working group did not want to make any recommendations -- that would have been a useful part of the working group discussion for the shepherd to summarize, especially given the answer to question 9 (and see my DISCUSS above).

------------------------------------------------------------------------------
On the document:

-- Section 1 --

Total nit: in paragraph 1, "SPAM" is not an acronym, and the custom is to spell it with no caps, as "spam".  The canned meat is "SPAM" or "Spam", and those are trademarked.

-- Section 2 --

  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.

I understand that it's not *designed* to reveal the identity of a user.  Nevertheless, it's *likely* to reveal the identity of users often.  Because you address privacy issues in Section 3, I think this paragraph needs a forward reference to that section.

-- Section 3 --

  The proposals considered in this document add a measure of
  identifiability back to hosts that share a public IP address.  The
  extent of that uniqueness depends on what information is included in
  the HOST_ID.

The extent of what uniqueness?  Do you mean "the extent of that identifiability"?

  The volatility of the HOST_ID information is similar to the source IP
  address:

Later in the paragraph you say "internal IP address".  For clarity, you should be consistent in how you refer to the IP addresses on either side of the NAT.  Also fixing a nit, I think this should be, "The volatility of the HOST_ID information is similar to that of the internal IP address:".

-- Section 3.1 --

  Uniqueness of identifiers in HOST_ID:  It is recommended that
      HOST_IDs be limited to providing local uniqueness rather than
      global uniqueness.

I don't understand how that matters at all: as you point out above, if the HOST_ID is locally unique, the combination of it and the external IP address is globally unique.  Perhaps an explanation of what you're actually recommending and why might make this clearer.

In fact, I think that's true of all four items in this section: I'm having trouble understanding the real point of any of them, so a bit more explanation of what they're really trying to say, and including "why", would really help.

-- Section 4.1.1 --

You cite RFC 6864 here, and that document consistently refers to the field you're talking about as "the IPv4 ID field".  You're calling it "the IP-ID field".  Wouldn't it make sense to make your usage consistent with that of the document you're citing?

  Note that this field is not altered by some NATs; hence,
  there are some side effects such as counting hosts behind a NAT

Not altered: isn't that the point?  I thought the whole *point* of this was to provide a HOST_ID that survives the NAT and can be inspected outside.  Now I'm confused.

  Address-sharing devices using this solution would be required to
  indicate that out of band, possibly using a special DNS record.

What is the antecedent of "that"?  This seems very odd in a paragraph all on its own.

-- Section 4.1.2 --

  Complications may arise if the packet is fragmented before reaching
  the device injecting the HOST_ID.  To appropriately handle those
  packets, the address-sharing function will need to maintain a lot of
  state.

"The packet" and "those packets" disagree in number, making this confused.  Perhaps you mean, "To appropriately handle the multiple packets created by fragmentation, ..." ?

  one can argue this coordinated NAT scenario is not a typical
  deployment scenario but still using IP-ID as a channel to convey a
  HOST_ID is ill-advised.

I can't parse this, and don't know what you're trying to say (though I do get that the end result is that this is ill-advised).  Perhaps you need some punctuation?

  The risk to experience session failures due to handling a new TCP
  Option is low as measured in [Options].
  [I-D.abdo-hostid-tcpopt-implementation] provides a detailed
  implementation and experimentation report of a HOST_ID TCP Option.
  [I-D.abdo-hostid-tcpopt-implementation] investigated in depth the
  impact of activation HOST_ID on the host, the address-sharing
  function, and the enforcement of policies at the server side.
  [I-D.abdo-hostid-tcpopt-implementation] reports a failure ratio of
  0.103% among top 100000 websites.

I strongly suggest that you re-word this paragraph.  Having three citations to the same document in three consecutive sentences is really awkward, and the whole thing is choppy and hard to follow.

-- Section 5 --

  o  "Success ratio" indicates the ratio of successful communications
      with remote servers when the HOST_ID is injected using a candidate
      solution.

Measured how?  So these are actually coded and people did experiments?  Are there raw numbers that we can look at?

Ah, I see that you kinda-sorta try to answer this below the table.  Please re-organize the text (or maybe just use a "see below" reference) so that it's clearer what this row of the table means and where it comes from.  (Mostly, I'm sensing that it's a "wild guess", rather than anything remotely real.)

    (7)  The solution is a theoretical construct.

In other words, this is just an idea that someone threw out, which isn't completely baked?  It would have been *really* nice to have said that up in Sections 4.1, 4.6, and 4.7, rather than only including it as a note in this table!

-- Section 7 --

You should refer to Section 3 in here.  Perhaps insert a new third paragraph that says something like, "For more discussion of privacy issues related to HOST_ID, see Section 3."

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-intarea-nat-reveal-analysis-05.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments) to Informational RFC


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID)
  in Shared Address Deployments'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-03-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document is a collection of solutions to reveal a host
  identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or
  application proxies are involved in the path.  This host identifier
  is used by a remote server to sort out the packets by sending host.
  The host identifier must be unique to each host under the same shared
  IP address.

  This document analyzes a set of solution candidates to reveal a host
  identifier; no recommendation is sketched in the document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis/ballot/


No IPR declarations have been submitted directly on this I-D.

All,
    I have completed my AD evaluation for the above draft and have some feedback for the group.  I will focus on the substantive comments for the time being since some of them may result in re-written text in places.  I will follow up with the document authors on editorial nits and such at a later time.

1. It is obvious from the way certain sections of text are written that the original intent was to make a recommendation on which of the described approaches should be used to disambiguate between multiple hosts behind a NAT/CGN.  Given that the document is now simply a characterization of those mechanisms, I would suggest spending some time cleaning up the Abstract, Section 1.1, and Section 2 so that they focus on the task of describing the mechanisms, rather than mentioning abstract requirements for those mechanisms. There are concrete suggestions a little later in this note.

2. The mechanisms described in this draft fall into two broad categories, deployed and proposed. Those in the former category can be characterized based on actual usage scenarios, which would benefit the table shown in Figure 3. The latter should be described in terms of what they are proposed to do, but cannot be assessed against the same metrics as the other groups.

3. The "Requirements Language" section should be removed.  As an Informational document describing mechanisms, there is no need to leverage 2119 keywords.

4. It would be useful if the third paragraph of Section 1.1 was expanded to discuss the risks in more detail.  In fact, it may be clearer to understand this draft if the problem statement came before the context (Section 2).

5. Section 2

* The Observation text should provide some brief examples of how and why special treatment is needed/provided.  Is it sufficient to identify the sending host? application? user? It should also note that there may be issues with the fact that some IP addresses will be shared and others may not.  How does that impact the performance of these mechanisms?

* I would like some text in the Objective text to explain why such sorting is needed.  This relates back to the Context description in Section 1.1.

* I don't think there needs to be a description of a Requirement in this document any more, so that text can be removed.

6. Section 3.1 should be removed.  This is simply an analysis of the mechanisms, so there is no new work which needs requirements defined at this point.

7. In Section 4.1.2, it would be good to describe any issues that the approach has with the original use of the Identification field for fragmentation reassembly.  If a middlebox changes the ID field, weird things can/will happen if those packets are fragmented somewhere.

8. I don't see a need for a forward reference in Section 4.2.2. I would suggest simply stating that the IP Option approach will support any/all transport protocols.

9. In Section 4.3.2...

* I would like to see some description of what risk(s) may arise with a TCP option, even though they are apparently low probability.

* Additionally, the text contains "0,103%", which I assume should be "0.103%" (i.e., 1/10th of 1%).

*The third bullet mentions that having several NATs in the path may cause issues for a TCP option.  Isn't this true for other approaches discussed in the document?  These should be identified as well.

10. In Section 4.5.1, I would suggest adding some text that describes how to interpret Figure 2.

11. Is Section 4.6 theoretical or is there a specific reference that can be added for this technique?

12. Section 4.7.2 should clearly state that HIP is an ideal solution for this identification problem, even though the document states there is a high cost for deployment. I would also like to see some description of why HIP does not work if "the address sharing function is required to act as a UDP/TCP-HIP relay".

13. Section 4.8.2

* The text says that the ICMP approach is viable for TCP and UDP.  Any reason why it may be an issue for other transport protocols (e.g., SCTP or RTP)?

* I would also like to see some text describing why the approach is not compatible with cascading NATs.

* The last bullet mentions FMC and Open WiFi with no context or references.  These should either have references or their mention should be removed since they don't add much to the description.  The same goes for their mention in Section 4.9.2 (8th bullet).

14. In Section 4.9.2 (3rd bullet), is the solution to publish this info in DNS or is that just an example approach?  This should be clarified.

15. Section 5

* Shouldn't there be an additional metric that covers the impact/cost of needing client or middlebox code changes?

* Where did the 100% success ratio for IP-ID come from?  There have been documented cases of OSes setting the Identification field to zero.  If that is true, the success ratio can't be 100% can it?

* Given the goal of this document to describe these identification mechanisms, I don't see the need for the last bulleted list.

Regards,
Brian