[Mobopts] RE: [Mipshop] RE: Review of draft-vidya-mipshop-handover-keys-aaa -00.txt

[Narayanan Vidya-CVN065 <vidya at motorola.com>]

James,

> >
> 
> No, the idea is to minimize the different protocols on the 
> host, and to align the signaling for the handover key 
> exchange with network access authentication. There's no way 
> to get around having the AAA-AR SA if you want to do key 
> exchange with it.
> 


I am not sure what it really means to support an additional protocol on the host. We are talking about support for the same functionality regardless of whether it is an extension of an existing protocol or a new one. The fact that it is running on a different UDP port should not be a factor in my mind. Now, if there is replication of functionality between two protocols running on a host, I see your point of re-use. But, in this case, I don't see replication of functionality. I don't see an incentive to align the signaling for handover key exchange with network access - if anything it seems to be complicating the design due to its dependence on different types of L2 protocols. If there is a way to avoid having the AAA-AR SA, I can see that being an incentive - but, that seems impossible - so, I am still not seeing the point. 


> >
> I think I see your point. Your point is that the EAP is end 
> to end, host to AAA server, and that the EAP-AMSK will end up 
> at the NAS when it needs to be at the AR.
> 

Yes. 

> Here is a possibility. The pAR asks the NAS for the key when 
> the FBU arrives from the MN the first time the MN hands over. 
> If the NAS is co-located with the pAR, then this is just an 
> API call within the router, and fast. If the NAS is at an AP 
> (such as 802.11) then it would require a Radius transaction, 
> which will be slow and undesirable since it is part of the 
> handover path. But note that this need only occur the first 
> time the MN hands over. Since nAR also handles the FBU and 
> the MN must authenticate through the NAS on nAP first in 
> order to be able to send the FBU (in which case the new 
> EAP-AMSK will be at the NAS prior to the FBU  being sent), 
> nAR can ask the NAS for the MN's handover key when the FBU 
> goes by. This need not delay the FBU, since nAR doesn't need 
> the handover key for processing it, because the FBU is going 
> to pAR. Later, when the MN hands over from nAR, the key will 
> already be there when the FBU arrives from the yet newer AR.
> 

Certainly, we can come up with a way of pushing the key from the NAS to the AR - the thing I am struggling with is that this seems more complex to me than the AR itself getting the key in the first place. We now require different NAS-es - APs, 802.16 BSs, PAAs, etc. to support this functionality. There is not much difference in what the MN does - instead of requesting a handover key through the NAS, it requests it from the AR with which it intends to share it. Also, why should we require a L2 entity to cache the HKs for an MN? 802.11 and 802.16 seem to be having enough key caching problems on their own for pre-authentication and predictive handoffs, etc. So, I don't think it makes sense to say that the NAS needs to store the key until the AR asks for it. Also, the NAS probably doesn't know anything about the lifetime of the key (nor should it) - so, how long does it cache it if the AR doesn't ask for the key for a long time? 


> There are also a couple other ways the NAS could get the key 
> to the first AR prior to the first handover. Unfortunately, 
> Radius isn't one of them, because Radius doesn't allow push. 
> Diameter would work, however. Also, if the NAS sends some 
> kind of COPS or SNMP message to the AR to unblock Internet 
> routing, that would provide another vehicle. The AR could 
> also ask for the key using Radius after performing the first 
> NS/NA (aka ARP) to get the MN's IPv6 address to link address 
> mapping, if it doesn't have the key, or upon reception of an 
> outbound packet with no neighbor cache entry for the IPv6 
> address, or upon reception of an RS from the MN with a SLLAO. 
> Triggering on link address to IPv6 address mapping would 
> probably be best, because it allows the AR to establish the 
> linking between the address as the name for the key and the 
> key itself.
> 
> Also, I think that the extension in this case would be for 
> Radius not EAP (sorry about that) because EAP is end to end 
> and the host isn't getting the key. The Radius extension 
> would work for both the link authentication and PANA case. In 
> the link authentication case, the handover key would end up 
> on the NAS, in the PANA case, it would end up on the PAA. In 
> either case, the AR would need to know the relevant gateway 
> to ask, of course, but the same Radius handover key extension 
> could be used to ask the router.
> 

I see the same issues on any of these approaches. 

> > - Along the same lines, I especially see a problem when 802.11r is 
> > used -
> in this case, there may not be an EAP exchange when the MN 
> hands off. What happens then?
> 
> I think preauthentication is an option for 802.11r. If 
> preauthentication is used, the key can be distributed to the 
> NASes during the preauthenication phase. The nAR can fetch 
> the key from its local NAS when the FBU for pAR goes by, or 
> on NS/NA if its the first time, as above.
> 


So, now we have to define something different for an 802.11r like scenario. Pre-authentication is not a given for all systems. It comes with its own set of problems and people are still trying to see if it makes sense or not. It doesn't seem like we can have a general solution here. 

Also, what if later on we wanted to use this protocol over 802.11s? They do EAP in a slightly different manner and IEEE is still flushing out details. Regardless of the L2 protocol, people use IP at L3 to be able to leverage the standards and protocols. So, in general, I view L3 independence of L2 as a benefit. 

> >
> > - This method, as Rajeev pointed out, puts HK derivation in the 
> > critical
> handoff path. That seems unncessary. The MN should be able to 
> hand off with only the essential steps and nothing else.
> >
> 
> Only for some specific  and very limited cases (i.e. if the 
> pAR needs to ask the NAS for the key when the FBU arrives on 
> the very first handover in the access network). And if the 
> bootstrapping procedure using NS/NA described above is used, 
> then it need not even happen then.
> 
> How does that sound?


If we were to design the protocol and architecture with a requirement that states "MUST be tied to network access authentication", I can see having approaches like this. But, the requirements we designed against were more like "MUST be simple" and "MUST be able to use the MN-AAA secret that is already present for EAP purposes" and this in my mind does not lead to an approach tied to network access. These approaches seem to be adding functionality to an entity (NAS) that does not really need to be part of this protocol. And, at least up to this point, I am not able to see what it buys. 

This will be a useful discussion to have in Paris. I will bring it up in the presentation so that we can discuss it further. 

Vidya

_______________________________________________
Mobopts mailing list
Mobopts at irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts