Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

From: Suresh Krishnan <[email-masked]>
Date: Thu, 5 Jun 2014 04:20:56 +0000

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

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 11:44:34 +0000

Hi Suresh,

Thank you for initiating this call.

FWIW, the latest version is -05 not -04: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.

Unsurprisingly, I'm supportive to see this work adopted in intarea as a companion effort to RFC6269 and RFC6967.

Cheers,
Med

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,

Regards

Suresh & Juan Carlos

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 5 Jun 2014 12:06:52 +0000

I support adoption of this draft.

-Tiru

From: Int-area [mailto:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Thursday, June 05, 2014 9:51 AM
To: Internet Area
Subject: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

Hi all,

Regards

Suresh & Juan Carlos

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 12:11:16 +0000

WG,

I also support the adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea WG document.

Cheers,

Christian.

De : Int-area [mailto:[email-masked]] De la part de Tirumaleswar Reddy (tireddy)
Envoyé : jeudi 5 juin 2014 14:07
À : Suresh Krishnan; Internet Area
Objet : Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

-Tiru

Hi all,

Regards

Suresh & Juan Carlos

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Jun 2014 13:48:17 +0100

Hiya,

On 05/06/14 08:05, Hannes Tschofenig wrote:
> If you want to review a document with privacy implications then 
> have a look at the NAT reveal / host identifier work (with 
> draft-boucadair-intarea-host-identifier-scenarios-04 currently in
> a call for adoption).
> 
> I had raised my concerns several times now on the mailing list and 
> during the meetings.

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. For something like this, the onus ought
IMO be on the proposers to have done that work before asking for
adoption. Based on the draft, they clearly have not done that.

We could also ask to add more use-cases:

use-case#12: spy on everyone more easily, TEMPORA++
use-case#13: sell data that's even more fine-grained than clickstreams
use-case#14: expose your n/w internals to help on path attackers
use-case#15: track hosts from which people emit "dangerous" utterances
use-case#16: block hosts from which people emit "dangerous" utterances
use-case#17: charge me more for using two of my computers in my house

The set of use-cases presented very much contradicts the explicit
claim in the draft that no position is being taken as to the merits
of this. IMO that argues strongly to not adopt this.

One could also comment on the requirements that seem to
require new laws of physics or are otherwise pretty odd:

REQ#1: seems to require knowing from packets passing by that
a device is a "trusted device" (and REQ#15 says that can be
done with 16 bits;-) Hmm... are those qubits maybe?

REQ#5: *all* IP packets MUST have a HOST_ID... but presumably
without a flag day. Hmm...

REQ#6: says this is a transport thing. Eh, why ask INT-AREA?

REQ#10+REQ#11: MUST be intradomain only but MUST also be inter
domain. Hmm...

REQ#18: receiver MUST "enforce policies like QoS." Huh?

Such a frankly bogus list of "requirements" also means that
this is not something that ought be adopted in the IETF.

I also think that this proposal has previously been proposed
in other ways and not adopted. Such forum-shopping is yet
another reason to not adopt it, and certainly not as an
area wg thing without any broader IETF-wide consideration.
(As an aside: having to play whack-a-mole with such repeat
proposals is one of the downsides of area wgs. Not sure
if anything can be done about that though.)

In summary: ignoring BCP188, the selection-bias in use
cases, the badly thought out "requirements" and forum
shopping are all independently sufficient reasons to
not adopt this. And of course that doesn't include all
the other issues with potential solutions listed in
RFC6967 (the reference to which is oddly to the I-D and
not the RFC).

My conclusion: this one ought go to /dev/null same as the
previous attempts to shop the same thing into other parts
of the IETF.

S

> 
> Ciao Hannes
> 
> 
> -------- Original Message -------- Subject: 	[Int-area] Call for 
> adoption of draft-boucadair-intarea-host-identifier-scenarios-04 
> Date: 	Thu, 5 Jun 2014 04:20:56 +0000 From: 	Suresh Krishnan 
> <[email-masked]> To: 	Internet Area 
> <[email-masked]>
> 
> 
> 
> 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
> 
> 
> 
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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________ ietf-privacy 
> mailing list [email-masked] 
> https://www.ietf.org/mailman/listinfo/ietf-privacy
>

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 13:11:48 +0000

Hi Stephen,

You referred in your message to an old version. The latest version of the document does not include any requirement, it is only an inventory of use cases when problems are encountered. The latest version is available at: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.

Some of these use cases are restricted to a single administrative domain while others span multiple domain. Privacy concerns are really important; these are discussed in RFC6967.

The use cases are not theoretical ones, but are those where complications arise. Explicitly calling out security risks (including privacy ones) will benefit to this work. It is really helpful to understand the use cases and call out any potential risks rather than speculating without actual understanding of what the problem is.

This document is the opportunity to record security and privacy concerns that apply to these use cases. The content of the document is not frozen. Adopting it as a WG document will undoubtedly enrich it and benefit from other perspectives that those of the authors. 

Cheers,
Med

>-----Message d'origine-----
>De : ietf-privacy [mailto:[email-masked]] De la part de
>Stephen Farrell
>Envoyé : jeudi 5 juin 2014 14:48
>À : Hannes Tschofenig; [email-masked]
>Cc : [email-masked]; Zuniga, Juan Carlos
>Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>Hiya,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>
>iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX
>w+fFwSpCfi1LzZzxYR+ZgnL96ed8QPJ/YJEb4S1jZ0u2g1+DqMbSMsuQ6aW78+WM
>iHfyIqO8m7Ahkk1J++/5bK3N0fbqhMjWmqs1cCa7Gg/o9RScZQiMJQef8Iju5gVN
>3dnd/7riV9THntV7DQdwGC0SXp9Wfwn2i3oAqxYVpEixCxxGbQBRPIiXBcaLBP4s
>lr86tLPCPdXB2K4uPsuofVxL/uGBkahF6DAGjq3URcUEVi/J82XL+eB/3bLQU5XG
>2Mr0LMu7v4XQ+92zCjm7UmWmiL1fcQ+M0g+5nESSP8bO3sNlFlN33+jzsEGTBRM=
>=TF0g
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>ietf-privacy mailing list
>[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Jun 2014 14:24:12 +0100

Hi Med,

On 05/06/14 14:11, [email-masked] wrote:
> Hi Stephen,
> 
> You referred in your message to an old version. 

That was the one for which the adoption call was issued. I
guess just a typo.

I looked quickly at the diff between 04 and 05 and my
conclusion remains the same and most of my comment I think
still apply, despite the removal of the odd requirements
section.

S.

> The latest version of
> the document does not include any requirement, it is only an
> inventory of use cases when problems are encountered. The latest
> version is available at:
> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.
>
>  Some of these use cases are restricted to a single administrative
> domain while others span multiple domain. Privacy concerns are really
> important; these are discussed in RFC6967.
> 
> The use cases are not theoretical ones, but are those where
> complications arise. Explicitly calling out security risks (including
> privacy ones) will benefit to this work. It is really helpful to
> understand the use cases and call out any potential risks rather than
> speculating without actual understanding of what the problem is.
> 
> This document is the opportunity to record security and privacy
> concerns that apply to these use cases. The content of the document
> is not frozen. Adopting it as a WG document will undoubtedly enrich
> it and benefit from other perspectives that those of the authors.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : ietf-privacy
>> [mailto:[email-masked]] De la part de Stephen
>> Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
>> [email-masked] Cc : [email-masked]; Zuniga, Juan Carlos 
>>>> If you want to review a document with privacy implications
>>>> then have a look at the NAT reveal / host identifier work
>>>> (with draft-boucadair-intarea-host-identifier-scenarios-04
>>>> currently in a call for adoption).
>>>> 
>>>> I had raised my concerns several times now on the mailing list
>>>> and during the meetings.
> 
> use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell
> data that's even more fine-grained than clickstreams use-case#14:
> expose your n/w internals to help on path attackers use-case#15:
> track hosts from which people emit "dangerous" utterances 
> use-case#16: block hosts from which people emit "dangerous"
> utterances use-case#17: charge me more for using two of my computers
> in my house
> 
> One could also comment on the requirements that seem to require new
> laws of physics or are otherwise pretty odd:
> 
> REQ#1: seems to require knowing from packets passing by that a device
> is a "trusted device" (and REQ#15 says that can be done with 16
> bits;-) Hmm... are those qubits maybe?
> 
> REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without
> a flag day. Hmm...
> 
> Such a frankly bogus list of "requirements" also means that this is
> not something that ought be adopted in the IETF.
> 
> I also think that this proposal has previously been proposed in other
> ways and not adopted. Such forum-shopping is yet another reason to
> not adopt it, and certainly not as an area wg thing without any
> broader IETF-wide consideration. (As an aside: having to play
> whack-a-mole with such repeat proposals is one of the downsides of
> area wgs. Not sure if anything can be done about that though.)
> 
> In summary: ignoring BCP188, the selection-bias in use cases, the
> badly thought out "requirements" and forum shopping are all
> independently sufficient reasons to not adopt this. And of course
> that doesn't include all the other issues with potential solutions
> listed in RFC6967 (the reference to which is oddly to the I-D and not
> the RFC).
> 
> My conclusion: this one ought go to /dev/null same as the previous
> attempts to shop the same thing into other parts of the IETF.
> 
> S
> 
> 
>>>> 
>>>> Ciao Hannes
>>>> 
>>>> 
>>>> -------- Original Message -------- Subject: 	[Int-area] Call
>>>> for adoption of
>>>> draft-boucadair-intarea-host-identifier-scenarios-04 Date:
>>>> Thu, 5 Jun 2014 04:20:56 +0000 From: 	Suresh Krishnan 
>>>> 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-
>
>>>> 
scenarios-04
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>

---

From: <[email-masked]>
Date: Thu, 5 Jun 2014 13:40:57 +0000

Re-,

I have two comments:

(1) 

If one missed the following sentences in -04 "Below is listed as set of requirements to be used to characterize
   each use case (discussed in Section 3):" and "Once this list is stabilized, each use case will be checked against
   these requirements.", then the requirements list can be seen as odd. I agree the wording is not so that clear. The initial intent was to identify the ones from the list that apply for each use case. That effort was abandoned in -05 to focus on the description of the use cases where problems are encountered.

(2)

Privacy concerns are not ignored. A section is present in the draft to recall some privacy-related issues: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05#section-15. If there are other concerns not already covered, it will be relay helpful to explicit them. 

The document does not include any solution discussion but focuses only on the description of deployment use cases where problems are encountered. 

Cheers,
Med

>De : Stephen Farrell [mailto:[email-masked]]
>Envoyé : jeudi 5 juin 2014 15:24
>À : BOUCADAIR Mohamed IMT/OLN; Hannes Tschofenig; [email-masked]
>scenarios-05.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 05 Jun 2014 07:16:36 -0700

Hi Tiru,
>I support adoption of this draft.

May I ask why you support adoption of this draft?  Please note that I 
consider the question as a difficult one.

Regards,
S. Moonesamy

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Jun 2014 13:10:49 -0700

On 6/5/2014 5:48 AM, Stephen Farrell wrote:
> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jun 2014 08:28:40 +1200

Stephen,

> discussed, IETF consensus. 

I have to call you on that. WG adoption is not approval. It's agreement
to work on a topic. It is not OK to attempt a pocket veto on adoption
because you don't like the existing content.

> For something like this, the onus ought
> adoption. 

Why? Where do the rules say that?

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

> Based on the draft, they clearly have not done that.
> 
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
> .
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Jun 2014 16:42:26 -0400

Brian, in my experience working group adoption is more than the working 
group agreeing to work on the topic.  It is generally the working group 
agreeing that the given document is a good basis for starting the work. 
  Yes, there will almost always be need for improvement.  Sometimes 
major improvement.  But it is an agreement that this is a good starting 
point.

Without commenting on the specific document, leaving out that 
consideration in your response to Stephen makes the discussion MUCH harder.

Yours,
Joel

On 6/5/14, 4:28 PM, Brian E Carpenter wrote:
...
> because you don't like the existing content.
...

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Jun 2014 13:42:27 -0700

On 6/5/2014 1:28 PM, Brian E Carpenter wrote:
...
> call the misuse cases. That's a discussion the intarea WG could have.

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Jun 2014 17:26:37 -0400

> because you don't like the existing content.

WG adoption is a pretty heavy action.   It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC.   If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them.   So bringing up those flaws during the adoption process is crucial to the process.

It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work.

So needless to say I at least am watching keenly to see if Stephen's objections are being addressed, and likely won't approve the adoption of the work if they aren't.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Jun 2014 15:50:26 -0700

Ted said: 
"If there are problems with the document, part of the adoption process should be the identification of those flaws and an agreement to address them.   So bringing up those flaws during the adoption process is crucial to the process."
[BA] I would agree that there should be an agreement to address the flaws prior to adoption, but in my experience that is often not enough.  If the flaws are major enough, sometimes the fixes end up being non-trivial, or even turn into an argument about the feasibility of fixing them at all.   More than once I have seen this turn into a "war of attribution" between the editors and the WG, where the editors assert that because the WG adopted the document, they effectively endorsed the approach, and the WG asserting that they never would have adopted the document with the knowledge that the flaws would remain. 
To prevent this kind of argument down the line, if there is a major flaw in a document, I now believe it is best to insist that it be addressed  *prior* to adoption.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jun 2014 10:51:33 +1200

On 06/06/2014 08:42, Joel M. Halpern wrote:
>  Yes, there will almost always be need for improvement.  Sometimes major
> improvement.  But it is an agreement that this is a good starting point.
> 

Well, not harder than suggesting immediate /dev/null I think.

Also, there is history here (RFC6269 and RFC6967) so I think it's
clear that the topic is appropriate for the WG. There is a real
problem caused by NAT, compared with the theoretically normal
case where the host's globally unique address is visible to all.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jun 2014 10:58:24 +1200

> WG adoption is a pretty heavy action.   It states that the WG has consensus to work on the document, and weighs heavily in the consensus evaluation during WGLC.   If there are problems with the doc…

I have no problem with that.

> It's also worth noting that the INTAREA working group is a special working group, with an extremely broad charter, 

Indeed. So (speaking only for myself) I tend to ignore drafts aimed at
the WG until they are close to adoption, because my input bit rate
is limited.

   Brian

> which is moderated by the fact that in order for work to be done by the working group, the Internet Area ADs have to approve the work.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jun 2014 11:10:20 +1200

One more response and then I will shut up on this issue:

> To prevent this kind of argument down the line, if there is a major flaw in a document, I now believe it is best to insist that it be addressed  *prior* to adoption.  

That seems to me to be going one step further than the criteria
suggested in RFC7221 (only Informational, but recently approved by
the IESG) at http://tools.ietf.org/html/rfc7221#section-2.2
		 	   		
Specifically, it's a higher bar than the combination of
   *  Does the document provide an acceptable platform for continued
      effort by the working group?
and
   *  What are the process or technical objections to adoption of the
      draft?

If the draft is an acceptable base and the technical objections
are understood, there's no reason not to proceed. And to repeat,
I agree with the technical objections in this case, and with the
suggestion of how to fix them.

    Brian

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 08:11:37 +0000

Hi Ted,

As far as this document is concerned, we are open to address technical concerns. It will be helpful if these concerns are specific enough and hopefully in reference to http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.

Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3.  

Cheers,
Med

>De : Int-area [mailto:[email-masked]] De la part de Ted Lemon
>Envoyé : jeudi 5 juin 2014 23:27
>À : Brian E Carpenter
>Cc : [email-masked]; [email-masked]; Stephen Farrell
>Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
>
>WG adoption is a pretty heavy action.   It states that the WG has consensus
>to work on the document, and weighs heavily in the consensus evaluation
>during WGLC.   If there are problems with the document, part of the
>adoption process should be the identification of those flaws and an
>agreement to address them.   So bringing up those flaws during the adoption
>process is crucial to the process.
>
>It's also worth noting that the INTAREA working group is a special working
>group, with an extremely broad charter, which is moderated by the fact that
>in order for work to be done by the working group, the Internet Area ADs
>have to approve the work.
>
>So needless to say I at least am watching keenly to see if Stephen's
>objections are being addressed, and likely won't approve the adoption of
>the work if they aren't.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 6 Jun 2014 06:48:24 -0400

> Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3.  

The document hasn't been adopted yet, so we can avoid security issues simply by not adopting it.   Talking about what the security considerations section might do to ameliorate the harm isn't in scope yet.   First we need to decide whether there is more harm than good done by adopting and publishing the document!

---

From: <[email-masked]>
Date: Fri, 6 Jun 2014 11:41:26 +0000

Re-,

Please see inline.

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : vendredi 6 juin 2014 12:48
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : Brian E Carpenter; [email-masked]; [email-masked]; Stephen
>Farrell
>> Adding a discussion on potential misuses can be considered to address the
>comment from Stephen if those are not redundant with the text already in
>http://tools.ietf.org/html/rfc6967#section-3.
>
>The document hasn't been adopted yet, so we can avoid security issues
>simply by not adopting it.

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

   Talking about what the security considerations
>section might do to ameliorate the harm isn't in scope yet.   First we need
>to decide whether there is more harm than good done by adopting and
>publishing the document!

[Med] Fair enough.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Jun 2014 16:22:18 +0100

I think Ted answered this but one little bit more...

>> Why? Where do the rules say that?

Just to clarify: I don't think we have rules that say that,
nor do I have any kind of veto, I was just expressing my
opinion, for this case.

S

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Jun 2014 16:59:26 +0100

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.

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

---

From: "Horne, Rob" <[email-masked]>
Date: Fri, 6 Jun 2014 16:09:08 +0000

I agree too and think Joe's outlined a good starting point to discuss "misuse".

Rob

-----Original Message-----
From: ietf-privacy [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: 05 June 2014 21:42
To: Brian E Carpenter; Stephen Farrell
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers

> 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

---

From: Dan Wing <[email-masked]>
Date: Fri, 6 Jun 2014 18:38:25 -0700

On Jun 5, 2014, at 1:10 PM, Joe Touch <[email-masked]> wrote:

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

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.

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.

-d

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 07 Jun 2014 14:20:31 +0100

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

Adding new identifiers with privacy impact, as proposed here, is
quite different.

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.

---

From: Joe Touch <[email-masked]>
Date: Sun, 8 Jun 2014 17:26:13 -0700

> NATs have both good and bad properties. The slightly better privacy

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

---

From: Xueli <[email-masked]>
Date: Mon, 9 Jun 2014 02:39:42 +0000

Hi all

I support the adoption of draft-boucadair-intarea-host-identifier-scenarios-05 as an intarea WG document.

Regards
Li as co-author

From: Int-area [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, June 05, 2014 7:45 PM
To: Suresh Krishnan; Internet Area
Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

Hi Suresh,

Cheers,
Med

Hi all,

Regards

Suresh & Juan Carlos

---

From: Brandon Williams <[email-masked]>
Date: Mon, 09 Jun 2014 09:46:59 -0400

Hi Stephen,

 > Adding new identifiers with privacy impact, as proposed here, is

It is not the intention of the authors for this to be a solution draft. 
The draft is intended to describe address sharing use cases and 
deployment scenarios.

Would you please indicate where the draft proposes a new identifier? If 
you are seeing a proposal for protocol changes somewhere in the draft, 
editing work is required in order to either clarify or excise the 
associated text.

Thanks,
--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jun 2014 15:01:14 +0100

> editing work is required in order to either clarify or excise the

Fair enough that its an assumption of mine that adding some kind of
identifier is required to meet the (no-longer mis-stated:-)
requirements for these use-cases. But I think that is logically
required, and its valid to draw obvious conclusions and its also
invalid to ignore obvious conclusions.

S.

---

From: Brandon Williams <[email-masked]>
Date: Mon, 09 Jun 2014 10:36:04 -0400

I agree that the discussions in this draft and rfc6269 at least imply 
that potential solutions would provide a host identifier of some sort. 
However, this draft does not in fact propose any such solution, and 
instead clearly references rfc6967, which includes a discussion of the 
privacy implications of host identification. In particular, that 
document states:

    HOST_ID specification document(s) should explain the privacy impact
    of the solutions they specify, including the extent of HOST_ID
    uniqueness and persistence, assumptions made about the lifetime of
    the HOST_ID, whether and how the HOST_ID can be obfuscated or
    recycled, whether location information can be exposed, and the impact
    of the use of the HOST_ID on device or implementation fingerprinting.
    [IAB-PRIVACY] provides further guidance.

Considering the fact that there is already a separate solution analysis 
rfc that discusses privacy considerations and provides the above 
guidance for authors of solution drafts, what are you suggesting for the 
use cases draft?

Thanks,
--Brandon

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Jun 2014 15:40:40 +0100

Hiya,

On 09/06/14 15:36, Brandon Williams wrote:
> what are you suggesting for the use cases draft?

I thought I was clear. My suggestion is to not adopt it.

S.

---

From: David Singer <[email-masked]>
Date: Mon, 09 Jun 2014 09:34:51 -0400

> 	a NAT hides the host *at the expense* of exposing a router

If I have the energy to do a DoS attack, surely I have the energy to traceroute the hosts I know to find a common routing point?

David Singer
Manager, Software Standards, Apple Inc.

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jun 2014 08:30:32 -0700

On 6/9/2014 6:34 AM, David Singer wrote:
> If I have the energy to do a DoS attack, surely I have the energy to
> traceroute the hosts I know to find a common routing point?

1) ICMPs are often blocked - either at network boundaries or inside 
routers themselves

2) an ICMP tells you only how your packets get to the destination; it 
says nothing about how other traffic gets there or the return path

A NAT address tells you both directions and *cannot* be hidden except by 
another NAT along the same path.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jun 2014 18:32:21 +0200

Hi Stephen,

> Adding new identifiers with privacy impact, as proposed here, is

This came up today in a discussion around spam and cybersecurity with at
least one major service provider who has some pretty sophisticated
cbyersecurity systems.  Someone mentioned CGN and how entire groups of
customers are blocked when a single IP address goes bad.  We even
experienced this on the IAB, by the way, when its MSP got blocked by an
anti-spam site due to presumably someone else misusing them.  Our
architecture isn't really set up for IP address sharing or hiding.  If
your source address is naughty, the only back pressure I have at my
disposal is to block it.  If enough in an address range are bad, I might
block a range, even if that means some small amount of good mail being
blocked.  Go to a lousy SP and this is what it gets you.

But does adding a header solve the problem?  Not unless it is signed AND
I believe the signature.  And then I had better be willing to spend the
processing time to sort out your good customers from your bad
customers.  I *might* do that if you're at a very big mail service
provider, in which case I probably get very little spam, anyway.  I
probably won't do that if you're Joe's small time ISP, unless there is
some scaling feature not yet deployed today.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jun 2014 12:43:47 -0400

On Jun 9, 2014, at 12:32 PM, Eliot Lear <[email-masked]> wrote:
> But does adding a header solve the problem?  Not unless it is signed AND I believe the signature.  And then I had better be willing to spend the processing time to sort out your good customers from your bad customers.  I might do that if you're at a very big mail service provider, in which case I probably get very little spam, anyway.  I probably won't do that if you're Joe's small time ISP, unless there is some scaling feature not yet deployed today.

Bingo.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 09 Jun 2014 10:16:19 -0700

>> editing work is required in order to either clarify or excise the

There are 6 citations of

http://tools.ietf.org/html/rfc6967

the document doesn't exist in a vacuum where somehow how to do it has
fallen off the table.

given the repeated asertion that this work is useful because of external
requests (etsi) and that request is in fact tied closely to a particular
method it is relatively strait forward to conflate the discussion of
scenarios and methods.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2014 08:10:49 +1200

>> But does adding a header solve the problem?  Not unless it is signed AND I believe the signature.  And then I had better be willing to spend the processing time to sort out your good customers fro…

So, there are some more components of the threat analysis and the solution
requirements. That's good, but I thought we were discussing whether
to document the use cases.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jun 2014 22:19:51 +0200

Just to be clear: that was SMTP.  The calculus can be different for
other protocols, depending on their end to end nature.  SMTP is very hop
by hop and it is very difficult to secure an entire path with confidence
due to downgrade attack threats.  https would be a horse of a different
color.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Jun 2014 17:47:05 -0400

On Jun 9, 2014, at 4:10 PM, Brian E Carpenter <[email-masked]> wrote:
> I thought we were discussing whether

Is there some value in documenting the use cases?   Do people have plans?

---

From: <[email-masked]>
Date: Tue, 10 Jun 2014 12:30:46 +0200

Dear all,
I would like to confirm this: As already pointed out by Bruno in http://www.ietf.org/mail-archive/web/int-area/current/msg03904.html there is the emergency call use case at ETSI and beside that there are application proposals within WGs SFC, TCPM, etc. beside other drafts which refer to RFC 6967.

And although I might repeat again what has been stated many times: Intended goal is and should be to find a solution to fulfil dedicated and real use cases demands - respecting privacy, reducing vulnerability, strengthening protection against misuse as mentioned in BCP188, and so on ...

Best regards
Dirk 

-----Original Message-----
From: Int-area [mailto:[email-masked]] On Behalf Of joel jaeggli
Sent: Montag, 9. Juni 2014 19:16
To: Stephen Farrell; Brandon Williams; Dan Wing
Cc: [email-masked]; Internet Area
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On 6/9/14, 7:01 AM, Stephen Farrell wrote:
>> Would you please indicate where the draft proposes a new identifier? 
>> If you are seeing a proposal for protocol changes somewhere in the 
>> draft, editing work is required in order to either clarify or excise 
>> the associated text.

There are 6 citations of

the document doesn't exist in a vacuum where somehow how to do it has fallen off the table.

given the repeated asertion that this work is useful because of external requests (etsi) and that request is in fact tied closely to a particular method it is relatively strait forward to conflate the discussion of scenarios and methods.

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 14:31:38 +0000

Hi Stephen,

Please see inline.

Cheers,
Med

>Envoyé : vendredi 6 juin 2014 17:59
>À : BOUCADAIR Mohamed IMT/OLN; Ted Lemon
>Cc : Brian E Carpenter; [email-masked]; [email-masked]

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

>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

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 14:38:16 +0000

Re-,

Please see inline.

Cheers,
Med

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

[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

[Med] I have already clarified this point: the scenario draft does not propose any identifier!

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Jun 2014 07:54:12 -0700

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jun 2014 16:09:19 +0100

> or MUST- level requirements in that doc. Let's please not wave it in the

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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Jun 2014 16:18:22 +0100

Hiya,

On 11/06/14 15:38, [email-masked] wrote:
>> 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,
>> 
>>> 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.
>> 
>> NATs have both good and bad properties. The slightly better
>> privacy is one of the good ones.
>> 
>> 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.

> Privacy implications should be assess on a per
> use case basis 

Where do I find the per-use-case analysis of privacy implications?

> (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."
> 
>> 

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.

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

---

From: <[email-masked]>
Date: Wed, 11 Jun 2014 15:26:39 +0000

Re-,

Please see inline.

Cheers,
Med

>Envoyé : mercredi 11 juin 2014 17:18
>À : BOUCADAIR Mohamed IMT/OLN; Dan Wing

[Med] OK.

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

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Jun 2014 09:14:59 -0700

> 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

---

From: Brandon Williams <[email-masked]>
Date: Wed, 11 Jun 2014 13:04:10 -0400

I agree entirely that defining host identification as a problem 
indicates that the authors believe a solution is called for. I also 
agree that the privacy impact of solution candidates must be discussed, 
including making a concerted effort to mitigate the possibility of those 
solution candidates being used for pervasive monitoring purposes. My 
point is simply that this draft is not intended to propose solutions or 
discuss solution candidates.

RFC6967, which as you note is repeatedly cited, discusses solution 
candidates and lays out a framework for privacy discussion related to 
solution proposals. Future RFCs that actually propose solutions are 
already expected to follow the guidance from RFC6967, and the references 
to that RFC in this draft are meant to point to RFC6967 as the 
authoritative guidance.

Is there some reason why you do not consider it adequate for this "use 
cases" draft to reference the existing and already published "potential 
solutions analysis" rfc? What specific content related to privacy and/or 
pervasive monitoring belongs in this draft that is not already present 
in RFC6967?

Thanks,
--Brandon