Re: (in)security of ESP with header compression

[David Mcgrew <mcgrew@cisco.com>]

Derek,

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

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
>used.


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.

thanks,

David



> > 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