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

Re: (in)security of ESP with header compression


At 01:21 PM 4/16/2003 -0400, Derek Atkins wrote:
David Mcgrew <mcgrew@xxxxxxxxx> 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.

That makes sense. For the record, the IPCOMP definition concerns inter-packet state, it says that "each IP datagram is compressed and decompressed by itself without any relation to other datagrams".

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

IPHC and ROHC were designed with links in mind, but there is now interest in adapting them for use at the internetwork layer. The AVT WG enhanced compressed RTP is one of these efforts. I think that there's similar interest in ROHC WG, though I am less familiar with that work and should let someone from that group comment. I don't think that it's a bug that the compression methods assume a reliable link, since compression is much easier when you can make that assumption. But certainly a more robust compression scheme would be more generally useful.



> 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 Atkins
       Computer and Internet Security Consultant
       derek@xxxxxxxxx             www.ihtfp.com