FW: CDR review ROHCoIPSec
"Ertekin, Emre [USA]" <[email protected]>
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <37BDD2FAF2AEAE459C6C70FDC2892E4E0398FFC0@MCLNEXVS05.resource.ds.bah.com> |
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