CDR review ROHCoIPSec
"Robert A. Stangarone Jr." <[email protected]>
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <[email protected]> |
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 protected]