Subject: [rohc] FW: CDR review ROHCoIPSec

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Tue, 25 Nov 2008 11:38:32 -0500

Robert,

Thank for taking the time to provide us an in-depth review of our
drafts.  Please find our responses to your comments inline:

> ------ draft-ietf-rohc-hcoipsec-09.txt ------
> 
> Suggest rewording throughout document (i.e. changing of "inner" to
> "encapsulated") to indicate that all headers that are supported by
ROHC
> Profiles can be compressed by ROHC before being encapsulated in an
> IPsec
> packet.

We are using terminology consistent with RFC 4301.  Therefore, I would
like to leave this wording as-is.

> 1. Introduction:
> 
> Suggest rewording second sentence of second paragraph to state:
> "...hop-by- hop basis, it requires extensions..." as ROHC will require
> IPsec extensions to enable its operation over IPsec SAs, hence the
need
> for the ROHCoIPsec document.

OK.

> 3. Terminology:
> 
> Suggest rewording the Compressed Traffic section as follows:
> 
> "Traffic that is processed through the ROHC compressor and
decompressor
> instances. Packet headers are compressed and decompressed using a
> specific header compression Profile."
> 
> This is more accurate as the compressor works in conjunction with the
> decompressor to compress traffic over a ROHC Channel. ROHC uses
> Profiles
> to compress specific protocol header types.

OK.

> 5.2 Summary of the ROHCoIPsec Framework:
> 
> Suggest rewording of second sentence of third paragraph as follows:
> 
> "Compression of the encapsulated IP and transport layer protocol
> headers
> in such a manner offers a reduction of per-packet protocol overhead
> between the two SA endpoints."
> 
> This more accurately describes that the encapsulated headers are being
> compressed.

Again, I would like to remain consistent with terminology used in RFC
4301.  Therefore, I would like to leave this text as-is.

> Suggest rewording of third sentence in fifth paragraph as follows:
> 
> "For tunnel mode SAs, compression may be applied to the transport
layer
> header and the IP header before encapsulation." Compression is applied
> to the header, not the protocol.

I left the "inner" nomenclature in the sentence; however, to address
your comment, I've also updated the text to read as follows: "For tunnel
mode SAs, compression may be applied to the transport layer and the
inner IP headers".

> The final paragraph's assertion that "...intermediary devices...will
be
> unable to determine the content of these packets since they are unable
> to parse the ROHC-compressed headers." is not true. The ESP header
> contains a next header field which could be used to determine that its
> payload is a ROHC packet. Capturing enough packets, especially a
packet
> with a ROHC IR header, could allow an attacker to build a local copy
of
> a ROHC context in use.

I agree that the paragraph here needs to be re-worked.  We wanted to
call this out to indicate the challenges that ROHC poses on intermediary
devices  (e.g., as defined in " draft-ietf-ipsecme-traffic-visibility").

I've updated the second sentence to read the following:

"However, this poses challenges for intermediary devices (within the
unprotected domain) inspecting ESP-NULL encrypted packets; these
intermediary devices will require additional functionality to determine
the content of the ROHC packets."

> 6.1 ROHC and IPsec Integration:
> 
> This section could be improved by including references and diagrams
> related to RFC 3759, sections 5 (Unidirectional mode) and 6.2
> (Bidirectional mode) where appropriate. Also suggest that the outbound
> and inbound processing discussions be broken into independent
> subsections (each with their own diagrams) for clarity, as within this
> section there are 2 "Block A:" and 2 "Block B:" paragraphs.

This section is meant only to provide a simple explanation of the steps
needed for a RoHCoIPSec node to process packets; it is not meant to
provide an exhaustive explanation.  However, we will include a
note/reference regarding RoHC unidirectional and bidirectional mode.

> 6.1.1.  Header Compression Protocol Considerations
> The entire last paragraph "Additionally, ROHCoIPSec..." is a general
> ROHC issue, which belongs in the ROHC RFC, not this one.

I don't think that it hurts to keep this paragraph in here.  The
consequences of sending feedback within the context of ROHCoIPsec is
more severe than traditional hop-by-hop ROHC (from an efficiency
perspective) since feedback needs to be tunneled from the decompressor
to the compressor.

> 6.1.3 Encapsulation and Identification of Header Compressed Packets:
> 
> Suggest rewording fourth sentence to state: "Another example is when
> traffic is selected by IPsec to a ROHC-enabled SA, but cannot be
> compressed by the ROHC process because the appropriate ROHC Profile
has
> not been negotiated for use." This is a more technically correct
> explanation of a case where a particular packet type might not be
> compressed by a ROHC process.

Good suggestion.  I will change the text accordingly.

> The final sentence in the last paragraph discussing an IANA allocation
> of a Protocol ID should be removed and a request added to section 8 as
> noted below.

This draft is intended to be an Informational RFC; this is why we
included the ProtocolID allocation in the IPsec extensions draft.

> 8. IANA Considerations:
> 
> This section should request an IANA protocol allocation per:
> http://www.ietf.org/ID-Checklist.html, section 2.2, item 7, parts A
and
> B.

Please see above.

> ------ draft-ietf-rohc-IPsec-extensions-hcoipsec-03 ------
> 
> 2.1 Security Policy Database (SPD)
> 
> Segmentation:
> 
> Suggest you include a reference to section 5.2.5 of RFC 4995 and 6.1
of
> RFC 5225 for additional justification of why segmentation is not used.

OK.

> Feedback:
> 
> A reference to section 6.2 of RFC 3759 may be helpful to provide
> additional information to the reader.

Agreed.  We added the reference to Section 6.2 of RFC 3759 as
recommended.  In addition, we added this reference to the framework
draft, section 6.1.2.

> The last sentence in section 2.1 states that: "If an SA in the reverse
> direction does not exist, ROHC must operate in the Unidirectional
> Mode."
> Suggest rewording to state: "If an SA in the reverse direction does
not
> exist, ROHC must not operate in Bidirectional Mode", As ROHC always
> begins operation in Unidirectional Mode (see RFC 5225, Section 6.2).

OK.

> 2.2.  Security Association Database (SAD)
> 
> Section 2.1 last paragraph & section 2.2:
> 
> The FEEDBACK_FOR ROHC Channel Parameter should only be populated in
the
> SAD when a SA in the reverse direction is available. Section 2.2 needs
> clarification regarding the purpose/function of each of the ROHC SAD
> configuration items as they relate to the directional processing flow
> (inbound and outbound) of a particular SA.
> 
> 3.1 Addition to the IANA Protocol Numbers Registry
> 
> Suggest rewording final sentence as follows: "Conversely, for an
> inbound
> packet, the value of the security protocol Next Header field is
checked
> to determine if the packet includes a ROHC header, in order to
> determine
> if it requires ROHC decompression. See section 6.1 of [ROHCoIPsec]."
> This clarifies the role of the Next Header Field in determining what
> action is taken upon detection of a "ROHC" value.

As you suggested, I added the clause "in order to determine if it
requires ROHC decompression".  However, I omitted the last sentence of
your proposed text, since this draft will contain the ProtocolID
allocation.

> 3.2 Verifying the Integrity of Decompressed Packet Headers
> 
> Suggest rewording the third sentence in the first paragraph as
follows:
> "At the decompressor, the decompressed packet (including the
> uncompressed IP header, higher-layer headers, and packet payload; but
> not including the authentication data) will be used with the Integrity
> Algorithm (and its respective key) to compute a value that will be
> compared to the appended ICV." This clarifies that the ICV calculated
> at
> the decompressor is compared to the ICV that was calculated at the
> compressor.

OK.

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

> 3.2.1.  ICV Computation and Integrity Verification
> The last bullet of the last list should be reworded as follows: "The
> decompressed packet is used with the Integrity Algorithm (and its
> respective key) to compute a ROHC ICV that is compared to the appended
> ICV (if these two values differ, the packet is dropped)"

OK.

> 4.  Security Considerations
> First paragraph:
> 
> A mention of the trade off associated with using the ROHC ICV should
be
> included. Use of a ROHC ICV offers better security, but the ICV also
> adds bytes to the packets ROHC is trying to compress. RoHC mechanisms
> will be used by people who absolutely, positively, must squeeze every
> last bit of bandwidth efficiency out of their links. The ICV is nice
> from a security point of view, but will probably very rarely be used
in
> practice.

We agree with the trade off that you pointed out of security vs.
efficiency.  

I changed the paragraph to read the following:

"...forwarded by a ROHCoIPsec device into a protected domain.  On the
other hand, using a strong integrity check will reduce the overall
efficiency benefit offered by header compression.

One approach to mitigate this security concern is as follows: if an
integrity check algorithm is used with IPsec, leverage an
equivalent-strength integrity check algorithm for verifying the valid
decompression of headers."

> Last paragraph:
> 
> The need for Traffic Flow Confidentiality (TFC), and and the need for
> aggressive header compression techniques are simply mutually
exclusive.
> People using ROHC almost certainly can't spare the extra bytes needed
> to
> provide effective packet size obfuscation. If TFC mechanisms are
needed
> on their ROHC enabled SA, then they should be using standard ESPv3
> level
> TFC mechanisms.

The use of ROHC padding is not mandatory; we say that it "may" be used.
It is only proposed as a way to mitigate the security consideration.   I
did add a sentence that again indicates that the overall efficiency
benefit of header compression is reduced with the use of padding.

> 5. IANA Considerations:
> 
> The request for IANA to allocate a Protocol ID for ROHC should be
moved
> to the ROHCOIPSEC document. The Integration of ROHC over IPsec SAs
> requires the ROHC Protocol ID for the Next Header field for
> de-multiplexing inbound traffic.

Please see previous responses regarding the allocation of the ROHC
Protocol ID.
 
