Subject: Dependency on informational documents (was RE: [Mipshop] FMIPv6 - FBU Authentication)

From: "Narayanan Vidya-CVN065" <[email-masked]>
Date: Mon, 24 Oct 2005 12:14:32 -0400

All,
I'd like to raise a general question on dependencies on informational
RFCs for a different standards track document. The particular discussion
corresponds to the re-use of the MIP6 auth protocol and the definition
of an MN-AR auth option sub-type based on the same for deriving
AAA-based handover keys and also for carrying auth data in FMIPv6 for
FBU/FBAck. 

We re-use the MN-AAA auth option to carry authentication data from the
MN to the AAA server in draft-vidya-mipshop-handover-keys-aaa-01. We
also use the MN-AR auth option defined in
draft-narayanan-mipshop-mn-ar-auth-option-00 to carry authentication
data between MN and AR. The proposal was to use the latter also for
carrying authentication data in FBU/FBAck. 

The issue is that "Authentication Protocol for MIP6" is an informational
document, while 4068bis and the handover keys using AAA work are both
targeting PS. 

>From a technical standpoint, it makes perfect sense to simply re-use the
defined options rather than define new ones. The question needs to be
answered from a non-technical document dependency point of view. 

We can define new options if such dependency is an issue, but it is
going to look the same as the ones already defined :) 

Do the chairs have an opinion on this? Since the dependency here is on a
mip6 informational document, I've copied the mip6 chairs as well. 

Thanks,
Vidya

ps: Links to relevant drafts
http://www.ietf.org/internet-drafts/draft-narayanan-mipshop-mn-ar-auth-o
ption-00.txt
http://www.geocities.com/hellovidya/draft-vidya-mipshop-handover-keys-aa
a-01.txt 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan Vidya-CVN065
> Sent: Monday, October 24, 2005 9:58 AM
> To: [email-masked]
> Cc: mipshop
> Subject: RE: [Mipshop] FMIPv6 - FBU Authentication 
> 
> Hi Francis,
>     
> > => it makes sense but IMHO this is not a good idea: the 
> > "Authentication Protocol for Mobile IPv6" is for specific 
> environments 
> > and should be informational for ever, so if you use it you 
> should be 
> > restricted to these environments and never go to standard track. I 
> > think you should look at better bootstrapping stuff, 
> including IKEv2 
> > which seems the best general mechanism, and AAA-based 
> mechanisms which 
> > should be applicable in your special case.
> > 
> 
> The dependency on an informational document did concern me as well.
> Please note that we aren't using this to bootstrap a key 
> between the MN and AR. The AAA-based or SEND-based mechanism 
> will be used to create the shared key itself. Once a key is 
> available between the MN and AR, this is just providing a 
> means of carrying the SPI and auth data between the MN and AR. 
> 
> We can define a separate mobility option independent of the 
> mip6 auth protocol - but, it is going to look identical :) 
> However, if folks think that just for the sake of removing 
> the dependency on informational documents, that is better, we 
> can certainly go that route. 
> 
> Comments? 
> 
> Regards,
> Vidya
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

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

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Oct 2005 23:33:37 -0700 (PDT)

This shouldn't be a major concern: if your draft ends up having good support, if it's
sound,
generally applicable, etc, then this could be a good reason to push the
informational draft into PS as well. I'm a little hazy as to the details, but this
is pretty much what happened with GRE. It was an informational document until
mobile ip (perhaps other reasons as well) revived it into a revised document
that went to PS.

-gabriel