Re: FW: CDR review ROHCoIPSec

Carl,

Responses inline,


Carl Knutsson wrote:
> Tero Kivinen wrote:
>> Carl Knutsson writes:
>>>> On the other hand I do not know if the PROFILE of the ROHC can be
>>>> seen from the packet. If the recipient of compressed packet can see
>>>> from the packet to which profile it is using, then there is no need to
>>>> agree on one profile, but it is better to just announce what can be
>>>> received. If the profile cannot be seen from the packet, then we must
>>>> agree on one profile only.
>>> The profile can be seen in the packet, but not the version. You cannot
>>> advertising both the RFC3095 and RFC5225 versions of a profile. A
>>> decompressor supporting both RFC3095 and RFC5225 profiles have to pick
>>> one version of each profile without knowing the capabilities of the
>>> compressor.
>> So the profile which can be seen from the packet is different than
>> what is seen in the 16-bit profile number which will be sent inside
>> the IKEv2 negotiation?
>>
> 
> Yes, the 8 most significant are the version and the least significant is
> the profile. You cannot negotiate two profiles with the same 8 least
> significant bits.
> 
>>> 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 some may want to implement RFC3095 profiles with 
ROHCoIPSec, and the signaling approach may not allow some devices in 
some situations to utilize ROHC.

One point to note is that we are working to compile a specification for 
use with IKEV2, and implementers could use this as an opportunity to 
move from RFC 3095 ROHC to 4995/5225 ROHC.

Cheers,

Bob

> _______________________________________________
> Rohc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rohc