Re: [rohc] RE: (in)security of ESP with header compression

["Mikael Degermark" <micke@cs.arizona.edu>]

I believe that the compressor also needs to be involved, 
as reordering can only be detected by the decompressor
if the compressor ensures that the sequence numbers it
sends out are ordered.

Is there still an equivalent to the IPv4 protocol or IPv6
Next Header field in the new ESP header?

Micke

----- Original Message ----- 
From: "Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>
To: "Yaron Sheffer" <yaronf@gmx.net>
Cc: <rohc@ietf.org>; <ipsec@lists.tislabs.com>
Sent: Friday, April 18, 2003 12:34 AM
Subject: RE: [rohc] RE: (in)security of ESP with header compression


> Yaron,
> 
> > ESP includes a 32-bit sequence number. It is mandatory for 
> > the sender to set and increment it correctly, but optional
> > for the receiver to verify it. It is there to prevent
> > malicious replay of messages.
> >
> > Under these assumptions, I don't believe any change to the
> > operating assumptions of ROHC, or a new ROHC profile, is
> > needed. This is not "ROHC over tunnels" but only "ROHC over
> > ESP", but it's still an interesting case.
> 
> This is the approach we have previously discussed in ROHC
> (just informally), and most tunneling protocols seem to have
> a similar sequence number. The solution would then just be
> a modified decompressor, making use of the tunnel sequence
> number.
> 
> But still, someone should look more carefully at this, and
> write something.
> 
> Rgds,
> /L-E
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
>