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

[Behcet Sarikaya <[e-mail]>]

On Thu, Dec 12, 2013 at 11:39 AM, joel jaeggli <[e-mail]> 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 <[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.
>
>
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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/hiaps
> >>
> >>
> >
>
>
>