Re: Justifications for standardizing draft-ietf-mip6-auth-protocol-00.txt

I've read the draft and as many as possible previous comments about it
in the list, including Hesham's.
IMHO there are three main questions raised by the draft:
 1- IPsec (AH/ESP) as the way to protect the BU/BA
 2- IKE as the way to established the IPsec SA pair needed by 1
 3- AAA as the whole mechanism vs. as a bootstrapping mechanism.

About the point -1-, the draft is deliberately written to confuse this
issue with the -2-, at such a level I have a real concern with the fact
the authors are the chairmen of the WG.
I can't see a real argument about -1-, IPsec provides a proper protection,
including the anti-replay:
 - the anti-replay is necessary because the ordering of the BU sequence
   number can be cheated with two or more wraps. This is a minor point,
   IMHO not enough to banish manual keying from RFC 3776, but as a side
   effect automatic keying should be prefered.
 - the anti-replay can be provided by IPsec at the exception of manual
   keying (I'll be polite and I won't explain why). Note that the
   automatic keying term stands for any not manual keying, i.e., as soon
   as some mechanisms build session keys the keying is no more manual
   and anti-replay can (should!) be used. I don't understand why some
   persons seem to argue the opposite???

About the point -2-, IKE is the only universal way to establish IPsec
SAs today. There are many others, and we can imagine more, but they are
not universal so they had no place in the RFC 3776, even they are better.
An AAA mechanism for instance can provide more features (home address
assignment), can be more efficient (with piggy-backing) and can be even
more secure (ownership of the care-of address). This is known from years,
I wrote and participated to the writing of many drafts about it and
IMHO the "bootstrapping activity" of the WG is about to publish such
mechanisms as soon as possible, as the "alternate security" for the
routing optimization (note that the return routability procedure is
exactly like IKE, it is in the RFC 3775 not because it is very good,
but only because it is the only universal available solution which does
the job).
In conclusion I understand why some don't like IKE and want in their
environment switch to a better solution. But this is not a valid
argument about the point -1- or -3-.

In the point -3- I'll try to find what can be the difference between
AAA as the whole mechanism (i.e., the auth data option) and AAA as
a bootstrapping mechanism:
 - there is no real difference about what to implement: IPv6 compliant
   nodes already have IPsec (AH/ESP) and perhaps enough of the PF_KEY API
   to use IPsec. 3GPP2 nodes already support the whole AAA & co protocols
   they need.
 - both solutions need the specification of a new AAA application or
   of a new EAP stuff. We can discuss about what is the best but I can't
   see a difference which matters about we are talking about.
   To use other words, at least we need an attribute to carry the
   assigned home address...
 - both solutions need a session key and to exchange some parameters
   (for instance SPIs). IPsec can support more negociations but this
   is not a real advantage (i.e., the choice of algorithms will be static
   for instance). If one'd like to understand how the session key can be
   used, I highly recommend to look at the KINK documents.
 - in RFC 377[56], IPsec is not used only to protect home registration
   BU/BA but is used for other things, including HoTI/HoT. AAA as a
   bootstrapping mechanism has no problem to provide this, AAA as
   the whole mechanism can't. This can be a very unfair way to kill
   the return routability/routing optimization.

My proposal is to reject the auth data option and to publish an AAA based
bootstrapping mechanism as soon as possible as experimental protocol.
I know some of them are already implemented so why to continue to
lose our time (another opinion I share with Hesham :-)?

Regards

Francis.Dupont@xxxxxxxxxxxxxxxx