[Ipsec] Two IKEv2 issues from the IESG

[Russ Housley <housley@vigilsec.com>]

Here are two issues from the IESG regarding IKEv2.  I hope that these can 
be quickly resolved by the IPsec Working Group.  Charlie has already agreed 
to quickly update the document to reflect the Working Group decision, once 
consensus is clear.


MINIMUM PACKET SIZE

Margaret Wasserman asked that the specification state the minimum packet 
that must be supported.  The response to her request included several 
changes that reduce the livelihood of exceeding a minimum, but falls short 
of actually specifying a minimum.

There is a fundamental problem when one side does not know the maximum size 
for a packet that can be sent to a peer.  If the specification does not 
provide guidance, then an implementation must assume the worst case, which 
is 576 bytes for IPv4, including headers.  If a larger packet is sent, it 
is often unclear what happens.  Will it get silently discarded?  If so, 
this is indistiguishable from other types of failure, like packet 
loss.  Will an error indicate what the maximum packet size?  Almost 
certainly not.  Such support is not presently part of IKEv2, and the IESG 
is not asking for it to be added.  Doing so can be very tricky; the IP 
stack may accept a different maximum packet size than the upper layer 
application.

Arguably, one of the regrettable such defaults is in the DNS were one can 
only assume DNS packets of 512 bytes. We have been paying for that for 
years, and we had to invent EDNS0 to overcome this limitation.

In summary, it really does make sense for IKEv2 to some thing like: 
implementations MUST be prepared to accept IKEv2 packets of size at least 
XXX, where XXX is something reasonably large.  Leaving this unspecified 
will almost certain come back to haunt us down the road, and it is easy to 
fix at this point in time.

I suggest the addition of the following text:

    "All IKEv2 implementations MUST be able to receive and process
    packets that are up to 1280 bytes long, and they SHOULD be able
    to receive and process packets that are up to 3000 bytes long."

The numbers in this suggestion come from Tero.  I support them.  The 
rationale is simple.

The minimum IPv6 MTU is 1280, thus every implementation that supports IPv6 
must already support the MUST packet size.  This does not impose any new 
requirements on IPv6 hosts.  Further, Tero provides a bit of IKEv2-specific 
analysis.

The typical IPv4 packet carrying an IKEv2 message will be:

    - 20 bytes of IPv4 header
    - 8 bytes of UDP header
    - 28 bytes of generic header
    - 4 + 16 + 12 bytes of encrypted payload overhead
    - 8 bytes of ID overhead + ID length of say 21 (kivinen-laptop.iki.fi)
    - 28 bytes of SHA-1 AUTH payload
    - 4 + 8 + 4 bytes of SA payload overhead plus 8 bytes per
       transform ID + 4 bytes for key length of AES, typically we
       have 2 transforms, one having the key length = 36 bytes
    - 2 * 24 bytes of traffic selectors

This totals to 229 bytes, allowing 1051 bytes for a certificate, which is 
plenty for a certificate carrying a 1024-bit public key, even with a fair 
number of certificate extensions.  A certificate carrying a 2048-bit public 
key with a modest number of certificate extensions can also be accommodated.

A 3000 byte packet is enough for any normal certificate 
use.  It  accommodates two certificates, each  carrying a 2048-bit public 
key with a modest number of certificate extensions


ELLIPTIC CURVES

I am raising the second issue.  In 2002, the working group decided not to 
pursue elliptic curves.  Hilarie made several presentation advocating them; 
her slides are in the minutes.  However, the IPR concerns associate with 
elliptic curves lead the working group to classic Diffie-Hellman.  Yet, two 
elliptic curve groups are still included in the document.  This seems to 
contradict the working group decision.

I am not suggesting any protocol changes.  Therefore, the specification of 
elliptic curves in the future is still viable.  In fact, I would like to 
see that happen in the future.  However, the inclusion of elliptic curves 
in Appendix B at this time concerns me from a process perspective.  I will 
gladly entertain suggestions for a follow-on document in this area once the 
base IKEv2 document is finished.

I suggest the removal of the elliptic curve groups from Appendix B.


I hope that these two issues can be quickly resolved.

Russ


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec