Subject: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

From: Brian Haberman <[email-masked]>
Date: Mon, 11 Feb 2013 16:11:47 -0500

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 11 Feb 2013 19:08:52 -0500

Hi Brian,
  Thanks for the review. I wanted to clarify three points that you
raised and I will ask the authors take care of the rest.

> things can/will happen if those packets are fragmented somewhere.

Agree. I think this is precisely the reason that the mechanism for
putting the HOST_ID in the IP-ID is a non-starter.

> be added for this technique?

There are several mechanisms that use port sets for IPv4 address
sharing. A+P (RFC6346) is one such mechanism.

> that is true, the success ratio can't be 100% can it?

This technique involves the translator (and not the sender) setting the
IP-ID field. That is why it can still work with OSes on senders setting
the IP-ID to zero.

Thanks
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Mon, 11 Feb 2013 19:44:18 -0500

Hi Suresh,

> putting the HOST_ID in the IP-ID is a non-starter.

I agree.  But that rationale should be in the draft.

> sharing. A+P (RFC6346) is one such mechanism.

Then I would ask that a reference be put in to give readers an example.

> IP-ID field. That is why it can still work with OSes on senders setting

You still have the issue of the middlebox setting that ID to something 
that potentially impacts fragmentation reassembly.  So, I would still 
like to know how that 100% success ratio was collected.

Regards,
Brian

---

From: <[email-masked]>
Date: Tue, 12 Feb 2013 11:34:15 +0100

Dear Brian,

Many thanks for the detailed review.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked]
>[mailto:[email-masked]] De la part de Brian Haberman
>Envoyé : lundi 11 février 2013 22:12
>À : [email-masked];
>[email-masked]
>Objet : [Int-area] AD evaluation:
>draft-ietf-intarea-nat-reveal-analysis
>
>All,

Med: It is true there was a version of the document which includes a recommendation but the initial intent of the document was to analyze candidate solution. I updated the text to make it explicit: I changed the text in the sections you mentioned. In particular, the change in the abstract is:

OLD:

   This document analyzes a set of solution candidates to mitigate some
   of the issues encountered when address sharing is used.  In
   particular, this document focuses on means to reveal a host
   identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application
   proxies are involved in the path.  This host identifier must be
   unique to each host under the same shared IP address.

NEW:

   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.

>they are proposed to do, but cannot be assessed against the

Med: Figure 3 includes this note:

 (2)  This solution is widely deployed.

Can you explicit what change you want to be added? Thanks.

>Informational document describing mechanisms, there is no need to

Med: Done.

>understand this draft if the problem statement came before the context

Med: I changed the text as follows:

OLD:

   The sole use of the IPv4 address is not sufficient to uniquely
   distinguish a host.  As a mitigation, it is tempting to investigate
   means which would help in disclosing an information to be used by the
   remote server as a means to uniquely disambiguate packets of hosts
   using the same IPv4 address.

NEW:

   In particular, some servers use the source IPv4 address as an
   identifier to treat some incoming connections differently.  Due to
   the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that
   address will be shared.  In particular, when a server receives
   packets from the same source address, because this address is shared,
   the server does not know which host is the sending host [RFC6269].
   The sole use of the IPv4 address is not sufficient to uniquely
   distinguish a host.  As a mitigation, it is tempting to investigate
   means which would help in disclosing an information to be used by the
   remote server as a means to uniquely disambiguate packets of hosts
   using the same IPv4 address.

>special treatment is needed/provided.

Med: I updated the text with an example:

   Policies relying on source IP address which are enforced by some
   servers will be applied to all hosts sharing the same IP address.
   For example, blacklisting the IP address of a spammer host will
   result in all other hosts sharing that address having their access to
   the requested service restricted.  [RFC6269] describes the issues in
   detail.  Therefore, due to address sharing, servers need an extra
   information than the source IP address to differentiate the sending
   host.  We call HOST_ID this information.

  Is it sufficient to
>identify the
>sending host? application? user?

Med: I added this sentence:

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

It should also note that there may be
>may not.  How does that impact the performance of these mechanisms?

Med: The document assumes the address sharing function injects the host identifier. BTW, there is already a performance criterion listed in Figure 3.

