Subject: Re: [rohc] FW: ESP and header compression (ROHC)

From: Bjoern Groenvall <[email-masked]>
Date: 15 Apr 2003 12:50:28 +0200

>>>>> "Lars-Erik" == Lars-Erik Jonsson (EAB) <[email-masked]> writes:

>> Taking the 'ROHC over re-ordering channels' question more
>> generally; RFC 3095 does not work in such an environment.  However,
>> we are (I believe) trying to address this issue as part of ROHC for
>> TCP...

Lars-Erik> This was a design decision we made for 3095, but personally
Lars-Erik> I think the modifications needed to make it work also in
Lars-Erik> case of mis-ordering are small. If someone wants to look at
Lars-Erik> this and write some input on it, I would be more than
Lars-Erik> happy.

The ESP and AH headers also have a "Sequence Number"-field that may be
used to detect reordering and packet losses.

/Björn

-- 
  _     _                                               ,_______________.  
Bjorn Gronvall (Björn Grönvall)                        /_______________/|     
Swedish Institute of Computer Science                  |               ||
PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
Email: [email-masked], Phone +46 -8 633 15 25              |      Cat      |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------'

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Tue, 15 Apr 2003 10:22:30 +0200

> generally; RFC 3095 does not work in such an environment.  
> However, we are (I believe) trying to address this issue as 
> part of ROHC for TCP...

This was a design decision we made for 3095, but personally
I think the modifications needed to make it work also in case
of mis-ordering are small. If someone wants to look at this
and write some input on it, I would be more than happy.

> Anyway, tunnels (and especially IPsec) can simply be treated 
> as a link.  In which case, rohc can be applied on that link.

Yes, a "ROHC over tunnels" document could potentially be 
justifiable.

> In the case of IPsec/ESP it may make a great deal of sense to 
> compress the headers inside of the tunnel encapsulation.  The 
> VPN endpoints are probably disjoint from any particular 
> physical link that benefits from compression and so, to me, 
> it makes sense to do the compression in the two different places.

Yes, that is what you would have to do if encryption is applied
over the tunnel.

/L-E