Re: FW: CDR review ROHCoIPSec

Emre, Robert, Tero,

Comments inline..

Tero Kivinen wrote:
> Ertekin, Emre [USA] writes:
>>> There is an inherent friction between bandwidth and security
>> concerning
>>> the ROHC ICV. Since one of primary goals of ROHC is to reduce
>>> bandwidth,
>>> perhaps it would be worthwhile if the IKEv2 extension to ROHC provided
>>> some flexibility to negotiate the length of the ROHC ICV (perhaps by
>>> truncation), agnostic of the algorithm used.
>> Although this may provide efficiency benefits, there are some
>> considerations to this approach.  One of them includes interoperability,
>> where one vendor may end up supporting ICVs of length 32, another vendor
>> would support ICVs of 64, another 96.  One might propose providing the
>> flexibility to support variable length ICVs in a ROHCoIPsec
>> implementation--but this flexibility comes at the cost of increased
>> complexity when implementing.
> 
> As the macs normally used in the IPsec are already truncated, and we
> would here only want to truncate them even more, I think it would
> quite easy to support any ICV length between 0-12 bytes. There is also
> completely valid reasons to use 0 bytes of ICV, for example in case
> the environment is known to be such that attackers cannot remove
> packets. Also even though the actual algorithm used should be same for
> both directions (as is normal in IPsec SAs), there is no need for the
> truncation length (if it is negotiated separately as I think would be
> best) to be same in both directions, i.e for high bandwidth upload
> link it might be longer, than in the very low bandwidth backward link
> which is used only for TCP ACKs anyways.
> 
>> Although the current text for negotiation of ROHC channel parameters in
>> the IKEv2 extensions draft aligns with the operation of IKEv2 (e.g.,
>> negotiation of IPcomp algorithms, where the initiator lists the
>> algorithms supported, and the responder selects the algorithm selected
>> for the SA), there appears to be no technical motivation for the
>> "negotiation"-based approach.
> 
> I actually think it is unfortunate that we made the IPcomp to use that
> kind of negotiation in the IKEv2. I think much better method for the
> IPcomp negotiation in the IKEv2 would have been so that both ends just
> send list of the supported IPcomp algorithms they are willing to
> receive on, and sender can use any of those to compress packet when
> sending packets to him. The different IPcomp algorims are already
> distinguished from each other by the CPI value send in the
> notification.
> 
> Unfortunately the IKEv2 specification decided to explictly forbid that
> kind of negotiation (and I do not know any good reason why we decided
> that way)...
> 
> In the ROHC, I think it makes much more sense to advertise what kind
> of parameters peer can accept when receiving packet, and sender peer
> will then limit its parameters to those that the responder can accept.
> 
> I do not think there is any need to agree symmetric parameters, and
> agreeing on specific parameters is always hard if you have multiple
> different type of parameters (i.e. some are lists where other end
> needs to pick one, other are numeric parameters where other end needs
> to pick number smaller or equal the number sent by other end etc).
> 
> It gets even more complicated if not all values are allowed (for
> example you have paremeter which must be multiple of 4 or similar in
> your end, and the other end does not have this limitation). 
> 
> Of course it does require that parameters are such that they can
> either been seen from the packet or the mismatch does not matter. I.e.
> the MAX_CID I guess it does not matter what maximum number each other
> is configured, as long as the sender keeps its context ID numbers
> below the MAX_CID announced by the recipient.
> 
> 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.

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.

/Calle