Hi, all, Agreeing to Dirk's observations, I also submit that the draft be adopted. On Jun 11, 2014 4:09 PM, <[email protected]> wrote:
> Send Int-area mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/int-area > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Int-area digest..." > > > Today's Topics: > > 1. Re: Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > ([email protected]) > 2. Re: Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > ([email protected]) > 3. Re: [ietf-privacy] NAT Reveal / Host Identifiers > ([email protected]) > 4. Re: [ietf-privacy] NAT Reveal / Host Identifiers > ([email protected]) > 5. Re: [ietf-privacy] NAT Reveal / Host Identifiers (Joe Touch) > 6. Re: [ietf-privacy] NAT Reveal / Host Identifiers (Stephen Farrell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 11 Jun 2014 14:20:52 +0200 > From: <[email protected]> > To: <[email protected]> > Subject: Re: [Int-area] Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > Message-ID: > < > 05c81a773e48dd49b181b04ba21a342a2e00822...@he113484.emea1.cds.t-internal.com > > > > Content-Type: text/plain; charset="utf-8" > > Dear all, > Considering the current discussion on pros and cons I think the topic of > NAT reveal and Host_Id in terms of problem statements and requirements > towards a solution space indeed needs to be assessed in further detail - > especially since there are actual use cases in heterogeneous access and > transport domains such as policy assignment, emergency calls, function > chaining, content streaming etc. pp. > > Since IntArea WG IMO seems to be a proper discussion arena I am in favor > of adopting the draft. > > Best regards > Dirk > > > De : Int-area [mailto:[email protected]] De la part de Suresh > > Krishnan Envoy? : jeudi 5 juin 2014 06:21 ? : Internet Area Objet : > > [Int-area] Call for adoption of > > draft-boucadair-intarea-host-identifier-scenarios-04 > > > > 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-sce > > narios-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 > > > ------------------------------ > > Message: 2 > Date: Wed, 11 Jun 2014 14:24:06 +0000 > From: <[email protected]> > To: S Moonesamy <[email protected]>, "Tirumaleswar Reddy (tireddy)" > <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: [Int-area] Call for adoption of > draft-boucadair-intarea-host-identifier-scenarios-04 > Message-ID: > > <787AE7BB302AE849A7480A190F8B9330016053@OPEXCLILM23.corporate.adroot.infra.ftgroup > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi SM, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De?: S Moonesamy [mailto:[email protected]] > >Envoy??: vendredi 6 juin 2014 14:56 > >??: BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int- > >[email protected] > >Objet?: RE: [Int-area] Call for adoption of draft-boucadair-intarea-host- > >identifier-scenarios-04 > > > >Hi Med, > >At 00:59 06-06-2014, [email protected] wrote: > >>[Med] FWIW, the scenarios draft is not a "HOST_ID specification > document". > > > >[snip] > > > >>[Med] Having a dedicated section for privacy is a signal that we > >>have those issues on our radar. Our analysis at this stage is that > >>RFC6967 includes a decent discussion that is still valid for this > >>use cases document. If you think that additional concerns are to be > >>discussed, please don't hesitate to share them. We will consider > >>updating the document accordingly. > > > >[snip] > > > >>[Med] There is no mention of "HOST_ID" in this draft. Furthermore, > >>the current text says the following: > >>" The document does not elaborate whether explicit authentication is > >> enabled or not." > >> > >>Solution-specific discussions are out of scope. The main mission of > >>the document is to help identifying use cases where there are > >>difficulties to enforce per-host policies due to the presence of > >>address sharing or the use of tunnels. > > > >[snip] > > > >>[Med] Documenting misuses should be definitely in scope. > >>Contributions are more than welcome. > > > > From the above (quoted text) I understand that there are > >difficulties to enforce policies and those difficulties have not be > >discussed or addressed in IETF RFCs. > > [Med] Yes. > > The INTAREA working group > >previously worked on a RFC about potential solutions for revealing a > >host identifier. Are the potential solutions discussed in RFC 6967 > >inadequate? > > [Med] The effort in RFC6967 does not ambition to pick a solution but to > conduct an analysis effort with a focus on the CGN case. That case is only > one among others defined in the scenario draft. Identify and document the > use cases is a first step to actually understand the problem we are talking > about. This is a contribution to clarify the big picture of this problem > space. > > I don't think the question is out of scope given that > >the draft references RFC 6967. > > [Med] Privacy is not out of scope as I mentioned in a previous message. > Nevertheless, privacy implications may depend on the targeted use case. The > considerations in RFC6967 can be completed with new ones if any. > > > > >If the mission is to identify use cases, why are discussions about > >the use cases (see Section 2) out of scope? > > [Med] What we declared out of scope is solution-oriented aspects. We > wanted to have a very focused document. > > > > >The lack of host identification does not affect host > >connectivity. This scenarios draft makes the case for the lack of > >host identification being the cause of problems. > > [Med] The draft focuses only on scenarios where complications arise. The > problem may be abstracted from other perspective but the host > identification is a valid angle IMHO. > > Do the problems > >affect the internet or are they limited cases? > > [Med] Implication on connectivity depends on the use cases. For example, a > service that black list a full IP address or rate limit based on the > source IP address will impact a lot of customers; access to services won't > be granted. > > > > >Regards, > >S. Moonesamy > > > > ------------------------------ > > Message: 3 > Date: Wed, 11 Jun 2014 14:31:38 +0000 > From: <[email protected]> > To: Stephen Farrell <[email protected]>, Ted Lemon > <[email protected]> > Cc: "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: > > <787AE7BB302AE849A7480A190F8B933001605D@OPEXCLILM23.corporate.adroot.infra.ftgroup > > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Stephen, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De?: Stephen Farrell [mailto:[email protected]] > >Envoy??: vendredi 6 juin 2014 17:59 > >??: BOUCADAIR Mohamed IMT/OLN; Ted Lemon > >Cc?: Brian E Carpenter; [email protected]; [email protected] > >Objet?: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > > > > > >Hi Med, > > > >On 06/06/14 12:41, [email protected] 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. > > > > ------------------------------ > > Message: 4 > Date: Wed, 11 Jun 2014 14:38:16 +0000 > From: <[email protected]> > To: Stephen Farrell <[email protected]>, Dan Wing > <[email protected]> > Cc: "[email protected]" <[email protected]>, Internet Area > <[email protected]> > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: > > <787AE7BB302AE849A7480A190F8B9330016077@OPEXCLILM23.corporate.adroot.infra.ftgroup > > > > Content-Type: text/plain; charset="iso-8859-1" > > Re-, > > Please see inline. > > Cheers, > Med > > >-----Message d'origine----- > >De?: ietf-privacy [mailto:[email protected]] De la part de > >Stephen Farrell > >Envoy??: samedi 7 juin 2014 15:21 > >??: Dan Wing > >Cc?: [email protected]; 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 > >[email protected] > >https://www.ietf.org/mailman/listinfo/ietf-privacy > > > > ------------------------------ > > Message: 5 > Date: Wed, 11 Jun 2014 07:54:12 -0700 > From: Joe Touch <[email protected]> > To: Stephen Farrell <[email protected]>, Dan Wing > <[email protected]> > Cc: "[email protected]" <[email protected]>, Internet Area > <[email protected]> > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > 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 > > > > ------------------------------ > > Message: 6 > Date: Wed, 11 Jun 2014 16:09:19 +0100 > From: Stephen Farrell <[email protected]> > To: Joe Touch <[email protected]>, Dan Wing <[email protected]> > Cc: "[email protected]" <[email protected]>, Internet Area > <[email protected]> > Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > > > 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 > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area > > > ------------------------------ > > End of Int-area Digest, Vol 107, Issue 12 > ***************************************** >
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
