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

[Chris Prince Udochukwu Njoku <[e-mail]>]

Hi, all,

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

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