Subject: [rohc] HCoIPsec Summary / Thoughts

From: "Ertekin Emre" <[email-masked]>
Date: Wed, 4 Oct 2006 09:02:23 -0400

Hi All,

I would like to summarize some of the HCoIPsec discussions on the mailer
list.  I've also provided some of my commentary, where noted.

As established in the 65th IETF HCoIPsec session, there needs to be a
mechanism to demultiplex header-compressed vs. uncompressed packets.
Please see:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04239.html.   At
the HCoIPsec session, we discussed two possible mechanisms to achieve
this: the first was to identify uncompressed packets via the IANA
PROTOCOL ID (i.e., Next Header), the second approach was to add
additional "control information" to packets which cannot be compressed
(e.g., through an uncompressed profile).  The conclusion from the 65th
IETF was that from an efficiency perspective, identifying uncompressed
packets via the IANA PROTOCOL ID is the better approach.

Since this decision, there has been discussion of two possible ways to
use the PROTOCOL ID for demultiplexing purposes.  The first approach is
to obtain an OFFICIAL PROTOCOL ID ALLOCATION; the second approach is
through an UNOFFICIAL PROTOCOL ID.

OFFICIAL PROTOCOL ID ALLOCATION: This proposal requests 1 allocation
from the IANA PROTOCOL ID registry.  Proceeding on the assumption that
we will only request one value from IANA, there are three approaches to
provide support for HC over IPsec: (1) Unification of HC algorithms and
a RoHC-Specific PROTOCOL ID; (2) Non-Unification and a Generic PROTOCOL
ID; (3) RoHC over IPsec and a RoHC-Specific PROTOCOL ID.  An
amplification on each approach is provided below:

   (1) Unification: This approach leverages providing ECRTP over IPsec
support through the RoHC framework. Some members feel that there are no
technical motivations for unification, thus a RoHC over IPsec solution
(detailed in (3)) will suffice
(http://www1.ietf.org/mail-archive/web/rohc/current/msg04419.html).
Others feel that we should provide support for "legacy" HC algorithms
through the RoHC framework
(http://www1.ietf.org/mail-archive/web/rohc/current/msg04420.html).

   (2) Non-Unification: This approach leverages a "generic" allocation
from the PROTOCOL ID field, in addition to pre-established state
information--both are used to identify a RoHC over IPsec packet versus
an ECRTP over IPsec packet.  IMO, the arguments against "generic" have
not been convincing.  We've established the fact that prior to HC
operation, SA state information needs to be configured on the IPsec
device (via IKE) which indicates the type of HC, and its associated
configuration parameters (e.g., RoHC, eCRTP, etc.).  Using this state
information, in conjunction with the "generic" allocation is sufficient
for identifying the type of header-compressed packet.  Other comments
indicated "interoperability" as a challenge.  I'd also question this
argument: are vendors today really who implement traditional hop-by-hop
HC schemes complaining about RoHC/eCRTP interoperability? 

   (3) RoHC-Only: This approach specifies a RoHC over IPsec solution,
with no support for ECRTP over IPsec.

UNOFFICIAL PROTOCOL ID: Jan's proposal specifies leveraging IKEv2 to
dynamically negotiate a next header value and a HC algorithm that will
be enabled for a given SA.  We could possibly get away with this
dynamic, unofficial value because the "next header" field is only
relevant to the two IPsec endpoints.  Note that (1), (2), and (3) can be
applied to this proposal.  There could, however, be considerations
associated with "next header field collision", because the PROTOCOL ID
value negotiated by IKE is an unofficial one.  IMO, I would still like
to discuss this concern.  Based on my understanding of IPsec tunneled
packets (which is what HCoIPsec is targeted for), there are only a
limited number of values that the ESP/AH "next header" field can take:
"IP" is one, another is "IPComp".  Are there any others?  I'm trying to
think of other scenarios where this collision could be a consideration;
if anyone has thought up of any scenarios that solidifies this concern,
I would appreciate this discussion.

---------

Based on the spirit of letting vendors choose which HC algorithm they
would like to implement, we have released the IKEv2 draft for HCoIPsec
parameter negotiation
(http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hc
oipsec-00.txt).  This draft is specified for a "Non-Unified, OFFICIAL
PROTOCOL ID ALLOCATION" approach.  

Please note that the first version of this draft does not intend to
reflect WG consensus on the HCoIPsec approach.  As always, comments are
welcome.

BR,

Emre

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Oct 2006 15:14:42 +0300

Ertekin Emre writes:
> The conclusion from the 65th

One more benefits from this solution is that it does not end up
problems with the PMTU and fragmentation. I.e. IPsec code already
knows how much the packet can grow when encrypted and encapsulated, so
it can already notify the sending node about the correct (decreased)
MTU for the tunnel. This is not changed at all if we use protocol ID
field to send uncompressable packets, as the packet size stays same.

If would be adding some extra headers (like uncompressed profile RoHC
header) that would expand the packets so the IPsec would need to send
ICMP messages with even smaller MTU to make sure that even those
uncompressable packets can be processed.

This was just a side note about why the protocol ID is better than
adding extra header (i.e. not only message size overhead, but also
other complications to the overall system).

> "IP" is one, another is "IPComp".  Are there any others?

Hmm... true, there is not that many possible protocol numbers for the
tunnel mode. For the transport mode it could be anything, but for
tunnel mode I think it has values of 4 (IPv4), 41 (IPv6), 59 (no
next header == TFC packet), or 108 (IPcomp). I cannot think now
directly any other values that could be there....
-- 
[email-masked]

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Mon, 9 Oct 2006 13:30:10 +0200

Emre,

Thanks for the summary, I'm filling in some clarifying details.

> OFFICIAL PROTOCOL ID ALLOCATION: This proposal requests 1
> allocation from the IANA PROTOCOL ID registry.  Proceeding on
> the assumption that we will only request one value from IANA,
> there are three approaches to provide support for HC over
> IPsec: (1) Unification of HC algorithms and a RoHC-Specific
> PROTOCOL ID; (2) Non-Unification and a Generic PROTOCOL ID;
> (3) RoHC over IPsec and a RoHC-Specific PROTOCOL ID.  An

The assumption that we will *only* request one single PROTOCOL
NUMBER, http://www.iana.org/assignments/protocol-numbers ,
is based on the fact that this number space is rather small,
and these numbers are therefore rather hard to get. Note
especially that only for ROHC would it be sufficient with a
single identifier, other HC schemes can not identify their
own packet types and would therefore require several
identifiers, or we would still have to create an additional
multiplexing layer for them.

For the three approaches below, one should further notice 
that (1) and (3) are identical when it comes to PROTOCOL
NUMBER allocation, we only allocate an identifier for the
ROHC platform, which is built to be an easy-to-integrate
and general platform for header compression (it has been
designed to better than the old schemes fit on top of any
channel technology, and to facilitate addition of profiles
for compression of new/different protocol combinations).

What differs between (1) and (3) is only the next step of
whether to provide ROHC encapsulation for other compression
schemes as ROHC profiles, which should actually be seen as
a separate question.

>    (1) Unification: This approach leverages providing ECRTP
> over IPsec support through the RoHC framework. Some members
> feel that there are no technical motivations for unification,
> thus a RoHC over IPsec solution (detailed in (3)) will
> suffice
>  Others feel that we should provide support for "legacy" > HC
algorithms through the RoHC framework 
>    (2) Non-Unification: This approach leverages a "generic"
> allocation from the PROTOCOL ID field, in addition to
> pre-established state information--both are used to identify
> a RoHC over IPsec packet versus an ECRTP over IPsec packet.
> IMO, the arguments against "generic" have not been
> convincing.  We've established the fact that prior to HC
> operation, SA state information needs to be configured on the
> IPsec device (via IKE) which indicates the type of HC, and
> its associated configuration parameters (e.g., RoHC, eCRTP,
> etc.).  Using this state information, in conjunction with the
> "generic" allocation is sufficient for identifying the type
> of header-compressed packet.  Other comments indicated
> "interoperability" as a challenge.  I'd also question this
> argument: are vendors today really who implement traditional
> hop-by-hop HC schemes complaining about RoHC/eCRTP interoperability?

First, the comment about interoperability is based on the general
fact that having several alternative schemes to handle one single
problem is by nature bad for interoperability and increases
complexity.

Secondly, the whole idea of generic can be questioned in terms
of its own definition. What is generic?? One can not allocate it
without a specific reference to a protocol that defines its
meaning, but I do not think we want to refer to IKE as THE SINGLE
protocol for this, right? Not referring to IKE, however, means we
would either leave it open to any similar protocol (which in
reality means the allocation just reserves a number for ANY
purpose), or we would have to create a separate sub layer that
defines the allocation, to which the IKE-HC would then form an
instance. Neither of these makes sense in my mind. With a pure
ROHC identifier, its meaning would always be unambiguous, without
us having to create more protocols to establish a meaning of it.

>    (3) RoHC-Only: This approach specifies a RoHC over IPsec
> solution, with no support for ECRTP over IPsec.

This is thus the same as (1), when it comes to PROTOCOL NUMBER
allocation.

/L-E

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 10 Oct 2006 14:30:31 +0200

> and these numbers are therefore rather hard to get. 

It might be worth saying that we are not really sure this is
actually a true fact. If not, one could of course also consider
a fourth approach, as added below.

>> over IPsec support through the RoHC framework. One ROHC
>> PROTOCOL NUMBER is allocated for ROHC.
>>

(4) Two PROTOCOL NUMBERS are allocated, one for ROHC and one
for "Legacy header compression", LEG_HC, the latter referring
to an "encapsulated IP-HC/CRTP/eCRTP" document, which is a
yet to be written specification of how the compressed headers
of these protocols are encapsulated to provide packet type
identification (a header compression functionality the ROHC
platform of course handles itself).

We should not forget (5) either:

(5) UNOFFICIAL PROTOCOL ID: Jan's proposal specifies leveraging
IKEv2 to dynamically negotiate a next header value and a HC
algorithm that will be enabled for a given SA.

In all 5 alternatives except (3), the specification defining
"encapsulation for IP-HC/CRTP/eCRTP" must be produced, as
these schemes are missing the multiplexing mechanism to
separate their own packet types. In alternative (1), this
specification would constitute a ROHC profile.

Personally, I would prefer (3), with (4), (5), and (1) as
potential alternatives.

What does these approaches mean, from a ROHC WG point of view?
(3) - HCoIPsec overview draft (Informational, as in charter)
    - ROHC PROTOCOL NUMBER allocation draft (PS, as in charter)
    - IKEv2 extension for ROHC (PS, as in charter)

(4) - HCoIPsec overview draft (Informational, as in charter)
    - ROHC+LEG_HC PROTOCOL NUMBER allocation draft (PS, as in
      charter, except that it makes two allocations)
    - IKEv2 extension for ROHC and LEG_HC (PS, as in charter,
      except that it covers both ROHC channel setup, and LEG_HC
      channel setup)
    - "encapsulation for IP-HC/CRTP/eCRTP" (PS, as the
      encapsulation document listed in the charter, but not
      written as a ROHC profile)

(1) - HCoIPsec overview draft (Informational, as in charter)
    - ROHC PROTOCOL NUMBER allocation draft (PS, as in charter)
    - IKEv2 extension for ROHC (PS, as in charter)
    - "encapsulation for IP-HC/CRTP/eCRTP" (PS, as a ROHC
      profile, in accordance with the charter)

(5) - HCoIPsec overview draft (Informational, as in charter)
    - IKEv2 extension for ROHC and LEG_HC (PS, as in charter,
      except that it covers both ROHC channel setup, LEG_HC
      channel setup, and UNOFFICIAL PROTOCOL NUMBER negotiation)
    - "encapsulation for IP-HC/CRTP/eCRTP" (PS, as the
      encapsulation document listed in the charter, but not
      written as a ROHC profile)

So, why do I list these details? We are currently actually
having a discussion about whether to develop solutions also
for the old "legacy" header compression solutions, along with
the solution for ROHC. While (3) is the pure ROHC solution,
both (4) and (1) are just extended solutions, not changing
how this is built for ROHC, which is preferable. (5) is an
outsider, clearly limiting the scope of the solution to IKEv2-
negotiated channels only, while it does not affect the other
parts of the whole picture. PROTOCOL NUMBER(s) could
later be allocated for turning this into (3), (4), or (1),
even if the documents are now written for (5). With (2) on
the other hand, the building blocks are different, and not
consistent with the pure ROHC solution (3). Therefore, in
addition to the technical detail arguments against it
already presented, I do not consider (2) a viable approach.

/L-E

---

From: "Jasani Rohan" <[email-masked]>
Date: Tue, 10 Oct 2006 14:38:34 -0400

Tero:
Good points.  I've expanded on the approach that was mentioned below.  I
think there is a way to negotiate a Next Header value for the
tunnel-mode case, where there would be no collisions.  However, the
transport-mode case does present problems.  See my comments inline
below.  Feedback will be greatly appreciated :)

BTW, I'll get back to you on your IKE comments email as well, thanks.

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

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 8:15 AM
> To: Ertekin Emre
> Cc: [email-masked]
> Subject: [rohc] HCoIPsec Summary / Thoughts
> 
> Ertekin Emre writes:
> One more benefits from this solution is that it does not end 
> up problems with the PMTU and fragmentation. I.e. IPsec code 
> already knows how much the packet can grow when encrypted and 
> encapsulated, so it can already notify the sending node about 
> the correct (decreased) MTU for the tunnel. This is not 
> changed at all if we use protocol ID field to send 
> uncompressable packets, as the packet size stays same.
> 
> header) that would expand the packets so the IPsec would need 
> to send ICMP messages with even smaller MTU to make sure that 
> even those uncompressable packets can be processed.
> 
> This was just a side note about why the protocol ID is better 
> than adding extra header (i.e. not only message size 
> overhead, but also other complications to the overall system).
> 
> > relevant to the two IPsec endpoints.  Note that (1), (2), 
> and (3) can 
> > be applied to this proposal.  There could, however, be 
> considerations 
> Hmm... true, there is not that many possible protocol numbers 
> for the tunnel mode. For the transport mode it could be 
> anything, but for tunnel mode I think it has values of 4 
> (IPv4), 41 (IPv6), 59 (no next header == TFC packet), or 108 
> (IPcomp). I cannot think now directly any other values that 
> could be there....

