Re: New Radius/Diameter authentication and key delivery for FMIP application

[Jari Arkko <jari.arkko@piuha.net>]

Vidya,

>
>>Some background on why this is needed particularly for a 
>>protocol such as FMIP 
>>
Thanks for the background!

>>>First of all, I don't want to take on work if it runs into 
>>>      
>>>
>>significant 
>>    
>>
>>>problems in parts that MIPSHOP does not own.
>>>
>>>      
>>>
>>I am missing something here. AAA-based support is seen as 
>>needed - just like how MIP6 (and many other WGs) come up with 
>>AAA protocol needs and address it via the respective AAA WGs, 
>>we would have to do that. Why is the situation different for MIPSHOP? 
>>    
>>
I hope we can get the AAA support -- but I want to get
a prior agreement from the relevant folks that this
is indeed possible even in this case. I worry that there
*might* be a problem if the Zorn keyreq stuff has been
stuck for years, too.

>>>Secondly, I worry about the practical impacts to AAA 
>>>      
>>>
>>infrastructures. 
>>    
>>
>>>Having a new "transaction"
>>>or application implies that additional support may be needed before 
>>>this can actually be used.
>>>
>>>      
>>>
>>I'm not really sure why this is a concern. Saying that 
>>support for "secure" FMIP requires additional AAA attributes 
>>- but then, we have a need for new AAA features any time a 
>>new protocol impacting authentication/authorization is 
>>introduced in a system that relies on AAA for those things. 
>>Especially, I don't understand the alternative - clearly, the 
>>alternative of making SeND and SeND-based handover keys a 
>>requirement for FMIP deployment seems to be too restrictive. 
>>Or, are we talking about some other option that has not yet 
>>been discussed? 
>>    
>>
I believe AAA-based FMIP security is a useful goal for
us -- I don't want to back down on that. What I'd like
to get feedback on from the AAA doctors group is if
they see issues or other design alternatives, still
assuming a AAA-based model.

For instance, the design makes a tradeoff where
a fair amount of AAA support, possibly even new
credentials, are needed but it provides a simple
and efficient result for FMIP. Is this the only design,
and is there something that the AAA doctors would
rather recommend? And Vidya, can you elaborate
on why IKEv2-based mechanism would be insufficient
(I think you indicated that the exchange is not
on the critical path. But I may not understand all
the scenarios this may get used in.)

>>>Thirdly, I worry about doing only Diameter work for this 
>>>      
>>>
>>function. It 
>>    
>>
>>>seems likely that some potential users of FMIP technology 
>>>      
>>>
>>run a RADIUS 
>>    
>>
>>>infrastructure, and adopting this particular FMIP authentication 
>>>scheme may therefore in practise imply adopting a RADIUS 
>>>      
>>>
>>extension for 
>>    
>>
>>>this.
>>>
>>>      
>>>
>>Actually, this seems equivalent to saying that developing a 
>>protocol for IPv6 alone will make it useless to IPv4 
>>infrastructures :) 
>>
>>Ideally, there would be both RADIUS and Diameter support for 
>>this - but, I don't think it is bad to work with Dimateter 
>>support for this, at least initially. RFC4004 is an example 
>>where this kind of work happened first for Diameter. Not to 
>>mention, a lot of next generation architectures are starting 
>>to embrace Diameter. 
>>    
>>

Yeah. But realistically, if we know we are going to develop
the same stuff for both, shouldn't we allocate just one set
of attributes?

But the answer to that depends a lot also on the plans
for RADIUS - Diameter interoperation and RADIUS
attribute space extension.

--Jari