Re: FW: CDR review ROHCoIPSec

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 protected]

Best Regards,
Emre