Re-, Please see inline.
Cheers, Med >-----Message d'origine----- >De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] >Envoyé : mercredi 11 juin 2014 17:18 >À : BOUCADAIR Mohamed IMT/OLN; Dan Wing >Cc : ietf-privacy@ietf.org; Internet Area; Joe Touch >Objet : 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. [Med] OK. > >> Privacy implications should be assess on a per >> use case basis > >Where do I find the per-use-case analysis of privacy implications? [Med] The current version cites the generic privacy considerations (RFC6967). Assessing the implications for each use case is in our to do list based on the discussion we had so far. This table (from the draft) shows whether each use case is restricted to a given administrative domain to it spans multiple ones. +-------------------+------+-------------+-----------------------+ | Use Case | IPv4 | IPv6 | Single Administrative | | | |------+------| Domain | | | |Client|Server| | +-------------------+------+------+------+-----------------------+ | CGN | Yes |Yes(1)| No | No | | A+P | Yes | No | No | No | | Application Proxy | Yes |Yes(2)|Yes(2)| No | | Provider Wi-Fi | Yes | No | No | Yes | | PCC | Yes |Yes(1)| No | Yes | | Femtocells | Yes | No | No | No | | Cellular Networks | Yes |Yes(1)| No | Yes | | Overlay Networks | Yes |Yes(3)|Yes(3)| No | | Emergency Calls | Yes | Yes |Yes | No | | TDF | Yes | Yes | No | Yes | | FMC | Yes |Yes(1)| No | No | +-------------------+------+------+------------------------------+ > >> (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. [Med] Here is a solution that can be used for a use case described in the draft: http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-00#section-4.2. As you can see, there is no identifier revealed in actual IP packets issued by the connected host ;-) > >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
