RE: [rohc] HCoIPsec Summary / Thoughts

Lars-Erik,

Thanks again for your response.  I've provided some comments inline.

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

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.

> 
> >    (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?
> 
> 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

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc