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

Re: Comments on AH and ESP drafts

> 
>  >(d) I haven't understood the reasons *why* for such a nesting
>  >between the same source and destination IPSEC system. I can
>  >understand nesting of the type where one of the endpoints varies
>  >between the "inner" and "outer" nesting (for example, where a system
>  >that is an endpoint for both an IPSEC transport mode connection as
>  >well as an endpoint for an intervening tunnel: it builds a transport
>  >mode IPSEC packet to send to its final destination, but then has to
>  >reencapsulate it in tunnel mode to get it through the tunnel). But
>  >this particular style of nesting hasn't made sense to me.
>
>  I have mixed feelings about this myself.  I'm not in favor or arbitrary
>  nesting, because of the potential complexity, but Charlie and a few other
>  folks have argued in favor of allowing it, e.g., to accommodate the use of
>  an outboard BITW implementation in conjunction with an integrated IPsec
>  implementation, when each was ignorant of the presence of the other.  I'd
>  prefer to establish a limited set of ordered combinations of AH and ESP, in
>  tunnel and transport modes, tailored to demonstrable, agreed upon host and
>  gateway requirements.  But, the WG has to decide on this and the traffic
>  favored the sort of unconstrained nesting that Charlie proposed, so ...
> 
> 
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?
Follow-Ups: References: