Subject: [Ipsec] Two IKEv2 issues from the IESG

From: Russ Housley <[email-masked]>
Date: Thu, 02 Sep 2004 09:53:55 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Sep 2004 11:02:48 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Russ" == Russ Housley <[email-masked]> writes:
    Russ> I suggest the addition of the following text:

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

  (Sorry to be pedantic here, but I think it is important)

  I think that the word "packet" is wrong here.

  I think that you mean "datagram" -- seeing as a 3000 byte datagram would
exceed common MTU, it must have been fragmented into multiple frames to
have been received.

  The above (corrected) statement also implies to me that an IKEv2 and
host must be prepared to re-assemble at least 3000 bytes bytes worth of
fragment.
  
    Russ> I am not suggesting any protocol changes.  Therefore, the
    Russ> specification of elliptic curves in the future is still
    Russ> viable.  In fact, I would like to see that happen in the
    Russ> future.  However, the inclusion of elliptic curves in Appendix
    Russ> B at this time concerns me from a process perspective.  I will
    Russ> gladly entertain suggestions for a follow-on document in this
    Russ> area once the base IKEv2 document is finished.

  I think that the answer is that... "They were in IKEv1."

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

  I don't object.

- --
]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 2 Sep 2004 09:19:39 -0700

>    to receive and process packets that are up to 3000 bytes long."

Yes. It gives implementers a hard number to work with, and a 
reasonable suggested number so that lazy implementers don't say "all 
we should do is 1280".

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

Yes. They shouldn't be there if we don't intend to support them well, 
and at this point that support is not there.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Thu, 02 Sep 2004 12:36:35 -0400

>host must be prepared to re-assemble at least 3000 bytes bytes worth of

I see your point.  If we take this approach, then we need to remove the IP 
header and UDP header sizes from the mandatory-to-support size.

Russ

---

From: Paul Koning <[email-masked]>
Date: Thu, 2 Sep 2004 13:10:18 -0400

Russ> Michael: I suggest the addition of the following text:
 Russ> "All IKEv2 implementations MUST be able to receive and process
 Russ> packets that are up to 1280 bytes long, and they SHOULD be able
 Russ> to receive and process packets that are up to 3000 bytes long."
 >> I think that you mean "datagram" -- seeing as a 3000 byte datagram
 >> would exceed common MTU, it must have been fragmented into
 >> multiple frames to have been received.
 >> 
 >> The above (corrected) statement also implies to me that an IKEv2
 >> and host must be prepared to re-assemble at least 3000 bytes bytes
 >> worth of fragment.

 Russ> I see your point.  If we take this approach, then we need to
 Russ> remove the IP header and UDP header sizes from the
 Russ> mandatory-to-support size.

If we weren't so afraid of internationalbureaucratspeak, we could just
say "APDUs" which would be clear and unambiguous.

    paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Sep 2004 11:29:31 +0300

> host must be prepared to re-assemble at least 3000 bytes bytes worth of

Yes. That was my intention, meaning that all implementations of IKEv2
SHOULD also supoprt IP fragmentation in their end. There might be
nodes between which make it impossible to use fragmentation (firewalls
/ NATs etc), but I think we should require that our own end is working
in this case. I have seen IKEv1 implementation which implemented their
own IP / UDP code which didn't include any reassembly at all. I do not
want to that happen in the IKEv2. 

>     Russ> I suggest the removal of the elliptic curve groups from

Same here. It really does not matter if they are there or not. If they
are there, then it might be easier for people to define more of them
later, as the document also describes what to put in the KE payload,
so if we remove the groups, do we also remove this text from
draft-ietf-ipsec-ikev2-15.txt:
----------------------------------------------------------------------
   The data in the KE payload when using this group is the value x from
   the solution (x,y), the point on the curve chosen by taking the
   randomly chosen secret Ka and computing Ka*P, where * is the
   repetition of the group addition and double operations, P is the
   curve point with x coordinate equal to generator 1 and the y
   coordinate determined from the defining equation. The equation of
   curve is implicitly known by the Group Type and the A and B
   coefficients. There are two possible values for the y coordinate;
   either one can be used successfully (the two parties need not agree
   on the selection).
-- 
[email-masked]

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 10 Sep 2004 11:37:04 -0400

> contradict the working group decision.

No one has objected to this change.  So Charlie, please remove
elliptic curve groups from Appendix B.

>    to receive and process packets that are up to 3000 bytes long."

There have been a few people who have suggested that they would prefer
a simple 3000 byte MUST requirement instead.  However, these people
seem to have been in the minority, and given that 1280 bytes is enough
for a 1024 bit certificate, and 2048 with modest certificate
extensions, it seems that 1280 byte requirement is sufficient for many
applications.  In addition, it is likely that most implementations
will implemement SHOULD requirements.

Do any of those people advocating the 3000 byte MUST object strenously
to the above text requiring a 1280 MUST, and a 3000 byte SHOULD?

						- Ted

---

From: suren <[email-masked]>
Date: 10 Sep 2004 15:44:04 -0700

Since, IKE over TCP is not defined, I go with making 3K bytes MUST for
IKE over UDP.

Suren
Intoto Inc.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Sep 2004 10:01:00 -0400

>     to receive and process packets that are up to 3000 bytes long."

I don't see how the SHOULD is useful. The problem is that a sender has
no way of knowing whether the other end supports the larger packet
size. So, for interoperability, it can't try a size that large. If it
does, it may well send packets into a black hole. This is a generic
issue that has come up in many other protocols. It would be nice to
send larger packets, but it turns out that there exist compliant
implementations that don't support them, so one can't count on such
packets being supported.

Note, the key issue is what is the receiver mandated to be capable of
accepting? 

Or, is there a way for IKE to respond to such packets with an error
effectively saying "packet too big"? If so, then one could try a large
packet, and negotiate a smaller value. That also works.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Sep 2004 11:10:52 -0400

>   (Sorry to be pedantic here, but I think it is important)

This is an important point.

> exceed common MTU, it must have been fragmented into multiple frames to

Actually, even "datagram" is ambiguous. I think you want something
more like:

   ... be able to receive and process IKE payloads that are up to 3000
   bytes long.

(or is "IKE Payload" defined as something else ... what I'm after is
essentially "the user  data part of the UDP datagram")

I.e., what you want is clarity that IKE is able to send 3000 bytes of
user data, independent of the underlying IP headers, and know that it
will be accepted/processed by the receiver.

Thomas