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

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:hiaps-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Donnerstag, 12. Dezember 2013 18:47
To: joel jaeggli
Cc: hiaps@ietf.org
Subject: Re: [hiaps] with respect to the BOF request.

On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>> wrote:
On 12/12/13, 9:19 AM, Behcet Sarikaya wrote:
> Hi Joel,
>
> Thanks for your comments.
> My views inline.
> Med can say more...
>
>
> On Thu, Dec 12, 2013 at 2:31 AM, joel jaeggli <joelja@bogus.com<mailto:joelja@bogus.com>> wrote:
>
>>> 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.
>>
>> 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.
Oddly I don't agree. being an emergency does not absolve us of dealing
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.

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

> 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.
>>
>>
>> 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.
yeah that's not what I took away from the dicussion.

I hope it is clarified now?

>
>
>> _______________________________________________
>> hiaps mailing list
>> hiaps@ietf.org<mailto:hiaps@ietf.org>
>> https://www.ietf.org/mailman/listinfo/hiaps
>>
>>
>