>sorting is needed.  This relates back to the Context description in

Med: The new text is:

   Policies relying on source IP address which are enforced by some
   servers will be applied to all hosts sharing the same IP address.
   For example, blacklisting the IP address of a spammer host will
   result in all other hosts sharing that address having their access to
   the requested service restricted.  [RFC6269] describes the issues in
   detail.  Therefore, due to address sharing, servers need an extra
   information than the source IP address to differentiate the sending
   host.  We call HOST_ID this information.

>document any more, so that text can be removed.

Med: Done.

>mechanisms, so there is no new work which needs requirements

Med: Section 3.1 was added as a result of a review from privacy people. I do think it is useful to maintain it. Perhaps, move the text to the security considerations?

>things can/will happen if those packets are fragmented somewhere.

Med: We thought having a reference to draft-ietf-intarea-ipv4-id-update (now RFC6864) is sufficient. The impact of Middleboxes is already discussed in that document (see section 5.3).

>suggest simply stating that the IP Option approach will

Med: Done.

>TCP option, even though they are apparently low probability.

Med: The main risk we had in mind is session failure due to handling an unknown TCP option. Are you suggesting this text should be expanded?

   The risk related to handling a new TCP Option is low as measured in
   [Options].

>"0.103%" (i.e., 1/10th of 1%).

Med: Fixed. Thanks.

>discussed in the document?  These should be identified as well.

Med: There are some proposals (e.g., XFF, Forward-For) which allow to prepend several host-ids. This is already mentioned in the text:

   When several address sharing devices are crossed, XFF/Forwarded-For
   header can convey the list of IP addresses (e.g., Figure 1).  The
   origin HOST_ID can be exposed to the target server.

For some proposals (e.g., IP Option), this point is not mentioned as the analysis shows these proposals are a no starter.

For the TCP option, the loss of the original host_id may not be a problem as the target usage is between proxies of a CGN and server. Only the information leaked in the last leg is likely to be useful.

>how to interpret Figure 2.

Med: Done.

>be added for this technique?

Med: Added a ref to RFC6346.

>act as a UDP/TCP-HIP relay".

Med: The current text says:

"If the address sharing function is required to act as a UDP/TCP-HIP relay, this is not a viable option."

This require ALL servers in the Internet are HIP-enabled. It is obvious this is not a viable option for a deployable solution.

>reason why it may be an issue for other transport protocols

Med: The ICMP approach can work for any transport protocol making use of a port number. We mentioned TCP and UDP as these are the widely deployed transport protocol. I updated the text as follows:

OLD:

   o  This ICMP proposal is valid for both UDP and TCP.  Address sharing
      function may be configurable with the transport protocol which is
      allowed to trigger those ICMP messages.

NEW:

   o  This ICMP proposal is valid for any transport protocol that uses a
      port number.  Address sharing function may be configurable with
      the transport protocol which is allowed to trigger those ICMP
      messages.

>compatible with cascading NATs.

Med: The main reason is that each NAT in the path will generate an ICMP message. These messages will be translated by the downstream NATs. The remote server will receive multiple ICMP messages and will need to decide which host identifier to use.

>for their mention in Section 4.9.2 (8th bullet).

Med: I updated the text with a reference to a document where the problem is described in detail:

OLD:

   o  In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi,
      etc.), HOST_ID should be interpreted by intermediate devices which
      embed Policy Enforcement Points (PEP, [RFC2753]) responsible for
      granting access to some services.  These PEPs need to inspect all
      received packets in order to find the companion (traffic) messages
      to be correlated with ICMP messages conveying HOST_IDs.  This
      induces more complexity to these intermediate devices.

NEW:

   o  In some scenarios (e.g., Section 3 of
      [I-D.boucadair-pcp-nat-reveal]), HOST_ID should be interpreted by
      intermediate devices which embed Policy Enforcement Points (PEP,
      [RFC2753]) responsible for granting access to some services.
      These PEPs need to inspect all received packets in order to find
      the companion (traffic) messages to be correlated with ICMP
      messages conveying HOST_IDs.  This induces more complexity to
      these intermediate devices.

I updated also the text in Section 4.9.2.

