Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02
-Original Message- From: Wesley Eddy [mailto:w...@mti-systems.com] Sent: Wednesday, August 08, 2012 8:26 PM To: Dan Wing Cc: 'Scott Brim'; 'Joe Touch'; 'Internet Area'; 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On 8/8/2012 11:30 AM, Dan Wing wrote: Today's Internet users, which are not sharing addresses with other users, are sending an uniquely-identifyable identifier to every Internet server they use: their unique IP address. Users don't have IP addresses. Machines do. Which are we trying to identify again? I think the distinction is important since the relation between users and devices can be one-to-many, or many-to-one, and certainly isn't one-to-one, even if we went back in time when the relation between end-host machines and addresses might have been closer to one-to-one. I also don't think user and subscriber are synonyms for many purposes, though some of the reveal-analysis seems to be more oriented towards identifying the access network subscriber. RFC6269 section 13.1 mixes the term 'subscriber' itself: When an abuse is reported today, it is usually done in the form: IPv4 address X has done something bad at time T0. This is not enough information to uniquely identify the subscriber responsible for the ^^ abuse when that IPv4 address is shared by more than one subscriber. ...^^ Second and more likely is that one user who fails a number of login .. attempts may block out other users who have not made any previous ^ attempts but who will now fail on their first attempt. That subscriber generally may have quite a few users and machines behind them. draft-ietf-intarea-nat-reveal-analysis is not analyzing that problem. Today's IP address penalty boxes do not attempt to distinguish between the hacker son at home doing a dictionary attack against a mailserver and the mom trying to legitimately login to that same mailserver. The mailserver will protect itself from the dictionary attack by putting that offending IP address into a penalty box. The different problem that draft-ietf-intarea-nat-reveal-analysis is analyzing is when multiple subscribers can no longer be individually identified by their IP address because of IP address sharing. This means the hacker son (in the scenario in the previous paragraph) can now deny service to everyone else sharing that same IP address, which could be dozens or hundreds of subscribers. We might replace 'hacker son' with 'compromised host'. -d ___ 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
On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: ... During the INTAREA presentation, one suggestion I heard was a separate protocol (ident-like). I will submit an I-D towards that end, which I am dusting off from 2010 when I first considered ident and discarded it for a variety of reasons. Do you have additional suggestions on how to accomplish convey an identifer? There are two separate problems: - establishing an identity and pairing it with a tag - getting that tag into connections so each connection can be correlated back to the identity This draft focuses on the second step. The first is either trivial (with cooperating entities) or needs to be inferred if possible (with non-cooperating/legacy entities). It doesn't matter whether the entity is a person or a machine in general, though this draft focuses on machine entities. Any out-of-band mechanism shares the fate of ident in this doc, as noted in Sec 5.9, though. Is there a point to generating another solution in that space? Joe ___ 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
On Wed, Aug 8, 2012 at 10:49 AM, Joe Touch to...@isi.edu wrote: On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: ... During the INTAREA presentation, one suggestion I heard was a separate protocol (ident-like). I will submit an I-D towards that end, which I am dusting off from 2010 when I first considered ident and discarded it for a variety of reasons. Do you have additional suggestions on how to accomplish convey an identifer? There are two separate problems: - establishing an identity and pairing it with a tag - getting that tag into connections so each connection can be correlated back to the identity 3) making sure that not everyone can associate the identity with that tag. ___ 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
-Original Message- From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Wednesday, August 08, 2012 8:02 AM To: Joe Touch Cc: Dan Wing; Internet Area; Behcet Sarikaya Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On Wed, Aug 8, 2012 at 10:49 AM, Joe Touch to...@isi.edu wrote: On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: ... During the INTAREA presentation, one suggestion I heard was a separate protocol (ident-like). I will submit an I-D towards that end, which I am dusting off from 2010 when I first considered ident and discarded it for a variety of reasons. Do you have additional suggestions on how to accomplish convey an identifer? There are two separate problems: - establishing an identity and pairing it with a tag - getting that tag into connections so each connection can be correlated back to the identity 3) making sure that not everyone can associate the identity with that tag. Scott, Today's Internet users, which are not sharing addresses with other users, are sending an uniquely-identifyable identifier to every Internet server they use: their unique IP address. -d ___ 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
On Aug 8, 2012, at 8:30 AM, Dan Wing wrote: 3) making sure that not everyone can associate the identity with that tag. Scott, Today's Internet users, which are not sharing addresses with other users, are sending an uniquely-identifyable identifier to every Internet server they use: their unique IP address. Given how IP addresses are used today, an address alone is insufficient to indicate a host. That's the whole point of this doc. Addresses and ports together sometimes do, but not in all cases. Other IDs are required - again, the conclusion of this doc. Out-of-band IDs are problematic for many reasons, again as per Sec 5.9 Joe ___ 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
On 8/8/2012 11:30 AM, Dan Wing wrote: Today's Internet users, which are not sharing addresses with other users, are sending an uniquely-identifyable identifier to every Internet server they use: their unique IP address. Users don't have IP addresses. Machines do. Which are we trying to identify again? I think the distinction is important since the relation between users and devices can be one-to-many, or many-to-one, and certainly isn't one-to-one, even if we went back in time when the relation between end-host machines and addresses might have been closer to one-to-one. I also don't think user and subscriber are synonyms for many purposes, though some of the reveal-analysis seems to be more oriented towards identifying the access network subscriber. That subscriber generally may have quite a few users and machines behind them. -- Wes Eddy MTI Systems ___ 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
-Original Message- From: Wesley Eddy [mailto:w...@mti-systems.com] Sent: Saturday, July 28, 2012 12:28 AM To: Dan Wing Cc: sarik...@ieee.org; 'Internet Area'; 'Behcet Sarikaya' Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On 7/27/2012 2:03 PM, Dan Wing wrote: -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Wesley Eddy Sent: Thursday, July 26, 2012 11:34 AM To: sarik...@ieee.org Cc: Internet Area; Behcet Sarikaya Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: On Thu, Jul 26, 2012 at 3:25 AM, mohamed.boucad...@orange.com wrote: 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. Section 3.3 seems to give preference to one specific solution, as such it is against the whole spirit of this document. I suggest removing it. +1 In fact, I suggest that the draft should clearly say that it's doubtful whether a solution actually *needs* to be identified and recommended, especially ones that are implemented awkwardly in other layers. I can't make technical sense of which of the 8 approaches are awkward, in your analysis. I have my own analysis, but the document does not do an evaluation on awkwardness. The underlying problem was identified in Section 13.1 Abuse Logging and Penalty Boxes of RFC6269, Issues with IP Address Sharing, http://tools.ietf.org/html/rfc6269#section-13.1. That was an INTAREA document. Hence, that is why the analysis document is also an INTAREA document. My view is the penalty box problem described in Section 13.1 of RFC6269 is real. My view is the penalty box problem will continue to grow so long as there are IPv4-accessible servers and so long as there are IPv6 clients (NAT64) or IPv4 clients accessing those IPv4 servers. There appear to be different views on the size and trajectory of the problem (getting worse versus getting better). Perhaps discussing those views would be beneficial. Hi Dan - The problem is real because there are bits of deployed code built on an assumption that was good maybe 12 years ago, that IP addresses could be tied to users or machines. Since this is totally broken now, the solution is to get rid of them and use the proper identifiers for whatever it is that these system are trying to do. During the INTAREA presentation, one suggestion I heard was a separate protocol (ident-like). I will submit an I-D towards that end, which I am dusting off from 2010 when I first considered ident and discarded it for a variety of reasons. Do you have additional suggestions on how to accomplish convey an identifer? Building kludges in other layers to supplement the IP address is not the answer. We do have a long history of crossing layers, as much as we pretend we don't do that -- ARP, IPv6 changing UDP checksum requirements compared to IPv4, incorporation of IP addresses for referrals in dozens of protocols (partially due to lack of a name service). Since the analysis in the document already indicates that each of the 8 solutions has non-starter properties to them, I consider that to make them pretty awkward. Recommending any of them is like saying this is the best tasting crap we could find. Yeah, awkwardness happens a lot with address sharing. I also wish it was different. -d ___ 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
Med, My opinion, not as AD, is that this document should not make a recommendation. This document should be strictly an analysis so that we have a baseline understanding of all the existing solutions. Brian On 7/30/12 2:41 AM, mohamed.boucad...@orange.com wrote: Dear Lars, Could be more explict and explain what is missing in draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage? Thanks. Cheers, Med -Message d'origine- De : Eggert, Lars [mailto:l...@netapp.com] Envoyé : vendredi 27 juillet 2012 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Internet Area Objet : Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On Jul 27, 2012, at 0:09, mohamed.boucad...@orange.com wrote: The argument I heard in Paris meeting for including a recommendation is to help vendors to select the solution to implement in their devices. They can not provide the same feature using 8 implementation options. That argument makes sense to me. We're not at the stage yet where we can recommend anything to vendors. We first need to determine if there even is a solution where the benefits outweigh the drawbacks. Lars ___ 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
In your previous mail you wrote: You keep saying privacy, but without explaining the problem or how IPv4 address sharing makes privacy better or worse than IPv6. = there are two levels about the privacy problem: the technical one which is explained/addressed in the draft (section 4) and worse the way it can be perceived which is less (or not at all) rational as the long and silly history of the privacy extensions for stateless address autoconfiguration in IPv6 (RFC 3041 and 4941) has shown. So there is a technical and a political argument against the whole HOST_ID idea. Unfortunately the IETF (and this mailing list) can only deal with the first one. Regards francis.dup...@fdupont.fr PS: to discuss about the technical point IMHO no HOST_ID proposal brings a clear advantage. The real issue (address sharing breaks the address == identity assumption) has to be solved by the impacted part (i.e., people should accept this assumption doesn't apply)... ___ 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
Hi, On Jul 29, 2012, at 23:41, mohamed.boucad...@orange.com wrote: Could be more explict and explain what is missing in draft-ietf-intarea-nat-reveal-analysis-02 to reach that stage? the goal of this draft was to survey the options. I don't think it should make any recommendation at all. If there was a solution for which the benefits outweigh the drawbacks (which I don't think there is), the adoption of a document that specifies it by the IETF and the eventual publication of that document would constitute an IETF recommendation. 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] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02
In your previous mail you wrote: What analysis is missing from draft-ietf-intarea-nat-reveal-analysis to weigh the drawbacks of the 8 solutions. = there are two kinds of drawbacks: the technical drawbacks and the not technical drawbacks, e.g., the impact on privacy... Note because if the second kind I am strongly against the 3.3 (if not changed into a SHOULD NOT :-) and I suggested to NOT RECOMMEND all proposals perhaps at the exception of one (i.e., leave one proposal without any recommendation). Regards francis.dup...@fdupont.fr PS: IMHO only the not advertised port set makes sense, any other proposal deployed in countries where privacy is protected (any place in European Union for instance) should make the ISP to be sued... PPS: we can postpone the discussion to Berlin meeting (privacy concerns are pushed in Germany clearly behind the sillyness point :-). ___ 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
On 7/27/2012 2:03 PM, Dan Wing wrote: -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Wesley Eddy Sent: Thursday, July 26, 2012 11:34 AM To: sarik...@ieee.org Cc: Internet Area; Behcet Sarikaya Subject: Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On 7/26/2012 1:08 PM, Behcet Sarikaya wrote: On Thu, Jul 26, 2012 at 3:25 AM, mohamed.boucad...@orange.com wrote: 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. Section 3.3 seems to give preference to one specific solution, as such it is against the whole spirit of this document. I suggest removing it. +1 In fact, I suggest that the draft should clearly say that it's doubtful whether a solution actually *needs* to be identified and recommended, especially ones that are implemented awkwardly in other layers. I can't make technical sense of which of the 8 approaches are awkward, in your analysis. I have my own analysis, but the document does not do an evaluation on awkwardness. The underlying problem was identified in Section 13.1 Abuse Logging and Penalty Boxes of RFC6269, Issues with IP Address Sharing, http://tools.ietf.org/html/rfc6269#section-13.1. That was an INTAREA document. Hence, that is why the analysis document is also an INTAREA document. My view is the penalty box problem described in Section 13.1 of RFC6269 is real. My view is the penalty box problem will continue to grow so long as there are IPv4-accessible servers and so long as there are IPv6 clients (NAT64) or IPv4 clients accessing those IPv4 servers. There appear to be different views on the size and trajectory of the problem (getting worse versus getting better). Perhaps discussing those views would be beneficial. Hi Dan - The problem is real because there are bits of deployed code built on an assumption that was good maybe 12 years ago, that IP addresses could be tied to users or machines. Since this is totally broken now, the solution is to get rid of them and use the proper identifiers for whatever it is that these system are trying to do. Building kludges in other layers to supplement the IP address is not the answer. Since the analysis in the document already indicates that each of the 8 solutions has non-starter properties to them, I consider that to make them pretty awkward. Recommending any of them is like saying this is the best tasting crap we could find. -- Wes Eddy MTI Systems ___ 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
Hi Behcet, The argument I heard in Paris meeting for including a recommendation is to help vendors to select the solution to implement in their devices. They can not provide the same feature using 8 implementation options. That argument makes sense to me. Now, as I said earlier, I will remove or maintain that section according to the guidance from the WG. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 26 juillet 2012 19:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Suresh Krishnan; Internet Area Objet : Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02 On Thu, Jul 26, 2012 at 3:25 AM, mohamed.boucad...@orange.com wrote: 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. Section 3.3 seems to give preference to one specific solution, as such it is against the whole spirit of this document. I suggest removing it. Behcet 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 ___ 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
On Jul 27, 2012, at 0:09, mohamed.boucad...@orange.com wrote: The argument I heard in Paris meeting for including a recommendation is to help vendors to select the solution to implement in their devices. They can not provide the same feature using 8 implementation options. That argument makes sense to me. We're not at the stage yet where we can recommend anything to vendors. We first need to determine if there even is a solution where the benefits outweigh the drawbacks. 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] 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
