Re: (in)security of ESP with header compression

[Derek Atkins <derek@ihtfp.com>]

David Mcgrew <mcgrew@cisco.com> writes:

> > The big question for IPsec is whether ROHC can it be considered an
> > IPCOMP instance and thus fit within the existing framework.
> 
> The IPCOMP spec is only intended for stateless compression algorithms.
> It doesn't say if this is because of the security issue due to packet
> reorder or not; this might just be an assumption of the authors.

It depends on your definition of "stateless."  I believe that you can
have "state" (just like you require cryptographic "state" in order to
process ESP or AH).  However, the key is that there is no inter-packet
state.  That requirements stems from 2401 (IIRC), due to the IPsec
architecture treating each packet individually.

So, I don't see why IPCOMP should be any different than ESP or AH in
terms of packet independence.  If ROHC is truly dependent on packet
ordering, then I think this is a bug in ROHC and needs to be addressed
there.  It certainly limits the types of links in which ROHC can be
used.

> Another point about IPCOMP is that it would be useful in exactly the
> same situations that header compression would be useful.  It is
> probably desirable to allow the use of both mechanisms simultaneously.
> I am not sure if IPCOMP allows multiple compression methods, but I
> suspect that it does not.
> 
> IPHC is also of interest as well, though I don't think that it raises
> any issues that ROHC doesn't.
> 
> David

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com