Subject: [hiaps] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

From: joel jaeggli <[email-masked]>
Date: Thu, 06 Mar 2014 16:28:13 +0000

Greetings int-area and hiaps-mailing-list folks,

I realize that this is midweek at the IETF, however this question is not
far from several discussions I've had this week.

I have been asked to consider AD sponsoring
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

In the process of  considering doing so I'd like to get some input with
respect to:

A. The appetite for pursuing some or any of this work in existing
working groups, and in particular within the INT area.

B. A consensus basis for moving beyond RFC 6269 into active work in this
area.

C. How we address concerns raised by the IETF community expressed
through  draft-farrell-perpass-attack when evaluating scenarios and
beginning to address requirements and solution-space.

Obviously these are complex questions and I do not expect that we will
arrive at answers easily nor does work on this or other drafts depend on
answering them, however it's part of the dialog.

Thanks
joel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2014 07:03:26 +1300

a) Since this is fixing some of the damage done by NAT, it's
really unfinished business for BEHAVE, which if iirc was a
Transport Area WG. Just saying...

b) The word "privacy" doesn't appear in the draft. Discussing
privacy aspects is clearly essential if there is any thought of
advancing this work. Actually I doubt if such a host ID is ever
going to be acceptable from a privacy point of view, unless the
end system is at liberty to change it at random (like RFC 4941).

c) A hard-nosed argument is that since we want to sunset IPv4,
it's time to stop working on ways of making NAT solutions work
better. Is there anything in the use cases that can't be fixed by
native IPv6?

(The use case in expired draft
http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01
is not at all convincing to me, especially when adding the privacy
argument. It actually seems to describe a bug in 3GPP. But in any case,
the draft appears to suggest mitigations.)

Regards
   Brian

On 07/03/2014 05:28, joel jaeggli wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2014 18:13:18 +0000

It also seems doubtful that this would be useful outside the carrier network, since service providers would have to implement it and middleboxes would have to support it, neither of which is something we can depend on.   Inside of the carrier network, solutions like A+P at the very least are quite easy to track algorithmically, so this solution is overkill.

And of course I agree with all the points you made, Brian.

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Mar 2014 11:34:24 -0800

> working groups, and in particular within the INT area.

Given that draft-ietf-intarea-nat-reveal-analysis is in INT, and this 
document expands on that, I think this belongs in INT.

> B. A consensus basis for moving beyond RFC 6269 into active work in this

See my response to (A). INT is already active in that area.

> beginning to address requirements and solution-space.

That should definitely be addressed in this doc.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 Mar 2014 11:37:02 -0800

Brian,

Although I don't disagree with the points below, it's useful to consider 
that INT is already working in this area, so I don't see either (a) or 
(c) as being relevant unless you expect to shift current INT docs to 
other WGs too.

(b) just warrants an update. I disagree that privacy concerns will 
negate the benefits, though - a HOST ID might also be used to defeat or 
deny other claimed identifiers.

Joe

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Mar 2014 03:30:26 -0600

Hi Joe,

On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch <[email-masked]> wrote:

> that INT is already working in this area, so I don't see either (a) or (c)
> as being relevant unless you expect to shift current INT docs to other WGs
> too.
>
>
Respectfully disagree.
There has been some time passed since then and many thing happened such as
hiaps and a solution draft submission to tcpm.

Use case draft contains many more use cases than was discussed before.
Different use cases may require different solutions at different levels.
I think it is the mystery of this century to find out where this works
belongs :-).

> (b) just warrants an update. I disagree that privacy concerns will negate
> the benefits, though - a HOST ID might also be used to defeat or deny other
> claimed identifiers.
>
> We identified many places for a revision in this document in an informal
hiaps Bar BoF this week, the resulting document could become a completely
different draft.

Regards,

Behcet

---

From: joel jaeggli <[email-masked]>
Date: Fri, 07 Mar 2014 09:41:35 +0000

> hiaps and a solution draft submission to tcpm.

hiaps is not a chartered activity in the IETF. it is a mailing list, not
a working group.

---

From: Scott Brim <[email-masked]>
Date: Fri, 7 Mar 2014 09:41:59 +0000

