Subject: [Ideas] Identity/identifier and session continuity

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Jul 2017 09:35:23 +0200

I understand the desire to provide good privacy by decoupling a 
longer-lived identity from shorter lived and potentially in the clear 
identifiers.

But since the identifiers are used for the transport connection 
identification, changing the identifier(s) used in an unlinkable way 
means that the transport sessions would break.

Seems like a tricky tradeoff.

What are the thoughts in this area?

Thanks,
    Erik

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 20 Jul 2017 08:04:41 +0000

Hi Erik,

I may not get your question right, but let me give it a try.

Yes, identifiers are used on data plane for the transport connection, but an identifier used in one tcp session is not going to change during the session.

If you're asking about initiating a session using a new identifier, it's different based on whether it's the sender or the receiver using a new identifier. But the bottom line is an entity will query the mapping system about the idf/loc information, and since the MS has the info of identity and identifiers mappings it can make the right resolution. The exact control messages needed will be defined by the WG later.

Thanks,
Yingzhen

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, July 20, 2017 12:35 AM
To: [email-masked]
Subject: [Ideas] Identity/identifier and session continuity

I understand the desire to provide good privacy by decoupling a longer-lived identity from shorter lived and potentially in the clear identifiers.

But since the identifiers are used for the transport connection identification, changing the identifier(s) used in an unlinkable way means that the transport sessions would break.

Thanks,
    Erik

_______________________________________________
Ideas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ideas

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 20 Jul 2017 08:36:48 +0000

Hi Erik,

> But since the identifiers are used for the transport connection identification, changing the identifier(s) used in an unlinkable way means that the transport sessions would break.

I second below response.

2 quick things:

1. If an entity intends to use ephemeral identifiers in the data plane for any reason (including for anonymity for outside observers), the frequency of use (one or more sessions) can be determined either by entity or through MS.  
  I don't see why during a session it has to be changed, especially as it will break the session as you suggested.

2. IDEAS doesn't intend to provide any mechanism how anonymous Identifiers can be defined in a particular protocol. For example LISP has a mechanism for EID anonymity "draft-farinacci-lisp-eid-anonymity-02".
    However IDEAS can provide simple policy  at GRIDS and can provide mechanisms how sender/receiver can wish to anonymize (for example frequency) their communication, if needed.

--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Yingzhen Qu
Sent: Thursday, July 20, 2017 1:05 AM
To: Erik Nordmark <[email-masked]>; [email-masked]
Subject: Re: [Ideas] Identity/identifier and session continuity

Hi Erik,

Thanks,
Yingzhen

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, July 20, 2017 12:35 AM
To: [email-masked]
Subject: [Ideas] Identity/identifier and session continuity

Thanks,
    Erik

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 01:50:55 -0700

> Seems like a tricky tradeoff.

I believe we can have it both ways. 

If one wants ephemeral-EIDs, they are used for short-lived transport connections. If there will be long-lived transport connections, EIDs stay assigned to the node for a longer period of time but the encapsulated packets are encrypted. You can have one or both. You can get privacy either way.

Also note, in LISP, one can use ephemeral-EIDs and still get crypto-based authentication using a crypto-EID for the sole purpose of sending Map-Registers and Map-Requests and not for transport connections.

Dino

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Jul 2017 17:12:04 +0200

> If one wants ephemeral-EIDs, they are used for short-lived transport connections. If there will be long-lived transport connections, EIDs stay assigned to the node for a longer period of time but t…

Yes, but when there is a potential combination of long-lived connections 
and short-lived connections using different identifiers that might 
provide the ability for an observer to link the different identifiers 
together. A resourceful observer with the ability to observe on many 
links and networks than then build up the collection of identifiers 
which have been used by a single identity. (Unlinkability is defined in 
rfc6973)

One can avoid this linkability by changing all the identifiers (and 
other things visible in the clear like MAC addresses) and the same time 
as the locators are changing e.g. when the endpoint moves to a new 
network/link, but that will break the long-lived connections that are 
active when the change happens.

Of course, one can encrypt the identifiers (e.g., by encrypting 
everything but the outer IP header) in the data packets since only the 
locators are needed for packet delivery.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Jul 2017 17:14:28 +0200

Erik

---

From: Tom Herbert <[email-masked]>
Date: Thu, 20 Jul 2017 08:56:46 -0700

On Thu, Jul 20, 2017 at 8:12 AM, Erik Nordmark <[email-masked]> wrote:
>>> identification, changing the identifier(s) used in an unlinkable way means
>>> that the transport sessions would break.
>>>
>> If one wants ephemeral-EIDs, they are used for short-lived transport
>> connections. If there will be long-lived transport connections, EIDs stay
>> assigned to the node for a longer period of time but the encapsulated
>> packets are encrypted. You can have one or both. You can get privacy either
>> way.
>
>
> Yes, but when there is a potential combination of long-lived connections and
> short-lived connections using different identifiers that might provide the
> ability for an observer to link the different identifiers together. A
> resourceful observer with the ability to observe on many links and networks
> than then build up the collection of identifiers which have been used by a
> single identity. (Unlinkability is defined in rfc6973)
>
> One can avoid this linkability by changing all the identifiers (and other
> things visible in the clear like MAC addresses) and the same time as the
> locators are changing e.g. when the endpoint moves to a new network/link,
> but that will break the long-lived connections that are active when the
> change happens.
>
> Of course, one can encrypt the identifiers (e.g., by encrypting everything
> but the outer IP header) in the data packets since only the locators are
> needed for packet delivery.
>
Right, that would have to include the transport headers since it would
be easy to correlate packets for the same flow by looking at sequence
and ack numbers. Also changing addresses of an existing TCP connection
will wreak havoc on stateful middleboxes like firewalls. Maybe the
goal should be to prevent correlation of identity between flows.

Tom

>    Erik
>
>
>>
>> Also note, in LISP, one can use ephemeral-EIDs and still get crypto-based
>> authentication using a crypto-EID for the sole purpose of sending
>> Map-Registers and Map-Requests and not for transport connections.
>>
>> Dino
>>
>>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 10:34:19 -0700

> Yes, but when there is a potential combination of long-lived connections and short-lived connections using different identifiers that might provide the ability for an observer to link the different identifiers together. A resourceful observer with the ability to observe on many links and networks than then build up the collection of identifiers which have been used by a single identity. (Unlinkability is defined in rfc6973)

If an the xTR has multiple RLOCs, it can use different ones for encapsulated traffic for both long-lived and short-lived sessions and EIDs, while EIDs are encrypted.

It will be harder to associate when multiple addresses are BOTH encrypted and changing. Note, changing RLOCs does not change the path packets arrive to these EIDs. However, on egress, uRPF issues may be created. So one will need to have multiple PA addresses for each link connected to different providers.

> One can avoid this linkability by changing all the identifiers (and other things visible in the clear like MAC addresses) and the same time as the locators are changing e.g. when the endpoint moves to a new network/link, but that will break the long-lived connections that are active when the change happens.

There is no reason on a point-to-point link that a source MAC cannot be 00:00:00:00:00:00. That is pretty good obfuscation if you believe it is needed.

> Of course, one can encrypt the identifiers (e.g., by encrypting everything but the outer IP header) in the data packets since only the locators are needed for packet delivery.

Yes, "everthing should be encrypted . . . always” (tm).  ;-)

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 10:37:13 -0700

> goal should be to prevent correlation of identity between flows.

In lisp-crypto (RFC8061), everything after the LISP header is encrypted. The LISP header must be in the clear so we can use multiple keys (see KK bits below).

Dino

---

From: Tom Herbert <[email-masked]>
Date: Thu, 20 Jul 2017 12:07:08 -0700

On Thu, Jul 20, 2017 at 10:37 AM, Dino Farinacci <[email-masked]>
wrote:

> In lisp-crypto (RFC8061), everything after the LISP header is encrypted.
> The LISP header must be in the clear so we can use multiple keys (see KK
> bits below).
>
Very nice.

One could also use IPsec in tunnel mode, transport mode if the receiver
knows how to map addresses to original source address. In that case the SPI
would need to change for every address change.

Even with all of this though, I'm still skeptical that this will ever
achieve something we can call real security for identity protection of a
long lived flow. Packets need to be routable in the Internet so there's
only so much of the addresses that can be obfuscated and analysis of
communication patterns can yields information even for encrypted flows. In
practice it's probably far simpler to just not use long lived connections
if identity is a concern there, applications already need to handle
restarts for connection failures anyway so it's not a big deal to
reestablish a connection (NAT state timeouts have already necessitated this
model for several years).

Tom

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Jul 2017 21:13:52 +0200

> On Jul 20, 2017, at 9:07 PM, Tom Herbert <[email-masked]> wrote:
> 
> Even with all of this though, I'm still skeptical that this will ever achieve something we can call real security for identity protection of a long lived flow. Packets need to be routable in the Internet so there's only so much of the addresses that can be obfuscated and analysis of communication patterns can yields information even for encrypted flows. In practice it's probably far simpler to just not use long lived connections if identity is a concern there, applications already need to handle restarts for connection failures anyway so it's not a big deal to reestablish a connection (NAT state timeouts have already necessitated this model for several years).

