Emre Ertekin wrote:[mailto:emreertekin(_dot_)ietf(_at_)gmail(_dot_)com]
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf