Subject: [hiaps] with respect to the BOF request.

From: joel jaeggli <[email-masked]>
Date: Thu, 12 Dec 2013 00:31:34 -0800

>Description: Host identification is required in IPv4 when the hosts are
behind a NAT box or
>when the communication is tunneled such as using IPSec. Host
identification is also
>required in IPv6 when the hosts are assigned addresses from a shared
prefix. In most of
>these scenarios, the hosts access the network using Wireless Local Area
Networks, aka
>Wi-Fi access. In case the hosts are behind a NAT box, there is a strong
need for the host
>identification when the host is accessing a fixed network and trying to
place an emergency >call.

It is likely given current events, that persistent identifiers visible
to on-path observers are going to be viewed by the IETF community in
general in an extraordinarily negative light. in particular in the IPv6
context I would think it antithetical to the goals of regular rotation
of temporary/privacy or cryptographically generated addresses to retain
host identity bindings that are visible outside a limited scope e.g. an
l2 domain and which persist across host address changes.

In terms of employing them for roaming, the question of how would they
be generated and where who they be stored becomes germain. What
semantics are they actually carrying and the question of persistence
further raises the  stakes with respect to revalation to remote observers.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 Dec 2013 11:19:43 -0600

Hi Joel,

Thanks for your comments.
My views inline.
Med can say more...

On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli <[email-masked]> wrote:

> I understand there are privacy concerns.
But in our case, we justify it strongly on a case-by-case basis.

In our IPv6 case, host identifier is IPv6 address and it needs to be
revealed to the edge router. We don't see any privacy issue here because
the edge router will know IPv6 address of the communicating hosts anyway.

In our IPv4 case, the situation is that the host is in the process of
making an emergency call. The call server to which the host identity will
be revealed has to find the position of the host in order to serve the
host.
Again we don't see the same effects of revealing the host identity  to any
server in this case. It is emergency call situation.

Having said the above two, I think we need to of course clarify these
issues in the drafts as much as possible.

In case of IPv4 we have many other cases, e.g. CGA and the concerns you
mentioned could be valid to some extent, I believe those are somewhat
clarified in Med's RFCs, Med can chip in here to say more.

> I think it was clarified during email discussions on the list that there
is no roaming case per se in hiaps, we do not have any case that requires a
persistent host identity during roaming. Of course we consider mobile hosts
but the identity will be different in each place.

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

---

From: joel jaeggli <[email-masked]>
Date: Thu, 12 Dec 2013 09:39:55 -0800

> server in this case. It is emergency call situation.

Oddly I don't agree. being an emergency does not absolve us of dealing
with the question of visibility on path.

> but the identity will be different in each place.

yeah that's not what I took away from the dicussion.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 Dec 2013 11:47:05 -0600

> with the question of visibility on path.
Of course, this brings the security of the protocols used in the solutions
issue, right?
We need to work on that. I believe the protocols can be made secure.

> yeah that's not what I took away from the dicussion.
I hope it is clarified now?

---

From: <[email-masked]>
Date: Thu, 19 Dec 2013 16:46:02 +0100

Dear all,
If you have followed the discussion below, it might be of interest to you that we are currently revising the description for the planned BoF in London and the proposed charter focusing on the emergency call location use case for reasons of privacy issues.
The new proposal will include the identified problems and try to fix the goal more clearly.
Also the existing work of other WGs on that topic will be considered.
We expect the updated text to post early next year and hope you will join.
Thanks!

Best seasonal greetings and kind regards
Dirk
From: hiaps [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Donnerstag, 12. Dezember 2013 18:47
To: joel jaeggli
Cc: [email-masked]
Subject: Re: [hiaps] with respect to the BOF request.

On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli <[email-masked]<mailto:[email-masked]>> wrote:
On 12/12/13, 9:19 AM, Behcet Sarikaya wrote:
> On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli <[email-masked]<mailto:[email-masked]>> wrote:
>

Of course, this brings the security of the protocols used in the solutions issue, right?
We need to work on that. I believe the protocols can be made secure.

>> [email-masked]<mailto:[email-masked]>