Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Dear Joe, all, Apologies for the delay to answer (I was out of office). I have no problem to remove Section 3.3 if this is what the WG wants. As a reminder, I added that section after the Paris meeting in accordance with what I heard in the meeting: more voices in favour of adding a recommendation. I sent a notification to the mailing list mid-april to acknowledge this change. Now, I'm waiting for a feedback from the WG to maintain or to remove Section 3.3. Cheers, Med -Message d'origine- De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la part de Joe Touch Envoyé : vendredi 6 juillet 2012 02:17 À : Suresh Krishnan Cc : Internet Area Objet : Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 As a co-author, I didn't want to remain silent per se, so I'll at least be public in my view. I think the doc is good, but I do take Alissa's concerns to point - it might be preferable to remove section 3.3 and leave this doc as a comparison of solutions, and avoid any recommendation of a way forward at this point. Joe On 6/27/2012 8:57 AM, Suresh Krishnan wrote: Hi all, The WGLC on this draft ended with no comments at all. In this context, we cannot assume that silence equates to consent. In order for this draft to progress, we need people to read the draft and provide their opinions on whether the draft is ready. To enable people to comment, the last call period is extended until Friday July 6, 2012. Thanks Suresh and Julien On 06/08/2012 10:06 AM, Suresh Krishnan wrote: Hi all, This message starts a two week intarea working group last call on advancing the draft about Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments as an Informational RFC. The draft is available at http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on June 22, 2012. Regards, Suresh Julien ___ 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 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] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Dear Lars, Please see inline. Cheers, Med -Message d'origine- De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la part de Eggert, Lars Envoyé : vendredi 6 juillet 2012 09:40 À : Alissa Cooper Cc : Internet Area Objet : Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On Jul 5, 2012, at 22:48, Alissa Cooper wrote: With the changes to this draft in the -02 version, I'm having a little trouble seeing its purpose. It basically now seems like a shell for the recommendation in 3.3, with the analysis stuffed into appendices. But given that there is no stable proposal for the actual TCP option to be implemented, what is the purpose for advancing this document right now? I think I've heard that folks needed to know what to implement, but does this document really resolve that problem given that even within the space of TCP-option-based solutions for this, there are multiple different proposals, none of which has been standardized? This document made more sense when it was just a comparison of the different potential solutions spaces. Fully agree with Alissa. An comparison of options would be fine. But 3.3 and other text go beyond a comparison. Med: FYI I added Section 3.3 after the Paris meeting where I asked the question whether we need to add a recommendation or not. It seems to me I heard more voices for having a recommendation in the document. A notification has been sent to this mailing list in mid-april. Anyway, I'm open to record the consensus of the WG: maintain or remove that section. I also don't understand why INTAREA is entertaining work that is clearly intending to define new TCP options. Med: This draft is not about the TCP option but to analyze a set of solutions to solve a problem already documented in RFC6069. None of the -abdo- drafts have been presented in TCPM or even discussed on the mailing list. (My guess is that the authors know that this would never get traction in TCPM and are venue shopping.) Med: I checked tcpm agenda, draft-abdo will be presented in tcpm in Vancouver. Lars ___ 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] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02
Dear Suresh, all, After reading received comments, the major point we need to discuss is whether the WG wants to remove Section 3.3 or maintain it. I'm waiting for a feedback from the WG for the direction to take. I will implement any change requested by the WG. Cheers, Med -Message d'origine- De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la part de Suresh Krishnan Envoyé : vendredi 20 juillet 2012 20:56 À : Internet Area Objet : [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 Hi all, After going through the responses to the WGLC, it is clear that the draft is not ready to go forward in the publication process. We will discuss further steps for this draft at the Vancouver meeting. Thanks Suresh Julien ___ 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
