Subject: Re: [hiaps] work to do

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 4 Nov 2014 09:48:54 -0600

Hi all,

If I understood Dirk's mail, it seems like he is saying that we should
first work on a security analysis of host identifiers.

So I suggest having

Threat analysis
as the first step.

Is there a draft that covers similar issues? Maybe we can start with
that. Otherwise we discuss with the intent of outputting a draft.

Regards,

Behcet

On Thu, Oct 30, 2014 at 2:35 PM, Behcet Sarikaya <[email-masked]> wrote:
>  Hi all,
>
> I tried to dress up things to do in hostid below as follows:
>
> - requirements
>
> - updated solution analysis
>
> - solution(s) given the fact that we have diverse set of use cases,
> one size fits all type of a single solution may not be the way to go.
>
> Regards,
>
> Behcet

---

From: <[email-masked]>
Date: Thu, 6 Nov 2014 10:51:40 +0100

Hi Behcet,
Not exactly - I just wanted to say that the privacy issues are as important as the other topics like scope and problem statement.
But I agree that we should look at existing drafts ... 
A quick look at very recent I-Ds https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-02 related to SIP and https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity-00 might help, but more detailed investigations would be useful ... 
Volunteers welcome ;-)

Best regards
Dirk
-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Dienstag, 4. November 2014 16:49
To: [email-masked]
Cc: Mohamed Boucadair; Brandon Williams; von Hugo, Dirk
Subject: Re: work to do

Hi all,

If I understood Dirk's mail, it seems like he is saying that we should first work on a security analysis of host identifiers.

So I suggest having

Threat analysis
as the first step.

Is there a draft that covers similar issues? Maybe we can start with that. Otherwise we discuss with the intent of outputting a draft.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 Nov 2014 09:41:05 -0600

Hi Dirk, all,

Reading your mail I  came to understand a common misunderstanding on
our activity.

In fact what we are trying to do is already done in IPv6: every packet
in IPv6 carries a public source address. Even in IPv4 in some cases it
is done.

I think privacy and security issues over which there is so much noise
are related to the long lived host identifiers like MSISDN which is
your phone number, as Med said. I don't remember anyone complaining on
privacy / security issues on the very basic way IPv6 works.

This leads me to say that Med initially made an innocent mistake in
selecting host id which can easily be mistaken for other host
identifiers. Unfortunately this mistake has been hitting us like a
boomerang.

My view of the way out is to change the name.
I think we should call host addresses and NOT host ids.
So maybe we should NOT use hiaps but use haaps or host address and
prefix sharing issues. This is a small change and we can easily carry
this over on our work, drafts, etc.

What do you think?

Regards,

Behcet

On Thu, Nov 6, 2014 at 3:51 AM,  <[email-masked]> wrote:
> _______________________________________________
> hiaps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hiaps

---

From: joel jaeggli <[email-masked]>
Date: Fri, 07 Nov 2014 09:09:34 -0800

> privacy / security issues on the very basic way IPv6 works.

Well. There's a reason why hosts are generating privacy  addresses. Back
when they all encoded their mac addresses in the host field  as modified
eui64 and allowed that to be stable  across subnets, a locally
significant but unique identifier was leaking into the internet. That
was addressed and to wit if you have a host identity problem with the v6
addressing architecture that exists today it's because you cannot
distinguish between hosts purely on the basis of source address within a
shared prefix.

everytime I close the lid on the laptop or it goes to sleep I use a new
source address even though for example I use the same v4 address because
my lease still holds.

	inet6 2601:9:####:####:####:####:####:#### prefixlen 64 autoconf
	inet6 2601:9:####:####:159a:c4b1:4efd:21a2 prefixlen 64 autoconf temporary
...

	inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf temporary

> identifiers. Unfortunately this mistake has been hitting us like a

I'm not sure I consider 6967 to be a mistake.

http://tools.ietf.org/html/rfc6967#section-3

> I think we should call host addresses and NOT host ids.

not all the proposals involve addresses they are all identifiers.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 09 Nov 2014 10:36:54 -1000

On 11/9/14 10:30 AM, Behcet Sarikaya wrote:
> In all cases we are dealing with addresses IPv4 or v6.
> They could be public or random or privacy addresses 
> 
> So I think host address use is justified.

a 16 bit field is not an ip address.

> Regards
> 
> Behcet 
> 
> Sent from my iPhone
> 
>> On Nov 7, 2014, at 7:09 AM, joel jaeggli <[email-masked]> wrote:
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 9 Nov 2014 10:30:01 -1000

Regards

Behcet 

Sent from my iPhone

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 9 Nov 2014 10:30:01 -1000

Regards

Behcet 

Sent from my iPhone

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 Nov 2014 01:28:18 -0600

> a 16 bit field is not an ip address.

I think Med or Brandon should say something here, to my knowledge it
is part of an address.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Nov 2014 13:57:43 -0600

>         inet6 2601:9:####:####:a96e:3bcd:b861:ee69 prefixlen 64 autoconf temporary

Maybe this gives us another use case for host address/ids?

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Nov 2014 14:00:14 -0600

> a 16 bit field is not an ip address.

RFC 6967 mentions this:

the lower 16 bits of an IPv4
   address

So it is not an ip address by itself (of course) but it is part of an address.

---

From: Brandon Williams <[email-masked]>
Date: Tue, 11 Nov 2014 15:45:22 -0500

> So it is not an ip address by itself (of course) but it is part of an address.

You are referring to examples presented in RFC6967, not a statement of 
requirements. The same example text refers to some non-address options 
too (VLAN ID, VRF ID, or subscriber ID). I think it's clear from the 
thread that at least some of us think that we need to be more careful 
than this list of examples suggests (e.g. I would not support a spec 
that intends to use subscriber ID as a HOST_ID value and would expect to 
see language in a solution RFC that prohibits such identifiers.).

In other words, RFC6967 is not a solution spec and should not be 
considered as such. It is an analysis document intended to help assess a 
particular category of solution and for this reason it may contain 
unaddressed security and/or privacy issues.

--Brandon

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

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 Nov 2014 17:10:15 -0600

On Tue, Nov 11, 2014 at 2:44 PM, Brandon Williams <[email-masked]> wrote:
> requirements. The same example text refers to some non-address options too
> (VLAN ID, VRF ID, or subscriber ID). I think it's clear from the thread that
> at least some of us think that we need to be more careful than this list of
> examples suggests (e.g. I would not support a spec that intends to use
> subscriber ID as a HOST_ID value and would expect to see language in a
> solution RFC that prohibits such identifiers.).
>
> In other words, RFC6967 is not a solution spec and should not be considered
> as such. It is an analysis document intended to help assess a particular
> category of solution and for this reason it may contain unaddressed security
> and/or privacy issues.
>

Absolutely.

At the beginning of this thread, we mentioned requirements as the
first in things to do.

Regards,

Behcet
>>>>>>> Not exactly - I just wanted to say that the privacy issues are as
>>>>>>> important as the other topics like scope and problem statement.
>>>>>>> A quick look at very recent I-Ds
>>>>>>> https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-02 related to SIP and
>>>>>>> https://tools.ietf.org/html/draft-baker-openstack-rbac-federated-identity-00
>>>>>>> might help, but more detailed investigations would be useful ...
>>>>>>> Volunteers welcome ;-)
>>>>>>>
>>>>>>> Best regards
>>>>>>> Dirk
>>>>>>> If I understood Dirk's mail, it seems like he is saying that we
>>>>>>> should first work on a security analysis of host identifiers.
>>>>>>>
>>>>>>> So I suggest having
>>>>>>>
>>>>>>>
>>>>>>> Threat analysis
>>>>>>> as the first step.
>>>>>>>

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 15:19:27 +0000

Hi Behcet, all,

HOST_ID as initially defined in intarea document is not an IP address. RFC6967 says explicitly the following:

" due to address sharing, servers need
   extra information beyond the source IP address to differentiate the
   sending host.  We call this information the HOST_ID." 

And the following:

   "Because the HOST_ID is used by a remote server to sort out the
   packets by sending host, the HOST_ID must be unique to each host
   under the same shared IP address, where possible.  In the case where
   only the Home Gateway is revealed to the operator side of the
   translation function, the HOST_ID need only be unique to the Home
   Gateway.  The HOST_ID does not need to be globally unique.  Of
   course, the combination of the (public) IP source address and the
   identifier (i.e., HOST_ID) ends up being unique.

   If the HOST_ID is conveyed at the IP level, all packets will have to
   bear the identifier.  If it is conveyed at a higher connection-
   oriented level, the identifier is only needed once in the session
   establishment phase (for instance, a TCP three-way handshake), then
   all packets received in this session will be attributed to the
   HOST_ID designated during the session opening."

Cheers,
Med

-----Message d'origine-----
De : hiaps [mailto:[email-masked]] De la part de joel jaeggli
Envoyé : dimanche 9 novembre 2014 21:37
À : Behcet Sarikaya
Cc : [email-masked]; [email-masked]; BOUCADAIR Mohamed IMT/OLN; Brandon Williams; [email-masked]
Objet : Re: [hiaps] work to do

---

From: <[email-masked]>
Date: Wed, 12 Nov 2014 15:43:30 +0000

Hi Behcet,

We have chosen HOST_ID on purpose to explicitly show that we are asking for a user identifier or a subscriber identifier. What is needed is a ** demux information to unambiguously distinguish a host among those sharing the same IP address **. Whether that identifier is a some bits of an IPv4 address or IPv6 prefix is actually deployment-specific.

We could use HOST_NAT_ID but this would not work too given that the demux issue is valid for other non-NAT contexts such as A+P, application proxies, etc.

The demux is not necessarily an internal IP address as it would be assumed by XFF for instance. Think about the DS-Lite context where the same internal IPv4 address will be common to several DS-Lite serviced networks.

Cheers,
Med

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]] 
Envoyé : vendredi 7 novembre 2014 16:41
À : [email-masked]
Cc : [email-masked]; BOUCADAIR Mohamed IMT/OLN; Brandon Williams
Objet : Re: [hiaps] work to do

Hi Dirk, all,

What do you think?

Regards,

Behcet