Subject: Re: FMIPv6 Security (was Re: [Mipshop] Confirmation on decision onHMIPv6 Security)

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 23 Nov 2006 15:07:30 -0800 (PST)

----- Original Message ----
From: Alper Yegin <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>; Vijay Devarapalli <[email-masked]>
Cc: [email-masked]
Sent: Thursday, November 23, 2006 11:16:21 AM
Subject: RE: FMIPv6 Security (was Re: [Mipshop] Confirmation on decision onHMIPv6 Security)

Hi Vidya,

> > > It is not practical to run IKEv2 with every AR to create IPsec SAs,
> > > given that AR changes may occur frequently.
> >
> > This is about running IKEv2 with the serving AR. If the AR
> > changes so rapidly that the MN does not have a chance to
> > complete one IKEv2 between the time it has established
> > network connectivity with the AR to the time it disconnects,
> > I'd say this is an extreme case. Does it make sense to rule
> > out a scheme as "not practical" under this circumstance?
> >
> 
> There is no operator that currently wants to run FMIP, given that it
> introduces additional signaling over the air, every time the AR changes.

If we are talking about Mobile IPv6 operators, I think we are only talking
about 3GPP2 and WiMAX. I've never heard FMIP being turned down because of
its over-the-air messaging. It's been always because such architectures
already take care of fast handovers without needing additional protocols.

This is correct indeed. 3GPP2 and WiMAX have bicasting which is similar to PAR-NAR tunnel. FMIP being IPv6 based might have been one obstacle. But I believe that FMIP should be adopted (maybe sometime in the future) as the unified handover signalling.

> If there is someone who wants to allow an additional 6-message exchange
> with the MN to create SAs for securing FMIP, sure - that is their call.
> But, this clearly is not the typical case.
> 
> >
> > > The target AR prediction
> > > often does not happen enough in advance or with enough accuracy to
> > > take on such an exchange. It is also impractical to expect
> > the MN to
> > > have a PSK with every AR that it might visit, which means
> > that we are
> > > really talking about running IKEv2-EAP.
> >
> > I don't understand this either. Given that typically AR is
> > same as NAS,
> 
> Huh? Maybe if you are running PANA, the AR will be the same as the NAS,
> but that is not a given even there. Are you saying that 802.11 devices
> are the ARs that run FMIP or are you saying that the 802.11 devices are
> not the ones running 802.1x and 802.11i/802.11r? I'm lost.

Don't be so lost. With CAPWAP and WiMAX NWG architectures, the NAS is no
longer on the AP/BS. NAS is on the AR. Same is true for 3GPP2.

> Using network access authentication and worse still, using the EAP MSK
> for generating keys for FMIP is a layer violation that doesn't fit with
> most models of network access being deployed today.

This deserves another thread, if you care to explain us why... I am not
aware of the issue.

> > you know MN and AR/NAS has a PSK (MSK) for
> > secure network access. So, MN and AR sharing a PSK is indeed
> > practical.
> >
> 
> Please see the above explanation. And, the MSK is not a PSK. 

As far as what goes into the IKEv2 as input, an MSK is as good as a PSK.
Practically, there is no difference. Who cares of one is driven from another
process, and the other is manually entered.

> Today,
> IKEv2 allows the use of MSK purely for one client authentication. An
> IKEv2 PSK, OTOH, could be used repeatedly for a number of IKEv2
> exchanges between two entities.

I'd appreciate more explanation on this too. 

Alper

> 
> Vidya
> 
> >
> > > The DH, combined with the minimum of
> > > 6-message exchange for IKEv2-EAP with every AR is extremely
> > impractical.
> > >
> > >
> > > For HMIPv6 or MIP6, the MAP/HA changes do not occur
> > frequently enough
> > > for this to be an issue. Further, from a practical deployment
> > > perspective, it is feasible to overlap the MAP coverage
> > regions such
> > > that the IPsec SA can be established with the new MAP before the MN
> > > starts using the new MAP.
> >
> > Alper
> >
> >
> >
> >
> > >
> > > Vidya
> > >
> > > > -----Original Message-----
> > > > From: Vijay Devarapalli [mailto:[email-masked]]
> > > > Sent: Tuesday, November 21, 2006 12:15 PM
> > > > To: Alper Yegin
> > > > Cc: [email-masked]
> > > > Subject: RE: FMIPv6 Security (was Re: [Mipshop] Confirmation on
> > > > decision onHMIPv6 Security)
> > > >
> > > >
> > > > > > Alper Yegin wrote:
> > > > > > > If EAP/IKEv2 is sufficient for HMIP, why not for FMIP as
> > > > > well? In other
> > > > > > > words, do we still need FMIPv6 security solutions?
> > > > > >
> > > > > > I don't think one would ever use IKEv2 with an access router.
> > > > >
> > > > > Why? What's wrong with IKEv2?
> > > >
> > > > I didn't say there is something wrong with IKEv2.
> > > > I just don't see it being used between a mobile node and
> > an access
> > > > router. IKEv2, like any other protocol has its applicability
> > > > scenarios, and I don't see FMIPv6 being one of them.
> > > >
> > > > I don't know what kind of answer you were expecting from me. :)
> > > >
> > > > Vijay
> > > >
> > > > _______________________________________________
> > > > Mipshop mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mipshop
> > > >
> >
> >

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop