Subject: arguments in favor of ND-based solutions

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Jun 2003 10:39:10 +0300

Hi,

Tuomas Aura asked me to send his list of arguments
in favor of a ND-option based solution to the list.
You will find the list below.

We also talked about transition mode in the ND-option
case, and Tuomas promised to think about it. I feel
that the way I defined it in draft-send-ndopt.txt, it
still needs some work... I'm quite happy with the rest
of the design but this is still somewhat unclear.

--Jari

(1) The IPSec architecture is not particularly suitable for
SEND and other potential applications of CGA. My main concern
is that the IPSec policy only accepts or drops packets.
Information about the type and strength of the authentication
is lost. There is no way to allow both authenticated and
unauthenticated packets of the same type, or to differentiate
between different types of authentication.

Example: The SEND protocol currently does not allow SEND
nodes to receive both secure and insecure ND and RD
messages. This limitation is caused by the decision to
use IPSec AH. If the authorization data were in the
ICMP message options, it would be possible for a host
to have both secure and insecure personalities.

(2) The IPSec policy selectors will never cover all the
possible information that application protocols might
want to take into account when verifying the authentication
on a packet.

Example: RS messages need authentication only if they
contain the Source link-layer address option. Similarly,
a RA message needs trusted-root+CGA authentication if
the Source link-layer option is present and only
trusted-root authentication if it is not. (Admittedly,
the option SHOULD be present in these cases.)

(3) Using the CGA+AH headers in a new protocol might not
as straightforward as hoped. The CGA mechanism is
typically used for authenticating IP-layer
signaling messages where the IP addresses are used in
some "funny" way. Otherwise, there would not be the need
to prove address ownership. Thus, it will not be sufficient
to configure the IPSec policy and SAs for the new
applications. It will still be necessary to write
application-specific code to tweak the way in
which the CGA+AH headers are processed in the
specific application. This means that the expected
benefits from the layered solution do not materialize.

Example: If one tries to sign Mobile IPv6 binding updates
with the CGA+AH headers, the address to authenticate is not
the source address of the a packet but the home address
in the HAO. There is a chicken and egg problem between
processing the HOA, CGA+AH, and BU. They will need to
be processed as a monolithic message and not as a
layered one where the authentication is verified first
and the payload processed then. Thus, there is no benefit
from slitting the authentication data into separate headers.
It could as well be a part of the BU.

But as Pekka has pointed our earlier, there is always
a way around the limitations of IPSec. My question is,
does not make sense to twist the logic of other protocols
to fit the IPSec model of thinking?

There is another, procedural, issue:

(4) Application-specific authentication or authorization
mechanisms (new ND options) fall within the charter of the
SEND WG. Defining a new general-purpose variation of AH
does not. Thus, the process would have to involve other WGs
that have different goals, different historical baggage,
and different schedule. Synchronizing the work of multiple
WGs is guaranteed to either fail or to take years. Moreover,
if a new application of CGA needs to change the way in which
the authentication data is processed, it will be have to
go through the same process.

Example: Just take a look at the cross-posted messages
between IPSec and SEND.

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 19 Jun 2003 11:49:01 +0300

I will try to write down a drafty draft about the
inline KMP + AH approach today.  Unfortunately I am
leaving for a vacation tomorrow, and therefore I don't
have more time but just this day.

Now, some comments on Jari's argumentation:

> between different types of authentication.

Well, based on the discussion that is going on at the saag
ML, I think that a number of people disagree with you.

I do agree that the current SPD based IPsec "architecture"
makes that limitation.  However, at least some implementations
(KAME in particular) do carry already now some metadata up
from IPsec to the upper parts of the TCP/IP stack.  RFC2401
does not forbid that; it just does not mandate that, either.

Now, I think that in the long run we should enhance the
interface from IPsec up, and annotate the packets with
more information.  However, even that is *not* needed for
SEND. For SEND it is perfectly enough to use the source
address as a key, and only indicate whether a particular
source address was authenticated or not.

> use IPSec AH. 

Well, to be more precise, this is a decision caused by
the current use of a single SA at IPsec AH.  This could
be changed.

> If the authorization data were in the

So could a host that separates CGA and AH, and annotates
each address separately whether it is a secured or
insecured address.  I've already implemented the main
parts of the CGA related things on KAME; the AH modifications
must wait.

> want to take into account when verifying the authentication

Here I agree with you.  However, it may not be necessary
to use the selectors to cover all.  If AH can verify the
integrity and data origin authenticity of a packet, and
associate the packet with a unique SA, that is sufficient.
The protocols upwards in the stack can then use the SA
as a reference point when considering the validity of
application specific fields.

> contain the Source link-layer address option.

The ND layer can check whether the RS message carries
the said option, and if it does, drop the message if
the associated metadata indicates that the packet was
not authenticated.  If the packet was authenticated, the
ND layer can compare the Source LL address with the
credentials associated with the SA or source IP address,
and make its decision based on the credentials.

> Similarly,

I don't think we need CGA even if the src ll option
is present.  If you trust a node to be a router, you
should believe it also to be trustworthy enough to
select its own IP address.  Anyway, it can spoof any
node in any case, since it is the router.

> benefits from the layered solution do not materialize.

Jari, here I must respectfully disagree, though mostly
based on gut feeling only.

Could you please give an example of this application-specific
tweaking in the case of SEND?  And how come does that
tweaking to be done at CGA or AH processing, not only
at the application level?

> in the HAO.

That is mainly a limitation of the current MIPv6 design.
If RO BUs were sent with the HoA as the source address,
this problem would not appear.

IMHO, HAO is a hack, and it should not be used until
there is a binding in effect.  Hence, you should not
use HAO when you send an initial binding.

(I don't have time right now to think about your
alledged chicken-and-egg problem.  Maybe we can
return to it later.)

> to fit the IPSec model of thinking?

Indeed.  This is a very good, architectural question,
which should gain much more attention!

> go through the same process.

The SEND charter states:

2) A protocol for assuring authenticatable distribution
    of public keys, that allows for example tying a public
    key to a node's IP address or interface ID, ...,
    will be designed.

Hence, desiging a generic CGA extension header does fit
into the SEND charter.

Continuing,

3) The use of the key distribution protocol and public key
    cryptographic scheme for calculating digital signatures
    in IPsec AH and/or ESP headers will be specified.

Hence, using AH to carry a PK signature does fall within
the charter as well.

I do agree that mixing these two together, the way it is
currently done, may be considered as stretching the
charter.  I am sorry that I have not perceived that earlier.
However, keeping 2) and 3) separate does not need to
involve other WGs, since the work would clearly fall
within the charter.

So far, the only real change that SEND requires to AHbis
is to allow an AH to be selected based on the SPI and
the source address only (perhaps with the protocol field).
The reason for that is the desire to use PK crypto, not
the usage of CGA.

Making the change would involve removing one paranthesized
sentence from AHbis.  More would be better, but just that single
change would suffice.

--Pekka Nikander

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Jun 2003 14:52:27 +0300

> Now, some comments on Jari's argumentation:

Just a point of clarification. These arguments
were from Tuomas, though I do agree with them.

--jari