Hi Valery,
Thanks a lot for quickly addressing my comments. Your proposed
resolutions sound good to me.
Cheers
Suresh
On 03/13/2014 02:03 AM, Valery Smyslov wrote:
Hi Suresh,
thank you for the review. Please find my answers below.
----- Original Message -----
*From:* Suresh Krishnan <mailto:[email protected]>
*To:* [email protected]
<mailto:[email protected]> ;
General Area Review Team <mailto:[email protected]>
*Sent:* Thursday, March 13, 2014 4:50 AM
*Subject:* Gen-ART Last Call review of
draft-ietf-ipsecme-ikev2-fragmentation-05
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.
Right.
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.
Duplicated fragments are discarded without verification. It is described
in Section 2.6, second bullet:
o Check, that this IKE Fragment Message is new for the receiver and
not a replay. If IKE Fragment message with the same Message ID,
same Fragment Number and same Total Fragments fields was already
received and successfully processed, this message is considered a
replay and MUST be silently discarded.
Note, that this check takes place before verifying fragment authenticity
(next bullet).
If you think this text is unclear, could you please suggest how to
improve it?
* 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.
Thank you, I'll use it.
* Editorial
Appendix A:
s/forgeg/forged/
s/ reassempling/reassembly/
Thanks,
Valery.
Thanks
Suresh
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
