Subject: RE: [mobile-ip] authentication and authorization ( was questions on fast handoffs for MIPv6)

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 11 Jun 2001 15:17:49 -0500

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Friday, June 08, 2001 6:05 PM
To: [email-masked]
Subject: [mobile-ip] authentication and authorization ( was questions on
fast handoffs for MIPv6)

Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> Alper,
> 
> Hate to bring security issues in here, since this was about buffering
> but, you brought it up :) Sorry.
> 
> 1-Why does MN need to authenticate itself to oldAR, while it
> is saying "goodbye" to it. It has been receiving service from
> oldAR so far, hasn't it?
> 

what Alper meant was the F-BU needs to have an authentication
header. this authentication header would make use of the
existing security association between the MN and the oldAR.

MN>> Thanks Vijay, I thought about it right after I sent the email :)

> 2-authentication of oldAR to newAR does not solve all the
>  security problems, what about
> authentication of newAR to oldAR, what about authorization of
> newAR to receive MN's packets?
> 

oldAR and newAR share a pair of security associations which 
protect the HI and HAck. the HAck has to come back before 
the oldAR starts forwarding the packets meant for the MN 
to the newAR.

MN>> Ok, If you have two SAs for mutual authentications, then that is
better. 

in the mobile controlled handoff case, its the MN which says 
i want to move to this particular AR. so here there is no 
question of authorization of the newAR to receive MN's 
packets. in the network controlled handover, its again some 
network entity which decides that this particular MN should 
be handed over to this AR. there is no question of 
authorization of the newAR in this case either.

MN>> Ok, assuming that authentication also means authorization,
 for network controlled HO it makes sense, if the two
ARs are authenticated to each other. For mobile determined, 
I thought mobile only knows the layer 2 device and not AR
 (I guess you again mean that during HI/HACK the newAR
proves to oldAR that it is authorized to get MN's packets)

madjid

Barani, this answers your question too. 

Vijay

> Madjid
> 
> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Friday, June 08, 2001 2:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6
> 
> >
> > I agree. It is also not clear on "mobile has not arrived". Has the mobile
> been
> > authenticated by the new AR? If not, how the new AR can receive packets
> for
> > un-authenticated mobile. We need to check security issues here.
> 
> F-BU authenticates MN to oldAR.
> HI authenticates oldAR to newAR.
> 
> If you are asking "how can newAR trust MN and release the buffers", that's
> outside the scope of this draft. Even without buffering, some other node on
> the
> same link can steal your traffic by overwriting neighbor cache of the AR.
> 
> alper
> 
> >
> > Barani.
> >
> >
> >
> >
> > James Kempf <[email-masked]> on 06/07/2001 09:41:22 AM
> >
> > Please respond to [email-masked]
> >
> > Sent by:  James Kempf <[email-masked]>
> >
> >
> > To:   [email-masked]
> > cc:    (Barani Subbiah/HQ/3Com)
> > Subject:  Re: [mobile-ip] questions on fast handoffs for MIPv6
> >
> >
> >
> > >Can you add the following text to the draft then?
> > >
> > >    When the newAR is receiving packets forwarded by the
> > >    oldAR for the MN, and the MN hasnt shown up yet, the
> > >    newAR SHOULD buffer packets. If the newAR does not
> > >    buffer packets, it would the packets meant for the MN.
> > >
> >
> > I don't think this text should be added.
> >
> > It is entirely unclear at this point whether buffering will work without
> causing
> > user-perceivable artifacts in real time streams. In fact, I know of
> > at least one experiment with buffering (in IPv4) that showed it cannot be
> done.
> > This experiment was not definitive, of course, but I think it is
> > not wise to write buffering into the standard until more is known
> > about whether it will work or not.
> >
> > There are other alternatives to handoff smoothing, for example bicasting,
> > that could handle some portion of the handoff smoothing task without
> > introducing artifacts. We need to leave the standard open on this
> > until there is more evidence.
> >
> >           jak
> >
> >
> >
> >
> >
> 
> alper