For the tunnel-mode case:

Since there are only 4 potential values for the ESP/AH Next Header
field, during SA establishment a value other than these 4 values can be
negotiated to indicate "compressed headers" (This does not require the
use of IKE, this value can be negotiate manually, via a recommended
value).  Since in tunnel-mode the entire packet is protected, the ESP/AH
next header value is only used by the IPsec devices and thus is
essentially local to those devices.  When ESP is applied, the next
header value is encrypted, thus no other devices can see it, so there
are no problems here.  In the AH case, the value will be visible,
however I would imagine that devices aren't supposed to make decsisions
based on the contents of that field ?

NOTE:  HCoIPsec is currently only specified for tunnel-mode.

For the transport-mode case:

Since there are too many potential values for the ESP/AH Next Header
field, the only approaches we were able to create entailed using
existing allocations:

A)  Use Protocol ID 255 (Reserved for IANA) to indicate "Compressed
Headers"
B)  Use Protocol ID 243 or 244 (Reserved for Testing) to indicate
"Compressed Headers"
C)  Use a Protocol ID for an obscure protocol to indicate "Compressed
Headers"

I like A), however I'm not completely aware if that is allowed or
advisable ?

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 11 Oct 2006 08:58:00 +0200

> value). 
> Since in tunnel-mode the entire packet is protected,the ESP/AH
> however I would imagine that devices aren't supposed to make
> decsisions based on the contents of that field ?

