[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on AH and ESP drafts
Eric,
>This is making a working IPSec (system A) to work with a
>misconfigured IPSec system (system B). I think this is wrong.
>The misconfigured system will have SAs in two separate spaces,
>in the BITW IPSec and also in the native IPSec.
>
>When system A initiates the connection, it has only one set of SA
>bundle attributes and will not work with system B, one of the IPSec
>processing (most likely the BITW IPsec) will consume the headers
>and the other would fail the policy check.
>
>When system B initiates the connection, it may work due to two
>separate key negotiations and system A process the headers intertively
>(ignoring the local policy). However; this is a side effect of
>a misconfigure remote system. It will not work with manually
>configured SA, unless someone goes thru the trouble of configuring
>both SAs in the native and the BITW IPsec.
>
>Am I missing something?
The proponents of this approach would argue that supporting the BITW IPsec
along with the native IPsec in system B is a feature that makes IPsec more
flexible. There is nothing intrinsically wrong with being able to support
such a configuration; it just makes life more complex and, as Cheryl
pointed out, ISAKMP is not capable of coordinating the SAs at the other
end, thus arguing against support for such complex configurations at the
current stage of Ipsec evolution. The resolution that I would suggest for
this sort of situation is to restrict the MUST support set of SA types for
now, with the intent of expanding this in IPSecond.
Steve
Follow-Ups:
References: