Re: FW: CDR review ROHCoIPSec

Hi Tero, Carl,

> >> If the RFC3095 and RFC5225 capable decompressor advertise the
> RFC3095
> >> profiles to a RFC5225-only-compressor, you will end up with a ROHC
> >> channel only supporting the uncompressed profile. By having a two-
> way
> >> "negotiation-approach" you will be able to advertise all profiles
> you
> >> can handle (both RFC525 and RFC3095 profile) and with response both
> >> peers will agree on a common set of profiles.
> >
> > There are ways to support both, i.e. the profile negotiation could
be
> > described bit differently. I assume that newer RFC5225 version of
the
> > same profile is better than RFC3095 version, so it would be better
to
> > use the newer version if both are supported? If so then the
> > negotiation could be defined so that initiator can send both RFC3095
> > and RFC5225 versions, and if responder supports both it MUST not
send
> > both of them, but only one of them and that also tells the initiator
> > that responder will only be using that version. I.e. if responder
> > replies with RFC3095 version then initiator will know that responder
> > does not support newer version thus will always send data in RFC3095
> > version. If responder selects RFC5225 version then that will be used
> > instead.
> >
> 
> This solution could probably work.
> 
> I am ok with the existing solution in
> draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt too.
> 
> > How many different profiles there are which could be used here in
> > IKEv2? Is the older RFC3095 profile really even an option with IKEv2
> > and IPsec use?
> 
> I would say yes, RFC3095 profiles are an option for ROHCoIPSec. It is
> not really up to us to tell the implementer/user which profiles to
use.
> If the service of the RFC3095 profiles are satisfactory to the user,
> let
> him/her use it. I think we should concentrate on designing a
> negotiation
> for the ROHC framework as whole and not for individual profiles.
> 
> RFC3095 can be made to work over channels that reordering too, not as
> efficient RFC5225, but it will work.
> 
> /Calle

I agree that RFC 3095/5225 could both be options for ROHCoIPsec.  It's
up to the ROHCoIPsec implementers to decide which profiles they would
like to implement.  

Since we all agreed to the signaling-based approach for ROHC channel
parameters, we should stick to the signaling flavor for the PROFILES
parameter. 

i.e., The initiator and responder signal the profiles which they can
decompress.  During the CCSA exchange, initiators/responders must not
signal two versions of the same profile.  If multiple versions of a
profile are supported at a ROHCoIPsec implementation, only one version
of the profile can be signaled for an SA.  

Best Regards,
Emre