Looks good. One small correction:

many IKEv2 have not implemented => many IKEv2 implementations do not include

Thanks,
        Yaron

On 11/16/2015 06:05 PM, Daniel Migault wrote:
Hi,

Thank you Yaron for your comments. Please find the new update ot the draft:

https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002

Comment 1:
IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this documentmust not be considered for IKEv1.

I change MUST NOT in must not. I left the whole sentence as I beleive,
it provides the reason why IKEv1 is not in scope and state clearly that
applying considerations in this document to IKEv1 is a bad idea.

Comment 2:
I added some clarifying text on why not MUST. To me the obvious reason
is that an algorithm not mentioned in RFC4307 should not have a status
greater than SHOULD -- unless otherwise of course ;-). I though we had
this explanation somewhere, but maybe it is missing and should be added
in the intro for example.

I also provided dome explanation why ESP and IKEv2 are in a different
race which resulted in having AES-GCM not widely deployed for IKEv2

Comment 3:
"As it is not being deployed" as been replaced by "as it is not widely
deployed"

"and now it is known to be weak at least for a nation state" has been
changed to "and now it is known to be weak against a nation-state attacker".

Acknowledgement section has also been updated.

BR,
Daniel


On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <[email protected]
<mailto:[email protected]>> wrote:

    Yaron Sheffer writes:
    > The rationale for GCM describes why it's in the table, but seems to
    > argue for a MUST (rather than the SHOULD that's in the table). I guess
    > there's a reason why we don't have MUST, let's spell it out.

    The reason for that is that it is not needed as IKEv2 SA is never used
    to transmit huge amounts of data, thus the speed benefits you might
    get from there is not needed. Also support for the combined modes do
    require support for RFC5282, and there are implementations which have
    not done that (as there is no benefits or need for them to implement
    it).
    --
    [email protected] <mailto:[email protected]>

    _______________________________________________
    IPsec mailing list
    [email protected] <mailto:[email protected]>
    https://www.ietf.org/mailman/listinfo/ipsec



_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to