Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ipsecme-ikev2-fragmentation-05

[Jari Arkko <[e-mail]>]

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 <[e-mail]> 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:[e-mail]>
>>    *To:* [e-mail]
>>    <mailto:[e-mail]> ;
>>    General Area Review Team <mailto:[e-mail]>
>>    *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art