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