>in DNS or is that just an example approach?  This should be clarified.

Med: DNS is mentioned as an example. I updated the text as follows;

OLD:

   o  A hint should be provided to the ultimate server (or intermediate
      nodes) the address sharing function implements IDENT protocol.
      This can be achieved by publishing this capability using DNS.

NEW:

   o  A hint should be provided to the ultimate server (or intermediate
      nodes) the address sharing function implements IDENT protocol.  A
      solution example is to publish this capability using DNS; other
      solutions can be envisaged.

>needing client or middlebox code changes?

Med: For almost all solutions, the host identifier is not injected by the client. Host_id injection is done by an address sharing function.
The cost of the change in the address sharing will depend on the capabilities supported by that device: a NAT device re-writing packets can inject (in theory) L3/4 information without extra cost but inspecting packets to inject application-related header would require new features. We focused on the expected performance impact rather than the expect induced cost.

>that is true, the success ratio can't be 100% can it?

Med: the IP-ID tweaking is implemented in the address sharing function not the host/OS. In theory, if the address sharing functions follows the rule for IP-ID field, failure is unlikely.

>mechanisms, I don't see the need for the last bulleted list.

Med: The intent of that text is to provide a kind of conclusion. No problem to remove it if you think so.

>
>Regards,
>Brian
>_______________________________________________
>Int-area mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 12 Feb 2013 16:57:25 -0600

Hi Suresh,

On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan <
[email-masked]> wrote:

> Section 4.6 is not about about A+P. In A+P there is also the use of a
shared public IPv4 address.
I think that Section 4.6 refers to the port range solution for an RG with
NAT once suggested in BBF.

Regards,

Behcet

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Feb 2013 01:16:32 -0500

Hi Brian,

> I agree.  But that rationale should be in the draft.

Ack. Med proposed a reference to RFC6864 Section 5.3. Is that sufficient?

> Then I would ask that a reference be put in to give readers an example.

OK.

> like to know how that 100% success ratio was collected.

Makes sense. I read the test result % to mean successful connection
establishment and identification. Med, can you elaborate a bit on what
exactly was tested and what the success % means.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Feb 2013 01:56:58 -0500

Hi Behcet,

On 02/12/2013 05:57 PM, Behcet Sarikaya wrote:
> Hi Suresh,
> 
> On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Brian,

Right. But section 4.6 is about assigning port sets and Brian asked if
that was any specific mechanisms that assigned port sets. A+P does so.
Not sure about what you mean by "In A+P there is also the use of a
shared public IPv4 address". This is the reason why we need a HOST_ID at
all.

Thanks
Suresh

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 08:17:15 +0100

Hi Suresh,

Please see inline.

Cheers,
Med

>De : Suresh Krishnan [mailto:[email-masked]] 
>Envoyé : mercredi 13 février 2013 07:17
>À : Brian Haberman
>Cc : [email-masked]; 
>Objet : Re: [Int-area] AD evaluation: 

>exactly was tested and what the success % means.

Med: I made the following changes: 

OLD: 

   o  "Success ratio" indicates the ratio of successful communications
      when the option is used.  Provided figures are inspired from the
      results documented in [Options].

NEW:

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

And added this NEW text:

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

   The provided success ratio for IP-ID is theoretical; it assumes the
   address sharing function follows the rules in [RFC6864] to re-write
   the IP Identification field.

   Since PROXY and HIP are not widely deployed, the success ratio to
   establish a communication with remote servers using these protocols
   is low.

   The success ratio for ICMP-based solution is implementation-specific
   but it is likely to be close to 100%.  A remote server which does not
   support the ICMP-based solution will ignore received companion ICMP
   messages.  An upgraded server will need to hold accepting a session
   until receiving the companion ICMP message.  The success ratio
   depends on how efficient the solution is implemented at the server
   side.

   The success ratio for IDENT solution is implementation-specific but
   it is likely to be close to 100%.  A remote server which does not
   support IDENT will accept a session establishment request following
   its normal operation.  An upgraded server will need to hold accepting
   a session until receiving the response to IDENT request it will send
   to the host.  The success ratio depends on how efficient the solution
   is implemented at the server side.

Cheers;
Med

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Feb 2013 10:03:55 -0500

