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

Re: doi-07/interoperability questions



Bob and Ben,

>>> >as to whether I should support mixed proposals.  My opinion is that it
>>> >makes sense to support AH (transport) and ESP (tunnel) with the
>>> >following encapsulation:
>>> >
>>> >[IP2][AH][ESP][IP1][upper]
>>> >
>>> >and to not support AH (tunnel) and ESP (transport).  Does anyone else
>
>This feels right to me.  What you are saying is that the gateways are
>maintaining a secure tunnel, which is separately authenticated. (I think
>:).  So you want the tunneled IP datagram in one piece.  The AH (transport)
>and ESP (tunnel) delivers this.  The AH (tunnel) and ESP (transport) breaks
>the IP datagram.

I'm puzzled by this example.  Since we discard the outer IP header at a
security gateway, AH appears to add no security that cannot be offered by
use of the authentication facility in the ESP tunnel.  Also, the Arch Doc
requires that any SA terminating at a security gateway be in tunnel mode,
implying that there is an inner IP header.  So, in this example, AH should
be considered tunnel mode, not transport mode.  The position of AH realtive
to the outer IP header is the same in tunnel and transport modes, so the
difference between the two modes is less apparent here, but the
implications for header checking after processing are different.  In
reducing the required set of AH and ESP combinations to be supported, as
per the December IETF, we don't require support for nested AH + ESP in
tunnel mode, so we'd have to add this back in.  I may be that folks at that
meeting didn't feel the need to reatin this support for the reason cited
above.  Anyway, please think about the basic question of what features are
provided by the use of AH here, so we can decide if it's appropriate to
modify the arch doc again to accommodate this combination.

Steve




References: