[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: minor inconsistency in arch doc (maybe)
Scott,
>'- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the
>IPv6 "Next Header" fields. This may be an individual protocol number.
>These packet fields may not contain the Transport Protocol due to the
>presence of IP extension headers, e.g., a Routing Header, AH, ESP,
>Fragmentation Header, Destination Options, Hop-by-Hop options, etc. Note
>that the Transport Protocol may not be available in the case of receipt
>of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be
>supported.'
>
>I've always been under the impression that it is reasonable to use
>ESP/AH in this field, and in fact, this permits configuration of nested
>SAs, perhaps with different endpoints. The text seems to imply that this
>is inappropriate, but I don't think that's what is really meant. Earlier
>(section 4.4.1, last paragraph), explicit reference is made to using ESP
>as a selector for a discard action:
The only time two IPsec headers appear back-to-back is when AH and ESP are
used in transport mode. It was felt that there was not need to use both AH
and ESP together in tunnel mode and iterated tunnels always have IP headers
in between.
As Charlie noted, we once had another selector value, that distinguished
between transport protocols and whatever protocol was next, in support of
arbitrary nesting. However, because of the precieved complexity of
supporting such nesting, and because it did not seem that such nesting
really offered useful added security, this facility was dropped.
Steve
Follow-Ups:
References: