Subject: Re: [rohc] FW: CDR review ROHCoIPSec

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Mon, 1 Dec 2008 23:56:36 -0500

Hi Tero,

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

Sure, we can tailor the drafts such that there is flexibility to support
variable length (0-12 byte) ICVs.  We will use the notification
structure that you proposed below.

Regarding 0-byte ICVs: we also anticipated that this may be desirable
for some ROHCoIPsec scenarios--which is why we included support for this
case in previous versions of the drafts.

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

Yes, this was our understanding.  We can explicitly state this in the
document.

<snip>

> On the other hand I would suggest the notification data structure to
> have list of attributes instead of the current fixed format, i.e. make
> the notification data of the ROHC_SUPPORTED to be list of transform
> attributes using same format as specified in the section 3.3.5 of
> RFC4306, i.e.:
> 
> ----------------------------------------------------------------------
>                            1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       !A!     ROHC Attribute Type     !  AF=0  ROHC Attribute Length
!
>       !F!                             !  AF=1  ROHC Attribute Value
!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       !                   AF=0  ROHC Attribute Value
!
>       !                   AF=1  Not Transmitted
!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Where the "Attribute Type" values would be IANA registry having
> following initial values:
> 
>   ROHC Attribute Type Values
> 							      Type
>       RESERVED
0
>       Maximum value of context identifier (MAX_CID)		1
>       ROHC Profile (PROFILE)					2
>       ROHC Integrity Algorithm (ROHC_INTEG)			3
>       ROHC ICV Length in bytes (ROHC_ICV_LEN)			4
> 
> If unknown ROHC Attribute Type Value is received in the request then
> it is silently ignored, and no such attribute is added to the reply
> sent back to the other end. If unknown ROHC Attribute Type Value is
> received in the reply then that is silently ignored. Using this rules
> it means there is way to add new attributes which can be of either
> negotiated attributes (like ROHC_INTEG) or announced attributes like
> (MAX_CID, PROFILE or ROHC_ICV_LEN). For negotiated attributes they
> must be supported by both initiator and responder to be enabled, thus
> if initiator does not add support such attribute it will not include
> it to request, then responder cannot select one, and if initiator
> supports it but responder does not, then responder does not select any
> of the attributes, and the feture is not enabled. For the announcement
> type of attributes both ends can simply send them at will, and they
> are only announcing what other end can do, so there is no danger of
> ignoring them.

This approach is good.
 
> There MUST be exactly one MAX_CID attribute and its ROHC Attribute
> Value field must number between 0-16383 (and is always using AF=1
> format). The MAX_CID value specifies the maximum value the sender of
> this message can support, i.e. the recipient of this message can use
> up to that many context identifiers when sending data to other end.
> Both ends simply announce their own capabilities, and they does not
> need to negotiate or agree on single value. This is mandatory
> attribute.

OK -- this is good, too.
 
> There can be multiple PROFILE attributes, and in those the ROHC
> Attribute Value specifies the supported 16-bit profile identifiers
> (using AF=1 format). The list of profile identifiers specifies which
> ROHC profiles are supported by the sender for incoming traffic, i.e.
> the recipient of this message can use any of those profiles when
> sending data to the other end. Both ends simply announce their own
> capabilities, and they does nto need to negotiate or agree on using
> any of the profile. There must be at least one of the profiles if ROHC
> is supported at all.

OK.

> There can be multiple ROHC_INTEG attributes when the initiator is
> sending its list of supported ROHC integrity algorithms, and responder
> needs to select exactly one of those and send that back. The integrity
> values are taken from the IKEv2 Transform Type 3 (Integrity Algorithm)
> IANA registry (either by copying the current values to new registry or
> directly referencing to the existing registry) and are encoded using
> AF=1 format. This same integrity algorithm is used in both directions.
> This is optional attribute, but if initiator sent any of the
> ROHC_INTEG attributes, then responder MUST select one of them to be
> used. The selected one can be value 0 (NONE) if that was proposed by
> the initiator.

Sure, this sounds great.  One additional clause that we might want to
add is that the list of supported ROHC_INTEG attributes is ordered, in
terms of the initiator's most-preferred integrity algorithm to least
preferred. 

> The ROHC_ICV_LEN attribute specifies the number of octects the sender
> of this message wants to receive on incoming ROHC packets. This is
> always encoded using AF=1 format. I.e. the ICV field of the negotiated
> ROHC_INTEG algorithms are truncated to this many bytes by taking the
> first n bytes of the output. Both ends simply announce their own
> requirement, and they does not need to negotiate or agree on single
> value. The sender end MUST truncate the ICV to length required by the
> other end before sending ICV. If ROHC_ICV_LEN length is zero then no
> ICV is calculated or sent. If no ROHC_ICV_LEN attribute is sent at all
> or the ROHC_ICV_LEN is larger than the length of the ICV of selected
> algorithm, then the full ICV length as specified by the ROHC_INTEG
> algorithm is sent.

Sounds good!

> ----------------------------------------------------------------------
> 
> The reason for using the attribute format already specified in the RFC
> 4306 is that there is already code to parse and process that kind of
> lists of attributes, thus parsing and generating such lists is easy,
> and this also makes it easy to extend parameter negotiation in future
> in case there are new ROHC profiles created which need more
> parameters.
> --
> [email-masked]

Best Regards,
Emre
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Mon, 1 Dec 2008 23:56:37 -0500

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

---

From: "Robert A. Stangarone Jr." <[email-masked]>
Date: Mon, 01 Dec 2008 08:47:07 -0800

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
>>> channel only supporting the uncompressed profile. By having a two-way
>>> "negotiation-approach" you will be able to advertise all profiles you
>> 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
>> and RFC5225 versions, and if responder supports both it MUST not send
> 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

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