[Int-dir] int-dir review of draft-ietf-ipsecme-ikev2-fragmentation

[Ole Troan <[e-mail]>]

chairs, authors,

Brian asked me as part of the int-directorate to review this document.


Joe Touch had some good comments on this from the transport perspective.
(http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html)

Architecturally this opens up a larger debate. Any UDP application protocol that depends on IP fragmentation and doesn't do segmentation itself must be changed... if the premise is correct that IP fragmentation cannot work correctly.

there are a few approaches open to us:
- consider this a bug in the network, and require that to be fixed
- start work on a replacement of UDP that supports segmentation, SCTP?
- fix the applications.

I think this document solves a real problem. as a general recommendation I think the document should not re-specify Path MTU discovery. it should use RFC1981 and make application specific considerations referencing RFC4821 (section 9, section 10.4)

I would recommend against recursive fragmentation.

I would also question the need to do path MTU discovery for a protocol that only does a few message exchanges? at least the document should clearly point out that there are three options for implementations of this:

- implementations that do not do PMTUD and does use the minimum message sizes (576/1280)
- implementations that depend on PMTUD (1191/1981) with a fallback to minimum
- implementations that use PMTUD/PLMTUD (1191/1981/4821) with application probes 

comments (marked @@)
----------------------------------


1. Introduction:
@@ it would be good if the document made it clear that for IPv4 these NAT devices are broken (ref RFCXXX), and that for IPv6 throwing away fragments is an operational choice, and it is as far as I know no evidence that this happens on the open Internet. (it certainly happens on network borders, e.g. in front of services, where the operator has control and is confident no services using fragmentation exists).

  The problem is that some network devices,
  specifically some NAT boxes, don't allow IP fragments to pass
  through.  This apparently blocks IKE communication and, therefore,
  prevents peers from establishing IPsec SA.  This problem is valid for
  both IPv4 and IPv6 [FRAGDROP].

@@ the document would benefit from a few more definite articles. (and language review in general). nothing that reduces understandability though.

  e.g. "Initiator may first try to send
  unfragmented message and resend it fragmented only if it didn't
  receive response after several retransmissions, or it may always send
  messages fragmented (but see Section 3), or it may fragment only
  large messages and messages causing large responses."

2.4 Using IKE fragmentation

@@ this seems a little at odds with a section full of 2119 language.
   "In general the following guidelines are applicable for Initiator:"
   "In general the following guidelines are applicable for Responder:"


@@ vague. replace with recommendation to base the decision on the link and path MTU?

  o  Initiator MAY fragment outgoing message if it has some knowledge
     (possibly from lower layer or from configuration) that either
     request or response message will be fragmented by IP level or if
     unfragmented message was sent and no response was received after
     several retransmissions.

  o  Responder MAY respond to unfragmented message with fragmented
     response if it has some knowledge (possibly from lower layer or
     from configuration) that response message will be fragmented by IP
     level.

@@ this section is does not define "fragmentation threshold"

2.5.  Fragmenting Message

@@ could "fragment number" and "total fragments" be single octets?

2.5.1

@@ I'm not sure text like... adds value.

  "Sender MAY use other values if they are
  appropriate."

2.5.2

@@ I hope "refragment" doesn't mean that the individual fragments are fragmented again? but rather that the original message is fragmented into a set of smaller fragments?

  "While doing probes, node MUST start from
  larger values and refragment message with next smaller value if it
  doesn't receive response in a reasonable time after several
  retransmissions. "

@@ please give better advice. "reasonable time" is hard to implement.
  "doesn't receive response in a reasonable time after"

@@ should also reference RFC1981

@@ oh, so it is recursive fragmentation. that makes me somewhat uncomfortable.

  "In case of PMTU discovery Total Fragments field is used to
  distinguish between different sets of fragments, i.e. the sets that
  were obtained by fragmenting original message using different
  fragmentation thresholds.  As sender will start from larger fragments
  and then make them smaller, the value in Total Fragments field will
  increase with each new try.  When selecting next smaller value of
  fragmentation threshold, sender MUST ensure that the value in Total
  Fragments field is really increased.  This requirement should not
  become a problem for the sender, as PMTU discovery in IKE is supposed
  to be coarse-grained, so difference between previous and next
  fragmentation thresholds will be significant anyway.  The necessity
  to distinguish between the sets is vital for receiver as receiving
  any valid fragment from newer set will mean that it have to start
  reassembling over and not to mix fragments from different sets."


section 2.6

@@ section 2.5 states that the EFP MUST be the last payload message, but section 2.6 specifies that it may not be the first. inconsistency?

  The Encrypted Fragment Payload, similarly to the Encrypted Payload,
  if present in a message, MUST be the last payload in the message.

 Note, that it is possible for this payload to be not the first (and the only) payload in the message (see
  Section 2.5.3). 

@@ please recommend a default timeout interval.
  If receiver doesn't get all IKE Fragment Messages needed to
  reassemble original Message for some Exchange within a timeout
  interval, it acts according with Section 2.1 of [RFC5996], i.e.
  retransmits the fragmented request Message (in case of Initiator) or
  deems Exchange to have failed.