On 2/12/13 5:34 AM, [email-masked] wrote:
> Cheers, Med
>> -----Message d'origine----- De : [email-masked]
>> Envoyé : lundi 11 février 2013 22:12 À : [email-masked];
>> [email-masked] Objet :
>> [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis
>>
>> 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.
>
> Med: It is true there was a version of the document which includes a
> recommendation but the initial intent of the document was to analyze
> candidate solution. I updated the text to make it explicit: I changed
> the text in the sections you mentioned. In particular, the change in
> the abstract is:
>
> OLD:
>
> The host identifier must be unique to each host under the same
> shared IP address.
>

The above text is a good addition to the document.

>> 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.
>

Isn't the IP-ID approach also used in some deployments?

I would suggest re-ordering the table so that deployed approaches are 
collected together (and labeling them as deployed).  If the HTTP 
Forwarded header is the only deployed approach, I would simply add a 
note for the others stating whether they are a documented proposal or a 
theoretical construct.

>> Informational document describing mechanisms, there is no need to

Ok.

>>
>> 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).
>
> means which would help in disclosing an information to be used by
> the remote server as a means to uniquely disambiguate packets of
> hosts using the same IPv4 address.
>
> NEW:
>
> the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]),
> that address will be shared.  In particular, when a server receives
> packets from the same source address, because this address is
> shared, the server does not know which host is the sending host
> [RFC6269]. The sole use of the IPv4 address is not sufficient to
> uniquely distinguish a host.  As a mitigation, it is tempting to
> investigate means which would help in disclosing an information to be
> used by the remote server as a means to uniquely disambiguate packets
> of hosts using the same IPv4 address.
>

That sounds better.

>>
>> 5. Section 2
>>
>> * The Observation text should provide some brief examples of how
>> and why special treatment is needed/provided.
>
> servers will be applied to all hosts sharing the same IP address. For
> example, blacklisting the IP address of a spammer host will result in
> all other hosts sharing that address having their access to the
> requested service restricted.  [RFC6269] describes the issues in

Ok.

>
> Is it sufficient to
>> identify the sending host? application? user?
>

That should suffice.

>> issues with the fact that some IP addresses will be shared and
>> others may not.  How does that impact the performance of these
>> mechanisms?
>
> Med: The document assumes the address sharing function injects the
> host identifier. BTW, there is already a performance criterion listed
> in Figure 3.
>

I was thinking more generically than the performance criterion.  Suppose 
a server employs the IP-ID approach.  If several packets arrive with the 
same source IP address and the same value in the IP-ID field, there is 
no way to know if the IP-ID value was injected by a NAT/CGN box.  Or is 
your response saying that scenario is covered by the metrics used in 
Figure 3?  If so, which metric?  None of the descriptive text in Section 
5 talks about this type of issue.

>> sorting is needed.  This relates back to the Context description
>> in Section 1.1.
>
> Med: The new text is:
>
> servers will be applied to all hosts sharing the same IP address. For
> example, blacklisting the IP address of a spammer host will result in
> all other hosts sharing that address having their access to the
> requested service restricted.  [RFC6269] describes the issues in

Ok.

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

Ok.

>>
>> 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.
>
> Med: Section 3.1 was added as a result of a review from privacy
> people. I do think it is useful to maintain it. Perhaps, move the
> text to the security considerations?
>

If anything, these are privacy considerations that may be impacted by 
these types of functions.  They can't be requirements at this point. 
Keeping the text is a good idea in that light, but don't call them 
Requirements.  Moving them to the Security Considerations section would 
work.

>>
>> 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.
>
> Med: We thought having a reference to
> draft-ietf-intarea-ipv4-id-update (now RFC6864) is sufficient. The
> impact of Middleboxes is already discussed in that document (see
> section 5.3).
>

So maybe the way to clarify this is to re-word the text in 4.1.2.  How 
about:

OLD:
This usage is not compliant with what is recommended in
    [I-D.ietf-intarea-ipv4-id-update].

NEW:
This usage is not consistent with the fragment reassembly use of the 
Identification field [RFC791] or the updated handling rules for the 
Identification field [I-D.ietf-intarea-ipv4-id-update].

