Skip to main content

Last Call Review of draft-ietf-ipsecme-ikev2-fragmentation-05
review-ietf-ipsecme-ikev2-fragmentation-05-genart-lc-krishnan-2014-05-08-00

Request Review of draft-ietf-ipsecme-ikev2-fragmentation
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-04-22
Requested 2014-02-27
Authors Valery Smyslov
I-D last updated 2014-05-08
Completed reviews Genart Last Call review of -05 by Suresh Krishnan (diff)
Secdir Last Call review of -05 by Derek Atkins (diff)
Assignment Reviewer Suresh Krishnan
State Completed
Request Last Call review on draft-ietf-ipsecme-ikev2-fragmentation by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 10)
Result Almost ready
Completed 2014-05-08
review-ietf-ipsecme-ikev2-fragmentation-05-genart-lc-krishnan-2014-05-08-00

I am the assigned Gen-ART reviewer for draft-ietf-ipsecme-ikev2-fragmentation-05



For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.



Please resolve these comments along with any other Last Call comments you may
receive.



Summary: This draft is almost ready for publication as a Proposed Standard but
I have some suggestions that the authors may like to consider.



* Retransmission and duplication



It is unclear how the receiver of the message deals with lost fragments that
are retransmitted. If I understand correctly, the sender only knows that all
the fragments did not get to the receiver, and has no knowledge about which
fragments
 were not received. So it ends up retransmitting all the fragments. This means
 that the receiver needs to do some form of de-duplication. Are the duplicate
 fragments discarded on the receiver (without verification) or are they blindly
 written into a reassembly buffer (after verification)? The difference is
 pretty significant because there is a authentication step involved for each
 fragment.



* IPv6 payload length



I find this text to be a bit handwavy



“   For IPv6 this estimation is difficult as there may be varying IPv6

   Extension headers included.”



I think it would be preferable to at least estimate for the case where there
are no extension headers. Suggest adding some text like this (Feel free to
modify/ignore)



NEW:



   For IPv6 Encrypted Payload content size is less than IP Datagram size

   by the sum of the following values in the case where there are no

   extension :



   o  IPv6 header size (40 bytes)



   o  UDP header size (8 bytes)



   o  non-ESP marker size (4 bytes if present)



   o  IKE Header size (28 bytes)



   o  Encrypted Payload header size (4 bytes)



   o  IV size (varying)



   o  padding and its size (at least 1 byte)



   o  ICV size (varying)



   The sum may be estimated as 81..85 bytes + IV + ICV + padding.



   If extension headers are present, the payload content size is further

   reduced by the sum of the size of the extension headers. The length of

   each extension header can be calculated as 8 * (Hdr Ext Len) bytes

   except for the fragment header which is always 8 bytes in length.



* Editorial



Appendix A:

s/forgeg/forged/

s/ reassempling/reassembly/



Thanks

Suresh