Subject: [rohc] CDR review ROHCoIPSec

From: "Robert A. Stangarone Jr." <[email-masked]>
Date: Thu, 13 Nov 2008 13:41:12 -0800

Authors and ROHCers,

Here are my comments on the following documents:

draft-ietf-rohc-hcoipsec-09.txt
draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt 		
draft-ietf-rohc-ipsec-extensions-hcoipsec-03.txt

The comments are a combination of my review as well as input from 
several other members of my team. I hope you find them useful, and thank 
you for the opportunity to review and provide input on your work.

------------------------------------------------------------------------

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Feedback:

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

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

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.

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.

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.

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

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.

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.

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.

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

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?).
- The Payload Length field should have a description and identify the 
valid range of values.

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?).
- The Profiles field description has a broken reference to [ROHCPROF].

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...".
- Please clarify that when Zero is received by either end, no integrity 
shall be applied by either ROHC compressor.
- "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.

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.

--------------------------------------------------
IETF idnits tool output:

idnits 2.10.00 (04 Nov 2008)

tmp/draft-ietf-rohc-ipsec-extensions-hcoipsec-03.txt:

Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:

----------------------------------------------------------------------------

      No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

----------------------------------------------------------------------------

   == No 'Intended status' indicated for this document; assuming Proposed
      Standard

Checking nits according to http://www.ietf.org/ID-Checklist.html:

----------------------------------------------------------------------------

      No issues found here.

   Miscellaneous warnings:

----------------------------------------------------------------------------

      No issues found here.

Checking references for intended status: Proposed Standard

----------------------------------------------------------------------------

(See RFCs 3967 and 4897 for information about using normative references 
to lower-maturity documents in RFCs)

   -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2EXT'

      Summary: 0 errors (**), 1 warning (==), 1 comment (--).

Run idnits with the --verbose option for more detailed information about 
the items above.
--------------------------------------------------------------------------------

idnits 2.10.00 (04 Nov 2008)

tmp/draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt:

Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:

----------------------------------------------------------------------------

      No issues found here.

Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

----------------------------------------------------------------------------

   == No 'Intended status' indicated for this document; assuming Proposed
      Standard

Checking nits according to http://www.ietf.org/ID-Checklist.html:

----------------------------------------------------------------------------

      No issues found here.

   Miscellaneous warnings:

----------------------------------------------------------------------------

      No issues found here.

Checking references for intended status: Proposed Standard

----------------------------------------------------------------------------

(See RFCs 3967 and 4897 for information about using normative references 
to lower-maturity documents in RFCs)

-- Possible downref: Non-RFC (?) normative reference: ref. 'ROHCOIPSEC'

      Summary: 0 errors (**), 1 warning (==), 1 comment (--).

Run idnits with the --verbose option for more detailed information about 
the items above.
--------------------------------------------------------------------------------

idnits 2.10.00 (04 Nov 2008)

tmp/draft-ietf-rohc-hcoipsec-09.txt:

Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:

----------------------------------------------------------------------------

      No issues found here.

Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

----------------------------------------------------------------------------

      No issues found here.

Checking nits according to http://www.ietf.org/ID-Checklist.html:

----------------------------------------------------------------------------

      No issues found here.

   Miscellaneous warnings:

----------------------------------------------------------------------------

      No issues found here.

Checking references for intended status: Informational

----------------------------------------------------------------------------

      No issues found here.

      No nits found.
--------------------------------------------------------------------------------

------------------------------------------------------------------------

Cheers,

Robert (Bob) Stangarone
[email-masked]
_______________________________________________
Rohc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rohc