Suresh: Thank you very much for the review, and Valery for making the changes. I have placed the no-objection position for this document in tomorrow's IESG telechat.
Jari On Mar 13, 2014, at 7:48 PM, Suresh Krishnan <[email protected]> wrote: > 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