>>
>> 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.
>
> Med: Done.
>

Ok.

>
>>
>> 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.
>
> Med: The main risk we had in mind is session failure due to handling
> an unknown TCP option. Are you suggesting this text should be
> expanded?
>

It would be good to mention at least one risk, like session failure, in 
the text to give the readers some clue as to the type of risks being 
considered.

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

Ok.

>>
>> *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.
>
> Med: There are some proposals (e.g., XFF, Forward-For) which allow to
> prepend several host-ids. This is already mentioned in the text:
>
> For some proposals (e.g., IP Option), this point is not mentioned as
> the analysis shows these proposals are a no starter.
>
> For the TCP option, the loss of the original host_id may not be a
> problem as the target usage is between proxies of a CGN and server.
> Only the information leaked in the last leg is likely to be useful.
>

Ok.  I can see how this is covered.

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

Ok.

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

Ok.

>>
>> 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".
>
> This require ALL servers in the Internet are HIP-enabled. It is
> obvious this is not a viable option for a deployable solution.
>

That is understood.  It is not clear why the "UDP/TCP-HIP relay" aspect 
is mentioned.  Is there something special about that deployment model 
that has additional issues (other than needing all servers to understand 
HIP)?

>>
>> 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)?
>
> Med: The ICMP approach can work for any transport protocol making use
> of a port number. We mentioned TCP and UDP as these are the widely
> deployed transport protocol. I updated the text as follows:
>
> OLD:
>
> o  This ICMP proposal is valid for both UDP and TCP.  Address
> sharing function may be configurable with the transport protocol
> which is allowed to trigger those ICMP messages.
>
> NEW:
>
> o  This ICMP proposal is valid for any transport protocol that uses
> a port number.  Address sharing function may be configurable with the
> transport protocol which is allowed to trigger those ICMP messages.
>

That works.

>
>>
>> * I would also like to see some text describing why the approach is
>> not compatible with cascading NATs.
>
> Med: The main reason is that each NAT in the path will generate an
> ICMP message. These messages will be translated by the downstream
> NATs. The remote server will receive multiple ICMP messages and will
> need to decide which host identifier to use.
>

The above text, or something similar, should be added to that bullet.

>> 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).
>
> received packets in order to find the companion (traffic) messages to
> be correlated with ICMP messages conveying HOST_IDs.  This induces
> more complexity to these intermediate devices.
>
> NEW:
>
> [RFC2753]) responsible for granting access to some services. These
> PEPs need to inspect all received packets in order to find the
> companion (traffic) messages to be correlated with ICMP messages
> conveying HOST_IDs.  This induces more complexity to these
> intermediate devices.
>

Ok.

>>
>> 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.
>
> nodes) the address sharing function implements IDENT protocol. This
> can be achieved by publishing this capability using DNS.
>
> NEW:
>

Ok.

>
>>
>> 15. Section 5
>>
>> * Shouldn't there be an additional metric that covers the
>> impact/cost of needing client or middlebox code changes?
>
> Med: For almost all solutions, the host identifier is not injected by
> the client. Host_id injection is done by an address sharing
> function. The cost of the change in the address sharing will depend
> on the capabilities supported by that device: a NAT device re-writing
> packets can inject (in theory) L3/4 information without extra cost
> but inspecting packets to inject application-related header would
> require new features. We focused on the expected performance impact
> rather than the expect induced cost.
>

Ok.

>>
>> * 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?
>
> Med: the IP-ID tweaking is implemented in the address sharing
> function not the host/OS. In theory, if the address sharing functions
> follows the rule for IP-ID field, failure is unlikely.
>

Even in the case where packets are fragmented after the middlebox sets 
the IP-ID?  It seems that the success ratio ignores those types of 
errors.  Are those errors counted in the "Possible Perf Impact" metric?

> problem to remove it if you think so.

I would prefer that type of discussion be done as prose, rather than a 
list.  I will not object if the authors want to leave it as a list.

I do have one other issue...

The discussion in 4.4.1 inter-mixes two different HTTP headers.  The XFF 
header is now obsolete (RFC 6648).  It has been replaced by the 
Forwarded: header defined in the referenced draft.  Figure 1 uses the 
correct header name, but the supporting text references XFF in several 
places.  All uses of XFF should be replaced by Forwarded: to be 
consistent with the current specs.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Feb 2013 10:04:48 -0500

> Ack. Med proposed a reference to RFC6864 Section 5.3. Is that sufficient?

That reference should be fine.

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 17:12:06 +0100

Re-,

Please see inline.

Cheers,
Med

>De : Brian Haberman [mailto:[email-masked]]
>Envoyé : mercredi 13 février 2013 16:04
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked];

Med: I added these two notes:

 (7)  The solution is a theoretical construct.
 (8)  The solution is a documented proposal.

And updated the table accordingly.

>5 talks about this type of issue.

Med: For the particular case of IP-ID, we assume the address sharing function does not assign the same ID under the same IP address during a given interval time. The following note:

     (1)  Requires mechanism to advertise NAT is participating in this
          scheme (e.g., DNS PTR record).

Is here to precise another mechanism is needed to inform the server IP-ID is carrying a host identifier.

>Requirements.  Moving them to the Security Considerations

Med: Section 3.1 is now entitled "Privacy-related Considerations". The text is cleared to not use "requirement" term.

>Identification field [I-D.ietf-intarea-ipv4-id-update].

Med: Works for me. I updated the text. Thanks.

>the text to give the readers some clue as to the type of risks being

Med: The text reads now:

"The risk to experience session failures due to handling a new TCP Option is low as measured...".

