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

From: "Sarkar, Biplab" <[email-masked]>
Date: Mon, 25 Sep 2006 17:57:46 +0530

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. 

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

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Wednesday, September 20, 2006 10:45 AM
> To: Jasani Rohan
> Cc: Stephen Kent; Ertekin Emre
> Subject: RE: IPsec Processing & HCoIPsec
> 
> Jasani Rohan writes:
> > Stephen:
> > Thanks for clarifying some of the "undocumented" aspects of the 
> > allocation process :)  I definitely understand your concerns, as we 
> > too would like to prevent any delays in HCoIPsec development.  We 
> > definitely want bring consensus on the HCoIPsec approaches with you 
> > and the various other community members.  I've reiterated the 
> > approaches we've discussed below to make sure we are on the 
> same page 
> > and added a new approach that provides similar 
> functionality, however, through an alternate mechanism.
> > What are your thoughts on Approach 3 ?
> 
> I have one more option:
> 
> Approach 4: 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. 
> --
> [email-masked]
> 

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

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 25 Sep 2006 15:23:15 +0200

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

> Kivinen Cc: Ertekin Emre Subject: RE: IPsec Processing & HCoIPsec
> 
> 
> All:
> packet. + For ECRTP, currently a 1-byte shim header will need to be
> inserted to
> value. + The main drawback is that packets traversing an HC-enabled
> SA that are
> 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. 
> 
> 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