Only true when EIDs need to interwork with non-EIDs. Which I think will be necessary for a long transition period. But for use in VPNs where each VPN site talks only to each other, you can have data-plane crypto all the time. And for container networking and IoT device to cloud app, this will also be the case. 

Dino

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 20 Jul 2017 20:40:30 +0000

Couple of questions:

1. Not really fully sure what's the need for full encryption (if need is only obfuscation of identifiers) of the packet, if obfuscation is done through ephemeral identifiers.
              
2. Sure, If #1 is needed and packet is encrypted (above IP) with whether  LISP encryption or IPSec tunnel mode, what is the privacy concern for long lived flow. What useful  information observer would get in that case?

And also 

    - there is a high possibility for double encryption (if  ubiquitous encryption is there at application layer), if we propose to "encrypt all" is the rule, even if the need is only obfuscation.
    - there could be late binding cases in the network and for that identifiers has to be consulted - but we will  have an issue if we ought to do full encryption just for obfuscation.

--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Thursday, July 20, 2017 12:14 PM
To: Tom Herbert <[email-masked]>
Cc: Erik Nordmark <[email-masked]>; [email-masked]; Erik Nordmark <[email-masked]>
Subject: Re: [Ideas] Identity/identifier and session continuity

Dino

---

From: Tom Herbert <[email-masked]>
Date: Thu, 20 Jul 2017 14:06:51 -0700

> 1. Not really fully sure what's the need for full encryption (if need is only obfuscation of identifiers) of the packet, if obfuscation is done through ephemeral identifiers.
The "need" would be to obfuscate other parts of the packet that
contain information that could be used to discern that two packets are
part the same flow even if they have different IP addresses. The most
obvious data that comes to mind for would be port numbers and TCP
sequence numbers and acknowlgements .

> 2. Sure, If #1 is needed and packet is encrypted (above IP) with whether  LISP encryption or IPSec tunnel mode, what is the privacy concern for long lived flow. What useful  information observer wo…
They would get a lot less information, but as I pointed out an
observer can still infer some information based on communications
pattern, packet sizes, etc.

>     - there could be late binding cases in the network and for that identifiers has to be consulted - but we will  have an issue if we ought to do full encryption just for obfuscation.
Full encryption would help this case and be beneficial for other
aspects of security, however in the Internet we are no where near
ubiquitous full packet encryption. Even TLS is not completely deployed
yet. I would say it's a nice to have, but it can't be a requirement
set by IDEAS, at best it's a MAY.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 20 Jul 2017 21:25:16 +0000

Hi Tom,

	> 1. Not really fully sure what's the need for full encryption (if need is only obfuscation of identifiers) of the packet, if obfuscation is done through ephemeral identifiers.
	The "need" would be to obfuscate other parts of the packet that contain information that could be used to discern that two packets are part the same flow even if they have different IP addresses. 
                The most obvious data that comes to mind for would be port numbers and TCP sequence numbers and acknowlgements .

Yes, that’s possible. So what is the security issue especially as you said if IP addresses are changing. Yes an observer identify the long lived flow between two obfuscated one time  identifiers. I am missing some thing.

	> 2. Sure, If #1 is needed and packet is encrypted (above IP) with whether  LISP encryption or IPSec tunnel mode, what is the privacy concern for long lived flow. What useful  information observer w…
	They would get a lot less information, but as I pointed out an observer can still infer some information based on communications pattern, packet sizes, etc.

Remember padding field in IPSEC  ESP header, this is precisely there to mask packet sizes.

	>     - there could be late binding cases in the network and for that identifiers has to be consulted - but we will  have an issue if we ought to do full encryption just for obfuscation.
	Full encryption would help this case and be beneficial for other aspects of security, however in the Internet we are no where near ubiquitous full packet encryption. Even TLS is not completely deployed yet.
                I would say it's a nice to have, but it can't be a requirement set by IDEAS, at best it's a MAY.

Agree, that is what I feel and don't see IDEAS mandated full encryption, rather opposite and allow identifiers outside (with obfuscation, even if rest of the packet is encrypted) to help late binding and last QoS application based on Identifiers if needed.

Thx!

--
Uma C.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 25 Jul 2017 09:40:19 -0400

On 07/20/2017 11:12 AM, Erik Nordmark wrote:
>>> longer-lived identity from shorter lived and potentially in the 
>>> clear identifiers.
>>>
>> connections. If there will be long-lived transport connections, EIDs 
>> stay assigned to the node for a longer period of time but the 
>> encapsulated packets are encrypted. You can have one or both. You can 
>> get privacy either way.
>
> Yes, but when there is a potential combination of long-lived 
> connections and short-lived connections using different identifiers 
> that might provide the ability for an observer to link the different 
> identifiers together. A resourceful observer with the ability to 
> observe on many links and networks than then build up the collection 
> of identifiers which have been used by a single identity. 
> (Unlinkability is defined in rfc6973)
>
> other things visible in the clear like MAC addresses) and the same 
> time as the locators are changing e.g. when the endpoint moves to a 
> new network/link, but that will break the long-lived connections that 
> are active when the change happens.
>

Here be lots of dragons.  The performance cost of such an approach needs 
careful consideration.

I am very interested in long-lived associations.  The privacy 
implications of these are important and a way to link and change them 
will need to be worked out.  In part, this is orthogonal to the basic 
mapping requirements.  For example, I can define a chain of Identifiers 
such that the Endpoints understand the relationship, but not the 
eavesdropper.  I prefer this to total encryption.  Total encryption 
means total decryption before any decisions; a wonder target to attack.

This is yet another reason to rethink HIT construction.  I will attempt 
to do this in the next version of the Hierarchical HIT draft.

Bob

>
>    Erik
>
>>
>> Also note, in LISP, one can use ephemeral-EIDs and still get 
>> crypto-based authentication using a crypto-EID for the sole purpose 
>> of sending Map-Registers and Map-Requests and not for transport 
>> connections.
>>
>> Dino
>>
>>
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Jul 2017 10:25:00 -0700

> I am very interested in long-lived associations.  

But with possible re-key occuring during the association?

> For example, I can define a chain of Identifiers such that the Endpoints understand the relationship, but not the eavesdropper.  I prefer this to total encryption.  

This is interesting Bob. Is the chain stored but not accessible by anyone but the endpoints that use the chain? Does the chain need to be encrypted while it is at rest?

> Total encryption means total decryption before any decisions; a wonder target to attack.

Very good point.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Tue, 25 Jul 2017 11:23:43 -0700

On Tue, Jul 25, 2017 at 6:40 AM, Robert Moskowitz
<[email-masked]> wrote:
>> and short-lived connections using different identifiers that might provide
>> the ability for an observer to link the different identifiers together. A
> I am very interested in long-lived associations.  The privacy implications
> of these are important and a way to link and change them will need to be
> worked out.  In part, this is orthogonal to the basic mapping requirements.
> For example, I can define a chain of Identifiers such that the Endpoints
> understand the relationship, but not the eavesdropper.  I prefer this to

But, again that doesn't solve the problem that there could be things
in plain text that are easily used to match packets to the same flow
even if IP addresses change on every packet for the flow. If the goal
is to prevent associations between packets for long lived flows then
all the methods by which and attacker could make associations need to
be considered. If we don't consider that then all the work to
dynamically change addresses for a flow could be for naught.

Tom

---

From: "Liubingyang (Bryan)" <[email-masked]>
Date: Wed, 26 Jul 2017 00:54:48 +0000

> From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
> Sent: Wednesday, July 26, 2017 2:24 AM
> To: Robert Moskowitz <[email-masked]>
> Cc: Erik Nordmark <[email-masked]>; [email-masked]; Erik Nordmark
> <[email-masked]>; Dino Farinacci <[email-masked]>
> >>>> identification, changing the identifier(s) used in an unlinkable
> >>>> way means that the transport sessions would break.
> >>>>
> >>> encapsulated packets are encrypted. You can have one or both. You
> >>> can get privacy either way.
> >>
> >>
> >> everything but the outer IP header) in the data packets since only
> >> the locators are needed for packet delivery.
> >
> >
> > Here be lots of dragons.  The performance cost of such an approach
> > needs careful consideration.
> >
> > will need to be worked out.  In part, this is orthogonal to the basic mapping
> requirements.
> > For example, I can define a chain of Identifiers such that the
> > Endpoints understand the relationship, but not the eavesdropper.  I
> > prefer this to
> 
> But, again that doesn't solve the problem that there could be things in plain
> text that are easily used to match packets to the same flow even if IP
> addresses change on every packet for the flow. If the goal is to prevent
> associations between packets for long lived flows then all the methods by
> which and attacker could make associations need to be considered. If we don't
> consider that then all the work to dynamically change addresses for a flow
> could be for naught.

Yes, but I don't think it is worse than today's IP. 

Bingyang