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

[joel jaeggli <[e-mail]>]

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 <[e-mail]> 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.

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

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