Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec

From: "Jasani Rohan" <[email-masked]>
Date: Mon, 25 Sep 2006 11:18:20 -0400

All:
Just to be clear, Approach 1 will allocate a "generic" compressed
headers IANA protocol ID value (not specific to a particular header
compression scheme).  Therefore, some other mechanism will need to
identify whether the compressed headers where compressed by ROHC, ECRTP,
etc.

Rohan Jasani
Booz | Allen | Hamilton
703.984.0337 (office)
832.452.3241 (mobile)

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Monday, September 25, 2006 9:23 AM
> To: Sarkar, Biplab; [email-masked]
> Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec
> 
> Biplab and others,
> 
> I also think this could be a nice solution, but I believe an 
> explicit ROHC PROTOOL NUMBER would be preferable over an 
> identifier that would require negotiation before its meaning 
> can be known. 
> 
> >From the point of view of this WG, I believe we should strive
> for a ROHC PROTOCOL NUMBER and develop a ROHC solution based on that. 
> 
> /L-E
> 
> 
> ----Original Message----
> From: Sarkar, Biplab [mailto:[email-masked]]
> Sent: den 25 september 2006 14:28
> To: [email-masked]
> Cc: Lars-Erik Jonsson (LU/EAB)
> Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec
> 
> > ROHCers,
> > 
> > I believe  APPROACH-1 is the most generic and neat. We can 
> have ROHC 
> > pkts sent as payloads in different type of packets and 
> having a unique 
> > IANA number would make it easy and explicit. Currently even 
> for ROHC 
> > over GRE for HRPD Rev-A calls, we don't have any number 
> assigned. So 
> > soon we would come across more and more cases where we need 
> to get a 
> > generic simple solution.
> > 
> > Thanks
> > Biplab
> > 
> > -----Original Message-----
> > From: Lars-Erik Jonsson (LU/EAB)
> > [mailto:[email-masked]]
> > 
> > Sent: Monday, September 25, 2006 5:42 PM
> > To: [email-masked]
> > Subject: [rohc] FW: IPsec Processing & HCoIPsec
> > 
> > Forwarded from the hcoipsec mail list. Please direct also further 
> > discussions of these issues to the ROHC WG mail list.
> > 
> > /L-E
> > 
> > 
> > ----Original Message----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Jasani 
> Rohan Sent:
> > den 22 september 2006 19:41 To: [email-masked]; Stephen 
> Kent; Tero 
> > Kivinen Cc: Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec
> > 
> > 
> > All:
> > I should have started this discussion on the HCoIPsec 
> mailer list, so 
> > I'm now including it on the list.  To get others up to speed on the 
> > discussion I've included a brief synopsis of previous emails.
> > 
> > Synopsis:
> > I originally emailed Stephen and Tero, to gather their thoughts on 
> > leveraging a generic IANA value to indicate whether a 
> packet contains 
> > compressed headers.  Stephen expressed that it is going to 
> be hard to 
> > get an IANA value allocated from the Protocol ID registry and that 
> > this could cause delays.  Subsequently, other approaches to achieve 
> > the same functionality started to be discussed (approaches 
> described 
> > below).
> > Currently, we are discussing Approaches 3 & 4.  Note that 
> Approach 4 
> > has already been debated early on during initial development of 
> > HCoIPsec and was not pursued.
> > 
> > Stephen and Tero, do you have any concerns with Approach 3 
> ?  If so, 
> > could you explain some of you thoughts.
> > 
> > I have some concerns with Approach 4.  The first being the 
> additional 
> > overhead of having to establish an additional SA for each 
> HC-enabled 
> > SA.
> > This can be a problem for resource constrained devices 
> (i.e. 6lowPAN), 
> > that want to minimize the number of SAs they have to 
> establish.  The 
> > second being that now SAs are being generated not solely based on 
> > security policy, but now partly based on the capabilities of the 
> > compressor/decompressor (i.e. based on which types of traffic the 
> > compressor/decompressor supports).
> > 
> > APPROACH 1:  Allocation of a Generic Compressed Headers IANA Value
> > + A generic Compressed Headers IANA value will be allocated from the
> > Protocol ID Registry and will be used to indicate that payload 
> > contains compressed headers.
> > + The main drawback is the hurdle of getting a IANA value, which can
> > cause delays and may not even get allocated.
> > 
> > APPROACH 2:  Leverage the "uncompressed" profile as a marker
> > + For ROHC, currently a packet that is ROHC compressed has a
> > ROHC header
> > with a Profiles field.  This field will have a value, known as the 
> > "uncompressed" profile, that indicates that the payload of the ROHC 
> > compressed packet is not compressed.  Therefore, this value 
> could be 
> > used to signal to the decompressor that it should not 
> decompress the 
> > packet. + For ECRTP, currently a 1-byte shim header will need to be 
> > inserted to identify the different ECRTP packet types.  The 1-byte 
> > header will be extended to contain a value, which we will call the 
> > "uncompressed"
> > profile.  This functions exactly as the ROHC "uncompressed" profile 
> > value. + The main drawback is that packets traversing an 
> HC-enabled SA 
> > that are uncompressed will now have an additional few bytes used to 
> > indicate that the packet is uncompressed.
> > + In the past, HCoIPsec community members have debated this approach
> > against Approach 1 due to the efficiency tradeoffs.  Due to 
> concerns 
> > of efficiency voiced by ROHC WG & 6lowPAN WG members, through 
> > consensus Approach 1 became the preferred approach.
> > 
> > APPROACH 3:  Negotiate a Compressed Headers Protocol ID 
> value local to 
> > each SA + When each SA is established, a value agreed upon by the 
> > peers is negotiated.  This value will be analogous to the 
> "Compressed 
> > Headers" value and will provide the same functionality and will be 
> > used in the similarly during processing. + Since, the ESP/AH next 
> > header value is "local to the IPsec devices", meaning that no 
> > intermediate nodes rely on the contents of this field, it should be 
> > fine to use a negotiated value.
> > 
> > APPROACH 4: Leverage 2 SAs, 1 for uncompressed traffic and one for 
> > compressed traffic If ROHC is negotiated for the IPsec SA then all 
> > packets MUST be compressed and decompressed when sent over 
> that IPsec 
> > SA. For those packets that do not compress at all we create another 
> > IPsec SA with identical selectors, but without ROHC, and 
> that will be 
> > used to send those packets which cannot be compressed. This 
> will add 
> > overhead of one extra SA, but this could be used to allow running 
> > those profiles which do not have special "uncompressed" profile 
> > defined without any modification, i.e. no need to add extra 1-byte 
> > shim header or anything like that.  I.e. that is variation of the 
> > Approach 2, but in such way that there is no need to add 
> extra headers 
> > and using extra bytes to indicate that traffic is 
> uncompressed. If the 
> > profile already has some other header which can be used to indicate 
> > whether the packet is compressed or not (i.e. the profile 
> field in the 
> > ROHC header) then there is no need to create that extra IPsec SA.
> > 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 26 Sep 2006 09:42:27 +0200

