Subject: Re: [Pidloc] PIdLoc Webex

From: <[email-masked]>
Date: Tue, 4 Dec 2018 09:13:02 +0000

Dear all
We had our call last week in terms of an Asian-European suitable time and discussed as described below.
Sorry to all who couldn’t make it!
We definitely will have a follow-on call at another time of day soon more convenient for NA ;-)
Please comment and consider joining …
See also the slides attached!
Thanks and best regards
Dirk

Minutes of phone/webex call on  Thursday Nov. 29, 2018 5 - 6 pm JST (UTC+09:00)
Dirk presented slides on behalf of Behcet on PIdLoc activities so far.
Shunsuke asked whether privacy issues should be resolved technically in terms of mechanisms/measures or functionalities/functional entities
Dirk expects that both specific methods and architectural functions could be in scope
Shunsuke asked whether BoF or new WG is proposed
Dirk stated that IETF first will try to re-use existing WGs but if this is not possible also new WGs via BoF would be a way
Luigi said that 3GPPs preferred tunneling also is built up between identifiable entities at specific locations
Shunsuke expects that 3GPP will not adopt Id-Loc approaches for 5G / Rel. 16
Luigi mentioned other use cases as IoT and Edge computing
Questioned explicitly by Dirk Luigi pointed out that LISP so far has not dealt with privacy problem but secured content by encryption and protected mapping request from attacks
LISP applies traditional filtering approach – interest/demand in privacy concerns may rise with new use cases
Luigi would like to see issue addressed – at first in terms of analysis of actual privacy issues
Dirk mentioned that these could cover more that LISP but also other protocols (ILNP, ILA, SRv6, …) – so work not necessarily to be done in LISP WG
Shunsuke said that regarding  Id-Loc in 5G 3GPP TSG SA2 would have to consider/propose this topic
Dirk thanked all for participation and contribution and hopes that we can have more calls (also convenient for other time zones) in the future.

PS: Regarding use case edge computing and the mentioned draft please find it here: https://tools.ietf.org/html/draft-nordmark-t2trg-computing-edge

-----Original Appointment-----
From: von Hugo, Dirk
Sent: Dienstag, 27. November 2018 14:30
To: von Hugo, Dirk; [email-masked]<mailto:[email-masked]>
Subject: FW: PIdLoc Webex
When: Donnerstag, 29. November 2018 17:00-18:00 (UTC+09:00) Osaka, Sapporo, Tokyo.
Where: Mobile +49697912293,,701111873# Dial-in +49697912293 Meeting-ID 701111873# webex - please see below

Dear all,
following our doodle for a kick-off webex we decided now on a date and time slot on
Thursday Nov. 29, 2018 5 - 6 pm (UTC+09:00) in Japan (Osaka, Sapporo, Tokyo)

Unfortunately for some other time zones it is not very convenient – sorry for that!

Please see below for details!

Agenda:

1. Summary of the discussion on Erik's draft on the list
2. Next Steps discussion: with a short presentation of possible directions including 5G
3. Closing

Thanks and best regards
Dirk

