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

Re: order/nesting of IPsec headers (transport mode)

I think that the question is really two questions humped together, and
that the answer(s) depend on which question one is really answering.

First, on the originating side, I agree that 1 thru 3 are reasonable,
i.e.,

	An implementation MUST be able to generate the following
	combinations of AH and ESP headers:  AH only, ESP only, and
	ESP above AH (i.e., in the outbound direction, do ESP
	processing, then do AH processing).

	Those implementation which choose to support other
	combinations MAY do so.  When doing so, an implementation MUST
	appear to have inserted the AH or ESP headers one at a time,
	from "top" to "bottom".  Note that this restriction is only
	significant for AH processing, where it means that the AH ICV
	computation must not cover any "lower" AH or ESP headers (that
	will be (logically) inserted later).  Note further that this
	means that the value in the "Next Header" field in the
	extension header before AH (ignoring any AH or ESP yet to be
	inserted) would be "AH" for the AH ICV computation, then
	changed when the next lower AH or ESP header is inserted
	(and the IP length field updated to include the new header).

As others have said, I do not think that any combination should be
prohibited at the receiver.  This is consistent with the current IPv6
specification.  Consequently,

	An implementation SHOULD be able to receive any combination of
	nested AH or ESP headers.  Each header should be processed,
	from "bottom" to "top", as follows.  The header should be
	processed according to the protocol, AH or ESP, and then
	(logically) removed from the packet, before proceeding to the
	next extension header.  Note that when the header is removed,
	the "Next Header" field in the extension header preceeding the
	one being removed will be changed to the value in the "Next
	Header" field of the AH or ESP being removed.


For example if ESP proceeds AH at the receiver, ESP would be processed on
the packet:

+--------------------+--------------------+--------------------+---+--------+
|IP, Next Header: ESP|ESP, Next Header: AH|AH, Next Header: TCP|TCP|ESP trlr|
+--------------------+--------------------+--------------------+---+--------+

When ESP processing is complete, the ESP header would be removed and
AH processed on the remaining portion of the packet.

+--------------------+                    +--------------------+---+
|IP, Next Header: AH*|                    |AH, Next Header: TCP|TCP|
+--------------------+                    +--------------------+---+

Note the change in the Next Header field of the IP header from ESP to AH*.

The reason for the procedures given above is to make things work when
a sender is using a hybrid stack, and the separate implementations,
e.g., bump in the wire and an imbedded or user space implementation,
and the two are not aware of the presence of the other.

In case it is not obvious, "removed" does NOT mean treaded as being zeros.

(While some might think that this is "too complicated", I do not think
it is from an implementation perspective.  It probably means that my
text needs some wordsmithing. :-)

While the question was specifically directed at transport mode, I think
that the same answers should apply to tunnel mode, as the choice of
where policy gets implemented should be left to the customers.

Charlie
Follow-Ups: