Re: [MEXT] situation with the -whyauthdataoption document

["Ahmad Muhanna" <[e-mail]>]

I also would like to comment on the justification of the need to use
Auth Protocol (RFC4285) based on the argument that MIP6 IPsec based
solution is becoming very complex.

I agree on the fact that any IPv6 mobility protocol (Client based or
Network based) needs to sincerely address the transitional period of
IPv4 transport/addressing while evolving to a full IPv6 deployment. I
also may add that this transitional period could take a long time.
However, trying to address every home-made deployment where a NAT MAY
exist in any place in the network is to some extent an exaggeration, the
least to be said. Also, IMO, that does not help in speeding IPv6
deployment nor shortening the transitional period.

For sure when all kind of NAT possibilities needs to be considered then,
you will have a complex IPsec based solution. But, many deployments do
not need to have that complexity! IMO, the best approach is to define
the respected standard which addresses the major deployments where a NAT
is not present and, after or in parallel, the solution which addresses
the presence of NAT wherever it is needed or any where in the network is
developed. This way we can have a more accurate assessment of the
complexity of the IPsec base MIP6 protocol before making a 180 degrees
turn and start contradicting what has been said about Auth protocol and
RFC4285.

Additionally, since probably all of the supporting mechanisms for a full
and dynamic deployment of IPsec based MIP6 solution has been identified
over the last few years, it will be a very good to have a quick exercise
on what is needed to bring Auth protocol solution to equal footing and
probably then compare its complexity too!


My 2 cents.

Regards,
Ahmad
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Narayanan, Vidya
> Sent: Monday, September 08, 2008 6:35 PM
> To: Arnaud Ebalard; Jari Arkko
> Cc: [e-mail]; Pasi 
> Eronen; [e-mail]
> Subject: Re: [MEXT] situation with the -whyauthdataoption document
> 
> 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
> 
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext