Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-01.txt

From: [email-masked]
Date: Fri, 23 Aug 2013 05:59:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : IKEv2 Fragmentation
	Author(s)       : Valery Smyslov
	Filename        : draft-ietf-ipsecme-ikev2-fragmentation-01.txt
	Pages           : 19
	Date            : 2013-08-23

Abstract:
   This document describes the way to avoid IP fragmentation of large
   IKEv2 messages.  This allows IKEv2 messages to traverse network
   devices that don't allow IP fragments to pass through.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 23 Aug 2013 17:35:50 +0400

Hi all,

I've just posted new version of IKEv2 Fragmentation draft.
Comments and reviews are appreciated.

Differences ftom -00 version:
1. As Yaron suggested Transport Considerations section is added and
    cryptographic processing of Encrypted Fragment Payload is clarified.
2. Based on comments from WG members Design Rationale Appendix is added.
3. Some sections are rewritten to improve (I hope) document clarity.

I am still not convinced to include additional field to 
IKE_FRAGMENTATION_SUPPORTED
notification, indicating peer's impression of PMTU, as Yaron suggested.

The reason is that some people consider IKE Fragmentation to be complex.
In this situation I see my goal not to do it more complex. Currently
ability to do PMTU discovery in the protocol is completely optional, all key 
words
that are concerned with this feature are "MAY". I suspect, that most 
implementations
won't do it and will just use fixed recommended values for fragments size.
Adding these fields is just an optimization and it will work only
for that minority of implementations, that will do PMTU discovery.
And even for them in most use cases it won't help much.
So, my opinion - it is not justified. And I still haven't see any
supporting comment from the WG. Yaron?

Probably we should get rid of (even completely optional) PMTU discovery at 
all,
if it encouraged people to implement the protocol.

Regards,
Valery Smyslov.

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

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 23 Aug 2013 16:59:18 +0300

Hi Valery,

Thank you for submitting the new version.

I am fine if you choose not to include the fragment size hint in the 
notification, unless there are opposing views on the list.

Regarding the new Transport Considerations section: please add a 
sentence that mentions that there is only an ack for the last fragment 
of each message, so that people who are not IKE experts can understand.

Also, we should say somewhere (maybe in this section) that each receiver 
must establish a timeout for the reassembly buffer, and silently discard 
any collected fragments if the whole message could not be reassembled by 
that time.

Thanks,
	Yaron

On 2013-08-23 16:35, Valery Smyslov wrote:
> ability to do PMTU discovery in the protocol is completely optional, all
> key words
> Probably we should get rid of (even completely optional) PMTU discovery
> at all,

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 23 Aug 2013 18:04:37 +0400

> Hi Valery,

Hi Yaron,

> Regarding the new Transport Considerations section: please add a sentence 
> that mentions that there is only an ack for the last fragment of each 
> message, so that people who are not IKE experts can understand.

OK.

> any collected fragments if the whole message could not be reassembled by 

OK.

Regards,
Valery.