[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ICMP Security Failures

	 If AH didn't protect bits of the IP header, then AH would be
	 useless because it wouldn't provide efficient packet-origin
	 authentication, which is one of the main points of using AH.
	 While a pseudo-header might appeal to those more concerned
	 with theoretical purity than with practicality, there is ample
	 evidence that AH as currently specified can be built and
	 interoperate.  In Dallas several independent implementations
	 were shown to interoperate using AH, to give a concrete
	 example.

As has been pointed out in the past, if the SPI is bound to a source
address it doesn't matter if the address in the packet is protected or
not.  But you're right; that issue has been discussed ad infinitum.

I'm more concerned with two other issues.  The first is what we're really
arguing about here -- a mismatch between the syntax of header composition
and the semantics of (a) what we want to do, and (b) the ways we can
request such things, via (for example) Photuris.

Syntactically, we can build any sequence of nested headers.  There are
some definition issues with respect to AH -- and that alone should raise
a warning flag -- but for the most part, we can comgine anything with
anything else.

On the other hand, it isn't clear that most combinations make sense.
Furthermore, what the user and/or the user's program wants is to say
things like ``confidential'', ``authentic'', ``protected between these
two gateways'', etc.  At the very least, we need an RFC (or a section of
the architecture RFC) that maps such concepts into a particular set of
headers.  But that's another warning flag, that we have a structure
so general that we need to define a profile of standard subsets for
interoperability.  That way lies GOSIP and other forms of madness.

It isn't clear to me what the right answer is.  We could accept the
full generality, and redefine AH and ESP to permit that.  A necessary
consequence would be that we'd have to enhance Photuris to list the
desired choices for each nested header in a sequence.  From the sending
side, the semantics are clear; it's less obvious how to handle that on
the receiving side, since the user will have specified high-level concepts
like ``confidential''.

Another choice would be to admit that ESP is wrong, and to produce
a new AESP protocol that provides authentication and confidentiality.
We could add the (very necessary) replay protection at the same time.
(I confess I don't understand where one might want confidentiality without
authentication.)  Then our choice set is much reduced.

Finally -- and in the real world, this is probably the right answer --
we could have a very simple set of rules for legal header sequences.
Perhaps something like

	IP-AH-transp
	IP-AH-ESP-transp	(or switch ESP and AH if you want)

with tunnel mode -- IP+anything -- allowed instead of transp.  That is,
if you want to play funny games, such as multiple levels of authentication,
tunnel it and ignore the (miniscule) efficiency gains from leaving out
an extra IP header.

In a totally different vein, it isn't clear to me that it makes sense
to tie anything to IP addresses, and therefore to protect them.  While
I'm not yet ready to make any suggestions, the ipsec community should
review Christian Huitema's multihome draft to see where my concerns are
coming from.