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

[Brian Haberman <[e-mail]>]

On 2/12/13 5:34 AM, [e-mail] wrote:
> Dear Brian,
>
> Many thanks for the detailed review.
>
> Please see inline.
>
> Cheers, Med
>
>> -----Message d'origine----- De : [e-mail]
>> [mailto:[e-mail]] De la part de Brian Haberman
>> Envoyé : lundi 11 février 2013 22:12 À : [e-mail];
>> [e-mail] 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:
>
> 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.
>

The above text is a good addition to the document.

>>
>> 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.
>
> Med: Figure 3 includes this note:
>
> (2)  This solution is widely deployed.
>
> Can you explicit what change you want to be added? Thanks.
>

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.

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

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

That sounds better.

>>
>> 5. Section 2
>>
>> * The Observation text should provide some brief examples of how
>> and why 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.
>

Ok.

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

That should suffice.

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

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

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?
>
> The risk related to handling a new TCP Option is low as measured in
> [Options].
>

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

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?
>
> Med: Added a ref to RFC6346.
>

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

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.

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

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

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?

>>
>> * Given the goal of this document to describe these identification
>> 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.

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