Subject: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02

From: SM <[email-masked]>
Date: Sat, 07 Jul 2012 01:40:35 -0700

Hello,

I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02.

In Section 1.1:

   "Examples of such issues are listed below:"

     "Redirect users with infected machines to a dedicated portal"

Why is this an issue?

   "The risk of not mitigating these issues are: OPEX increase for IP"

I suggest expanding "OPEX" on first use.

In Section 2:

   "Tomorrow, due to the introduction of CGNs (e.g., NAT44
    [RFC3022], NAT64 [RFC6146]), that address will be shared."

Isn't IPv4 shared addresses already in use in the wild?

In Section 2.1:

   "A solution to reveal HOST_ID is also needed in IPv6 deployment."

I suggest soliciting feedback from V6OPS about this.

The draft already mentions that the issue is caused by IPv4 address 
sharing.  It then goes on to suggest that address sharing can be used 
for IPv6.  That is going to create the same problem there and argue 
for the solution mentioned in this draft.

In Section 3.2:

   "Requires the client and the server to be HIP-compliant and HIP
    infrastructure to be deployed."

What's HIP?

   "XFF is de facto standard deployed and supported in operational
    networks"

What's XFF?

   "From an application standpoint, the TCP Option is superior to XFF/
    Forwarded-For since it is not restricted to HTTP."

That doesn't sound like a fair comparison.

   "Nevertheless XFF/Forwarded-For is compatible with the presence of
    address sharing and load-balancers in the communication path."

What is the meaning of compatible in here?

In Section 4:

   "some users realize privacy benefits associated with IP address
    sharing, and some may even take steps to ensure that NAT
    functionality sits between them and the public Internet."

What are the privacy benefits of IP address sharing?

In skimmed over the appendix.  What's "Application Headers"?

This draft would benefit from cross-area review.  It needs more work 
in my humble opinion.

Regards,
-sm

---

From: Tina TSOU <[email-masked]>
Date: Mon, 9 Jul 2012 20:41:23 +0000

I reviewed this draft and I found it very detailed about the various ways of including a HOST ID. Considering the number of users that share the same IPv4 address, there is an increasing importance of the HOST ID. Though it is discussed in the introduction about the various implications of not having HOST IDs, in my opinion, there should be a little more explanation of the problems faced if there is no HOST ID included. Moreover, the main concern is security issue. It is very difficult to identify a particular user, when there are a number of users with different private IP addresses sharing the same public address.

This document has very well explained the pros and cons of various methods of including the HOST ID. Among all the methods, the best one in my perspective would be to assign a port set dynamically to a particular user. As regards to the statement “it contradicts RFC 6269”, about the randomization of port allocation, the user can be allocated port set dynamically for a specific life time. The use of dynamic allocation ensures maximum utilization of port sets, as static allocation would lead to some ports being allocated but not being used. The port set allocation has more advantages than rest of the options and should be more detailed than the ones with more cons.

The TCP option is another good way to include the HOST ID in case of TCP and UDP communications. So if the document was written more based on applications, it would be more specific and user friendly. Considering the exhaustion of IPv4, I also feel IPv6 should be more stresses upon and included as an option, as IPv6 would solve the problem to a great extend. Including IPv6 might not exactly serve the purpose of the document, but would definitely be an alternative to mitigate the issue.

Tina

On Jul 7, 2012, at 1:44 AM, "SM" <[email-masked]<mailto:[email-masked]>> wrote:

Hello,

In Section 1.1:

Why is this an issue?

In Section 2:

In Section 2.1:

The draft already mentions that the issue is caused by IPv4 address sharing.  It then goes on to suggest that address sharing can be used for IPv6.  That is going to create the same problem there and argue for the solution mentioned in this draft.

In Section 3.2:

What's HIP?

What's XFF?

In Section 4:

This draft would benefit from cross-area review.  It needs more work in my humble opinion.

Regards,
-sm

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

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 09 Jul 2012 19:26:18 -0400

I read the document and came to rather different conclusions (see
below):

On 7/9/2012 4:41 PM, Tina TSOU wrote:
> I reviewed this draft and I found it very detailed about the various
> ways of including a HOST ID. Considering the number of users that share
> the same IPv4 address, there is an increasing importance of the HOST ID.
> Though it is discussed in the introduction about the various
> implications of not having HOST IDs, in my opinion, there should be a
> little more explanation of the problems faced if there is no HOST ID
> included. Moreover, the main concern is security issue. It is very
> difficult to identify a particular user, when there are a number of
> users with different private IP addresses sharing the same public address.

I agree with you that if the document is pursued, it should include
more discussion of what the problems are with not having a host ID;
the current text seems like handwaving to me.  I don't personally
think it is very well motivated, and from my standpoint there is
absolutely no reason to pursue a solution.  It would be enough to
simply have the analysis documented as to why all of the considered
approaches COMPLETELY STINK.

But aside from that, I disagree with you on purpose of whatever is
being attempted here.  The document is about identifying hosts, and
you mention "users".  These are not the same thing.  Which do you want
to identify?  In my opinion, anything related to users (and not hosts)
should be completely out of scope.

Further, I think the problem has to perhaps be refined to
disambiguating between different hosts using the same IP address
versus trying to semi-uniquely identify the hosts.  The problems
described are due to aliasing, and unique identification is a
rather strong means of de-aliasing.

> The TCP option is another good way to include the HOST ID in case of TCP
> and UDP communications. 

Surely there's a typo there, since it does not work at all in the
case of UDP.

I disagree with the overall recommendation of the document, since
it presumes that a solution is required, among other flaws with it.

Additionally, it is not particularly clear how this can work for
multiple layers of sharing (e.g. CGN), though draft-abdo seems to
think that CGN is a single layer of sharing.

-- 
Wes Eddy
MTI Systems

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 10 Jul 2012 08:14:23 +0000

> think that CGN is a single layer of sharing.

+1

Lars

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Jul 2012 20:53:50 -0400

>> think that CGN is a single layer of sharing.

<aol>Me too!</aol>

Existing "solutions" work well enough (even if in many cases the solution simply ignores the problem :-P)

W

> 
> Lars_______________________________________________
> Int-area mailing list
> [email-masked]

--
The duke had a mind that ticked like a clock and, like a clock, it regularly went cuckoo.

    -- (Terry Pratchett, Wyrd Sisters)

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 09:30:53 +0200

Dear Wes,

Please see inline.
Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Wesley Eddy
>Envoyé : mardi 10 juillet 2012 01:26
>À : Tina TSOU
>Cc : [email-masked]
>Objet : Re: [Int-area] Comments on 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>the current text seems like handwaving to me.

Med: The issues have been already documented in RFC6269. The draft includes pointers to some sections from that draft.

  I don't personally
>should be completely out of scope.

Med: Agreed. The notion of "user" is out of scope of draft-ietf-intarea-nat-reveal-analysis.

>it presumes that a solution is required, among other flaws with it.

Med: The recommendation has been added after the Paris meeting. I asked during the presentation whether we need to add a reco or not: I heard voices for having a reco.  

>think that CGN is a single layer of sharing.

Med: Good point. draft-abdo focuses on ds-lite model and as such there is only one level of NAT. Even in such scenario, the CGN is configured to strip an existing HOST_ID option since this information is not trusted. For double NAT scenario, only the external IP address after the first NAT is important to be passed by the second NAT.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jul 2012 10:51:52 +0300

Hi Mohamed, 

> Med: Agreed. The notion of "user" is out of scope of draft-ietf-intarea-nat-reveal-analysis.

It would be nice if that would actually be true. 

Just an example from Section 13.2 of RFC 6269 http://tools.ietf.org/html/rfc6269#section-13

"
   Simple address-based identification mechanisms that are used to
   populate access control lists will fail when an IP address is no
   longer sufficient to identify a particular subscriber.
"

Hint: >> particular subscriber <<

During the Taipei presentation I had complained about promoting inadequate (or historic) security mechanisms for user authentication already. 

The IETF has developed technology to provide cryptographic authentication (at all layers) already since 20 years. 

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 10:17:07 +0200