Subject: PIdLoc Webex
When: Donnerstag, 29. November 2018 09:00-10:00 (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna.
Where: Mobile +49697912293,,701111873# Dial-in +49697912293 Meeting-ID 701111873# webex - please see below

Dear all,
we just try to set up a date – in case this does not fit for you please propose an alternative!
And please forward it to whoever you think may be interested …
Thanks!
Best regards – also on behalf of Behcet
Dirk
-------------------------------------------------------
Important Note on Privacy & Security
-------------------------------------------------------
If you need to exchange confidential information, please deselect standard setting “allow external participants”
Standard setting option „allow external participants“ merely corresponds with Confidentiality Classification “internal”.

-------------------------------------------------------
MEETING DATA
-------------------------------------------------------

Meeting-ID: 701 111 873
Meeting Password: HNPQ32Wm

-------------------------------------------------------
Join the WEB CONFERENCE
-------------------------------------------------------

Click this link: https://t-systems.webex.com/t-systems-en/j.php?MTID=mcb4c550bf96f2b320e936251054d5229
If you are a participant, please enter your name and press „Join”.

Alternatively go to http://www.t-systems.com/scpconf and enter your Meeting-ID.

Please pay attention: KEYBOARD AND MOUSE SHARING IS ONLY PERMITTED FOR DTAG EMPLOYEES!

-------------------------------------------------------
Enter the AUDIO CONFERENCE
-------------------------------------------------------

1. Dial +49 69 791 22 93
2. When asked, enter your Meeting-ID

Dial in with Cisco  Jabber version 11.0 and higher: tel:+49697912293#,,701111873#

-------------------------------------------------------
International dial-in numbers
-------------------------------------------------------

If you have connection problems with an international dial-in number, or if there is no dial-in number for your country, please use the German dial-in number.

Germany: +49 69 791 2293
Austria: +43 57 057 8910
Belgium: +32 24019155
Brazil: +55 11 2184 2423
Croatia: +38514918888
Denmark: +45 78780993
Finland: +358 753258993
France: +33 1 85 14 81 87
Greece: +30 210 611 2600
Hungary landline: +36 1 381 8493
India: +91 1800 200 7872
Macedonia: +389 2324 2047
Malaysia: +603 8313 3232
Mexico: +52 222 223 4567
Montenegro: 382 2043 3796
Netherlands: +31 45 7111001
Poland: +48 22 413 77 77
Romania: +40 214006230
Singapore: +65 65106288
Slovakia mobile: +421 55 785 5555
South Africa (AVANTI): +27 21 974 3204
South Africa (IBG): +27 11 254 7782
Spain: +34 93 4456000
Sweden: +46 852503193
Switzerland: +41 31 528 1762
UK: +44 20 71086254
USA Downers Grove: +1 630 493 6788
USA New York: +1 212 301 6028
USA Tempe: +1 480 477 7017
USA Troy: +1 248 276 3424

For additional information, please go to DTAG Intranet: http://webex.telekom.de/en

---

From: <[email-masked]>
Date: Tue, 4 Dec 2018 08:59:58 +0000

Dear all

-----Original Appointment-----
From: von Hugo, Dirk
Sent: Dienstag, 27. November 2018 14:30
To: von Hugo, Dirk; [email-masked]<mailto:[email-masked]>
Subject: FW: PIdLoc Webex
When: Donnerstag, 29. November 2018 17:00-18:00 (UTC+09:00) Osaka, Sapporo, Tokyo.
Where: Mobile +49697912293,,701111873# Dial-in +49697912293 Meeting-ID 701111873# webex - please see below

Dear all,

Agenda:

Thanks and best regards
Dirk

Subject: PIdLoc Webex

Dear all,

Meeting-ID: 701 111 873

1. Dial +49 69 791 22 93

Germany: +49 69 791 2293
Austria: +43 57 057 8910
Belgium: +32 24019155
Brazil: +55 11 2184 2423
Croatia: +38514918888
Denmark: +45 78780993
Finland: +358 753258993

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 4 Dec 2018 08:53:56 -0800

> Questioned explicitly by Dirk Luigi pointed out that LISP so far has not dealt with privacy problem but secured content by encryption and protected mapping request from attacks

This is a broad statement. Can someone be more specific. 

If DTLS is used for LISP protocol messages and LISP-crypto is used for encapsulation than both the LISP control-plane and data-plane support privacy. Note that if you don’t use DTLS, one can send control-plane messages over LISP-crypto. So the architecture can support privacy.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Dec 2018 13:33:14 -0800

> If DTLS is used for LISP protocol messages and LISP-crypto is used for encapsulation than both the LISP control-plane and data-plane support privacy. Note that if you don’t use DTLS, one can send c…

DTLS could be applied to any UDP tunneling protocol, but that's not
really where the privacy problem lies. Presuming that as much of the
packet is encrypted as possible, then the question becomes what can be
inferred from the non-encrypted portions of the packet to breach
someone's privacy. The obvious data that could be exploited are the IP
addresses in a packet. There's at least two possible exploits: 1)
Addresses allow correlations between two different flows that they are
originated by the same user 2) Geo-location of a user can be deduced
from observed addresses. The actual identity of a user isn't
immediately available in addresses, but there's a fairly simple method
to deduce identity using #1.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Dec 2018 13:42:53 -0800

> DTLS could be applied to any UDP tunneling protocol, but that's not

Just to let you know that is not what I was suggesting. LISP could be use DTLS for its UDP control messages. Not tunneled packets since RFC 8061 (LISP-crypto) solves that. 

> addresses in a packet. There's at least two possible exploits: 1)

Yes for any protocol design. 

> to deduce identity using #1.

Only in the case of interacting with the mapping system, an eavesdropper can determine that an IP address is talking to a map-server or map-resolver but doesn’t know why and for what endpoints. 

That’s the best any design can hope for. The IP header can only be sent in the clear. 

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 5 Dec 2018 14:08:26 -0800

> Only in the case of interacting with the mapping system, an eavesdropper can determine that an IP address is talking to a map-server or map-resolver but doesn’t know why and for what endpoints.

Dino,

Just run your mapping system in a closed and presumably secured
network. Every service provider can run their own mapping system and
there's no need or value to build global mapping databases.

> That’s the best any design can hope for. The IP header can only be sent in the clear.
In order to communicate with Internet hosts plain text addresses are
used in packets. The are identifiers in idloc terminology and they are
exposed to the whole Internet. It's the privacy properties of these
that are of interest. For instance, today many service providers
assign a /64 to their users. So, that means that if a third party on
the Internet observes two flow with source addresses sharing the same
sixty-four bit prefix they can deduce that the source is the same (the
same user in case of personal devices). What is really needed for
privacy is to use a different uncorrelatable address per flow. Under
certain conditions, CGNAT provides that today which is why law
enforcement agencies are terrified of it. In lieu of NAT, idloc could
key to provide this privacy without resorting to NAT. See
draft-herbert-ipv6-prefix-address-privacy-00.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Dec 2018 14:42:08 -0800

> there's no need or value to build global mapping databases.

Yes, of course. That has always been an opiton and many enterprises are doing that today.

> used in packets. The are identifiers in idloc terminology and they are

In headers in particular. I hope you agree it can be avoided in payloads.

> privacy is to use a different uncorrelatable address per flow. Under

Agree.

> draft-herbert-ipv6-prefix-address-privacy-00.

Understand. But randomized addresses assign to tail site can still be achieved without the high-cost of managing a CGNAT. You only need to route back to that randomized/ephemeral address for a short period of time. In fact, the ISP can withdraw the route when it wants the tail site to use another address.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Dec 2018 09:26:42 -0600

My points below.

> Yes, of course. That has always been an opiton and many enterprises are

I am confused.
Are you (Tom, Dino) saying that service providers are already using IdLoc
protocols?

If not, what do they use their mapping system for?

> > draft-herbert-ipv6-prefix-address-privacy-00.

Wait a minute.
We expect to attack and solve this problem in Pidloc with all of you guys
active participation.

However, solution proposals are of course welcome.

Behcet

> > Tom
>
> Understand. But randomized addresses assign to tail site can still be
> achieved without the high-cost of managing a CGNAT. You only need to route
> back to that randomized/ephemeral address for a short period of time. In
> fact, the ISP can withdraw the route when it wants the tail site to use
> another address.
>
> Dino
>
>
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 6 Dec 2018 07:42:59 -0800

> Are you (Tom, Dino) saying that service providers are already using IdLoc

Network virtualization is IdLoc where virtual address is an identifier and
physical address is locator. Cloud providers have deployed this in various
forms for a long time now.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Dec 2018 09:52:03 -0600

On Thu, Dec 6, 2018 at 9:43 AM Tom Herbert <[email-masked]> wrote:

> physical address is locator.
>

You mean they use ILA?
I thought most of them use L2 protocols.
Well this is more of nvo3 issue :-)

> Cloud providers have deployed this in various forms for a long time now.
>
>>
>>

Cloud providers?

So we are not talking about network operators?

Behcet

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 15:59:51 +0000

Dear all
Regarding the interesting discussion on this I may ask whether there is interest for another Webex call for US-EU zone, possibly to take place sometime the week of December 10- December 14 around 4 pm UTC (17:00 Central EU time)?
https://doodle.com/poll/tb2dmhttdcfnbfbn
Thanks!
Kind regards
Dirk

---

From: Tom Herbert <[email-masked]>
Date: Thu, 6 Dec 2018 08:14:23 -0800

On Thu, Dec 6, 2018, 7:52 AM Behcet Sarikaya <[email-masked] wrote:

>>> Are you (Tom, Dino) saying that service providers are already using
>>> IdLoc protocols?
>>>
>>
>> Network virtualization is IdLoc where virtual address is an identifier
>> and physical address is locator.
>>
>
> You mean they use ILA?

They are using ILA, GRE, VXLAN, etc. Some are L2, bigger ones (e.g. Google
cloud) are L3.

> So we are not talking about network operators?

A mapping system is needed in both contexts, so makes sense to leverage a
common solution. Privacy properties are a bit different since network
providers are serving end users directly.

>>> We expect to attack and solve this problem in Pidloc with all of you
>>> guys active participation.
>>>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 6 Dec 2018 09:37:29 -0800

> Are you (Tom, Dino) saying that service providers are already using IdLoc protocols?

I didn’t say anything specific, but I will now.

Both AT&T and Verizon WAS using LISP for very specific use-cases when I worked at cisco, circa 2012.

Dino

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Dec 2018 09:55:50 -0600

> worked at cisco, circa 2012.

Thanks Dino.

Our suggestion is let's discuss these things on a Webex call next week.
Dirk already sent a mail, it could be any day next week, time suitable for
US colleagues.

Regards,
Behcet

---

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Dec 2018 09:32:07 -0800

> Understand. But randomized addresses assign to tail site can still be achieved without the high-cost of managing a CGNAT. You only need to route back to that randomized/ephemeral address for a shor…

That's where the scaling problem comes in. A mapping system should
scale to support a billion mappings in a single network, maybe
something like a 100M devices and ten mappings (identifiers) per
device. That is manageable. For instance if entries are 50 bytes then
the whole mapping database could fit in 50G of memory. But, if end
hosts use a different source IPv6 address for each connection, then
the number of mappings that would be needed increases by several order
of magnitude. That is not so manageable. Assuming end hosts might want
up to a thousand ephemeral addresses at a time, the memory requirement
is now 50T and this puts a lot of pressure on the network when
mappings need to be moved around. The alternative discussed in
draft-herbert-ipv6-prefix-address-privacy-00 is "hidden aggregation"
whereby the network is able to aggregate some number of addresses
(identifiers) to the same mapping, but outside of the network no
relation between addresses can be drawn.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 7 Dec 2018 10:16:18 -0800

> relation between addresses can be drawn.

You are bringing up a different issue now. And we have discussed this at length before. But as long as you have an underlay and plaintext headers, you still lose privacy even when EIDs are obfuscated.

If you put LISP xTRs inside of an ISP, then you have hidden aggregation of the RLOC addresses and any user addresses (EIDs) are obfuscated from payload encryption (i.e. lisp-crypto).

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Dec 2018 10:37:43 -0800

> You are bringing up a different issue now. And we have discussed this at length before. But as long as you have an underlay and plaintext headers, you still lose privacy even when EIDs are obfuscat…
The underlay protocol is not relevant to privacy, it is only the
mechanism used in a closed provider's network to deliver packets to
their destination. Outside of the network, only plain IP packets are
seen. It is the privacy attributes of the packets visible to the world
that are interesting.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 7 Dec 2018 10:42:40 -0800

> mechanism used in a closed provider's network to deliver packets to

Yes it is for the reasons you have stated before. If I run LISP from my house and obfuscate on EIDs, any eavesdropper can look at the source RLOC to determine I’m a Comcast customer (and can find out the head-end and tail-end connections - my house). That is a violation of my privacy. They can’t tell what transport connections I’m using and who I cam talking to but as long as the outer header is plaintext and “hidden aggreagated", it is a granular privacy invasion. If the LISP xTR was in Comcast, then it looks like some obfuscated EIDs are sending from Comcast. That doesn’t violate my personal privacy.

> seen. It is the privacy attributes of the packets visible to the world

That is what I’m talking about.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Dec 2018 10:57:24 -0800

> That is what I’m talking about.
Yes, the network should assign ephemeral addresses. Scaling this so
that hosts can use a different address per connection is the problem
that ensues.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 7 Dec 2018 11:08:13 -0800

> that hosts can use a different address per connection is the problem

For the outer (or only header), you cannot get assigned ephemeral addresses. They need to be provider-assigned addresses so routing deeper in the network can aggregate such addresses into coarser prefixes.

And note ISPs want to use uRPF so another reason for provider-assigned addresses. The best way to solve the *entire* problem is to tunnel with encryption from a point inside the ISP. Then the outer addresses are coarsified and the inner addresses are obfuscated.

You could solve some of the problem with ILA but you need to keep translating the packet as it goes to the destination. And that will be hard to debug since it breaks traceroute.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 7 Dec 2018 11:31:44 -0800

> You could solve some of the problem with ILA but you need to keep translating the packet as it goes to the destination. And that will be hard to debug since it breaks traceroute.

You are convoluting the behavior of internal network operations with
the externally visible behavior. Think of it this way, we have end
hosts and we have Internet servers. The desired property wrt privacy
is that any host can use an untrackable source address per connection
to talk to any Internet servers. Servers on the Internet should not be
able to draw any correlation between any two flows, nor should they be
able to deduce geographic location with any accuracy. End hosts and
server only see these assigned addresses. They don't know about
mapping systems, underlays, encapsulation, or what the addresses mean
other. All they know is that the addresses than they identify a
communicating node and are routable in IP packets over the Internet to
some service provider. It is up to the network provider to support
this using mechanisms that scale, but the details of that are not
relevant to privacy as long as the desired external behavior is met
and privacy is maintained.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 7 Dec 2018 11:45:56 -0800

Sorry, looking at the entire network, and how it works, scales, and what the cost of privacy is critical to evaluate. Just looking at it from the app end-systesm isn't looking at the details to *really* make the entire system work.

Dino

> On Dec 7, 2018, at 11:31 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Dec 2018 07:39:26 -0800

Dino,

There's already very large systems that *really* work. Both mobile
providers and cloud providers have been using identifier/locator
protocols and mapping systems for a long time. It is obvious that
access to the control plane needs to be tightly secured and providers
do that. If, for instance, someone were able to snoop call messages in
3GPP then all privacy and security break down (there's little choice
but to entrust providers with protecting privacy). A material problem
in these systems that isn't solved by a secure control plane is that
PII can deducible from IP addresses assigned by such systems that are
exposed to the outside world. IMO, this is a specific and current
problem and is worth discussion on this list.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Dec 2018 09:36:16 -0800

Yes I know. And you have mentioned this before. Are you trying to make a new point or repeating an old one?

Dino

> On Dec 10, 2018, at 7:39 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Dec 2018 09:49:12 -0800

> Yes I know. And you have mentioned this before. Are you trying to make a new point or repeating an old one?

I am trying to understand what problem this group is intending to solve.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Dec 2018 09:51:22 -0800

Me too.

Dino

> On Dec 10, 2018, at 9:49 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Dec 2018 09:28:34 -0600

> Me too.

That is one reason why we have these Webex's. To discuss what was discussed
so far and to project to the next steps. In the process try to understand
what people want.

Dirk is going to announce the next Webex time and date and we hope that
everyone attends the call.

 Behcet

> >>>> Sorry, looking at the entire network, and how it works, scales, and
> what the cost of privacy is critical to evaluate. Just looking at it from
> the app end-systesm isn't looking at the details to *really* make the
> entire system work.
> >>>>
> >>> Dino,
> >>>
> >>>>>> For the outer (or only header), you cannot get assigned ephemeral
> addresses. They need to be provider-assigned addresses so routing deeper in
> the network can aggregate such addresses into coarser prefixes.
> >>>>>>
> >>>>>> And note ISPs want to use uRPF so another reason for
> provider-assigned addresses. The best way to solve the *entire* problem is
> to tunnel with encryption from a point inside the ISP. Then the outer
> addresses are coarsified and the inner addresses are obfuscated.
> >>>>>>
> >>>>>> You could solve some of the problem with ILA but you need to keep
> translating the packet as it goes to the destination. And that will be hard
> to debug since it breaks traceroute.
> >>>>>>
> >>>>>