Subject: [IPsec] Beginning of WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Oct 2013 18:49:43 -0700

Greetings again. The WG's draft on IKEv2 fragmentation has gotten a fair amount of review in the past few months, and is thus ready for a two-week WG Last Call (ending November 1). The draft is at:

http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation

Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point.

If you have an IKEv2 implementation, or are using someone else's IKEv2 implementation in your products, you really should be reviewing and commenting on this draft. This will have a significant impact on IKEv2 implementations in the future, and having anything wrong or even unclear in the draft will make everyone's life worse. Please do a review and send any comments to the list.

--Paul Hoffman
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Oct 2013 07:53:26 -0700

Although there is a spirited, useful discussion going on between three or four participants, we could certainly use more reviewers for this WG document. Please send any comments to the list, and feel free to hop into the threads already running. Thanks!

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Oct 2013 20:05:48 +0000

Hi

I think the draft is in good shape and is almost ready for publication. There is a bunch of grammatical issues with it, but I think the RFC editor is much better at fixing those than most of us.

Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference between those two RFCs is not some technical difference between IPv6 and IPv4, but that the former was written in 1998 while the latter is from 1989. By 1998 it was reasonable to mandate infrastructure that could handle 1280-byte datagrams. This has become more true, not less in the 15 years since RFC 2460. Pretty much all networks today can carry IPv6, and any network that can carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. I don't think there's any point in still making this distinction today.

Lastly, some nits:

Section 2.1: 
OLD:
  The idea of the protocol is to split large IKE message into the set
  of smaller ones, calling IKE Fragment Messages.
NEW:
  The idea of the protocol is to split large IKE message into a set
  of smaller ones, called IKE Fragment Messages.

Section 2.5:
OLD:
  o  Total Fragments (2 octets) - number of fragments original message
     was divided into.  With PMTU discovery this field plays additional
     role.  See Section 2.5.2 for details.  This field MUST NOT be
     zero.
NEW:
  o  Total Fragments (2 octets) - number of fragments original message
     was divided into.  With PMTU discovery this field plays additional
     role.  See Section 2.5.2 for details.  This field MUST NOT be
     zero or one.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 25 Oct 2013 23:23:35 +0300

> Hi
[...]

>
> Section 2.5.1 recommends using 1280-byte max IP datagram size for
> IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big
> difference between those two RFCs is not some technical difference
> between IPv6 and IPv4, but that the former was written in 1998 while
> the latter is from 1989. By 1998 it was reasonable to mandate
> infrastructure that could handle 1280-byte datagrams. This has become
> more true, not less in the 15 years since RFC 2460. Pretty much all
> networks today can carry IPv6, and any network that can carry
> 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4
> packets. I don't think there's any point in still making this
> distinction today.
>
>
This draft is about broken networks/devices that are unable to handle 
IPv4 fragments. Can we really assume that they can carry IPv6 traffic?

Yes, RFC 1122 is very old, but if we recommend a larger size I would 
like to see better justification.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Oct 2013 20:51:32 +0000

On Oct 25, 2013, at 11:23 PM, Yaron Sheffer <[email-masked]> wrote:

> This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic?
> 
> Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification.

The original IKEv1 fragments were inspired by broken home routers that wouldn't keep enough state to NAT fragments. They still worked on Ethernet and 802.11 and had 1500-byte MTU.

The current work was inspired by CGNs doing the same thing. They also deal with 1500-byte Ethernet.

1280 leaves room for various tunnels, encapsulations and what not. 

Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTUs that small anymore.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 26 Oct 2013 12:14:57 +0300

> Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTU…
If we give a recommendation, I think it should be based on measured 
data. See for example Sec. 5.5 of 
http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf‎

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Sat, 26 Oct 2013 11:25:58 +0000

On Oct 26, 2013, at 12:14 PM, Yaron Sheffer <[email-masked]> wrote:

> If we give a recommendation, I think it should be based on measured data. See for example Sec. 5.5 of http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf‎
> 

Thanks for the link. And only 1 (out of >1150) probes found a PMTU in IPv4 smaller than 1280, and that was 1280. More than 2/3 were exactly 1500, and the vast majority was over 1400.

Smallest they found was 1240. Any reason to set the limit (much) below that?

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sat, 26 Oct 2013 12:52:29 +0000

> Smallest they found was 1240. Any reason to set the limit (much) below that?

s/and that was 1280/and that was 1240/

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 26 Oct 2013 16:17:06 +0300

>>> If we give a recommendation, I think it should be based on
>>> measured data. See for example Sec. 5.5 of
Thanks for the link. And only 1 (out of >1150) probes found a PMTU in 
IPv4 smaller than 1280, and that was 1280. More than 2/3 were exactly 
1500, and the vast majority was over 1400.
> s/and that was 1280/and that was 1240/
If we think this experiment is serious (e.g. that it covers much of the 
Internet, note that 1150 probes is a very small number), then we can 
recommend 1280 and cite this reference. Alternatively, we could ask the 
folks at TSVWG or IPPM.

I am not familiar with current large scale Internet measurement efforts. 
But you an I have one such project nearby: http://www.netdimes.org/new/. 
I will ping them.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 28 Oct 2013 09:03:42 +0400

Hi Yoav,

thank you for your review.

> I think the draft is in good shape and is almost ready for publication.
> There is a bunch of grammatical issues with it, but I think the RFC editor
> is much better at fixing those than most of us.
>
> Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6
> (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference
> between those two RFCs is not some technical difference between IPv6 and 
> IPv4,
> but that the former was written in 1998 while the latter is from 1989. By 
> 1998 it was
> reasonable to mandate infrastructure that could handle 1280-byte 
> datagrams.
> This has become more true, not less in the 15 years since RFC 2460.
> Pretty much all networks today can carry IPv6, and any network that can 
> carry
> 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets.
> I don't think there's any point in still making this distinction today.

I tried to be conservative here.

>  of smaller ones, called IKE Fragment Messages.

Fixed.

>     role.  See Section 2.5.2 for details.  This field MUST NOT be

I disagree. Total Fragments of one is perfectly valid. It makes sense
in situations, when short request could generate large response
(consider request of some parameters via Configuration Payload).
In this case initiator may send fragmented message (even if
there will be the only fragment) to quickly kick off responder to send
fragmented response.

And in general nothing in the draft prohibits some simple implementation
from always sending messages in fragmented form even the short ones.