> beginning to address requirements and solution-space.

http://tools.ietf.org/html/rfc6967#section-3 says that a host-id will
be generated anew any time the endpoint IP address changes. In fact it
seems that if the host can regenerate at will, the host-id will change
at least that often.  Therefore I don't believe this introduces any
new privacy issues.

By the way, it's nice to see that the session layer has a home in the
Internet Area.

swb

---

From: Joe Touch <[email-masked]>
Date: Fri, 07 Mar 2014 10:57:33 -0800

On 3/7/2014 1:30 AM, Behcet Sarikaya wrote:
> Hi Joe,
>
>
>
> On Thu, Mar 6, 2014 at 1:37 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Brian,
>
>     Although I don't disagree with the points below, it's useful to
>     consider that INT is already working in this area, so I don't see
>     either (a) or (c) as being relevant unless you expect to shift
>     current INT docs to other WGs too.
>
>
> Respectfully disagree.
> There has been some time passed since then and many thing happened such
> as hiaps and a solution draft submission to tcpm.

IMO:

TCMP - TCP *minor* mods.

TSVWG - TCP major mods or mods that affect multiple transports (IMO this 
should).

INT - endpoint IDs, except specific solutions like HIP and mobility

BEHAVE - changes local to how NATs work

> I think it is the mystery of this century to find out where this works

If it is then IMO you need to consider splitting it into separate docs.

Joe

---

From: Dan Wing <[email-masked]>
Date: Fri, 7 Mar 2014 20:31:22 +0000

> end system is at liberty to change it at random (like RFC 4941).

I interpret your statement to mean that address sharing is a desirable security property.  If that interpretation is correct, where does that leave IPv6?

> better. Is there anything in the use cases that can't be fixed by

Yes, attackers won't move to IPv6 if IPv4 provides them a superior way to hide their activities.  There are attackers already using IPv4 CGN to obfuscate themselves.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Mar 2014 20:03:34 +1300

Dan,

> I interpret your statement to mean that address sharing is a desirable security property.  If that interpretation is correct, where does that leave IPv6?

I'm not sure where you found that in what I wrote. I think that address
sharing is undesirable from every point of view; I suppose it
might reduce the risk of layer 3 based tracking of users,
but that's certainly not what I meant. IPv6 with RFC 4941 (which
appears to be deployed in the vast majority of IPv6 clients today)
is fine from this point of view. I don't see any difference in
privacy effect between a randomly-changing shared-IPv4 Host ID and
a randomly-changing IPv6 address.

> Yes, attackers won't move to IPv6 if IPv4 provides them a superior way to hide their activities.  There are attackers already using IPv4 CGN to obfuscate themselves.

Attackers will move to IPv6 when their targets do so. I guess
such attackers will find RFC 4941 useful too. What's good for
the privacy of legitimate users is also good for the privacy
of attackers.

   Brian

> .

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 7 Mar 2014 21:46:51 +0000

There are several paid VPN services that provide anonymity through
addresses sharing. This is becoming more and more popular these days.

It is public to public translation where you get a shared IP address on
purpose. This is not for attack purposes but just to reduce tracking by
third-parties. 

I would think that people interested in these services will continue to
use them but public IPv6 to public IPv6.

On 3/7/14, 12:31 PM, "Dan Wing (dwing)" <[email-masked]> wrote:

>I interpret your statement to mean that address sharing is a desirable
>security property.  If that interpretation is correct, where does that
>leave IPv6?
>
>
>Yes, attackers won't move to IPv6 if IPv4 provides them a superior way to
>hide their activities.  There are attackers already using IPv4 CGN to
>obfuscate themselves.
>
>-d
>
>
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Mar 2014 11:04:51 -0500

> BEHAVE - changes local to how NATs work
Or a different group?

> If it is then IMO you need to consider splitting it into separate docs.
Well, this could be one option.
I think right now, requirements should be split into a separate doc.
For the use cases, we need to do solution analysis work.
Without such work it is difficult to establish that we need different
solutions for different use cases.

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Mar 2014 11:34:21 -0500

Hi Brian,

