Subject: [rohc] FW: IPsec Processing & HCoIPsec

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

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

---

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

/L-E

----Original Message----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tero Kivinen Sent:
den 25 september 2006 12:22 To: Jasani Rohan
Cc: [email-masked]; Stephen Kent; Ertekin Emre
Subject: RE: IPsec Processing & HCoIPsec

> compressor/decompressor supports).

Actually now after thinking about the issue a bit, I do not think the
Approach 4 fits at all on the IPsec architecture. The problem there is
that the architecture with IPsec and ROHC is like this:

              Unprotected Interface
                      ^
                      |
     (nested SAs)+----------+
     ------------|Forwarding|<---------------------------+
     |           +----------+                            |
     |                ^                                  |
     |                | BYPASS                           |
     V             +-----+  +==PROCESS AH/ESP============|======+
 +-------+         | SPD |  |  +------+  +--------+  +-------+  |
.| SPD-I |.........|Cache|..|..|Tunnel|..|  ROCH  |..|  ESP  |..|..IPsec
 |  (*)  |         | (*) |---->|encaps|->|compress|->|Encrypt|  |
boundary
 +-------+         +-----+  |  +------+  +--------+  +-------+  |
     | +-------+    / ^     +===================================+
     | |DISCARD|<--/  |
     | +-------+      |
     |                |
     |          +-------------+
     |--------->|SPD Selection|
                +-------------+
                      ^
                      |     +------+
                      |  -->| ICMP |
                      | /   +------+
                      |/
                      |
                      |
              Protected Interface

I.e. after the SPD Cache is used to select the SA we go through the
ROHC processing, and then ESP encryption. The problem is that we have
already selected SA when we enter the ROCH processing, so we cannot
change it anymore. So I think the approach 4 does not really fit the
architecture and should be rejected because of that.

There is no problem on the inbound case, only in this outbound case. 

> cause delays and may not even get allocated.

I actually still think this is the best approach, even when it means
that we need to one protocol ID number from IANA.

> it should be fine to use a negotiated value.

The problem this approach is that it is complicated and can cause some
problems as it will always limit one protocol value from the SA. i.e.
if the SA has traffic selectors of the any protocol <-> any protocol,
then we need to pick one protocol number which is reserved for this
"compressed headers" value, and how we make sure we do not pick some
number that might actually be used by the traffic. The easiest way to
make sure of that would be to reserve number from IANA, i.e. back to
approach 1...

> is no need to create that extra IPsec SA. 

As I explained earlier, that this does not really fit to the IPsec
architecture. 
-- 
[email-masked]

---

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

FYI

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

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 10:26 AM
To: Tero Kivinen
Cc: Jasani Rohan; [email-masked]; Ertekin Emre
Subject: RE: IPsec Processing & HCoIPsec

The concern Jasani cited is not a valid one, i.e., we already allow a
sender to establish multiple SAs with the same traffic selectors so that
the sender can use different SAs for different classes of traffic.  The
receiver need not be aware of this distinction. 
However, Tero's observation is correct; we have already selected an
outbound SA before we would know whether a given packet can be
compressed, so it is not feasible to use two pairs of SAs to accommodate
compressed vs. uncompressed traffic on a per-packet basis.

So, despite my concerns about getting a new protocol ID assigned for
this purpose, I agree that it is the simplest and cleanest approach.

Steve

---

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

FYI

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

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 6:22 AM
To: Jasani Rohan
Cc: [email-masked]; Stephen Kent; Ertekin Emre
Subject: RE: IPsec Processing & HCoIPsec

Jasani Rohan writes:
> 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.
> 

              Unprotected Interface
                      ^
                      |
     (nested SAs)+----------+

I.e. after the SPD Cache is used to select the SA we go through the ROHC
processing, and then ESP encryption. The problem is that we have already
selected SA when we enter the ROCH processing, so we cannot change it
anymore. So I think the approach 4 does not really fit the architecture
and should be rejected because of that.

> Protocol ID Registry and will be used to indicate that payload 
> contains compressed headers.

> + For ROHC, currently a packet that is ROHC compressed has a ROHC 
> + header
> + For ECRTP, currently a 1-byte shim header will need to be inserted 
> + to
> + 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.
> 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.
> 

> 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.

---

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

Tero:
I agree with your explanation on Approach 4 and seems Approach 1 is the
preferred approach.

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

> > the same functionality started to be discussed (approaches 
> described below).
> Actually now after thinking about the issue a bit, I do not 
> think the Approach 4 fits at all on the IPsec architecture. 
> The problem there is that the architecture with IPsec and 
> ROHC is like this:
> 
>               Unprotected Interface
>                       ^
>                       |
>      (nested SAs)+----------+
>  |  (*)  |         | (*) 
> |---->|encaps|->|compress|->|Encrypt|  |  boundary
> I.e. after the SPD Cache is used to select the SA we go 
> through the ROHC processing, and then ESP encryption. The 
> problem is that we have already selected SA when we enter the 
> ROCH processing, so we cannot change it anymore. So I think 
> the approach 4 does not really fit the architecture and 
> should be rejected because of that.
> 
> I actually still think this is the best approach, even when 
> it means that we need to one protocol ID number from IANA.
> 
> The problem this approach is that it is complicated and can 
> cause some problems as it will always limit one protocol 
> value from the SA. i.e.
> if the SA has traffic selectors of the any protocol <-> any 
> protocol, then we need to pick one protocol number which is 
> reserved for this "compressed headers" value, and how we make 
> sure we do not pick some number that might actually be used 
> by the traffic. The easiest way to make sure of that would be 
> to reserve number from IANA, i.e. back to approach 1...
> 
> that IPsec 
> As I explained earlier, that this does not really fit to the 
> IPsec architecture. 
> --
> [email-masked]
>