Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Stephen, Please see inline. Cheers, Med -Message d'origine- De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] Envoyé : vendredi 6 juin 2014 17:59 À : BOUCADAIR Mohamed IMT/OLN; Ted Lemon Cc : Brian E Carpenter; ietf-privacy@ietf.org; int-a...@ietf.org Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers Hi Med, On 06/06/14 12:41, mohamed.boucad...@orange.com wrote: [Med] I'm not sure about this Ted. There are other initiatives that try to solve the issue for particular use cases, see for instance this effort for HTTP: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The rationale of the host identifier scenarios document is to group all use cases suffering from the same problem instead of focusing on one single case. This allows having a big picture view of the problem space. I think XFF is actually a good example of why we ought not adopt this work. [Med] I provided Forward as an example to illustrate there is a need to have a big picture view rather than focusing on specific use case. This draft does not suggest to adopt XFF or Forward at all. There is a need to understand the problem space and identify deployment scenarios where encountering complications. XFF is widely deployed already but somewhat flakey in terms of interop so the authors of the above draft aimed to produce a spec that just addressed interop. (*) That was adopted by an area WG without (IMO) ever really considering the privacy implications, and definitely without any effort having been made to develop a more privacy-friendly mechanism (which could have been done, again IMO) to solve what were the claimed use-cases. [Med] Wouldn't be this effort an opportunity to promote those solutions you are advocating for? The proxy use case (not limited to HTTP) is listed as a typical scenario. If there are other better solutions that solves your privacy concerns, why not documenting them? By the time it got to the IESG that was in practice unfixable and after some fairly painful discussions it ended up with 4 abstain ballots, including mine. [1] (For those who quite reasonably don't need to care about IESG balloting, an abstain means approximately yuk.:-) Of course that all also pre-dated BCP188 and the last year's shenanigans so I'd hope we have learned to not keep doing that. I'd be delighted if those who could get a better solution implemented/deployed were to attempt to try to address the privacy issues with XFF but it seems that at least in that case relevant folks don't care (sufficiently;-) deeply about our privacy to go do that. S. [1] https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/ (*) To be clear: I think the authors were genuinely just trying to fix what they saw as an interop problem. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 6/7/2014 6:20 AM, Stephen Farrell wrote: Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Again, BCP188 does not *call* for doing anything. There are no SHOULD- or MUST- level requirements in that doc. Let's please not wave it in the air as if there are. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Dear all, I would like to confirm this: As already pointed out by Bruno in http://www.ietf.org/mail-archive/web/int-area/current/msg03904.html there is the emergency call use case at ETSI and beside that there are application proposals within WGs SFC, TCPM, etc. beside other drafts which refer to RFC 6967. And although I might repeat again what has been stated many times: Intended goal is and should be to find a solution to fulfil dedicated and real use cases demands - respecting privacy, reducing vulnerability, strengthening protection against misuse as mentioned in BCP188, and so on ... Best regards Dirk -Original Message- From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of joel jaeggli Sent: Montag, 9. Juni 2014 19:16 To: Stephen Farrell; Brandon Williams; Dan Wing Cc: ietf-privacy@ietf.org; Internet Area Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers On 6/9/14, 7:01 AM, Stephen Farrell wrote: On 09/06/14 14:46, Brandon Williams wrote: Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. There are 6 citations of http://tools.ietf.org/html/rfc6967 the document doesn't exist in a vacuum where somehow how to do it has fallen off the table. given the repeated asertion that this work is useful because of external requests (etsi) and that request is in fact tied closely to a particular method it is relatively strait forward to conflate the discussion of scenarios and methods. Fair enough that its an assumption of mine that adding some kind of identifier is required to meet the (no-longer mis-stated:-) requirements for these use-cases. But I think that is logically required, and its valid to draw obvious conclusions and its also invalid to ignore obvious conclusions. S. ___ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Re-, Please see inline. Cheers, Med -Message d'origine- De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen Farrell Envoyé : samedi 7 juin 2014 15:21 À : Dan Wing Cc : ietf-privacy@ietf.org; Internet Area; Joe Touch Objet : Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) [Med] FWIW, this draft does not hint solutions but it aims to describe scenarios with problems. I understand you have concerns with privacy but this is not an excuse to abuse and characterize this effort as stupid. Privacy implications should be assess on a per use case basis (see for example cases where all involved entities belong to same administrative entity). Furthermore, the document (including -04) says the following : the document does not elaborate whether explicit authentication is enabled or not. Adding new identifiers with privacy impact, as proposed here, is quite different. [Med] I have already clarified this point: the scenario draft does not propose any identifier! S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 11/06/14 15:54, Joe Touch wrote: On 6/7/2014 6:20 AM, Stephen Farrell wrote: Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Again, BCP188 does not *call* for doing anything. There are no SHOULD- or MUST- level requirements in that doc. Let's please not wave it in the air as if there are. I don't buy that argument at all and didn't wave anything anywhere. BCP188 very clearly says: Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. and Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new pervasive monitoring considerations section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question Is pervasive monitoring relevant to this work and if so, how has it been considered? Reverting to RFC2119-keyword-lawyering is not IMO credible here. S. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hiya, On 11/06/14 15:38, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen Farrell Envoyé : samedi 7 juin 2014 15:21 À : Dan Wing Cc : ietf-privacy@ietf.org; Internet Area; Joe Touch Objet : Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) [Med] FWIW, this draft does not hint solutions but it aims to describe scenarios with problems. I understand you have concerns with privacy but this is not an excuse to abuse and characterize this effort as stupid. Apologies if you took it that way. What I meant was that BCP188 does not call for stupid stuff, I was not characterising the draft as stupid, but rather the assertion that BCP188 calls for such. Privacy implications should be assess on a per use case basis Where do I find the per-use-case analysis of privacy implications? (see for example cases where all involved entities belong to same administrative entity). Furthermore, the document (including -04) says the following : the document does not elaborate whether explicit authentication is enabled or not. Adding new identifiers with privacy impact, as proposed here, is quite different. [Med] I have already clarified this point: the scenario draft does not propose any identifier! I think its unrealistic to assert that any solution is possible without such. I would be interested in reading about any proposal that did not require a new identifier. So yes, I do assert that a need for a new identifier is implicit in the draft, even if that is not stated explicitly, and would be interested in arguments as to why I'm wrong about that. S. S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 6/11/2014 8:09 AM, Stephen Farrell wrote: On 11/06/14 15:54, Joe Touch wrote: On 6/7/2014 6:20 AM, Stephen Farrell wrote: Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Again, BCP188 does not *call* for doing anything. There are no SHOULD- or MUST- level requirements in that doc. Let's please not wave it in the air as if there are. I don't buy that argument at all and didn't wave anything anywhere. BCP188 very clearly says: Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. and Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new pervasive monitoring considerations section is needed in IETF documentation. It means that, if asked, there needs to be a good answer to the question Is pervasive monitoring relevant to this work and if so, how has it been considered? Reverting to RFC2119-keyword-lawyering is not IMO credible here. That's what RFC2119 is for and how we interpret BCPs. The doc goes out of its way - as you note - to include wiggle phrases like where possible and by not requiring a new considerations section. Yes, it's fine to discuss it here, and I've already outlined a way forward - with the caveat that my view is do no harm, not necessarily fix the lack of privacy already inherent in the Internet - at least in this doc. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
I agree entirely that defining host identification as a problem indicates that the authors believe a solution is called for. I also agree that the privacy impact of solution candidates must be discussed, including making a concerted effort to mitigate the possibility of those solution candidates being used for pervasive monitoring purposes. My point is simply that this draft is not intended to propose solutions or discuss solution candidates. RFC6967, which as you note is repeatedly cited, discusses solution candidates and lays out a framework for privacy discussion related to solution proposals. Future RFCs that actually propose solutions are already expected to follow the guidance from RFC6967, and the references to that RFC in this draft are meant to point to RFC6967 as the authoritative guidance. Is there some reason why you do not consider it adequate for this use cases draft to reference the existing and already published potential solutions analysis rfc? What specific content related to privacy and/or pervasive monitoring belongs in this draft that is not already present in RFC6967? Thanks, --Brandon On 06/09/2014 01:16 PM, joel jaeggli wrote: On 6/9/14, 7:01 AM, Stephen Farrell wrote: On 09/06/14 14:46, Brandon Williams wrote: Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. There are 6 citations of http://tools.ietf.org/html/rfc6967 the document doesn't exist in a vacuum where somehow how to do it has fallen off the table. given the repeated asertion that this work is useful because of external requests (etsi) and that request is in fact tied closely to a particular method it is relatively strait forward to conflate the discussion of scenarios and methods. Fair enough that its an assumption of mine that adding some kind of identifier is required to meet the (no-longer mis-stated:-) requirements for these use-cases. But I think that is logically required, and its valid to draw obvious conclusions and its also invalid to ignore obvious conclusions. S. ___ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On Jun 8, 2014, at 20:26 , Joe Touch to...@isi.edu wrote: a NAT hides the host *at the expense* of exposing a router If I have the energy to do a DoS attack, surely I have the energy to traceroute the hosts I know to find a common routing point? David Singer Manager, Software Standards, Apple Inc. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 09/06/14 14:46, Brandon Williams wrote: Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. Fair enough that its an assumption of mine that adding some kind of identifier is required to meet the (no-longer mis-stated:-) requirements for these use-cases. But I think that is logically required, and its valid to draw obvious conclusions and its also invalid to ignore obvious conclusions. S. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On Jun 5, 2014, at 1:10 PM, Joe Touch to...@isi.edu wrote: On 6/5/2014 5:48 AM, Stephen Farrell wrote: I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. That BCP thankfully includes zero RFC2119 language except the single word should (not capitalized) in the abstract, thus every new document is trivially compliant with its recommendations. (I really wish the IETF community cared as much about technical correctness and protocol robustness as they did about issuing that IMO largely political statement, which flies in the face of 40+ years of using globally-assigned, globally-unique IP addresses as endpoint identifiers as the basis of the Internet architecture). Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Stephen, On 06/07/2014 09:20 AM, Stephen Farrell wrote: Adding new identifiers with privacy impact, as proposed here, is quite different. It is not the intention of the authors for this to be a solution draft. The draft is intended to describe address sharing use cases and deployment scenarios. Would you please indicate where the draft proposes a new identifier? If you are seeing a proposal for protocol changes somewhere in the draft, editing work is required in order to either clarify or excise the associated text. Thanks, --Brandon On 06/07/2014 09:20 AM, Stephen Farrell wrote: Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Adding new identifiers with privacy impact, as proposed here, is quite different. S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Bingo. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 10/06/2014 04:43, Ted Lemon wrote: On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Bingo. So, there are some more components of the threat analysis and the solution requirements. That's good, but I thought we were discussing whether to document the use cases. Brian ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Just to be clear: that was SMTP. The calculus can be different for other protocols, depending on their end to end nature. SMTP is very hop by hop and it is very difficult to secure an entire path with confidence due to downgrade attack threats. https would be a horse of a different color. On 6/9/14, 10:10 PM, Brian E Carpenter wrote: On 10/06/2014 04:43, Ted Lemon wrote: On Jun 9, 2014, at 12:32 PM, Eliot Lear l...@cisco.com wrote: But does adding a header solve the problem? Not unless it is signed AND I believe the signature. And then I had better be willing to spend the processing time to sort out your good customers from your bad customers. I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway. I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today. Bingo. So, there are some more components of the threat analysis and the solution requirements. That's good, but I thought we were discussing whether to document the use cases. Brian ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On Jun 7, 2014, at 6:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: NATs have both good and bad properties. The slightly better privacy is one of the good ones. Better for the hosts they 'hide'; worse as a common network access point. Consider an enterprise. There are two things we can learn about it from IP addresses: - without a NAT, we learn about activity of individual hosts - with a NAT, we learn the common network access point If I want to track host activity - or attack a host, the former is better. If I want to know what to DOS to take down the entire enterprise, the latter is better. Think of it this way: a NAT hides the host *at the expense* of exposing a router If we're serious about considering privacy issues, there's a LOT more homework to be done. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Adding new identifiers with privacy impact, as proposed here, is quite different. S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
In many countries service providers are required to track which user behind a NAT mapped to what IP/port the used. NAT != privacy. -- Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See http://www.standardstrack.com/ietf/lemonade/ On Jun 7, 2014, at 9:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Hi Dan, On 07/06/14 02:38, Dan Wing wrote: Stephen, It seems NAPT has become IETF's privacy feature of 2014 because multiple users are sharing one identifier (IP address and presumably randomized ports [RFC6056], although many NAPT deployments use address ranges because of fear of compressing log files). As a former co-chair of BEHAVE it is refreshing to see the IETF embracing NAPT as a desirable feature. Embracing seems like significant overstatement to me, but maybe that's understandable given how calmly NAT is generally debated. NATs have both good and bad properties. The slightly better privacy is one of the good ones. Recognising that reality is neither embracing nor refreshing IMO, nor does it mean NAPT is (un)desirable overall. (That's an argument I only ever watch from the side-lines thanks:-) However, if NAPT provides privacy and NAT Reveal removes it, where does that leave a host's IPv6 source address with respect to BCP188? Afterall, an IPv6 address is quite traceable, even with IPv6 privacy addresses (especially as IPv6 privacy addresses are currently deployed which only obtain a new IPv6 privacy address every 24 hours or when attaching to a new network). If BCP188 does not prevent deployment of IPv6, I would like to understand the additional privacy leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of IPv6+privacy_address. I'm frankly amazed that that's not crystal clear to anyone who has read all 2.5 non-boilerplate pages of the BCP. Or even just the last two words of the 1-line abstract (hint: those say where possible.) Yes, source addresses leak information that affects privacy. But we do not have a practical way to mitigate that. So therefore BCP188 does not call for doing stupid stuff, nor for new laws of physics (unlike -04 of the draft we're discussing;-) Adding new identifiers with privacy impact, as proposed here, is quite different. S. PS: If someone wants to propose what they think is a practical way to mitigate the privacy issues with source addresses, please write a draft first and then start a separate thread somewhere. -d ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Hi Ted, As far as this document is concerned, we are open to address technical concerns. It will be helpful if these concerns are specific enough and hopefully in reference to http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05. Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3. Cheers, Med -Message d'origine- De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Ted Lemon Envoyé : jeudi 5 juin 2014 23:27 À : Brian E Carpenter Cc : ietf-privacy@ietf.org; int-a...@ietf.org; Stephen Farrell Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty heavy action. It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC. If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work. So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't. ___ Int-area mailing list int-a...@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Re-, Please see inline. Cheers, Med -Message d'origine- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : vendredi 6 juin 2014 12:48 À : BOUCADAIR Mohamed IMT/OLN Cc : Brian E Carpenter; ietf-privacy@ietf.org; int-a...@ietf.org; Stephen Farrell Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers On Jun 6, 2014, at 4:11 AM, mohamed.boucad...@orange.com wrote: Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3. The document hasn't been adopted yet, so we can avoid security issues simply by not adopting it. [Med] I'm not sure about this Ted. There are other initiatives that try to solve the issue for particular use cases, see for instance this effort for HTTP: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The rationale of the host identifier scenarios document is to group all use cases suffering from the same problem instead of focusing on one single case. This allows having a big picture view of the problem space. Talking about what the security considerations section might do to ameliorate the harm isn't in scope yet. First we need to decide whether there is more harm than good done by adopting and publishing the document! [Med] Fair enough. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Stephen, On 06/06/2014 00:48, Stephen Farrell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya, On 05/06/14 08:05, Hannes Tschofenig wrote: If you want to review a document with privacy implications then have a look at the NAT reveal / host identifier work (with draft-boucadair-intarea-host-identifier-scenarios-04 currently in a call for adoption). I had raised my concerns several times now on the mailing list and during the meetings. I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. For something like this, the onus ought IMO be on the proposers to have done that work before asking for adoption. Why? Where do the rules say that? As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian Based on the draft, they clearly have not done that. We could also ask to add more use-cases: use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell data that's even more fine-grained than clickstreams use-case#14: expose your n/w internals to help on path attackers use-case#15: track hosts from which people emit dangerous utterances use-case#16: block hosts from which people emit dangerous utterances use-case#17: charge me more for using two of my computers in my house The set of use-cases presented very much contradicts the explicit claim in the draft that no position is being taken as to the merits of this. IMO that argues strongly to not adopt this. One could also comment on the requirements that seem to require new laws of physics or are otherwise pretty odd: REQ#1: seems to require knowing from packets passing by that a device is a trusted device (and REQ#15 says that can be done with 16 bits;-) Hmm... are those qubits maybe? REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without a flag day. Hmm... REQ#6: says this is a transport thing. Eh, why ask INT-AREA? REQ#10+REQ#11: MUST be intradomain only but MUST also be inter domain. Hmm... REQ#18: receiver MUST enforce policies like QoS. Huh? Such a frankly bogus list of requirements also means that this is not something that ought be adopted in the IETF. I also think that this proposal has previously been proposed in other ways and not adopted. Such forum-shopping is yet another reason to not adopt it, and certainly not as an area wg thing without any broader IETF-wide consideration. (As an aside: having to play whack-a-mole with such repeat proposals is one of the downsides of area wgs. Not sure if anything can be done about that though.) In summary: ignoring BCP188, the selection-bias in use cases, the badly thought out requirements and forum shopping are all independently sufficient reasons to not adopt this. And of course that doesn't include all the other issues with potential solutions listed in RFC6967 (the reference to which is oddly to the I-D and not the RFC). My conclusion: this one ought go to /dev/null same as the previous attempts to shop the same thing into other parts of the IETF. S Ciao Hannes Original Message Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Date:Thu, 5 Jun 2014 04:20:56 + From:Suresh Krishnan suresh.krish...@ericsson.com To: Internet Area int-a...@ietf.org Hi all, This draft was originally intended to be published as an AD sponsored submission from the OPS area, but the authors have expressed their interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier discussions on the wg mailing list and the latest version of the draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 This call is being initiated to determine whether there is WG consensus towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2014-06-19. Regards Suresh Juan Carlos ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 6/5/2014 5:48 AM, Stephen Farrell wrote: I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. That BCP thankfully includes zero RFC2119 language except the single word should (not capitalized) in the abstract, thus every new document is trivially compliant with its recommendations. (I really wish the IETF community cared as much about technical correctness and protocol robustness as they did about issuing that IMO largely political statement, which flies in the face of 40+ years of using globally-assigned, globally-unique IP addresses as endpoint identifiers as the basis of the Internet architecture). Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 06/06/2014 09:26, Ted Lemon wrote: On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty heavy action. It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC. If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. I have no problem with that. It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, Indeed. So (speaking only for myself) I tend to ignore drafts aimed at the WG until they are close to adoption, because my input bit rate is limited. Brian which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work. So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On 6/5/2014 1:28 PM, Brian E Carpenter wrote: ... As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian I'd vote for WG adoption, and agree with the above with the caveat that such misuse should focus on: a) ways proposed mechanisms undo current mechanisms that *might* have been intended to preserve privacy (e.g., NATs are deployed for lots of reasons, and we never know intent per se, but privacy preservation CAN be a reason) b) ways proposed mechanisms can exceed restoring what such devices undo and be used to track hosts, processes, or other identities beyond what the original packet *would have already exposed*. I.e., for a device that inserts the source IP address and TCP source port for NAT traversal, it would at best be considered to 'undo' the potential privacy-creation intent of a NAT, but would NOT be considered to exceed what the original packet conveyed. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
I think Ted answered this but one little bit more... On 05/06/14 21:28, Brian E Carpenter wrote: Stephen, On 06/06/2014 00:48, Stephen Farrell wrote: Hiya, On 05/06/14 08:05, Hannes Tschofenig wrote: If you want to review a document with privacy implications then have a look at the NAT reveal / host identifier work (with draft-boucadair-intarea-host-identifier-scenarios-04 currently in a call for adoption). I had raised my concerns several times now on the mailing list and during the meetings. I share those concerns. And adopting this without any consideration of BCP188 would fly in the face of a very recent, very thoroughly discussed, IETF consensus. I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. For something like this, the onus ought IMO be on the proposers to have done that work before asking for adoption. Why? Where do the rules say that? Just to clarify: I don't think we have rules that say that, nor do I have any kind of veto, I was just expressing my opinion, for this case. S As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian Based on the draft, they clearly have not done that. We could also ask to add more use-cases: use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell data that's even more fine-grained than clickstreams use-case#14: expose your n/w internals to help on path attackers use-case#15: track hosts from which people emit dangerous utterances use-case#16: block hosts from which people emit dangerous utterances use-case#17: charge me more for using two of my computers in my house The set of use-cases presented very much contradicts the explicit claim in the draft that no position is being taken as to the merits of this. IMO that argues strongly to not adopt this. One could also comment on the requirements that seem to require new laws of physics or are otherwise pretty odd: REQ#1: seems to require knowing from packets passing by that a device is a trusted device (and REQ#15 says that can be done with 16 bits;-) Hmm... are those qubits maybe? REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without a flag day. Hmm... REQ#6: says this is a transport thing. Eh, why ask INT-AREA? REQ#10+REQ#11: MUST be intradomain only but MUST also be inter domain. Hmm... REQ#18: receiver MUST enforce policies like QoS. Huh? Such a frankly bogus list of requirements also means that this is not something that ought be adopted in the IETF. I also think that this proposal has previously been proposed in other ways and not adopted. Such forum-shopping is yet another reason to not adopt it, and certainly not as an area wg thing without any broader IETF-wide consideration. (As an aside: having to play whack-a-mole with such repeat proposals is one of the downsides of area wgs. Not sure if anything can be done about that though.) In summary: ignoring BCP188, the selection-bias in use cases, the badly thought out requirements and forum shopping are all independently sufficient reasons to not adopt this. And of course that doesn't include all the other issues with potential solutions listed in RFC6967 (the reference to which is oddly to the I-D and not the RFC). My conclusion: this one ought go to /dev/null same as the previous attempts to shop the same thing into other parts of the IETF. S Ciao Hannes Original Message Subject:[Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04 Date: Thu, 5 Jun 2014 04:20:56 + From:Suresh Krishnan suresh.krish...@ericsson.com To: Internet Area int-a...@ietf.org Hi all, This draft was originally intended to be published as an AD sponsored submission from the OPS area, but the authors have expressed their interest to continue this work in the intarea wg given that RFC6269 and RFC6967 originated here. The draft has been updated to address the issues brought up during earlier discussions on the wg mailing list and the latest version of the draft is available at http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04 This call is being initiated to determine whether there is WG consensus towards adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2014-06-19. Regards Suresh Juan Carlos ___ ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
I agree too and think Joe's outlined a good starting point to discuss misuse. Rob -Original Message- From: ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] On Behalf Of Joe Touch Sent: 05 June 2014 21:42 To: Brian E Carpenter; Stephen Farrell Cc: ietf-privacy@ietf.org; int-a...@ietf.org Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers On 6/5/2014 1:28 PM, Brian E Carpenter wrote: ... As a matter of fact I tend to agree with many of your criticisms of the draft, and I like the idea (below) of adding what we might call the misuse cases. That's a discussion the intarea WG could have. Brian I'd vote for WG adoption, and agree with the above with the caveat that such misuse should focus on: a) ways proposed mechanisms undo current mechanisms that *might* have been intended to preserve privacy (e.g., NATs are deployed for lots of reasons, and we never know intent per se, but privacy preservation CAN be a reason) b) ways proposed mechanisms can exceed restoring what such devices undo and be used to track hosts, processes, or other identities beyond what the original packet *would have already exposed*. I.e., for a device that inserts the source IP address and TCP source port for NAT traversal, it would at best be considered to 'undo' the potential privacy-creation intent of a NAT, but would NOT be considered to exceed what the original packet conveyed. Joe ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty heavy action. It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC. If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work. So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
Ted said: If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them. So bringing up those flaws during the adoption process is crucial to the process. [BA] I would agree that there should be an agreement to address the flaws prior to adoption, but in my experience that is often not enough. If the flaws are major enough, sometimes the fixes end up being non-trivial, or even turn into an argument about the feasibility of fixing them at all. More than once I have seen this turn into a war of attribution between the editors and the WG, where the editors assert that because the WG adopted the document, they effectively endorsed the approach, and the WG asserting that they never would have adopted the document with the knowledge that the flaws would remain. To prevent this kind of argument down the line, if there is a major flaw in a document, I now believe it is best to insist that it be addressed *prior* to adoption. ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
