Subject: [Ipsec] Fwd: Re: Two IKEv2 issues from the IESG

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

Since Thomas is not a member of the IPsec WG mail list, this message will 
probably sit in the spam queue indefinitely.  I think the WG should see it 
now.  So, I am forwarding it.

Russ

>To: Russ Housley <[email-masked]>
>cc: [email-masked], [email-masked]
>Subject: Re: Two IKEv2 issues from the IESG
>Date: Thu, 02 Sep 2004 10:01:00 -0400
>From: Thomas Narten <[email-masked]>
>
>Russ Housley <[email-masked]> writes:
>
> > 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."
>
>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

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 02 Sep 2004 21:45:35 +0300

I don't think IKE can respond.  I wouldn't have a problem with a MUST 
requirement to support 3000 bytes, but the fact that the peers are 
able to re-assemble them does not make it a good idea to send them.  
NAT devices, firewalls and routers on the way may drop fragmented UDP 
packets.

I guess this ties into the other thread here about big IKE packets.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Sep 2004 13:06:26 +0300

>implementations that don't support them, so one can't count on such

That would be the true if we would be talking about protocol talked
between any random host in the internet and another random host in the
internet.

With IPsec that is not normally the case. You need to have some kind
of trust relationship between the hosts to get IKEv2 working, i.e. you
need common CA, or shared secrets exchange priori etc. In most of the
cases you also need to agree about the policy to be used and so on.

This means that agreeing in the maximum datagram size using those same
out of band methods is possible. The 3000 bytes is more like to be
meant as an instruction to the the implementators, use this in your
implementation. If we leave it out all implementations will only
support 1280 or 1500 bytes, and then there are some implementations
which use 64k...

If the adminstrator is going to be putting up a road-warrior VPN
system for the company, and they enroll their own CA with 2048 bit
keys, and 2 level hierarchy, which would mean that it does not fit to
the 1280 byte packets, then can always say that we only support those
implementations which supports this 3000 bytes packets. In normal case
they will only support one implementation for the client end and one
implementation (or same implementation) for the SGW end, so this is
not really a problem. They simply need to select the implementations
so that it supports that feature (and configure them so).

On the other hand if you have something like garage door opener
device, which only supports minimal 1280 byte packets, and you have
your own 2048 bit CA in your house, you can still create smaller
certificate (1024 bits or 2048 bits without too much extensions) to
the door opening mechanisms so that that the door opener and opening
mechanism can create IKEv2 connection using packets which are smaller
than 1280 bytes (or you can simply use http transport for the
certificates). As you need to configure both ends (at least generate /
load the certificates for the private keys) anyways and add some kind
of trust relationship there, this shouldn't be a problem.

If you are really doing the random host to random host connections,
then you must limit yourself to 1280 bytes, and use http transfer for
certificates if the certificates doesn't fit otherwise, but as I said,
that random host to random host connections are not that common use
for the IPsec (at least now). The 1280 bytes is enough for basic
operations in that case too, so there is no problem there.

>packet, and negotiate a smaller value. That also works.

Not really, but adding such would be very easy. The IKE_SA_INIT are
almost always smaller than 1280 bytes:

20 + 8 + 28 + 4 + 8 + 4 + 8 * transforms + 8 + group_size + 4 +
nonce_size = 84 + 8 * transforms + group size (max 1024) + nonce size
(max 256) + 68 bytes of cookie.

The max SA payload size with all algorithms and all key sizes is about
300 bytes. This gives the max IKE_SA_INIT packet size for 4096 bit
Diffie-Hellman group 1220 bytes, which means that we can always send
and receive that.

Even 8192-bit Diffie-Hellman KE packet, with one crypto suite SA
proposal, and 64 bytes of nonce and 64 bytes of cookie, can fit to the
1280 bytes.

And as IKE_SA_INIT must be sent before the IKE_AUTH exchange (which
includes the certificates) can start, we can later add notification to
IKE_SA_INIT giving out the max size of packet we can receive. All
current implementations will simply ignore the notification, and if
implementation does not get such notification, and is not configured
to allow more than 1280 bytes, it should keep the packet sizes less
than 1280 bytes. So there is way to be able to configure bigger packet
size if such need is later needed.
-- 
[email-masked]

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Fri, 3 Sep 2004 10:56:00 -0700

It is good thing to explicit indicate the MUST and SHOULD length of
IKE messages to avoid interoperability problems.  I also would like 
having 3000 (or even 8K) as a MUST requirement, when certifiates
are used. For PSK only implementations, 1280 seems like a good limit value.

There are arguments in the community that
    - Some UDP/IP implementations do not support fragmentation and reassembly
    - Some routers/firewalls/NATs discard the fragments.
    - DoS attacks targeting reassembly process on the end hosts.

I feel that we should not worry about first two cases and I think they are in minority
and they need to be fixed and would be fixed due to market requirement.

We need to see, the type of reassembly DoS attacks that are possible. In my view, most of the systems
are already hardened.  There is one arugment that, ID (Identification) value in IP header can be 
guessed by blind attacker and can corrupt the datagram by sending fake IP packet
with guessed ID.  But, firewalls or even hardended systems sufficiently randomize this value
to protect against blind injection attacks. 

     - Keep the UDP transport as MUST for IKE (as it is today)
     - IKE implementations supporting PSK MUST be able to send/ receive 1280 byte messages.
     - IKE implementation supporting Certificates MUST be able to send/receive 3000 byte messages.
     - IKE implementation supporting  chain of certificates (upto 4) MUST be able to send/receive 8000 
             byte messages.

For the cases, where above values are not sufficient can make use of alternate mechanisms such as
TCP transport  Or HASH/URL mechanism or others. These can be 'MAY' options.

Srini

Intoto Inc.
www.intoto.com

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 6 Sep 2004 11:38:12 +0300

Thomas Narten writes:
> Um, aren't IKE and IPsec for communication between random hosts? True,
> most deployment to date has been VPNs. But are we resigning ourselves
> to that scenario forever? I hope not.

I do not think we are planning only for VPNs. We should have options
also for other uses too. 

> I agree with this, but do not agree that this implies that whoever is
> in charge of setting up the trust relationships is in a position to
> know (or ensure) that all the possible IKE participants will accept
> adequately large payloads beyound those _required_ (in the MUST sense)
> by the spec.

Then they assume 1280, and that is fine also. 

> Note: my real concern is that SHOULD is not strong enough. If it is
> not a MUST requirement that 3000 bytes (or whatever the right minimum
> lower bound is) be supported, we will eventually, once there is
> widespread deployment of IKE, run into a deployed base where some
> implementations only support the required minimum. At that point,
> implementations will (for interoperability) have to assume that the
> 3000 byte SHOULD is not universally implemented, and use the real
> lower bound (e.g., 1280).

For those people who will implement the stuff over operating system
UDP stack, adding support for 3000 byte packets will be 3-bit change
in their source code (i.e. change unsigned char udp_read_buffer[1280]
to unsigned char udp_read_buffer[3000] :-). This means that if we have
that bigger number as SHOULD all those implementors will simply use
the 3000 bytes, and forget the who thing. If we do not have any SHOULD
number in the RFC, they will start thinking (bad thing you know), and
they end up having random number between 1280 and 64k, with
distribution where you have about 40% using 1280, and 20% using 64k,
and rest of the 40% use values 1500/2048/3000/4096/8192.

Effectively the SHOULD will most likely limit implementations so that
almost none does more than 3000 bytes...

> If the WG feels that 1280 is really an adequate number to assume in
> the general case, I'm fine with that.

Good.

> My point is that the SHOULD recommendation is probably less useful
> than might seem.

I think the SHOULD do have good reasons to be there, as it will be
hard number for implementors. And we can benefit from that number when
we defined the extension telling that number to the other end.

> If this will eventually be needed, now is the time to do it, before
> there is a deployed base. It is the deployed base (which won't
> implement this) that will be the problem in the future (if it becomes
> a problem).

The extension would be quite easy. I think we do not want to add it to
the IKEv2 spec at this point, but create separate extension about
this. On the other hand if you feel that we should do it now to
resolve the max UDP packet size problems, then we can still do it if
IESG and area directors approve the change.

The text could be something like:
----------------------------------------------------------------------
...
        NOTIFY MESSAGES - STATUS TYPES           Value
        ------------------------------           -----
...
        MAX_UDP_IKE_PACKET                       XXXXX

            This notification asserts that the sending endpoint is
            capable of receiving UDP packets up to given size. The
            data associated with a MAX_UDP_IKE_PACKET notification
            MUST be 4 octets long and contain the big endian
            representation of the max UDP IKE packet size (i.e. size
            without IP or UDP headers) the sender promises to be able
            to receive. This notification SHOULD be sent inside the
            IKE_SA_INIT exchange so the initiator can use the bigger
            packet size when sending the IKE_AUTH exchange containing
            certificates. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Sep 2004 13:15:17 -0400

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

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:
    Tero> With IPsec that is not normally the case. You need to have
    Tero> some kind of trust relationship between the hosts to get IKEv2
    Tero> working, i.e. you need common CA, or shared secrets exchange
    Tero> priori etc. In most of the cases you also need to agree about
    Tero> the policy to be used and so on.

  Warning: VPN centric view!

  Multiple people do take the view that there are situations where 
the end points are not part of the same enterprise.
  Not just Opportunistic Encryption, but other views as well.

    Tero> If the adminstrator is going to be putting up a road-warrior
    Tero> VPN system for the company, and they enroll their own CA with
    Tero> 2048 bit keys, and 2 level hierarchy, which would mean that it
    Tero> does not fit to the 1280 byte packets, then can always say
    Tero> that we only support those implementations which supports this
    Tero> 3000 bytes packets. In normal case they will only support one
    Tero> implementation for the client end and one implementation (or
    Tero> same implementation) for the SGW end, so this is not really a
    Tero> problem. They simply need to select the implementations so
    Tero> that it supports that feature (and configure them so).

  I agree with you that this is something which can be locally
provisioned for the VPN scenario.
  I do not think that this is something that I want customers to have to
worry about.

- --
]     "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: Thomas Narten <[email-masked]>
Date: Fri, 03 Sep 2004 11:29:42 -0400

Thomas