> end system is at liberty to change it at random (like RFC 4941).
Scott Brim said there are no privacy issues.

> better. Is there anything in the use cases that can't be fixed by
Brandon could better address this, I think.

> the draft appears to suggest mitigations.)
It is kind of a bug in 3GPP, but remember that 3GPP makes protocols for
their own hosts called UEs. While here we are talking about fixed hosts.
This is what is called fixed mobile convergence, or policy for convergence,
to add more acronyms to the discussion.

Regarding privacy, in this use case, the communication is one hop and the
edge router already knows about the host, it is connected.
So the privacy property is not the same in this use case.

Regards,

Behcet

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Mar 2014 12:56:43 -0400

On Mon, Mar 10, 2014 at 12:34 PM, Behcet Sarikaya
<[email-masked]> wrote:
> Hi Brian,
>
> On Thu, Mar 6, 2014 at 12:03 PM, Brian E Carpenter
> <[email-masked]> wrote:
>>

I said I don't believe this introduces any NEW privacy issues, as long
as host-ids change at least as often as IP addresses. I hope you will
get other opinions. I just might be wrong, eh?

Scott

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Mar 2014 10:04:20 -0700

> get other opinions. I just might be wrong, eh?

Host-IDs might change a lot less often - to retain a persistent ID 
across such changes - or more often.

I don't think we can or should assume either one. We might assume that 
it should be under app-layer control, at which point the ball's in the 
user's court as to how to manage their own privacy.

That's worth pointing out, but AFAICT unless there's active user 
management to the contrary it can't be worse than an IP address wuold 
have been (but it might defeat a network edge from trying to protect 
internal users/services).

Joe

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Mar 2014 13:16:30 -0400

Joe, http:// <http://tools.ietf.org/html/rfc6967#section-3>tools.ietf.org<http://tools.ietf.org/html/rfc6967#section-3>
/ <http://tools.ietf.org/html/rfc6967#section-3>html<http://tools.ietf.org/html/rfc6967#section-3>
/rfc6967#section-3 <http://tools.ietf.org/html/rfc6967#section-3> says that
a host-id will be generated anew any time the endpoint IP address changes,
perhaps more often.

Is that wrong? It's hard to do a privacy audit if the behavior isn't agreed
on.
On Mar 10, 2014 1:05 PM, "Joe Touch" <[email-masked]> wrote:

> Host-IDs might change a lot less often - to retain a persistent ID across
> such changes - or more often.
>
> I don't think we can or should assume either one. We might assume that it
> should be under app-layer control, at which point the ball's in the user's
> court as to how to manage their own privacy.
>
> management to the contrary it can't be worse than an IP address wuold have
> been (but it might defeat a network edge from trying to protect internal
> users/services).
>
> Joe
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Mar 2014 10:44:25 -0700

On 3/10/2014 10:16 AM, Scott Brim wrote:
> Joe, http://
> <http://tools.ietf.org/html/rfc6967#section-3>tools.ietf.org
> <http://tools.ietf.org/html/rfc6967#section-3>/
> <http://tools.ietf.org/html/rfc6967#section-3>html
> <http://tools.ietf.org/html/rfc6967#section-3>/rfc6967#section-3
> <http://tools.ietf.org/html/rfc6967#section-3> says that a host-id will
> be generated anew any time the endpoint IP address changes, perhaps more
> often.

I believe you're referring to:

    "... a distinct HOST_ID may be used by the address-
    sharing function when the host reboots or gets a new internal IP
    address."

That's not a requirement; it's an example. This doc is a survey; no one 
rule applies everywhere.

> Is that wrong? It's hard to do a privacy audit if the behavior isn't
> agreed on.

Again, it's a survey. An audit would apply to a given approach.

Joe

---

From: <[email-masked]>
Date: Tue, 11 Mar 2014 16:50:09 +0100

Hi Brian,

Please see inline. 

Cheers,
Med

>-----Message d'origine-----
>De : Int-area [mailto:[email-masked]] De la part de Brian E
>Carpenter
>Envoyé : jeudi 6 mars 2014 19:03
>À : joel jaeggli
>Cc : [email-masked]; Internet Area; draft-boucadair-intarea-host-
>[email-masked]
>Objet : Re: [Int-area] request to consider sponsoring

[Med] It is not only about NAT but address sharing in general (including A+P and proxies). Issues are also encountered when tunnels are in use.

>end system is at liberty to change it at random (like RFC 4941).

[Med] A pointer to http://tools.ietf.org/html/rfc6967#section-3 can be added to the draft. 

>better. Is there anything in the use cases that can't be fixed by

[Med] The document includes some cases involving IPv6 (e.g., proxies, NPTv6, NAT64). See the table in http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04#section-4.2. The text can be made more clearer.

---

From: <[email-masked]>
Date: Tue, 11 Mar 2014 17:07:49 +0100

Hi Ted,

It is out of scope of the document to specify solutions but to enumerate the set of cases where issues will be encountered. The use cases identified so far are not specific to a given administrative domain as captured in http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04#section-4.2 

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

Given these use cases, operational considerations such as the performance impact induced by a solution to convey host_id should be taken into account. These impacts are solution-specific an deployment-sceptic.

For cases where functional elements belonging to several administrative domains are involved, standardized means are key.

Cheers,
Med

>De : hiaps [mailto:[email-masked]] De la part de Ted Lemon
>Envoyé : jeudi 6 mars 2014 19:13
>À : Brian E Carpenter
>Cc : Joel Jaeggli; [email-masked]; Internet Area; draft-boucadair-intarea-
>[email-masked]
>Objet : Re: [hiaps] [Int-area] request to consider sponsoring
>It also seems doubtful that this would be useful outside the carrier
>network, since service providers would have to implement it and middleboxes
>would have to support it, neither of which is something we can depend on.
>Inside of the carrier network, solutions like A+P at the very least are
>quite easy to track algorithmically, so this solution is overkill.
>
>hiaps mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/hiaps

---

From: <[email-masked]>
Date: Wed, 12 Mar 2014 11:48:18 +0100

Hi Scott, all,

In addition to what is mentioned by Joe, RFC6967 provides some recommendations:

   ".. the following design considerations are to be taken into
   account:

   o  It is recommended that HOST_IDs be limited to providing local
      uniqueness rather than global uniqueness.

   o  The address-sharing function should not use permanent HOST_ID
      values."

A detailed audit should be conducted for specific solutions. These solutions should follow the guidelines provided in RFC6967:

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

draft-boucadair-intarea-host-identifier-scenarios does not specify a solution but enumerate use cases in which host identification issues are encountered. Citing privacy considerations discussed RFC6967 would be fine. 

Cheers,
Med

>De : Int-area [mailto:[email-masked]] De la part de Joe Touch
>Envoyé : lundi 10 mars 2014 18:44
>À : Scott Brim
>Cc : [email-masked];
>Internet Area; [email-masked]

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Mar 2014 00:38:58 +0000

> use them but public IPv6 to public IPv6.

Sure, and those services won't log and won't emit any of the identifiers in RFC6967.

draft-boucadair-intarea-host-identifier-scenarios is trying to explain when such an identifier is useful; not when it isn't useful.

-d

---

From: Dan Wing <[email-masked]>
Date: Wed, 12 Mar 2014 00:45:32 +0000

On Mar 8, 2014, at 7:03 AM, Brian E Carpenter <[email-masked]> wrote:

> I'm not sure where you found that in what I wrote.

The authors can probably pull or copy text from RFC6967's Section 3 and its Security Considerations.

> I think that address
> but that's certainly not what I meant.

Address sharing does reduce the risk of layer 3 tracking.  Combined with port randomization between subscribers ("NAPT"), it can do a pretty helpful job if that is the intent.

> IPv6 with RFC 4941 (which
> is fine from this point of view.

Not really.  But that is a different discussion; perhaps we should have that discussion somewhere.

> I don't see any difference in

The difference is scope:  can the traffic be identified to a single home (IPv6 /64 address; IPv4 /32 address; or a PSTN telephone number), or can the traffic only be identified to a region within a city (HTTP caching proxy; carrier grade NAT).

-d