Re: [MEXT] situation with the -whyauthdataoption document

["Narayanan, Vidya" <[e-mail]>]

I concur with many points Arnaud raises below.  I do agree that the
draft needs to be updated with the correct current status of things with
IKEv2/IPsec.  But, I don't think it makes sense to justify the use of
RFC4285 on the basis of implementation complexities associated with
using IPsec with MIP6, especially given that the complexity has to do
with NATs rather than MIP6. 

- Vidya

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Arnaud Ebalard
> Sent: Monday, September 08, 2008 5:46 AM
> To: Jari Arkko
> Cc: [e-mail]; Pasi 
> Eronen; [e-mail]
> Subject: Re: [MEXT] situation with the -whyauthdataoption document
> 
> Hi,
> 
> Jari Arkko <[e-mail]> writes:
> 
> > WG, Basavaraj, Gopal,
> >
> > I wanted to let everyone know where we are with this 
> document. It was 
> > in the IESG review a week ago. There are a few details to 
> change here 
> > and there, but the main issue is in Pasi Eronen's Discuss. It is 
> > copied below. I do agree with Pasi, and I'd like the 
> authors to revise 
> > the document accordingly. After this revision, it will be a much 
> > better document -- particularly because also adds important 
> arguments.
> >
> >> First of all, I should say that after working on the DSMIPv6 
> >> document, I'm rather sympathetic to arguments that perhaps using 
> >> IPsec for Mobile IPv6 wasn't such a great idea in hindsight
> 
> I am probably a bit biased on the topic but I am sure the 
> following arguments are valid.
> 
> IPsec works fine in IPv6 environments. It also works fine in 
> MIPv6 environments, even with dynamic keying when using the 
> appropriate interface between MIPv6 and IPsec/IKE.
> 
> NAT and IPv4 have always been problematic for IPsec/IKE. 
> MIPv6 has always been an IPv6 mechanism: we should not blame 
> the choice of IPsec now that IPv4 and NAT are on the table 
> with the design of DSMIPv6.
> 
> >> , and the authentication option can be valuable in some 
> deployments. 
> 
> in *some* deployments, maybe.
> 
> But in IPv6 environments, i.e. initial the target of MIPv6, 
> IPsec is available and the required extensions (interface 
> between IPsec/IKE and
> MIPv6) can be very limited in size.
> 
> >> [snip]
> >>
> >> Somewhat surprisingly for a document defending RFC 4285, 
> the document 
> >> also doesn't mention what's IMHO the *main* advantage of RFC 4285 
> >> over IPsec: implementation complexity.
> 
> All IPv6 stacks must support IPsec. For a MIPv6 
> implementation based on those stacks, adding the required 
> bits to support interactions with IPsec is not that complex 
> (less than 600 lines in Linux Kernel for current MIGRATE 
> implementation for both XFRM and PF_KEY, for instance).
> 
> Then, adding the missing bits for IKE requires some care but 
> it is not so difficult. If you want the values for userland 
> counterparts (MIPv6 daemon and IKE daemon), I can check.
> 
> Out of curisoity, can someone provide some feedback on RFC 
> 4285 implementation?
> 
> >>  Especially with new MIPv6 features like DSMIPv6 the interface 
> >> between IPsec stack and MIPv6 stack is getting complex
> 
> If normalized at some point, it will probably be ;-)
> 
> >> and the IPsec stack needs more MIPv6-specific 
> functionality (so you 
> >> can't necessarily use just any off-the-shelf IPsec stack
> 
> If "off-the-shelf IPsec stack" means only RFC430*-compliant 
> ones, that's true. Now, you can expect some common IPsec 
> stack to provide the required MIPv6-specific functionality if 
> those are normalized (i.e. IETF reference documents produced by a WG).
> 
> But we cannot blame the IPsec stacks not to implement 
> features that the IETF is not willing to work on / push.
> 
> Cheers,
> 
> a+
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
> 
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext