Subject: Re: [Int-area] Call for adoption of draft...

From: Chris Prince Udochukwu Njoku <[email-masked]>
Date: Thu, 12 Jun 2014 10:23:58 +0200

Hi, all,

Agreeing to Dirk's observations, I also submit that the draft be adopted.
On Jun 11, 2014 4:09 PM, <[email-masked]> wrote:

> Send Int-area mailing list submissions to
>         [email-masked]
>
> 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-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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-masked])
>    2. Re: Call for adoption of
>       draft-boucadair-intarea-host-identifier-scenarios-04
>       ([email-masked])
>    3. Re: [ietf-privacy] NAT Reveal / Host Identifiers
>       ([email-masked])
>    4. Re: [ietf-privacy]   NAT Reveal / Host Identifiers
>       ([email-masked])
>    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-masked]>
> To: <[email-masked]>
> Subject: Re: [Int-area] Call for adoption of
>         draft-boucadair-intarea-host-identifier-scenarios-04
> Message-ID:
>         <
> [email-masked]
> >
>
> 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-masked]] 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-masked]>
> To: S Moonesamy <[email-masked]>, "Tirumaleswar Reddy (tireddy)"
>         <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: [Int-area] Call for adoption of
>         draft-boucadair-intarea-host-identifier-scenarios-04
> Message-ID:
>
> <[email-masked]
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi SM,
>
> Please see inline.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De?: S Moonesamy [mailto:[email-masked]]
> >Envoy??: vendredi 6 juin 2014 14:56
> >??: BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
> >[email-masked]
> >Objet?: RE: [Int-area] Call for adoption of draft-boucadair-intarea-host-
> >identifier-scenarios-04
> >
> >Hi Med,
> >At 00:59 06-06-2014, [email-masked] 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-masked]>
> To: Stephen Farrell <[email-masked]>, Ted Lemon
>         <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>,
>         "[email-masked]" <[email-masked]>
> Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
> Message-ID:
>
> <[email-masked]
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Stephen,
>
> Please see inline.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De?: Stephen Farrell [mailto:[email-masked]]
> >Envoy??: vendredi 6 juin 2014 17:59
> >??: BOUCADAIR Mohamed IMT/OLN; Ted Lemon
> >Cc?: Brian E Carpenter; [email-masked]; [email-masked]
> >Objet?: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
> >
> >
> >Hi Med,
> >
> >On 06/06/14 12:41, [email-masked] 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-masked]>
> To: Stephen Farrell <[email-masked]>, Dan Wing
>         <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Internet Area
>         <[email-masked]>
> Subject: Re: [Int-area] [ietf-privacy]   NAT Reveal / Host Identifiers
> Message-ID:
>
> <[email-masked]
> >
>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
> >-----Message d'origine-----
> >De?: ietf-privacy [mailto:[email-masked]] De la part de
> >Stephen Farrell
> >Envoy??: samedi 7 juin 2014 15:21
> >??: Dan Wing
> >Cc?: [email-masked]; 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-masked]
> >https://www.ietf.org/mailman/listinfo/ietf-privacy
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 11 Jun 2014 07:54:12 -0700
> From: Joe Touch <[email-masked]>
> To: Stephen Farrell <[email-masked]>, Dan Wing
>         <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Internet Area
>         <[email-masked]>
> Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
> Message-ID: <[email-masked]>
> 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-masked]>
> To: Joe Touch <[email-masked]>, Dan Wing <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Internet Area
>         <[email-masked]>
> Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
> Message-ID: <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> ------------------------------
>
> End of Int-area Digest, Vol 107, Issue 12
> *****************************************
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 11:21:02 -0400

> Agreeing to Dirk's observations, I also submit that the draft be adopted.

FWIW, messages of this sort in a consensus call have no value to the chairs or to the AD.   If you think it should be supported, please explain why, or what you say won't make any difference.   E.g., "I want this because it will help me in the following way" would be helpful.   If you just want to express solidarity, that is of course perfectly fine! :)