Emre Ertekin wrote:[mailto:emreertekin.ietf@xxxxxxxxx] > > 1) None of the drafts really describe the reason why the ROHC ICV > > is included. It was not present in the early drafts, and was added > > after long and complex discussions. I would strongly encourage > > summarizing those discussions in one of the drafts -- otherwise, > > the reader cannot really figure out why the ROHC ICV is included > > (since the packets are already protected by the AH/ESP ICV), and > > what risks omitting the ROHC ICV might have. > > Sure, we can add some description on this. How much detail are you > looking for? > > Perhaps we can add the following text in a separate section under > Section 6.1 of the framework draft, entitled "Motivation for the > ROHC ICV": > > Although ROHC was designed to tolerate packet loss and > reordering, the algorithm does not guarantee that packets > reconstructed at the decompressor are identical to those > constructed at the compressor. As stated in Section 5.2 of > [RFC 4224], the consequences of packet reordering between ROHC > peers may include undetected decompression failures, where > erroneous packets are constructed and forwarded to upper > layers. > > When using IPsec integrity protection, a packet received at > the egress of an IPsec tunnel is identical to the packet that > was processed at the ingress (given that the key is not > compromised, etc.). > > When ROHC is integrated into the IPsec processing framework, > the ROHC processed packet is protected by the AH/ESP ICV. > However, bits in the original IP header are not protected by > this ICV. Therefore, under certain circumstances, erroneous > packets may be constructed and forwarded into the protected > domain. > > To ensure the integrity of the original IP header within the > ROHCoIPsec-processing model, an additional integrity check may > be applied before the packet is compressed. This integrity > check will ensure that erroneous packets are not forwarded > into the protected domain. The specifics of this integrity > check are documented in Section 3.2 of [IPSEC-ROHC]. Looks very good! > > 2) ipsec-extensions, Section 3.3, doesn't really correctly > > describe the MTU-related processing in RFC 4301. The three cases > > refer to IPsec implementations that both process unprotected ICMP > > messages and actually receive them (they're often filtered in the > > network), and thus have a Path MTU estimate value. But an IPsec > > implementation that doesn't process (or receive) unprotected ICMP > > messages does not even have a Path MTU estimate value... > > This is a good point. I would assume that if the IPsec implementation > does not have a Path MTU estimate value, then it SHOULD NOT attempt to > segment packet headers, as it does not have full insight into the MTU > in the unprotected domain. Is this in line with your thoughts? Yes. > > 3) According to RFC 4224, ROHC segmentation does not work over > > reordering channels. Thus, it seems suggesting that ROHC > > segmentation could be used instead of pre-encryption fragmentation > > (e.g. ipsec-extensions, Section 3.3) -- and in general, allowing > > segmentation at all -- seems misguided (it's unnecessary > > complexity that would be IMHO best left out). > > Although I agree that ROHC segmentation is not a good idea, it is an > optional functionality in the spec. The implementer can decide > whether or not they want to code it. > > If a vendor chooses not to implement the functionality, they can > hardwire the MRRU channel parameter to zero. OK, let me phrase my question in another way: why does the spec contain a feature that does not really work? (Even as optional feature?) > > 4) None of the drafts have any RFC 2119 keywords > > (MUST/SHOULD/etc). They SHOULD use those to make it less > > ambiguous what is the required behavior (and what is optional) to > > claim compliance with these drafts. > > OK, we will take a run through the IKEv2 and IPsec extensions drafts > to account for these keywords. Not the framework draft though, since > the draft is intended to be informational. Being "Informational" (vs. Proposed Standard) RFC has nothing to do with the question -- many Informational RFCs do use RFC 2119 keywords, and there's nothing special about that. To me, it looks like the framework draft has normative statements (things implementations are required or recommended to do in order to get interoperability), too, so 2119 keywords would be appropriate (and actually, it could be Standards Track, too). > > 5) In ikev2-extensions, Section 2.1.2 it is not very clear which of > > the attributes are just one-way notifications (the sender of the > > attribute tells the other end what it can handle), and which are > > negotiated (the initiator tells the other end what it supports; the > > responder then selects one, and tells what it selected). > > > > I would suggest adding text like "Note that different ATTRIBUTE_NAME > > value can be used in each direction" for those attributes that are > > just one-way (I think at least MAX_CID, ROHC_PROFILE -- for MRRU and > > ROHC_ICV_LEN, I don't know which way they're supposed to work). > > OK, sounds good. We will add this clarification to the parameters. > > FYI, we intended to have the ROHC_INTEG algorithm as the only > negotiated parameter. All other parameters are one-way > negotiations. Please let us know if you see any issues with this. Seems OK to me. > > 6) ikev2-extensions, Section 2.1.2, says "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)." I don't > > think this is sufficient to get interoperable implementations; more > > details are needed. > > Could you clarify why this is not sufficient? If it's computed using exactly the same method as the IPsec Integrity Algorithm Key, it would be the *same* key, and that's certainly not the intent here. Perhaps something like "The keys (one for each direction) for this Integrity Algorithm are derived from the IKEv2 KEYMAT (see [IKEV2], Section 2.17). For the purposes of this key derivation, ROHC is considered to be an IPsec protocol."? Best regards, Pasi _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf