Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02
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
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
Hi Mohamed, On Jul 26, 2012, at 10:30 AM, mohamed.boucad...@orange.com 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
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
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, mohamed.boucad...@orange.com 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
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, mohamed.boucad...@orange.com 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, mohamed.boucad...@orange.com 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
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, mohamed.boucad...@orange.com 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, mohamed.boucad...@orange.com 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
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
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 aolMe 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 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
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
[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? 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