> ------ draft-ietf-rohc-ikev2-extensions-hcoipsec-07 ------
> 
> 2.1.  Negotiation of ROHC Channel Parameters
> 
> This section describes a negotiation process for establishing ROHC
> channel parameters using IKEv2. This process assumes that ROHC
> parameters must be the same for both of the logical channels
> established
> during the IKE negotiation. For example, consider the following
> sequence
> of ROHC negotiation events:
> 
>    Initiator sends:
>       MAX_CID=10
>       PROFILES=IP,UDP/IP
> 
> The responder is then constrained to reply with MAX_CID<=10, and
> PROFILES being a subset of IP,UDP/IP. Suppose the responder can only
> handle the IP profile, and MAX_CID=5:
> 
>    Responder sends:
>       MAX_CID=5
>       PROFILES=IP
> 
> This results in the establishment of 2 logical ROHC channels, which
> have
> identical ROHC parameters, as illustrated in the following diagram:
> 
> 
> 
>           INITIATOR                               RESPONDER
> -----------------------------            -----------------------------
> 
> 
> 
>          feedback      +-----+   chan2   +-----+        feedback
>      +---------------->|     |---------->|     |------------------+
>      |                 |     |           |     |                  |
>      |                 |     |           |     |                  |
>      |                 | oSA |           | iSA |                  |
>      |                 |     |           |     |   MAX_CID=5      |
>      |                 |     |   chan1   |     |   PROFILES=IP    |
>      |          +----->|     |---------->|     |------+           |
>      |          |      +-----+           +-----+      |           |
>      |          |                                     v           v
> +--------+  +-------+                             +--------+
+-------+
> | chan2  |  | chan1 |                             | chan1  |  | chan2
|
> | Decomp |  | Compr |                             | Decomp |  | Compr
|
> +--------+  +-------+                             +--------+
+-------+
>      ^          ^                                     |           |
>      |          |      +-----+   chan1   +-----+      |           |
>      |          +------|     |<----------|     |<-----+           |
>      |     feedback    |     |           |     |    feedback      |
>      |                 |     |           |     |                  |
>      |                 | iSA |           | oSA |                  |
>      |MAX_CID=5        |     |           |     |                  |
>      |PROFILES=IP      |     |   chan2   |     |                  |
>      +-----------------|     |<----------|     |<-----------------+
>                        +-----+           +-----+
> 
> 
> Where:
> oSA    = Outbound SA
> iSA    = Inbound SA
> chan1  = Logical RoHC Channel #1
> chan2  = Logical RoHC Channel #2
> Compr  = RoHC Compressor instance
> Decomp = RoHC Decompressor instance
> 
> In the scenario described above, both RoHC Channel #1 (inside loop)
and
> RoHC Channel #2 (outside loop) are constrained to use the same MAX_CID
> and PROFILES, even though they are logically separate. The channel #1
> decompressor (on the Responder) only supports 6 contexts and the IP
> profile. Similarly, the channel #2 decompressor on the Initiator only
> supports 6 contexts and the IP profile.
> 
> While this negotiation mechanism is functional, it is slightly more
> complicated than necessary, and unnecessarily constrains the ROHC
> channels. Given that the ROHC channels are logically separate, there
is
> no reason for their parameters to necessarily be symmetric.
> 
> Instead, a ROHC parameter "signaling" mechanism would be more
flexible.
>   Such a signaling mechanism would use the same ROHC Notify payload
> format, but it would not constrain the Responder to only reply with
> support for a subset of the parameters provided by the Initiator.
> Rather, ROHC Notify payloads simply indicate to the peer what the
local
> decompressor will be able to handle. This would allow for a more
> flexible ROHC channel establishment scenario, such as:
> 
>    Initiator indicates decompressor capabilities, by sending:
>       MAX_CID=10
>       PROFILES=UDP/IP
> 
> The responder replies with its own capabilities as a decompressor,
> regardless of what was transmitted by the initiator.
> 
>    Responder sends:
>       MAX_CID=15
>       PROFILES=IP
> 
> 
> 
> Now, our ROHC channels will be established as follows:
> 
> 
> 
>           INITIATOR                               RESPONDER
> -----------------------------            -----------------------------
> 
> 
> 
>          feedback      +-----+   chan2   +-----+        feedback
>      +---------------->|     |---------->|     |------------------+
>      |                 |     |           |     |                  |
>      |                 |     |           |     |                  |
>      |                 | oSA |           | iSA |                  |
>      |                 |     |           |     |   MAX_CID=15     |
>      |                 |     |   chan1   |     |   PROFILES=IP    |
>      |          +----->|     |---------->|     |------+           |
>      |          |      +-----+           +-----+      |           |
>      |          |                                     v           v
> +--------+  +-------+                             +--------+
+-------+
> | chan2  |  | chan1 |                             | chan1  |  | chan2
|
> | Decomp |  | Compr |                             | Decomp |  | Compr
|
> +--------+  +-------+                             +--------+
+-------+
>      ^          ^                                     |           |
>      |          |      +-----+   chan1   +-----+      |           |
>      |          +------|     |<----------|     |<-----+           |
>      |     feedback    |     |           |     |    feedback      |
>      |                 |     |           |     |                  |
>      |                 | iSA |           | oSA |                  |
>      |MAX_CID=10       |     |           |     |                  |
>      |PROFILES=UDP/IP  |     |   chan2   |     |                  |
>      +-----------------|     |<----------|     |<-----------------+
>                        +-----+           +-----+
> 
> 
> Note that this signaling mechanism allows more flexibility than the
> negotiation mechanism, but it does not force an implementation into
> using asymmetric ROCH channel parameters. An implementation could
> easily
> internally affect the same results as the negotiation mechanism, by
> simply limiting itself to only using a common subset of ROHC
parameters
> when acting as a compressor - a peer says it can support a certain
> number of CIDs or profiles as a decompressor, but it does not mean the
> associated channel compressor _has_ to use all of them.

The co-authors of the ROHCoIPsec drafts ended up talking about this
quite a bit at the IETF this last week.  In addition, we discussed this
approach with several IKE experts.  In short, we concluded that both
approaches functionally work... 

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.  

Since the "signaling" proposal is a bit more flexible, we will update
the draft based on your recommendation.  Specifically, we will change
the descriptions for the ROHC channel parameters for the ROHC_SUPPORTED
Notify Payload, and the surrounding text to indicate signaling based
approach.

> Section 2.1 contains field descriptions for the Notify Payload format.
> There is no description for the RESERVED or Payload Length fields.
> - The RESERVED field is static in nature, and should have its value
> specified (all zeros?).

OK--we indicated that this field must be set to 0, and must be ignored
upon receipt.  

> - The Payload Length field should have a description and identify the
> valid range of values.

OK.

> This document needs to state that the final negotiated set of profiles
> (as transmitted by the responder if the signaling approach suggested
> above is adopted) MUST NOT contain in invalid combination of RoHCv1
and
> RoHCv2 profiles. For example, a RoHC channel cannot support both RFC
> 3095 UDP/IP and RFC 5225 UDP/IP.
> 
> For the Notify Message Type field, ROHC_SUPPORTED is specified, but
> there is no description of what value in that field indicates
> ROHC_SUPPORTED. What value should be used? Some reference to the need
> for IANA to allocate a IKEv2 Notify message registry would be
> informative.
> 
> For the Notification Data field:
> - The RESERVED field is static in nature, and should have its value
> specified (all zeros?).

OK--we indicated that this field must be set to 0, and must be ignored
upon receipt.

> - The Profiles field description has a broken reference to [ROHCPROF].

Fixed it, thanks!

> For the INTEGRITY ALGORITHMS field:
> - States: "In the case where a ROHCoIPsec implementation chooses to
> negotiate a value of "0" (this should be "zero" for consistency with
> your other field descriptions) in this field...".

OK.

> - Please clarify that when Zero is received by either end, no
integrity
> shall be applied by either ROHC compressor.

OK.

> - "The key for this Integrity Algorithm is computed using the same
> method as is used to compute IPsec's Integrity Algorithm key ([IKEV2],
> Section 2.17)." This is not a sufficient specification for how the key
> is derived. The document needs to explicitly state how the key is cut
> from KEYMAT.
> 

Could you clarify why this is not sufficient?  From RFC 4306, Section
2.17:

      All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going in the reverse direction.

      If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

      If a single protocol has both encryption and authentication keys,
      the encryption key is taken from the first octets of KEYMAT and
      the authentication key is taken from the next octets.

In other words, the keying material is derived from the order of
protocol headers for the encapsulated packet.  For example, for the SA
carrying data from initiator to responder, the order of keys derived
will be the keys for the IPsec security protocols (encryption key (if
any), authentication key (if any)) and then the authentication key will
be cut for ROHC.  After this, the keys for the responder to initiator SA
are derived in a similar fashion.

> General:
> 
> This document needs to clearly specify that/how 2 logically
independent
> ROHC channels(compressor/decompressor pairs) are established during
the
> IKE negotiation. Both IPsec peers will be able to RoHC
> compress/decompress traffic flows, and the CID space used for each of
> those channels is independent. Without explicitly describing this,
> there
> is room for misinterpretation in implementations.

OK, we will take a look through the document and clarify this.  We will
also add a reference to Section 6.2 of RFC 3759 where appropriate.

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 26 Nov 2008 16:25:01 +0200

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

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

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.

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. 
-- 
[email-masked]
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 27 Nov 2008 10:50:16 +0100

Emre, Robert, Tero,

Comments inline..

> 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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 27 Nov 2008 14:20:47 +0200

> one version of each profile without knowing the capabilities of the

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? 

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

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?
-- 
[email-masked]
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 28 Nov 2008 12:46:31 +0100

> what is seen in the 16-bit profile number which will be sent inside

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.

> version. If responder selects RFC5225 version then that will be used

This solution could probably work.

I am ok with the existing solution in
draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt too.

> IKEv2? Is the older RFC3095 profile really even an option with IKEv2

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