[Fwd: [Fwd: Returned mail: see transcript for details]]

Hi all,

Robert asked me to forward one of his email that didn't reach the
mailing list because of some technical issue. Here it is.

/Calle

---

Subject: Re: [rohc] FW: CDR review ROHCoIPSec
From: "Robert A. Stangarone Jr." <[email protected]>
Date: Mon, 01 Dec 2008 07:52:35 -0800
To: Tero Kivinen <[email protected]>
CC: "Ertekin Emre [USA]" <[email protected]>, "Christou Christos
\[USA\]" <[email protected]>, [email protected], [email protected], Yoav Nir
<[email protected]>

Tero,

See my responses 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.
>

RFC 4995, Section 5.2.2.1 shows the general format of an IR header,
which is used to establish a context (including a CID and associated
PROFILE):

5.2.2.1. ROHC IR Packet Type


   The IR header associates a CID with a profile, and typically also
   initializes the context.  It can typically also refresh all (or parts
   of) the context.  For IR, Header has the following general format:

     0   1   2   3   4   5   6   7
    --- --- --- --- --- --- --- ---
   :         Add-CID octet         :  if CID 1-15 and small CID
   +---+---+---+---+---+---+---+---+
   | 1   1   1   1   1   1   0 | x |  IR type octet
   +---+---+---+---+---+---+---+---+
   :                               :
   /      0-2 octets of CID        /  1 or 2 octets if large CIDs
   :                               :
   +---+---+---+---+---+---+---+---+
   |            Profile            |  1 octet
   +---+---+---+---+---+---+---+---+
   |              CRC              |  1 octet
   +---+---+---+---+---+---+---+---+
   |                               |
   / profile specific information  /  variable length
   |                               |
   +---+---+---+---+---+---+---+---+

   x: Profile specific information.  Interpreted according to the
      profile indicated in the Profile field of the IR header.

   Profile: The profile associated with the CID.  In the IR header, the
      profile identifier is abbreviated to the 8 least significant bits
      (see Section 5.1.2).

   CRC: 8-bit CRC (see Section 5.3.1.1).

   Profile specific information: The content of this part of the IR
      header is defined by the individual profiles.  It is interpreted
      according to the profile indicated in the Profile field.

So here you can see that only the 8 LSBs of the 16-bit PROFILE ID are
transmitted. The RFC 3095, 4995, and 5225 all use the same LSBs for
different versions of the PROFILES. This is why it is important to only
signal one PROFILE during the IKE_AUTH/CREATE_CHILD_SA exchange.

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

Agreed but, we need to address the case where more than on variant of
the same PROFILE may be supported by the sender.
>
> 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.
>
> 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.
> ----------------------------------------------------------------------
>
> 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.

Cheers,

Bob

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