Subject: RE: Issue 5: Updating device identifier

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 13 May 2003 12:19:21 -0700

> 
> On Mon, May 12, 2003 at 05:33:19PM -0700, Alper Yegin wrote:
> > 
> > http://danforsberg.info:8080/pana-issues/issue5
> > 
> > So, when does the PaC need to update its device identifier?
> > 
> > I don't think it ever needs to update its device identifier 
> if DI is 
> > its link-layer address. Generally an IP node should not 
> have to change 
> > its link-layer address.
> > 
> > If it is using RFC3041 - Privacy Extensions, this should not effect 
> > the IPv6 address used either. When IP address is used as 
> the DI, it'd 
> > be the link-local IPv6 address. Changing the global IPv6 addresses 
> > which are tunneled inside packets whose src/dst is the link-local 
> > address won't require a change in DI.
> > 
> > I'm not sure what is meant by "mobility management". What form of 
> > mobility will require change in DI in the context of a PANA session?
> > 
> > One scenario we have identified so far which potentially 
> requires a DI
> > modification:
> >     
> >     Imagine a network which uses IPsec for access control 
> but does not
> >     assign any IP address to PaC before they are authenticated.
> >     
> >     PaC successfully authenticates with the PAA without 
> acquiring an IP
> >     address initially. At this point, DI is the IP address, 
> but its value is
> >     0.0.0.0 or 0::0. Using the PANA SA and the PANA session 
> identifier, PaC
> >     can securely obtain an IP address from DHCP. Now PaC 
> can re-auth in
> >     order to notify the PAA (and, in turn EPs) about its IP 
> address. When
> >     the EP learns the new IP address, it can engage in IKE, etc. to
> >     kick-start IPsec-based access control.
> > 
> > I don't know of this really requires DI change, but here is 
> something 
> > else to consider:
> 
> The above PANA-DHCP-IKE scenario requires DI change, if IKE 
> operates in 
> pre-shared key authentication in Main Mode.  RFC 2409 says:
> 
>   "When using pre-shared key authentication with Main Mode 
> the key can 
>    only be identified by the IP address of the peers since 
> HASH_I must 
>    be computed before the initiator has processed IDir."
> 
> So, without notifying the PAA of the obtained IP address, it 
> is not possible for IKE to bind pre-shared key with the IP address.  
> 
> IKE pre-shared key authentication with Quick Mode allows more 
> Identity types, but IPsec DOI does not define link-layer 
> address to be used for IKE Identification Type.
> 
The scenario above requires a change from link layer address
as the DI (during DHCP) to IP address as the DI after Ipsec
is used for access control. So, this justifies the need to update DI.

-mohan

> > 
> >     When a PaC moves within the same access domain, instead of
> >     requiring a full authentication, network might be able to
> >     re-authenticate it using its ongoing PANA session with 
> another PAA of
> >     the domain (if it hasn't expired already).
> > 
> >     PaC can send its PANA session ID along with PANA_start 
> message sent to
> >     PAA. If the PAA has means to obtain a still valid PANA 
> SA from the
> >     previous PAA, it can respond with a PANA_reauth, 
> instead initiating a
> >     full authentication. Now PaC can respond with 
> PANA-reauth, and tag along
> >     the new DI.
> 
> What is the new DI?  If the DI used for mobility management 
> is link-layer address, it will not change unless 
> inter-technology handoff occurs.  So do you imply 
> inter-technology handoff?
> 
> > 
> >     The mechanisms needed to transfer PANA SA from one PAA 
> to another would
> >     be outside the scope of PANA. Context transfer protocol 
> (see Seamoby WG)
> >     might be used here.
> > 
> > Comments?
> > 
> > Alper
> > 
> > 
> 
> Yoshihiro Ohba
> 
>