If some devices in between are looking at an end-2-end field to make
decisions, that is their problem, nothing the end-2-end protocol
designer should care about. So I agree with you, not an issue.

> NOTE:  HCoIPsec is currently only specified for tunnel-mode.

This is an important point, which we should stick to, if there are
no convincing arguments why transport mode must also be supported.

/L-E

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 Oct 2006 14:49:42 +0300

> based on the contents of that field ?

I would not consider AH that much in this context. In the RFC4301 AH
is downgraded to MAY, so there is no need for the ROHC to support AH.

I do not know how many devices check the protocol inside the tunneled
AH packet, I would not guess not that many.

If we end up using that model, i.e. no real allocation, then I prefer
that we select one protocol id and use that. Implementing dynamic
negotiation for the protocol id there is just adding extra compexity. 

> field, the only approaches we were able to create entailed using

If we want to support transport mode, then I think we must allocate
proper ID number, we cannot assume that we can use some protocol ID
without properly allocating them, as the traffic going inside the
transport mode connection can have any protocol IDs, and we cannot
affect that. 

> B)  Use Protocol ID 243 or 244 (Reserved for Testing) to indicate

We cannot use those. Those are and will be used probably by some
experimental protocol or for testing, and we cannot use them. 

> C)  Use a Protocol ID for an obscure protocol to indicate "Compressed

That would be possible, similarly IPsec uses protocol ID 59 to
indicate that this is dummy packet. On the other hand I think it might
be easier to get the protocol number allocation that try to explain
to the IESG why we are using some dummy protocol number inside the
protocol. 

> I like A), however I'm not completely aware if that is allowed or

I am pretty much sure it would be very hard to use that protocol
number. It is reserved, and probably has reason for that (for example
future extension meaning protocol ID will be stored somewhere else or
something), thus using that could cause problems. 
-- 
[email-masked]

---

From: "Ertekin Emre" <[email-masked]>
Date: Fri, 13 Oct 2006 16:17:31 -0400

Lars-Erik,

Thanks again for your response.  I've provided some comments inline.
 
> allocation
> > we will only request one value from IANA, there are three
> approaches
> > to provide support for HC over
> PROTOCOL
> > ID; (2) Non-Unification and a Generic PROTOCOL ID;
> The assumption that we will *only* request one single PROTOCOL NUMBER,

> http://www.iana.org/assignments/protocol-numbers , is based on the 
> fact that this number space is rather small, and these numbers are 
> therefore rather hard to get. Note especially that only for ROHC would

> it be sufficient with a single identifier, other HC schemes can not 
> identify their own packet types and would therefore require several 

I agree.  Just one comment to the last clause of your last sentence ...
an additional multiplexing mechanism would be the better approach
(rather than allocating several NextHeader/ProtocolID values).  This
multiplexing mechanism would be analogous to what is currently proposed
in HC over MPLS (ref: draft-ietf-avt-hc-over-mpls-protocol-07.txt,
Section 5.3).
 
> For the three approaches below, one should further notice that (1) and

> (3) are identical when it comes to PROTOCOL NUMBER allocation, we only

> allocate an identifier for the ROHC platform, which is built to be an 
> easy-to-integrate and general platform for header compression (it has 
> been designed to better than the old schemes fit on top of any channel

> technology, and to facilitate addition of profiles for compression of 
> new/different protocol combinations)

Agree.

> What differs between (1) and (3) is only the next step of whether to 
> provide ROHC encapsulation for other compression schemes as ROHC 
> profiles, which should actually be seen as a separate question.

Agree.

> over IPsec
> > support through the RoHC framework. Some members feel that
> there are
> > no technical motivations for unification, thus a RoHC over IPsec 
> > solution (detailed in (3)) will suffice 
> pre-established
> > state information--both are used to identify a RoHC over
> IPsec packet
> > versus an ECRTP over IPsec packet.
> convincing.  We've
> > established the fact that prior to HC operation, SA state
> information
> > needs to be configured on the IPsec device (via IKE) which
> indicates
> > the type of HC, and its associated configuration parameters (e.g., 
> > RoHC, eCRTP, etc.).  Using this state information, in
> conjunction with
> > the "generic" allocation is sufficient for identifying the type of 
> > header-compressed packet.  Other comments indicated
> "interoperability" 
> First, the comment about interoperability is based on the general fact

> that having several alternative schemes to handle one single problem 
> is by nature bad for interoperability and increases complexity.

I still don't understand the issue with interoperability when there are
only 2 HC protocols.  A quick Google search can show that certain
vendors support RoHC, and certain vendors support (e)CRTP.  If vendors
have already selected one scheme over the other, then it should be their
decision as to whether they need to implement the other.

Where exactly is the complexity increased?  We aren't mandating that
both schemes be implemented on all HCoIPsec implementations.  If you
were discussing interoperability between ROHC and ECRTP, such that ECRTP
can talk to ROHC, then that would be a problem.  The complexity (I
think) that you are referring to is when a IPsec device will support
both eCRTP and RoHC.  Yes that's true, but only if a vendor decides to
support both protocols -- a vendor can only support 1 protocol if
complexity is a concern.

Again, the HC over MPLS work is specifying a solution for both RoHC and
IPHC/cRTP/eCRTP.  Why can't HCoIPsec stay consistent with this?

> Secondly, the whole idea of generic can be questioned in terms of its 
> own definition. What is generic?? One can not allocate it without a 
> specific reference to a protocol that defines its meaning, but I do 
> not think we want to refer to IKE as THE SINGLE protocol for this, 
> right?

We never stated that IKE was the only protocol used.  However, IKE is
the primary SA establishment protocol, and therefore we are extending
it.  If other protocols need to negotiate the meaning of the generic
identifier, then those can be extended as well in the future.  As such,
the generic value (by no means) is tied to IKE.

> Not referring to
> IKE, however, means we would either leave it open to any similar 
> protocol (which in reality means the allocation just reserves a number

> for ANY purpose)

The generic allocation would be strictly for HC schemes.  If any device
uses the "generic" allocation for "ANY" purpose, then there could be
collisions.  

>, or we would have to
> create a separate sub layer that defines the allocation, to  which the

>IKE-HC would then form an instance. Neither of  these makes sense in my

>mind. With a pure ROHC identifier,  its meaning would always be 
>unambiguous, without us having to  create more protocols to establish a

>meaning of it.

As indicated in previous emails, for HC to operate properly, state will
have to be negotiated before any HC session comes up; therefore, a
mechanism to negotiate this state will always exist.  The meaning of the
"generic value" is (IMO) just another parameter that the mechanism needs
to negotiate.  If you consider the "negotiation of this parameter" as a
"sublayer" then I would agree.

R,
Emre

---

From: "Ertekin Emre" <[email-masked]>
Date: Fri, 13 Oct 2006 16:19:55 -0400

Lars,

Thanks Lars-Erik for your useful thoughts.  My responses are inline.

> >> from the IANA PROTOCOL ID registry.  Proceeding on the assumption 
> >> that we will only request one value from IANA, there are three 
> >> approaches to provide support for HC over
> >> IPsec: (1) Unification of HC algorithms and a
> RoHC-Specific PROTOCOL
> > therefore rather hard to get.
> 
> It might be worth saying that we are not really sure this is actually 
> a true fact. If not, one could of course also consider a fourth 
> approach, as added below.

I agree, but in my opinion (and I think that various other members
expressed this as well) that getting 1 value will be hard, therefore
getting 2 will be even harder.  This is why we never proposed this as an
alternative.  
 
> (4) Two PROTOCOL NUMBERS are allocated, one for ROHC and one for 
> "Legacy header compression", LEG_HC, the latter referring to an 
> "encapsulated IP-HC/CRTP/eCRTP" document, which is a yet to be written

> specification of how the compressed headers of these protocols are 
> encapsulated to provide packet type identification (a header 
> compression functionality the ROHC platform of course handles itself).
> 
> IKEv2 to dynamically negotiate a next header value and a HC algorithm 
> that will be enabled for a given SA.
> 
> "encapsulation for IP-HC/CRTP/eCRTP" must be produced, as these 
> schemes are missing the multiplexing mechanism to separate their own 
> packet types. In alternative (1), this specification would constitute 
> a ROHC profile.
> 
> Personally, I would prefer (3), with (4), (5), and (1) as potential 
> alternatives.
> 
> So, why do I list these details? We are currently actually having a 
> discussion about whether to develop solutions also for the old 
> "legacy" header compression solutions, along with the solution for 
> ROHC.  While (3) is the pure ROHC solution, both (4) and (1) are just 
> extended solutions, not changing how this is built for ROHC, which is 
> preferable. (5) is an outsider, clearly limiting the scope of the 
> solution to
> IKEv2- negotiated channels only,

