Subject: RE: [rohc] Notes from the HCoIPsec Side-Session at IETF (03/20/06)

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 7 Apr 2006 16:44:12 +0200

> On Apr 05 2006, at 23:19 , Jan Vilhuber wrote:
> 
>> I would think not, as regular IPHC is still used as well.
> 
> Jan,
> 
> it seems you are missing the context of this discussion: the idea is
> that IP-HC (2507) and CRTP/ECRTP (2508 etc.) become another (set of)
> profiles in the ROHC framework, so there is no need to switch
> frameworks, just to select the right profile within the framework.
> Yes, this still needs to be written up.
> 
> Gruesse, Carsten

Yes, that is how I interpreted the "whole picture" from Emre's mail.
If we were not to encapsulate non-ROHC in a ROHC envelope, we were to
either:
1) Assign multiple protocol numbers, one for each compressed protocol,
   which is out of the question.
2) Rely on negotiation between endpoints (IKE in this case) to make
   clear what "compressed" actually means. I really do not like such
   an approach, as it would make the protocol type dependent on other
   means to get a meaning. I rather have one single self-describing
   protocol identifier registered for "ROHC".

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Jan Vilhuber <[email-masked]>
Date: Fri, 7 Apr 2006 10:25:59 -0700

>> frameworks, just to select the right profile within the framework.

Ugh. If I don't have actual ROHC implemented in some device, how much  
additional crud will I have to implement just to get IPHC/ECRTP?  
Seems a bit silly to me, but OK. Compression isn't my field of  
expertise.

>    means to get a meaning.

But that's what IKE is supposed to do, and does pretty well. You  
don't send "packet encrypted with aes-256, authenticated with sha-1"  
in an IPsec packet. You send "SPI 12345678" and the endpoints have to  
KNOW what SPI 12345678 means. Same with compression: Both endpoints  
have to know which compression scheme is being used (and what  
parameters were negotiated; i.e. number of slots and so forth), and  
hand it to the appropriate one when doing IPsec processing. There's  
nothing unusual with this approach.

jan

> I rather have one single self-describing

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Fri, 7 Apr 2006 20:06:58 +0200

> additional crud will I have to implement just to get IPHC/ECRTP?

Not much to get only the ROHC-envelope.

> But that's what IKE is supposed to do, and does pretty well.

Yes, for this specific IPSec solution for ROHC, but if we allocate a
protocol type it should not be defined only for this solution, and 
having
it self-describing would in my mind be a proper design choice.

I do not like the idea of confusing compressed packets from the generic
header compression platform (ROHC) with packets also from specific
schemes in the one single protocol id we would then allocate.

/L-E

---

From: Jan Vilhuber <[email-masked]>
Date: Fri, 7 Apr 2006 11:36:11 -0700

On Apr 7, 2006, at 11:06 AM, Lars-Erik Jonsson wrote:

>> Ugh. If I don't have actual ROHC implemented in some device, how  
>> much additional crud will I have to implement just to get IPHC/ECRTP?
>

How many bits does it add on the wire to have this?

> it self-describing would in my mind be a proper design choice.

Well I actually never thought we needed a protocol type allocated by  
IANA, since the protocol number used in IPsec (which is what we're  
talking about. This is afterall HCoIPsec we're talking about) is  
relevant ONLY to the endpoints. Since the packet is encrypted, no one  
in the middle will see it, and after decapsulation no one will see it  
outside the tunnel either.

So I find it perfectly acceptable to simply negotiate a random (well  
maybe not random) protocol number both ends agree to define as  
"compressed packet". As long as that protocol number doesn't conflict  
with any other traffic flowing in the tunnel, this isn't an issue  
(and there's so many unused or rarely used protocol numbers to pick  
from...).

jan