> compression scheme). 

This I think is an open question. If a PROTOCOL NUMBER is assigned,
its usage scope will not necessarily be limited to HCoIPsec. Having
a "generic" identifier for "header compressed packet" means the
identifier itself says nothing without some negotiated state. I
believe that would be unfortunate.

We need to see the whole picture here, the discussion about
"APPROACH 1-4" has not been very clear about which problem is
addressed. I believe we are mixing different problems and various
approaches solved these problems more or less completely.

Applying header compression over anything requires two things:
1) a logical channel for the header-compressed packets only, for
   some schemes a set of such logical channels is needed since
   the schemes can not identify their own different packet types
   (as they are actually designed for HDLC encapsulation).
2) a mechanism for negotiation of the header compression channel
   state.

While 2) is solved through the IKEv2 extension, 1) is not
completely solved by any of the suggested approaches.

Let's look at the first problem in detail, what is it about?
1a) Identify compressed header packets
    * all packets sent over the link can be one option.
    * otherwise a mechanism to create logical channels is needed.
    * for ROHC, only one such logical channel would be needed,
      while other schemes require a set of logical channels.
1b) What if both compressed and uncompressed traffic is to be
    multiplexed?
    * with ROHC this can be handled in a ROHC-only channel, 
      by making use of the uncompressed profile.
    * in an IP tunnel, one single additional protocol identifier
      would be enough to solve the whole problem for ROHC,
      while having support also for other schemes would mean
      multiple identifiers or additional mechanism are needed.

So, we need to address the question whether we should really
cover also non-ROHC schemes? If so, we will have to face the
fact that all the suggested approaches provides incomplete
solutions, as ECRTP et. al requires additional functionality
to identify their different packet formats. Further, in an
IP-tunnel, I assume reordering is a reality, and what does
that mean for IP-HC/CRTP/ECRTP? For ROHC, reordering has been
investigated, key problem areas identified and solutions
provided by RFC 4224. Enhanced ROHC profiles are also on their
way with built-in robustness to reordering. For IP-HC/CRTP/ECRTP,
we know there are problems, but there is no guidance for how
to handle those problems.

If we had been able to easily include support for the old
schemes along with ROHC, and if there had been convincing
arguments supporting the usefulness of those schemes in an
environment where reordering can occur, I had supported
that. However, as I see it now, this is not the case. By
"only" addressing ROHC, which is the general header
compression platform, the solution becomes more straight-
forward and we will not have to invent additional mechanisms
to support schemes that we do not even know for sure if/how
they can be made to work in these scenarios.

Rgds,
/L-E