Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
RFC 7383

Note: This ballot was opened for revision 07 and is now closed.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Benoît Claise) (was Discuss) No Objection

(Spencer Dawkins) (was Discuss) No Objection

Comment (2014-04-23 for -07)
No email
send info
Thank you for discussing my Discuss with me.

I completely missed the description of the double use for Total Fragments in this draft (not only signaling the number of fragments that the sender is sending, but also signaling that the sender has lowered the fragmentation threshold, so the receiver should discard previously received fragments and restart reassembly). 

You're right - the text describes this, but when I went back through the document looking for the description, I still missed it on my second attempt. The description is split between a couple of sections, and appears as part of the step-by-step procedure.

Perhaps this critical point would be easier to spot if you included a high-level description separately before the low-level text.

But I'm clearing my Discuss.

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-06-06 for -09)
No email
send info
Since there is a long history of flakey certificate processing
in the real world I'd suggest that a new security consideration
along these lines be added:

"It can be dangerous to process fragments before the
full set have been received. For example, even if 
a full certificate has been received in some 
fragment(s), receivers cannot safely validate that
certificate until all fragments are received as
that could create a vulnerability if a later (set of)
fragment(s) effectively overwrite the bytes of the
message containing the certificate.
The potential attack would be to send a good
certificate in the first set of fragments, but to
then replace that with a certificate that has
e.g. incorrect naming, in the hope that the first
certificate will pass validation, but that later
(or higher layer) authorization checks use the 
most recently received certificate without 
re-doing validation."




--- OLD COMMENTS BELOW

- I think it might be useful to add to the security
considerations that receivers should not start processing
the content of fragments until the entire reassembly
process is done. Maybe that's there already somewhere but
it wasn't clear to me. The concern is that e.g. a receiver
might extract one certificate from a set of fragments and
do a lot of work verifying that (e.g. OCSP) before the
potential DoS vector is closed off. This is similar to the
discuss point above but slightly differnt.

- 2.6 says: "if reassembling has already started, check
that Total Fragments field is equal to or greater than
Total Fragments field in fragments, that have already
received" What does that mean exactly?

- I agree that an editorial pass is badly needed, and
checking that wouuld need some IKE clue, so it might not
be enough for the RFC editor and author alone to do that.

- Doesn't this update 5996? 2.6.1 says explicitly that it
does, but there's nothing in the meta-data about that. I
guess a 5996 implementation will still work fine against
one that does this because it needs to be negotiated, but
did the WG consider that?

(Brian Haberman) (was Discuss) No Objection

(Joel Jaeggli) No Objection

Comment (2014-04-24 for -07)
No email
send info
coauthor of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02

it's pretty clear to me that cgnat devices are not the sole offender. any stateful device that uses some kind of an ecmp nexthop or which would need to do reassembly in order to apply  policy can get involved.

second allowing for fragment sizes substantially below the internet minimums is something a dos risk, e.g. somebody can dole out data a byte at a time for example  which can tie up reassembly resources to no end. very small initial fragments a a great reason to discard something imho.

Barry Leiba No Objection

Comment (2014-04-23 for -07)
No email
send info
I have no objection to the publication, but I do have a substantive, non-blocking comment that I'd like you to please consider:

-- Section 2.4 --

The pair of bullet lists strikes me as something of a 2119 mess.  I'm not sure that the qualified "MAY"s are really intended to be qualified by the "if" conditions, or whether those conditions are only meant to be explanatory.  I don't understand why there's a protocol-related difference between the first bullet (MAY) and the second (SHOULD).  I think the second sentence of the fourth bullet is unnecessary, as a special case of the first sentence.  I think the "MAY" in the last bullet is somewhat silly -- it's always an option to use unfragmented messages.

So, correct me if I'm wrong, but there is no *protocol requirement* either way here.  Whether one side is fragmenting or not is detectable by the other side, and both sides can handle either type.  You're not, therefore, providing any protocol needs here.  What you're doing is giving advice on when to use IKE fragmentation to avoid IP-layer fragmentation... and when *not* to use IKE fragmentation because it's not necessary and you want to avoid the overhead.  Is that right?

You're probably not going to want to do this (and this is *not* a blocking comment, so I'm not going to fight about it), but I'd like to see these bullet lists re-worked with that in mind, and with the correct meanings of "SHOULD", "SHOULD NOT", and especially "MAY" (entirely optional, one way or the other, with no recommendation either way) in mind, and with explanations of *why* you SHOULD or SHOULD NOT do it.

For what it's worth, if you *are* willing to consider that, I'll be happy to propose specific text as a starting point.

(Ted Lemon) No Objection

(Pete Resnick) (was Discuss) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2014-07-19)
No email
send info
The document has improved and addresses my points.