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

[mohamed.boucadair]

Dear SM,

Please see inline. 

Cheers,
Med 

>-Message d'origine-
>De : SM [mailto:s...@resistor.net] 
>Envoyé : mercredi 1 août 2012 00:15
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : int-area@ietf.org
>Objet : RE: [Int-area] Comments on 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>Hi Med,
>At 01:17 AM 7/26/2012, mohamed.boucad...@orange.com wrote:
>>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.
>
>That's not an issue; it's more of an action which may be taken once 
>the relevant host is identified.

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

>
>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: OK. The text is updated accordingly.

>
>>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: 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: Host Identity Protocol. A reference is provided in the draft.
>
>I suggest expanding on first use (RFC Editor nits).

Med: Done.

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

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

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.

>
>Regards,
>-sm
>
>P.S. Sorry for being short. 
>
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[SM]

Hi Med,
At 01:17 AM 7/26/2012, mohamed.boucad...@orange.com wrote:

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.


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. 


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

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 

>-Message d'origine-
>De : Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
>Envoyé : jeudi 26 juillet 2012 11:09
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org
>Objet : Re: [Int-area] Comments on 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>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
>
>On Jul 26, 2012, at 11:33 AM,  wrote:
>
>> 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 
>> 
>>> -Message d'origine-----
>>> De : Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
>>> Envoyé : jeudi 26 juillet 2012 09:52
>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>> Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org
>>> Objet : Re: [Int-area] Comments on 
>>> draft-ietf-intarea-nat-reveal-analysis-02
>>> 
>>> Hi Mohamed, 
>>> 
>>> On Jul 26, 2012, at 10:30 AM,  wrote:
>>> 
>>>>> 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.
>>>> 
>>>> 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
>>> 
>
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Hannes Tschofenig]

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

On Jul 26, 2012, at 11:33 AM,  wrote:

> 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 
> 
>> -Message d'origine-
>> De : Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
>> Envoyé : jeudi 26 juillet 2012 09:52
>> À : BOUCADAIR Mohamed OLNC/NAD/TIP
>> Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org
>> Objet : Re: [Int-area] Comments on 
>> draft-ietf-intarea-nat-reveal-analysis-02
>> 
>> Hi Mohamed, 
>> 
>> On Jul 26, 2012, at 10:30 AM,  wrote:
>> 
>>>> 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.
>>> 
>>> 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
>> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

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 

>-Message d'origine-
>De : Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
>Envoyé : jeudi 26 juillet 2012 09:52
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Hannes Tschofenig; Wesley Eddy; Tina TSOU; int-area@ietf.org
>Objet : Re: [Int-area] Comments on 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>Hi Mohamed, 
>
>On Jul 26, 2012, at 10:30 AM,  wrote:
>
>>> 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.
>> 
>> 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
>
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

Dear SM,

Apologies for the delay to answer. 

Please see inline.

Cheers,
Med  

>-Message d'origine-
>De : int-area-boun...@ietf.org 
>[mailto:int-area-boun...@ietf.org] De la part de SM
>Envoyé : samedi 7 juillet 2012 10:41
>À : int-area@ietf.org
>Objet : [Int-area] Comments on 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>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?

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

>
>   "The risk of not mitigating these issues are: OPEX increase for IP"
>
>I suggest expanding "OPEX" on first use.

Med: Done. 

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

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

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

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

>
>In Section 3.2:
>
>   "Requires the client and the server to be HIP-compliant and HIP
>infrastructure to be deployed."
>
>What's HIP?

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

>
>   "XFF is de facto standard deployed and supported in operational
>networks"
>
>What's XFF?

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.

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

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

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

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.

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

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

>
>This draft would benefit from cross-area review.  It needs more work 
>in my humble opinion.
>
>Regards,
>-sm
>
>
>
>
>___
>Int-area mailing list
>Int-area@ietf.org
>https://www.ietf.org/mailman/listinfo/int-area
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Hannes Tschofenig]

Hi Mohamed, 

On Jul 26, 2012, at 10:30 AM,  wrote:

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[mohamed.boucadair]

Dear Wes,

Please see inline.
Cheers,
Med 

>-Message d'origine-
>De : int-area-boun...@ietf.org 
>[mailto:int-area-boun...@ietf.org] De la part de Wesley Eddy
>Envoyé : mardi 10 juillet 2012 01:26
>À : Tina TSOU
>Cc : int-area@ietf.org
>Objet : Re: [Int-area] Comments on 
>draft-ietf-intarea-nat-reveal-analysis-02
>
>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.

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


  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.

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


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

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.  

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

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.

>
>-- 
>Wes Eddy
>MTI Systems
>___
>Int-area mailing list
>Int-area@ietf.org
>https://www.ietf.org/mailman/listinfo/int-area
>
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Warren Kumari]

On Jul 10, 2012, at 4:14 AM, Eggert, Lars wrote:

> On Jul 10, 2012, at 1:26, Wesley Eddy wrote:
>> On 7/9/2012 4:41 PM, Tina TSOU wrote:
>>> 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.
> 
> +1

Me too!

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

W

> 
> Lars___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

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

-- (Terry Pratchett, Wyrd Sisters)


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Eggert, Lars]

On Jul 10, 2012, at 1:26, Wesley Eddy wrote:
> On 7/9/2012 4:41 PM, Tina TSOU wrote:
>> 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.

+1

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Wesley Eddy]

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
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Tina TSOU]

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" mailto:s...@resistor.net>> 
wrote:

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




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[SM]

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




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area