Subject: [rohc] RE: HCoIPsec Drafts

From: "Ertekin Emre" <[email-masked]>
Date: Wed, 1 Mar 2006 17:33:34 -0500

Jan,

Thanks for your quick response.  Comments inline...  

> In section 5.3, you say:
> "   In addition to the common functionality described previously, this
>     alternative uses the security protocol "Next Header" field to
>     identify packets that can not be compressed over an 
> HC-enabled SA.  A
>     single allocation for "compressed headers" will need to 
> be reserved
>     from IANA in the "Protocol Numbers" registry."
> 
> This is not really true, as the Next-Header number used is of 
> local significance ONLY, i.e. is relevant to the two IPSec 
> endpoints. Thus it can be any number we want it to be, and 
> the two ends can even negotiate it via IKE (v1 or v2... or 
> whatever keying mechanism (KINK, manual, etc), really). It 
> was always my assumption that we would pick any number (maybe 
> pick one as a best-practice for interoperability), but leave 
> it flexible.
> 
> If IANA is willing to allocate us a number for this, I would, 
> of course, be overjoyed. But I expect that to be an uphill 
> battle (and an unnecessary one, as we can pick any number 
> that the ends agree on).

This is an attractive idea -- and as you mentioned, one that wouldn't
require the allocation of a next header field value from IANA.  Though I
would like to note that the allocation of such a value may be beneficial
for other HC tunneling scenarios ... 

That being said, the allocation of an IANA value is not a requirement
for HCoIPsec Approach 2. 
 
> Also, the reason I think this (i.e. approach 2) is more 
> attractive is because, at least with IPHC (as opposed to 
> ROHC, which I know very little about), the compressor can 
> refuse (or fail) to compress an entire flow. It may have run 
> out of pre-configured (or pre-
> negotiated) slots for compression, which means that some (possibly
> large) number of flows could go uncompressed. When this 
> happens, having an additional number of bytes PER PACKET on 
> these flows will increase the total number of bytes sent by a 
> not insignifcant number (haven't done the math on this, but 
> my gut tells me that in the lifetime of, say, a file transfer 
> or a phone call, this really adds up; A byte here and there 
> multiplied by a large number is still a large number).

I agree that HCoIPsec Approach 2 is more efficient than HCoIPsec
Approach 1.

In subsequent releases of the alternatives draft, we can update the
"HCoIPSec Approach 2" section of the draft to reflect your comments.  In
addition, we can add sections on the benefits/considerations of each
approach to reflect some of the mailer list discussions.
 
> jan

Best Regards,
Emre

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

---

From: Jan Vilhuber <[email-masked]>
Date: Wed, 1 Mar 2006 09:25:59 -0500

Hi Emre,

Good summary. Thanks for sending it out.

In section 5.3, you say:
"   In addition to the common functionality described previously, this
    alternative uses the security protocol "Next Header" field to
    identify packets that can not be compressed over an HC-enabled  
SA.  A
    single allocation for "compressed headers" will need to be reserved
    from IANA in the "Protocol Numbers" registry."

This is not really true, as the Next-Header number used is of local  
significance ONLY, i.e. is relevant to the two IPSec endpoints. Thus  
it can be any number we want it to be, and the two ends can even  
negotiate it via IKE (v1 or v2... or whatever keying mechanism (KINK,  
manual, etc), really). It was always my assumption that we would pick  
any number (maybe pick one as a best-practice for interoperability),  
but leave it flexible.

If IANA is willing to allocate us a number for this, I would, of  
course, be overjoyed. But I expect that to be an uphill battle (and  
an unnecessary one, as we can pick any number that the ends agree on).

Also, the reason I think this (i.e. approach 2) is more attractive is  
because, at least with IPHC (as opposed to ROHC, which I know very  
little about), the compressor can refuse (or fail) to compress an  
entire flow. It may have run out of pre-configured (or pre- 
negotiated) slots for compression, which means that some (possibly  
large) number of flows could go uncompressed. When this happens,  
having an additional number of bytes PER PACKET on these flows will  
increase the total number of bytes sent by a not insignifcant number  
(haven't done the math on this, but my gut tells me that in the  
lifetime of, say, a file transfer or a phone call, this really adds  
up; A byte here and there multiplied by a large number is still a  
large number).

jan

On Feb 28, 2006, at 3:48 PM, Ertekin Emre wrote:

> Hi All,
>
> Please review and comment on the updated draft "Header Compression  
> over
> IPsec Security Associations", in addition to a new draft "Alternatives
> to Achieving HCoIPsec".  The drafts can be found at:
>
> http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-01.txt
> http://www.ietf.org/internet-drafts/draft-jasani-rohc-hcoipsec- 
> alternati
> ves-00.txt
>
> The updates to the HCoIPsec draft are primarily based on comments that
> we received from Lars-Erik, Carsten, Stephen Kent, and Jan Vilhuber.
>
> Based on HCoIPsec discourse, two approaches to achieving HCoIPsec have
> emerged.  These approaches are detailed in the HCoIPsec Alternatives
> draft, which is intended to facilitate discussions on the two HCoIPsec
> approaches.  Ultimately, one of the approaches will be selected, and
> that approach will be reflected in subsequent updates to the HCoIPsec
> draft.
>
> Any comments/thoughts on either drafts are greatly appreciated.
>
> Best Regards,
> Emre