What is meant by outsider?  

Also, why IKEv2 negotiated channels only? Why can't any other SA
management protocol cannot negotiate a HC channel?  Note that this value
could be manually configured as well.

>while it does not affect the
>other parts of the whole picture. PROTOCOL NUMBER(s) could  later be 
>allocated for turning this
>into (3), (4), or (1),  even if the 
>documents are now written for (5). With (2) on  the other hand, the 
>building blocks are different,

Based on our understanding, you are indicating that approach (5) can be
converted into (3), (4), or (1) at a later time.  However, (5) cannot be
converted into (2) because the 'building blocks' are different.  

Which 'building blocks' are different for (2)?  From our understanding,
for solutions (1), (3), and (4) IKE will negotiate whether HC is enabled
on the SA, the type of HC, and the HC scheme's channel parameters.  For
option (2), IKE will negotiate the same set of parameters.

I'm not necessarily saying that (2) is the only way to go; I'm just
trying to understand why it's not a viable approach.

R,
Emre

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 18 Oct 2006 09:33:27 +0200

Emre,

Some more comments...

>>> IPsec: (1) Unification of HC algorithms and a RoHC-Specific PROTOCOL
>> NUMBER, 
> (rather than allocating several NextHeader/ProtocolID values).  

Yes, at least if we are talking official PROTOCOL NUMBERS. Still, this
is the same as redefining the legacy HC protocol headers.

> I still don't understand the issue with interoperability when
> there are only 2 HC protocols. A quick Google search can show that
> certain vendors support RoHC, and certain vendors support (e)CRTP.

Exactly, and if one of the communicating network nodes of the link
has been manufactured by one vendor and the other node by a different
vendor, this means HC may not even be possible. Multiple options to
solve the same problem reduces the chance to get interoperability.

> Where exactly is the complexity increased?  We aren't mandating
> that both schemes be implemented on all HCoIPsec implementations.

If you provide two alternative options to solve the same problem,
the only way a manufacturer can ensure interoperability is by
implementing both alternatives, which increases complexity.

> Again, the HC over MPLS work is specifying a solution for
> both RoHC and IPHC/cRTP/eCRTP.  Why can't HCoIPsec stay
> consistent with this?

One mistake does not motivate further mistakes. Specifying 
solutions for two alternatives requires more to be specified,
complicates the problem/solution space, and in addition it makes
things harder when it comes to interoperability and complexity.

>> of its own definition. What is generic?? One can not allocate
>> it without a specific reference to a protocol that defines its
>> meaning, but I do not think we want to refer to IKE as THE
>> SINGLE protocol for this, right?
> 
> We never stated that IKE was the only protocol used.  However,
> IKE is the primary SA establishment protocol, and therefore we
> are extending it.  If other protocols need to negotiate the
> meaning of the generic identifier, then those can be extended
> as well in the future.  As such, the generic value (by no
> means) is tied to IKE.

I get a parsing error on the last sentence since the essential
words were within paranteses, but I assume those paranteses were
not supposed to be there. I interpret it as saying "the generic
value would by no means be tied to IKE".

As I describe below, the PROTOCOL NUMBER allocation will have to
refer to some specification, either one clearly defining the
meaning of the allocated number (as in the ROHC-only case), or
(for a multi-purpose number) one that defines the protocol which
negotiates the meaning of the number. One can not allocate a
PROTOCOL NUMBER and refer to NULL. 

>> Not referring to IKE, however, means we would either leave it
>> open to any similar protocol (which in reality means the
>> allocation just reserves a number for ANY purpose)
> 
> The generic allocation would be strictly for HC schemes. If
> any device uses the "generic" allocation for "ANY" purpose,
> then there could be collisions.

Yes, the whole point with this was to make clear this is not
possible, but in reality the meaning of the proposal I have
seen so far.

>> , or we would have to create a separate sub layer that
>> defines the allocation, to which the IKE-HC would then form
>> an instance. Neither of these makes sense in my mind. With
>> a pure ROHC identifier, its meaning would always be
>> unambiguous, without us having to create more protocols to
>> establish a meaning of it.
> 
> As indicated in previous emails, for HC to operate properly,
> state will have to be negotiated before any HC session comes
> up; therefore, a mechanism to negotiate this state will
> always exist.  The meaning of the "generic value" is (IMO)
> just another parameter that the mechanism needs to
> negotiate.  If you consider the "negotiation of this
> parameter" as a "sublayer" then I would agree.

On the last question, I agree, in its realization. But now
we are back to the initial question above. You do this in IKEv2,
so we would then have to refer to IKEv2 in the PROTOCOL NUMBER
allocation, but neither you nor me would like to do that. This
leaves us with having to specify some generic negotiation 
protocol, which the allication would refer to, and the HC
extension for IKEv2 would form an instance to that generic
preudo-protocol. I do not like the conceptual complexity of
all this, and I can not see why we should do it when we can
avoid it (preferebly by not supporting legacy HC, but I have
also provided several other alternatives).

/L-E

---

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 18 Oct 2006 11:08:50 +0200

Even more responses...

>>>> allocation from the IANA PROTOCOL ID registry.  Proceeding on the
>>>> assumption that we will only request one value from IANA, there
>>>> are three approaches to provide support for HC over
>>> NUMBER, http://www.iana.org/assignments/protocol-numbers , is based
>>> on the fact that this number space is rather small, and these
>>> numbers are therefore rather hard to get.
>> 
> getting 2 will be even harder.  This is why we never proposed this
> as an alternative.

I hope it would be easier to get two well-defined numbers than to get
one ambiguously defined number. If I was to approve allocations, that
would at least be my take on it.

>>        allocation from the PROTOCOL ID field.
>> 
>>        "Legacy header compression", LEG_HC. 

>>        IKEv2 to dynamically negotiate a next header value and a
          HC algorithm that will be enabled for a given SA.
>> packet types. In alternative (1), this specification would
>> constitute a ROHC profile. 
>> 
>>     channel setup) - "encapsulation for IP-HC/CRTP/eCRTP" (PS, as the
>> solution to IKEv2- negotiated channels only,
> 

What I wrote afterwards, since the identifiers are unofficial, the
solution gets very dependent on being applied in a constrained
environment. I assumed the values would be settled by the IKEv2
extension, but you are right that of course this could be done also
in other ways. In any case, I still see 5 as a very special track,
since it is based on the use of unofficial identifiers.

>> (5) does not affect the other parts of the whole picture. PROTOCOL
>> NUMBER(s) could  later be allocated for turning this into (3), (4),
>> or (1),  even if the documents are now written for (5). With (2) on
>>  the other hand, the building blocks are different,
> 
> Based on our understanding, you are indicating that approach (5) can
> be converted into (3), (4), or (1) at a later time.  However, (5)
> cannot be converted into (2) because the 'building blocks' are
> different.

The IKEv2 extension part will be the same when it comes to each
schemes channel parameters, but the solution will have to be
changed to incorporate establishment of GENERIC_HC meaning. We will
also have to define the generic pseudo-protocol for the GENERIC_HC
negotiation, if we do not bind this allocated value to IKEv2 only.
(2) also excludes the possibility to use the HC schemes independent
of each other. 

For all alternatives (3), (4), (1), (5), the ROHC solution is really
the same and not changed to accommodate support for LEGACY_HC, and
this is in my opinion important if we are really to consider the
LEGACY_HC schemes at all. Alternative (5) only differs in that it
has to specify which unofficial numbers to use, and that it does not
include any official allocation request (which could still be made
later on). Only a ROHC allocation request would be needed to turn
(5) into (3).

/L-E