>that has additional issues (other than needing all servers to

Med: That model is mentioned because it does not require the host to be HIP-enabled. I updated the text to make it more explicit:

"An alternative deployment model, which does not require the client to be HIP-enabled, is the address sharing function behave as a UDP/TCP-HIP relay. This model is also not viable as it assumes all servers are ported to be HIP-enabled."

Med: Done.

>the IP-ID?

Med: if the middlbox follows the rules in rfc6864 and the same ID is not re-assigned to another host sharing the same ip address during a given time interval, why downstream fragmentation will be an issue?

 It seems that the success ratio ignores those types of
>errors.  Are those errors counted in the "Possible Perf Impact" metric?

Med: No.

>list.  I will not object if the authors want to leave it as a list.

Med: I removed the list to avoid mis-interpreting that text is promoting a particular solution.

>consistent with the current specs.

Med: I cleared the text when it makes sense.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Feb 2013 10:36:08 -0600

Hi Suresh,

On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishnan <
[email-masked]> wrote:

> the
I think that this draft is not about A+P (don't ask me why, ask Med :-) ).
The correct reference for Section 4.6 would be BBF document WT-146 on
Subscriber
Sessions

Regards,

Behcet

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 17:43:50 +0100

Hi Behcet,

I have two comments:

* Host identification issue is valid for any address sharing mechanism. This is why the introduction mentions already the following:

   As reported in [RFC6269<https://tools.ietf.org/html/rfc6269>], several issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P [RFC6346<https://tools.ietf.org/html/rfc6346>].

* RFC6346 is provided as an example of a solution making use of port sets. You are right, other solutions (than a+p) can be considered but having one pointer to a solution example is just fair. No need to be exhaustive here.

Cheers,
Med
________________________________
De : Behcet Sarikaya [mailto:[email-masked]]
Envoyé : mercredi 13 février 2013 17:36
À : Suresh Krishnan
Cc : Brian Haberman; [email-masked]; [email-masked]
Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Suresh,

On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

On 02/12/2013 05:57 PM, Behcet Sarikaya wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Hi Brian,

I think that this draft is not about A+P (don't ask me why, ask Med :-) ).
The correct reference for Section 4.6 would be BBF document WT-146 on Subscriber Sessions

Regards,

Behcet
Thanks
Suresh

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Feb 2013 11:51:06 -0500

> And updated the table accordingly.

That should work.

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

> Med: if the middlbox follows the rules in rfc6864 and the same ID is not re-assigned to another host sharing the same ip address during a given time interval, why downstream fragmentation will be a…

That is the piece that is missing.  The text in Section 4.1 (or its 
child sections) does not mention the dependency on RFC 6864.

Ok.

Ok.

Regards,
Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Feb 2013 11:00:30 -0600

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <[email-masked]> wrote:

> **
> Hi Behcet,
>
> I have two comments:
>
> * Host identification issue is valid for any address sharing mechanism.
>

I am not sure on A+P?
A+P requires point-to-point link, right?

> This is why the introduction mentions already the following:
>
>    As reported in [RFC6269 <https://tools.ietf.org/html/rfc6269>], several issues are encountered when an IP
>    (CGN), application proxies or A+P [RFC6346 <https://tools.ietf.org/html/rfc6346>].
>
Again, I am not sure if Section 4.6 describes what A+P says?

Regards,

Behcet

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 18:16:31 +0100

Re-,

Please see inline.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:[email-masked]]
Envoyé : mercredi 13 février 2013 18:01
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; [email-masked]; [email-masked]
Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Behcet,

I have two comments:

I am not sure on A+P?
[Med] both A+P and NAT-based address sharing solutions are covered by rfc6269. host identifier is just a means to distinguish hosts under the same IP address. It does not matter how address sharing is implemented.

Again, I am not sure if Section 4.6 describes what A+P says?
[Med] That section says non overlapping port sets are assigned to hosts sharing the same IP address. The text does not describe if the shared address is also configured to those hosts or if there is a NAT in the host, etc. These are implementation variants. There is no value to provide such details in that section. Adding a ref to A+P is just fair. This does not preclude other contexts.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Feb 2013 13:09:01 -0600

Hi Med,

I think that email discussions we had on this issue in fmc list last year
will provide good context in these discussions, please remember them.

See inline:

On Wed, Feb 13, 2013 at 11:16 AM, <[email-masked]> wrote:

> **
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
>  ------------------------------
> *De :* Behcet Sarikaya [mailto:[email-masked]]
> *Envoyé :* mercredi 13 février 2013 18:01
> *À :* BOUCADAIR Mohamed OLNC/OLN
> *Cc :* Suresh Krishnan; Brian Haberman;
> [email-masked]; [email-masked]
>
> *Objet :* Re: [Int-area] AD evaluation:
> [Med] both A+P and NAT-based address sharing solutions are covered by
> rfc6269. host identifier is just a means to distinguish hosts under the
> same IP address. It does not matter how address sharing is implemented.
>
> [Med] That section says non overlapping port sets are assigned to hosts
> sharing the same IP address. The text does not describe if the shared
> address is also configured to those hosts or if there is a NAT in the host,
> etc. These are implementation variants. There is no value to provide such
> details in that section. Adding a ref to A+P is just fair. This does not
> preclude other contexts.
>
>
If Section 4.6 applies to A+P, there is no need for such a text, just say
Use A+P and give the reference, right?

Regards,

Behcet

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Feb 2013 14:24:53 -0800

> putting the HOST_ID in the IP-ID is a non-starter.

It happens if the packet is fragmented before the middlebox (reusing the 
HOST_ID will destroy the reassembly if any fragment groups are 
interleaved), or after (if there are multiple paths and not all 
fragments go through the middlebox.

It also violates RFC6864 if the packets are already fragmented when they 
go through the middlebox translation.

Joe

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 07:51:29 +0100

Hi Behcet,

I'm aware of that context but the problem is that I don't have a good reference to cite for it. http://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would be a good reference to cite but unfortunately the port set section was removed in the last version http://tools.ietf.org/html/draft-schott-fmc-requirements-04.

Saying that, I really think having one example to cite is sufficient. No need to have an exhaustive reference list.

Thanks.

Cheers,
Med

Envoyé : mercredi 13 février 2013 20:09

Hi Med,

I think that email discussions we had on this issue in fmc list last year will provide good context in these discussions, please remember them.

See inline:

On Wed, Feb 13, 2013 at 11:16 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Re-,

Please see inline.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : mercredi 13 février 2013 18:01
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Med,

I have two comments:

I am not sure on A+P?

If Section 4.6 applies to A+P, there is no need for such a text, just say Use A+P and give the reference, right?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Feb 2013 11:36:41 -0600

Hi Med,

I realize that you published a revision with the A+P reference. However, I
believe A+P is a problem for address sharing with its own solution, i.e.
the port range is the host id.

I would favor removing Sec. 4.6. Anyway you have not been exhaustive on the
solution space.

Regards,

Behcet

On Thu, Feb 14, 2013 at 12:51 AM, <[email-masked]> wrote:

> **
> Hi Behcet,
>
> I'm aware of that context but the problem is that I don't have a good
> reference to cite for it.
> http://tools.ietf.org/id/draft-schott-fmc-requirements-02.txt would be a
> good reference to cite but unfortunately the port set section was removed
> in the last version
> http://tools.ietf.org/html/draft-schott-fmc-requirements-04.
>
> Saying that, I really think having one example to cite is sufficient. No
> need to have an exhaustive reference list.
>
> Thanks.
>
> Cheers,
> Med
>
> *Envoyé :* mercredi 13 février 2013 20:09
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Feb 2013 14:06:15 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Behcet Sarikaya
> Sent: Thursday, February 14, 2013 9:37 AM
> To: [email-masked]
> Cc: [email-masked]; int-
> [email-masked]
> Subject: Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-
> analysis
> 
> Hi Med,
> 
> I realize that you published a revision with the A+P reference. However,
> I believe A+P is a problem for address sharing with its own solution,
> i.e. the port range is the host id.

Except a remote server does not know the address is shared, nor what
port range is assigned to a user.  Lacking that, it does not have 
a solution.  With that, I would hesitate to rely on the system too
much, because changing number of ports per user would need to somehow
be coordinated with server logs -- which seems unlikely/impossible.

-d

> I would favor removing Sec. 4.6. Anyway you have not been exhaustive on
> the solution space.
> 
> Regards,
> 
> Behcet
> 
> 
> 	I'm aware of that context but the problem is that I don't have a
> good reference to cite for it. http://tools.ietf.org/id/draft-schott-
> fmc-requirements-02.txt would be a good reference to cite but
> unfortunately the port set section was removed in the last version
> 	Saying that, I really think having one example to cite is
> sufficient. No need to have an exhaustive reference list.
> 
> 	Thanks.
> 
> 	Cheers,
> 	Med
> 
> 
> 		Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-intarea-nat-
> [email-masked]; [email-masked]
draft-ietf-intarea-nat-
> reveal-analysis
> 
> 
> 		Hi Med,
> 
> 		I think that email discussions we had on this issue in fmc
> list last year will provide good context in these discussions, please
> remember them.
> 
> 		See inline:
> 
> 
> 				Cc : Suresh Krishnan; Brian Haberman;
draft-ietf-
> [email-masked]; [email-masked]
> 
draft-ietf-
> intarea-nat-reveal-analysis
> 
> 
> 				Hi Med,
> 
> 
> 					* Host identification issue is valid
for any
> address sharing mechanism.
> 
> 
> 				I am not sure on A+P?
> 
> 				[Med] both A+P and NAT-based address sharing
> solutions are covered by rfc6269. host identifier is just a means to
> distinguish hosts under the same IP address. It does not matter how
> address sharing is implemented.
> 
> 					This is why the introduction
mentions already
> the following:
> 
> 					   As reported in [RFC6269
> <https://tools.ietf.org/html/rfc6269> ], several issues are encountered
> when an IP
> 					   (CGN), application proxies or A+P
[RFC6346
> <https://tools.ietf.org/html/rfc6346> ].
> 					* RFC6346 is provided as an example
of a
> solution making use of port sets. You are right, other solutions (than
> a+p) can be considered but having one pointer to a solution example is
> just fair. No need to be exhaustive here.
> 
> 
> 
> 				Again, I am not sure if Section 4.6
describes what
> A+P says?
> 
> 				[Med] That section says non overlapping port
sets
> are assigned to hosts sharing the same IP address. The text does not
> describe if the shared address is also configured to those hosts or if
> there is a NAT in the host, etc. These are implementation variants.
> There is no value to provide such details in that section. Adding a ref
> to A+P is just fair. This does not preclude other contexts.
> 
> 
> 
> 
> 		If Section 4.6 applies to A+P, there is no need for such a
> text, just say Use A+P and give the reference, right?
> 
> 		Regards,
> 
> 		Behcet
> 
>