Dear SM,

Apologies for the delay to answer. 

Please see inline.

Cheers,
Med  

>[mailto:[email-masked]] De la part de SM
>Envoyé : samedi 7 juillet 2012 10:41
>À : [email-masked]
>Objet : [Int-area] Comments on 

Med: The issue is described in detail in RFC6269:

"
   In addition, there are web tie-ins into different blacklists that web
   administrators subscribe to in order to redirect users with infected
   machines (e.g., detect the presence of a worm) to a URL that says
   "Hey, your machine is infected!".  With address sharing, someone
   else's worm can interfere with the ability to access the service for
   other subscribers sharing the same IP address.
"

>I suggest expanding "OPEX" on first use.

Med: Done. 

>Isn't IPv4 shared addresses already in use in the wild?

Med: IPv4 address sharing is already deployed but still the widely deployed model is to assign public IP addresses to customers. Would you be OK with changing "due to the introduction of CGNs" to "due to the massive introduction of CGNs"?

>for the solution mentioned in this draft.

Med: I'm mainly thinking about NPTv6 (RFC6296). 

>    infrastructure to be deployed."

Med: Host Identity Protocol. A reference is provided in the draft.

>   "XFF is de facto standard deployed and supported in operational

Med: X-Forwarded-For. The acronym is expanded in the draft but in Section A.8.1. I will make sure it is expanded in first use.

>That doesn't sound like a fair comparison.

Med: Could you please indicate what is not fair about that sentence? Thanks.  

>What is the meaning of compatible in here?

Med: XFF allows to prepend a list of IP addresses when several address sharing, application proxies, etc. are in the path. The term compatible is used to indicate XFF can be used in that scenario. If you have any better wording, please advise. Thanks.

>What are the privacy benefits of IP address sharing?

Med: Anonymity may be provided; see for instance the TOR service.

>In skimmed over the appendix.  What's "Application Headers"?

Med: XFF is for instance an HTTP header, "via" is a SIP header, etc. Would it be better if we change "Application Header" to "Application Protocols Headers"?

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 10:33:26 +0200

Dear Hannes,

RFC6269 does not promote any mechanism but rather it identifies what is broken in real deployments. 

Saying that, do you think it is useful to re-insert the text we had in earlier version: 

   Enabling explicit identification means and adequate security suite is
   more robust than relying on source IP address or HOST_ID.  But
   tension may appear between strong privacy and usability (see Section
   4.2 of [I-D.iab-privacy-workshop]).

Cheers;
Med 

>De : Hannes Tschofenig [mailto:[email-masked]] 
>Envoyé : jeudi 26 juillet 2012 09:52
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; [email-masked]
>Just an example from Section 13.2 of RFC 6269 
>http://tools.ietf.org/html/rfc6269#section-13
>
>"
>During the Taipei presentation I had complained about 
>promoting inadequate (or historic) security mechanisms for 
>user authentication already. 
>
>The IETF has developed technology to provide cryptographic 
>authentication (at all layers) already since 20 years. 
>
>Ciao
>Hannes
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jul 2012 12:09:02 +0300

Hi Mohamed, 

I know that RFC 6269 just tries to identify what the authors consider as broken in real world deployments. The analysis in that document is, however, used as a justification for doing the work on draft-ietf-intarea-nat-reveal-analysis-02. 

As it turns out there are other ways to fix these problems, particularly with respect to authentication. Not only are these mechanisms less brittle but they also provide better properties from a security and privacy point of view. 

That's maybe the reason why your co-workers had been active in standardization on these security mechanisms for a long time (pointer to the work on SAML). 

I had, however, jumped into the discussion because of the statement that users are outside the scope of this work which I believe is incorrect. 

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 26 Jul 2012 11:19:05 +0200

Re-,

Please don't turn this discussion into "draft-ietf-intarea-nat-reveal-analysis is against authentication mechanisms". 

Implicit identification is only on use case targeted by the HOST_ID idea. I offered you the opportunity to introduce text (see the proposal below) to educate readers that explicit means are more robust but you rejected my offer. 

Cheers,
Med 

>Envoyé : jeudi 26 juillet 2012 11:09
>I know that RFC 6269 just tries to identify what the authors 
>consider as broken in real world deployments. The analysis in 
>that document is, however, used as a justification for doing 
>the work on draft-ietf-intarea-nat-reveal-analysis-02. 
>
>As it turns out there are other ways to fix these problems, 
>particularly with respect to authentication. Not only are 
>these mechanisms less brittle but they also provide better 
>properties from a security and privacy point of view. 
>
>That's maybe the reason why your co-workers had been active in 
>standardization on these security mechanisms for a long time 
>(pointer to the work on SAML). 
>
>I had, however, jumped into the discussion because of the 
>statement that users are outside the scope of this work which 
>I believe is incorrect. 
>
>Ciao
>Hannes
>
>> RFC6269 does not promote any mechanism but rather it 
>identifies what is broken in real deployments. 
>>

---

From: SM <[email-masked]>
Date: Tue, 31 Jul 2012 15:14:33 -0700

Hi Med,
>    other subscribers sharing the same IP address.

That's not an issue; it's more of an action which may be taken once 
the relevant host is identified.

Thinking aloud, this is more like creating a problem by sharing the 
same identifier and creating another identifier to solve that problem. :-)

>Med: IPv4 address sharing is already deployed but still the widely 
>deployed model is to assign public IP addresses to customers. Would 
>you be OK with changing "due to the introduction of CGNs" to "due to 
>the massive introduction of CGNs"?

If the technology has significant deployment, it does not make that 
difference whether it is introduced or massively introduced.  I 
suggest using the word "deployed" to keep it simple.

>Med: I'm mainly thinking about NPTv6 (RFC6296).

I am not keen on seeing this in IPv6 unless we are already running 
out of IPv6 addresses. :-)

>Med: Host Identity Protocol. A reference is provided in the draft.

I suggest expanding on first use (RFC Editor nits).

>Med: X-Forwarded-For. The acronym is expanded in the draft but in 
>Section A.8.1. I will make sure it is expanded in first use.

Ok.

>Med: Could you please indicate what is not fair about that sentence? Thanks.

I would not compare solutions at different layers and qualify them as 
a fair comparison.

>Med: XFF allows to prepend a list of IP addresses when several 
>address sharing, application proxies, etc. are in the path. The term 
>compatible is used to indicate XFF can be used in that scenario. If 
>you have any better wording, please advise. Thanks.

I'll get back to you on this.

>Med: Anonymity may be provided; see for instance the TOR service.

There was some discussion about privacy and identifiers for another 
draft.  You might end up getting in a long discussion about the privacy angle.

>Med: XFF is for instance an HTTP header, "via" is a SIP header, etc. 
>Would it be better if we change "Application Header" to "Application 
>Protocols Headers"?

If I recall correctly, the term is "message header fields".

Regards,
-sm

P.S. Sorry for being short.

---

From: <[email-masked]>
Date: Wed, 1 Aug 2012 08:56:27 +0200

Dear SM,

Please see inline. 

Cheers,
Med 

>De : SM [mailto:[email-masked]] 
>Envoyé : mercredi 1 août 2012 00:15
>Objet : RE: [Int-area] Comments on 

Med: That's the point, if there is not identifier to disambiguate hosts sharing the same address, all these users will be impacted.

>suggest using the word "deployed" to keep it simple.

Med: OK. The text is updated accordingly.

>out of IPv6 addresses. :-)

Med: NPTv6 does not deal with IP address depletion. Multi-homed enterprise site may for instance be tempted to "play" with that kind of techniques. I'm not advocating for it not arguing against. The document does only raise the point. 

Med: Done.

>I would not compare solutions at different layers and qualify them as 

Med: The purpose of the draft is to analyse and compare between alternative channels to convey the HOST_ID information. A set of criteria to assess the efficiency of each channel to solve encountered issues is used for that purpose.  

>If I recall correctly, the term is "message header fields".

Med: I wanted to have a generic title in which "Application" is mentioned. I will use "Inject Application Protocol Message Headers". I can change it if there are better suggestions. Thanks.