[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: order/nesting of IPsec headers (transport mode)
This message responds to messages from several folks in response to Karen's
message:
Mike-
If you persue Karen's note again, you'll notice that all of the examples
were cast on the context of transport mode, not tunnel mode, so some of
your observations re nesting are not applicable. I also have been of the
mind that AH must always immediately follow IP (modulo intervening IPv6
headers), but from several of the other responses, not everyone has the
same model. Hence the need to raise this issue.
Angelos-
The main issue here is what MUST a compliant implementaion support, both in
terms of inbound and outbound header configurations. If one were to
require support for arbitrary combinations of headers, this will increase
the complexity of implementations, and of the management interfaces needed
to be able to express the varried combinations. An intermediate position
it to mandate support for some minimal combinations (as Karem suggested),
but allow use of more elaborate combinations. However, this creates
opportunities for non-interoperability, e.g., allowing for special case
combinations that may work only if the same vendor's implementations are
employed at each endpoint.
Rodeny-
Note that AH and ESP are defined as extension headers in the IPv6 context.
IPv6 states that no more than one instance of an extension header (other
than destination options) shall be generated by a host. That would say
that duplicate AH instances as you describe are inappropriate, at least in
the IPv6 context. Admittedly, the IPv6 spec later goes on to argue that
hosts should accept the duplicate extension headers that it earlier
proscribed! I tend to view this as a failure of the standardes process ;-).
You asked if there had been discussion on the list, since 1825 did not
restrict combinations, and why did we need to change what 1825 said. The
answer is that 1825 did not spell out many architectural details and that's
why we're generating a new architecture document. Ran's last I-D in
November did include text dealing with this issue, but no feedback was
received on that draft. The IPv6 spec does call for an ordering of AH and
ESP (which is currently backwards, but will be fixed), so that WG thinks
such an ordering is appropriate to spell out. Implementors have
consistently argued for minimizing complexity in IPSEC; restricting the
ordering and nesting of headers, at least in terms of what MUST be
supported, is clearly in the vein.
Steve
References: