[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPCOMP and IPSEC
Marc,
> Jumping in here....
>
> > Roy,
> >
> > Actually, I don't think the way you proposed is correct. While IPCOMP
> > can be applied in either transport or tunnel mode it *has* to be applied
> > in the same mode as the parallel IPSec SA. The way you proposed has IPCOMP
> > in transport and IPSec in tunnel. That won't work.
> >
> > Dan.
>
> I think Dan's packet format makes sense, for the described scenario of
> a SG that is applying both compression and encryption/tunnelling in one
> step on behalf of a naive host. (As a side tidbit though, from the
> SG receiver's perspective of your packet Dan, isn't ESP really in
> Transport mode with respect to IPCOMP and its IPCOMP, in turn, thats in
> tunnel mode with a next header of IP? I don't recall any mention in the
> IPCOMP document of tunnel vs. transport, it seemed to assume that only
> ULPs are its next header payload but I don't see why that has to be.)
I guess you could say that ESP is in transport mode, but what about the
case where both AH and ESP are applied to the same packet:
[IP2][AH][ESP][IP1][data]
Is AH in transport mode?
> But isn't Roy's packet format OK for end-hosts that have a Compression
> Association between themselves (configured independently of IKE?) and
> there is an intermediate SG (based on its own policies and key
> negotiation) which is doing the tunnelling/encryption regardless
> whether the inner IP's payload is TCP or IPCOMP?
>
> I think Dan's scenario one that is likely to be widely deployed but Roy's
> format seems just as "correct" for host-based compression.
Roy's would correct if the compression was being done by the host before
passing the packet to the SG, but Stephen (in the original post that started
this all) stated that the original packet received by the SG was:
[IP1][TCP][data]
In this case I don't think it's legal for a SG to add anything-- IPSec or
IPCOMP-- in transport mode.
Dan.
References: