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:
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.
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/
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
