Subject: [IPsec] IKE fragmentation

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Mar 2013 21:49:14 +0200

Actually I verified the fragmentation support from Finland, and they
said it was requested, but it is not in any product yet, and as Paul
Wouters already commented to list that the problem with some
implementations sending fragmentation regardless whether it was
negotiated or not has already been fixed, I requirement to implement
this quickly has gone...

Anyways, if there is already more implementations doing IKE
framentation, it might be good idea to think whether we should
standardize that. On the other hand I am not sure if they are well
enough documented so that different implementations actually talk each
other...

Anyways we should most likely act fastly if we want to get this fixed
for IKEv2. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 13 Mar 2013 17:22:31 +0400

Hi,

> enough documented so that different implementations actually talk each

We support IKEv1 fragmentation based on documentation found at 
msdn.microsoft.com.
We are able to interoperate with both Microsoft and Cisco.

> Anyways we should most likely act fastly if we want to get this fixed

As for IKEv2, I don't know how Cisco is doing fragmentation in this case
(it seems to have support for it), but if it is done similarly to IKEv1,
than I prefer our own solution - draft-smyslov-ipsecme-ikev2-fragmentation.
The main difference is that in Microsoft/Cisco solution (for IKEv1)
the whole encrypted ISAKMP message is fragmented,
leaving each fragment unauthanticated untill message get reassembled
and its authentity could be verivied. This opens door for
a very simple DoS attack on receiver.

In our proposal each fragment is encrypted and authenticated
individually, that allows receiver to distinguish valid fragments
from bogus, thus preventing from abovementioned DoS attack.

And, of course, we have implemented this solution in our products.

And, of course, we are intersted in doing IKEv2 fragmentation
in standard, interoperable way (based either on our proposal or
smth else).

Regards,
Valery Smyslov.

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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 13 Mar 2013 15:43:35 +0200

Hi Valery,

I believe the DoS argument is incorrect, because the message we are most 
worried about (most likely to get fragmented) is IKE_AUTH, and at this 
point both peers are not yet authenticated, of course. So fragments and 
messages can be encrypted but cannot be authenticated. Thus, an attacker 
can send any number of seemingly valid fragments.

Let me know if I'm missing anything.

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2013 09:51:05 -0400 (EDT)

> a very simple DoS attack on receiver.

How is that a DOS attack? In our implementation of the IKEv1
fragmentation, we limit the number of fragments to 16. We will
only need to do any crypto when we received the IKE packet
marked as "last". Then we do crypto once on the assembled packet
and throw it away when crypto fails.

> from bogus, thus preventing from abovementioned DoS attack.

But I can send lots of small forged fragments and you will do lots
of crypto on them for _each_ forged fragment. I think you will end
up using a lot more cpu and the attacker needs a lot less bandwidth.

I actually do like the IKEv1 version. It's very simple. And uses
the exact same code path apart from a little buffer where we store
some fragments (with sane limits). The only oddness is that
fragmentation ID that serves no purpose, as you cannot really have
two different packets fragmented in flight for a single exchange.
(well you can, but they are going to be identical anyway)

While implementing the IKEv1 version, I did wonder about what should
trigger fragmentation. For instance, if both parties have send and
received the vendorid, and one side sends fragments, should the
other side fully indepedantly wait for failure/retransmit before
using fragments, or take the hint that if the path is broken one
way, it is likely broken in the other way as well? It seems that
being a little aggressive here can really help the IPsec SA to
establish much faster - especially since our own retransmit time
is 20 seconds, which is something we are now consideraing lowering
a lot.

Our implementation also does not handle the first packet of an
exchange to be fragmented, because we have no state to store the
fragments for. In practise this does not matter because the first
packet is never large enough to need fragmentation.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 13 Mar 2013 18:06:45 +0400

Hi Yaron,

> Let me know if I'm missing anything.

I agree that term "authenticated" is a bit misleading here.
The better term would be "integrity protected".
In our proposal receiver can be absolutely sure that
each fragment comes from the very peer he/she exchanged
DH exponents and calculated shared secret with.

All fragments which ICV cannot be verified are discarded
and don't prevent communication with real peer in any way.

Hope this helps.

Regards,
Valery.

>> than I prefer our own solution - 
>> draft-smyslov-ipsecme-ikev2-fragmentation.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 13 Mar 2013 18:31:12 +0400

Hi Paul,

> and throw it away when crypto fails.

If attacker sends you a forged fragment, you cannot determine this
untill you get reassembled the whole message. When you determine
this you have to discard all received fragments (as you don't know
which of them is bogus) and wait for retransmission. For attacker
it is enough to send you forged fragments with rather low rate
to have a good chance to prevent you from communication with your peer.

I think this is kind of DoS attack as Initiator is denied to get desired 
service (IPsec).

> up using a lot more cpu and the attacker needs a lot less bandwidth.

ICV check is (must be) very fast, and you cannot avoid this attack
even without fragmentation - attacker can send you
forged regular messages and you will have to do ICV check
for each of them. I don't think fragmentation makes this worse.

> is 20 seconds, which is something we are now consideraing lowering

I think that responder should start replying with fragments
immediately after it receives first fragmented message from initiator,
but not before this event. It is initiator who is responsible
for retransmissions and it is his/her responsibility to
switch on fragmentation.

> packet is never large enough to need fragmentation.

We do the same.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2013 10:40:28 -0400 (EDT)

> I think this is kind of DoS attack as Initiator is denied to get desired 

But then the attacker has to know the SPI/COOKIES too? So it is an
in-path attack. But I see you point.

> for retransmissions and it is his/her responsibility to

Yes, this case is different for IKEv2.

>> packet is never large enough to need fragmentation.

So does it make sense to say in the document that the first packet
must not be fragmented?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 13 Mar 2013 18:52:00 +0400

> So does it make sense to say in the document that the first packet

If you mean draft-smyslov-ipsecme-ikev2-fragmentation, that limitation must
be already there. If it is not clear enough, I'll make it more explicit.

Or are you talking about the fictional IETF document (not yet written)
describing existing IKEv1 fragmentation? Probably it is better that
the authors of that solution document it.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Mar 2013 10:58:40 -0400 (EDT)

> be already there. If it is not clear enough, I'll make it more explicit.

I have to re-read the draft again, sorry.

> the authors of that solution document it.

I don't think any IKEv1 documents will ever be written again? :)

Paul

---

From: "Derek Atkins" <[email-masked]>
Date: Tue, 12 Mar 2013 16:26:29 -0400

Mocana's implementation appears to only support fragmentation for IKEv1,
not IKEv2.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 Mar 2013 23:39:34 +0000

> I don't think any IKEv1 documents will ever be written again? :)

I think that if we make this a working group document, we should add an Appendix that will be informational and describe what people are doing for IKEv1, including the VendorID and the payload identifier "appropriated" for fragments.

When I implemented this I used the source of Wireshark to figure out how the protocol worked. Pretty poor reverse engineering, but it produced something that interoperates.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 Mar 2013 23:43:11 +0000

On Mar 13, 2013, at 10:06 AM, Valery Smyslov <[email-masked]> wrote:

> Hi Yaron,
> 
>> I believe the DoS argument is incorrect, because the message we are most worried about (most likely to get fragmented) is IKE_AUTH, and at this point both peers are not yet authenticated, of course. So fragments and messages can be encrypted but cannot be authenticated. Thus, an attacker can send any number of seemingly valid fragments.
>> 

So in order to get the responder to spend memory resources on storing the fragment, the initiator needs to expand CPU resources on completing the D-H calculation, and calculating integrity protection on the fragment. Makes sense.

What do you get when you put together the fragments? a decrypted IKE message?  Just the list of payloads?

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Mar 2013 07:33:32 -0400

<chair-hat on>

It is seeming that consensus is trending towards "let's document the fragmentation method some vendors are already doing instead of finishing IKEv2-over-TCP", but I would like to check that. Please respond to the informal poll below.

--Paul Hoffman

- I would prefer the WG to continue working on IKEv2 over TCP

- I would prefer the WG to stop working on IKEv2 over TCP and instead work on standardizing IKEv2 fragmentation

- I would prefer the WG to continue working on IKEv2 over TCP and also work on standardizing IKEv2 fragmentation

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 12:09:44 +0000

> - I would prefer the WG to continue working on IKEv2 over TCP and also work on standardizing IKEv2 fragmentation

In another meeting, I said that standardizing two ways of achieving the same goal is a failure mode. I still believe that. I also believe that fragmentation is easier to fall back on than TCP. IOW an IKE-over-TCP draft would likely become "always use IKE over TCP" in a product (my company's clients that had IKE-over-TCP did exactly that), whereas fragmentation is more likely to become "use fragmentation if the the regular UDP did not get an answer". So:

"I would prefer the WG to stop working on IKEv2 over TCP and instead work on standardizing IKEv2 fragmentation"

However, I would prefer that we clear up the situation with Microsoft's IPR before making such a change to our charter.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Mar 2013 09:20:23 -0400 (EDT)

> "I would prefer the WG to stop working on IKEv2 over TCP and instead work on standardizing IKEv2 fragmentation"

+1

> However, I would prefer that we clear up the situation with Microsoft's IPR before making such a change to our charter.

Less worried about the IPR claim.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Mar 2013 17:38:48 +0400

Hi Yoav.

> So in order to get the responder to spend memory resources on storing the 
> fragment, the initiator needs to expand
> CPU resources on  completing the D-H calculation, and calculating 
> integrity protection on the fragment. Makes sense.

Sorry, did you read the draft?

There is no DH calculating per fragment. DH is calculated once in 
IKE_SA_INIT
as in ordinary IKE SA establishment (note, that unprotected messages, 
including IKE_SA_INIT
and IKE_SA_RESUME cannot be fragmented).

And you spent absolutetly the same amount of CPU power to calculate/verify 
ICV on
fragments as you would spend it on non-fragmented message
(probably a little bit more, as total length of all fragments of one message 
could
be a bit more than the length of original message due to padding, IKE header 
and so on,
but the usual difference is few percents).

Let me emphasize again.
1. In our proposal sender and receiver spend roughly the same amount of CPU 
power
    as they would spend on protecting/verifying non-fragmented message.
2. In our proposal sender and receiver spend roughly the same amount of CPU 
power
    as they would spend on protecting/verifying fragmented message in 
Cisco/MS solution.
3. In our proposal sender needs to encrypt/protect one message twice only 
once
    per SA establishments and only if he/she tries first to send 
unfragmented
    message and after some retransmits decides to resend it fragmented.
    This is avoidable if sender always sends large messages fragmented.
4. Comparing to Cisco/MS solution our proposal allows receiver to
    verify integrity of individual fragment, so forged fragments will not
    consume receiver's memory and could not prevent receiver
    from getting valid fragments.

> message?  Just the list of payloads?

After you decrypt and verify content of Encrypted Fragment Payload of all 
fragments,
get rid of now unnecessary headers and put all together, you get a decrypted 
IKE message.

> Yoav=

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Mar 2013 17:42:10 +0400

> on standardizing IKEv2 fragmentation

I vote for this option.

Valery.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 14:10:40 +0000

On Mar 14, 2013, at 9:38 AM, Valery Smyslov <[email-masked]> wrote:

>> So in order to get the responder to spend memory resources on storing the fragment, the initiator needs to expand
>> CPU resources on  completing the D-H calculation, and calculating integrity protection on the fragment. Makes sense.
> 

Yes.

> There is no DH calculating per fragment. DH is calculated once in IKE_SA_INIT
> as in ordinary IKE SA establishment (note, that unprotected messages, including IKE_SA_INIT

If we do IKEv2 fragments the way everyone does IKEv1 fragments, the initiator can send multiple fragments that don't assemble to a protected packet, causing the responder to allocate memory to store these fragments (at least for a short while). Doing this does not require completing the D-H calculation, and does not require running either an encryption or MAC function.

What your draft does, is force the initiator to protect each fragment. To protect a fragment in a way that will cause the responder to store it, requires running the MAC function, and that in turn requires generating the keys (running the PRF), which in turn requires completing the D-H calculation. If the initiator fails to do any of these things, the fragment will be immediately rejected at the responder. Of course, the D-H calculation is not per-fragment, and I did not claim that this was the case.

> And you spent absolutetly the same amount of CPU power to calculate/verify ICV on

You spend the same amount only if you require that your ICV verify. This is not needed for creating DoS on the way fragmentation is done in IKEv1.

> (probably a little bit more, as total length of all fragments of one message could
> be a bit more than the length of original message due to padding, IKE header and so on,

Measurably more, because MAC functions have an initialization part, so running it on a single packet by parts incurs the per-run overhead multiple times. See the differences in the throughput of HMAC based on buffer size (obtained by running "opnessl speed":

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
hmac(md5)        17801.04k    53527.61k   132966.20k   210528.97k   253873.49k

So if the packet is 8000 bytes, and you divided it into 1024 fragments, you would incur a slightly more than 20% penalty.

> 
> Let me emphasize again.
> 1. In our proposal sender and receiver spend roughly the same amount of CPU power
> 2. In our proposal sender and receiver spend roughly the same amount of CPU power
>   as they would spend on protecting/verifying fragmented message in Cisco/MS solution.
> 3. In our proposal sender needs to encrypt/protect one message twice only once
>   per SA establishments and only if he/she tries first to send unfragmented
> After you decrypt and verify content of Encrypted Fragment Payload of all fragments,
> get rid of now unnecessary headers and put all together, you get a decrypted IKE message.

Good.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Mar 2013 10:27:52 -0400 (EDT)

> So if the packet is 8000 bytes, and you divided it into 1024 fragments, you would incur a slightly more than 20% penalty.

I don't understand this part? Legitimate fragments won't have a
count higher then about 10. Current implementations I've seen cap at
16 fragments. If you receive a fragment number higher then that, you
discard the whole thing. You could even wait with decrypting until you
got all fragments.

I don't see much value in authenticating each fragment. Possibly they
would come in faster then you can decrypt each fragment anyway, so you
need to store them regardless, especially in a DoS where the initiator
does not perform real encryption for sending fragments.

I would likely implement it to receive all fragments, then run
decryption on all its parts.

Furthermore, since we have the cookies/SPI, it is also pretty easy to
ignore bogus fragments, and to require the 6 message echange when
receiving a first-packet for a new exchange when under high load, so
IKE spoofing won't cause us that much of a higher load.

So I'm not too worried about the DOS, and I'm leaning towards a similar
model to the currently deployed method for IKEv1. Possibly dropping
the useless "fragment id" (not fragment number)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Mar 2013 16:29:43 +0200

Yoav Nir writes:
> > IKE_SA_INIT as in ordinary IKE SA establishment (note, that
> > unprotected messages, including IKE_SA_INIT and IKE_SA_RESUME
> > cannot be fragmented).
> 
> If we do IKEv2 fragments the way everyone does IKEv1 fragments, the
> initiator can send multiple fragments that don't assemble to a
> protected packet, causing the responder to allocate memory to store
> these fragments (at least for a short while). Doing this does not
> require completing the D-H calculation, and does not require running
> either an encryption or MAC function. 

I would assume all implementations start doing Diffie-Hellman even
before than they even see the first fragment. I.e. when the responder
sends it IKE_SA_INIT reply back it will also start the Diffie-Hellman
calculation on the background so it might be ready when it gets next
packet from the initiator. The initiator must do the Diffie-Hellman
before it can send first IKE_AUTH packet anyways.

When responder gets IKE_AUTH packet from the initiator, then they will
start Diffie-Hellman calculation if they have not yet done it
previously. 

> What your draft does, is force the initiator to protect each
> fragment. To protect a fragment in a way that will cause the
> responder to store it, requires running the MAC function, and that
> in turn requires generating the keys (running the PRF), which in
> turn requires completing the D-H calculation. If the initiator fails
> to do any of these things, the fragment will be immediately rejected
> at the responder. Of course, the D-H calculation is not
> per-fragment, and I did not claim that this was the case.

Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH.
Responder must do Diffie-Hellman anyways before it can process
incoming IKE_AUTH. And as the fragments are not acknowledged
separately the responder implementation can store all the encrypted
and authenticated fragments wihtout checking and when it all of them,
it can do Diffie-Hellman and decrypt + authentication to all of them,
just like in the IKEv1 fragment version. So there is no big difference
there.

The big differences is that smart implementation can check fragments
as they come in, thus it can immediately reject bogus fragments, and
only store and try reassembly on the valid fragments.

As earlier explained not doing that allows very wasy DoS attack, which
allows IKEv2 to finish by just sending very few packets, i.e. you send
one corrupted fragment to the packet and if you do that before
responder gets the correct fragment, the responder stores it for
reassembly and after it reassembles the packet it will only then
notice that the packet is corrupted, and then it needs to throw the
whole packet away. It cannot know which of the fragment is corrupted.
This means the initiator needs to retransmit whole packet, i.e. all
fragments of it, and attacker can do this again.

I think doing authentication per fragment is MUCH better method of
doing the fragmentation. 

> Measurably more, because MAC functions have an initialization part,
> so running it on a single packet by parts incurs the per-run
> overhead multiple times. See the differences in the throughput of
> HMAC based on buffer size (obtained by running "opnessl speed":

We are talking about IKE_AUTH here, and we will do the Diffie-Hellman,
and most likely also public key signature verification and generation
here (fragmentation is most likely only needed if we do have
certificates inside the packet, shared secret authentication should
work without fragmentation). 

> So if the packet is 8000 bytes, and you divided it into 1024
> fragments, you would incur a slightly more than 20% penalty.

It's actually more useful to compare the speeds from the 1024 bytes
down to 512 bytes and then add Diffie-Hellman over group 14 and RSA
signature verification + generation over 2048 bit key and check the
time difference there. I would expect it to be almost unnoticeable. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 14:37:58 +0000

> discard the whole thing. You could even wait with decrypting until you

True for the way things are done in IKEv1, but Valery's draft has you at least calculating the MAC for each fragment before storing. MAC-ing each fragment is 20% more expensive (for a 8000-byte message) than MAC-ing the whole thing. Not that it matters - it's all in the noise considering that there's also a D-H operation taking place.

> decryption on all its parts.

In that case you don't get the DoS protection offered by this draft.

> the useless "fragment id" (not fragment number)

It's a tradeoff of memory vs CPU. I'm not sure which is more constrained.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 14:49:53 +0000

> start Diffie-Hellman calculation if they have not yet done it

My implementation does that. We only calculate the shared key when we need it - when the IKE_AUTH request arrives.

> Initiator must do Diffie-Hellman anyways before it can send IKE_AUTH.

True for a legitimate Initiator. At attacker can send fake fragments, and the responder has the option of expanding CPU resources for verifying the ICV, or expanding the memory resources for storing them for a while.

> time difference there. I would expect it to be almost unnoticeable. 

I agree it's in the noise.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Mar 2013 18:51:27 +0400

> protected packet, causing the responder to allocate memory to store these 
> fragments (at least for a short while). Doing this does not

Yes, in our solution only protected messages could be fragmented. This is 
its limitation.
But in IKEv2 all messages except for IKE_SA_INIT, IKE_SA_RESUME and some
informational must be protected.

> What your draft does, is force the initiator to protect each fragment. To 
> protect a fragment in a way that will cause the responder
> to store it, requires running the MAC function, and that in turn requires 
> generating the keys (running the PRF), which in turn requires
> completing the D-H calculation. If the initiator fails to do any of these 
> things, the fragment will be immediately rejected at the responder.

Yes, but initiator needs to do it in any case. You cannot send protected
message (fragmented or not) without calculating DH, SKEYSEED etc.

> Of course, the D-H calculation is not per-fragment, and I did not claim 
> that this was the case.

Sorry I didn't quite catch you.

> You spend the same amount only if you require that your ICV verify. This 
> is not needed for creating DoS on the way fragmentation
> is done in IKEv1.

ICV must be verified in any case - fragmented or non-fragmented.

> Measurably more, because MAC functions have an initialization part, so 
> running it on a single packet by parts incurs the per-run
> overhead multiple times. See the differences in the throughput of HMAC 
> based on buffer size (obtained by running "opnessl speed":
>
> So if the packet is 8000 bytes, and you divided it into 1024 fragments, 
> you would incur a slightly more than 20% penalty.

Yes, as I've said there is some penalty. It may differ depending on 
algorithm and implementation.
I don't see a big problem here, as ICV computation must be fast anyway.

Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Mar 2013 10:51:58 -0400 (EDT)

> fragments of it, and attacker can do this again.

Note that requires an observer that can see your cookies/spi. Which would
mean a local attacker, whom could just as easilly send you nonsense
forged from the remote endpoint - as they are guaranteed to answer
faster. You'd be decrypting thousands of packets to find the needle in
the haystack. I wonder what the chances then are that you don't end up
dropping teh valid fragment.

If the attacker is not local, they need to be in your path to know the
spi/cookies, and they can just filter out the valid fragments.

But I see your point, it does raise the bar a little bit. Although I'm
not convinced it's worth it.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Mar 2013 19:08:47 +0400

> True for a legitimate Initiator. At attacker can send fake fragments, and 
> the responder has the option of expanding
> CPU resources for verifying the ICV, or expanding the memory resources for 
> storing them for a while.

There is no difference comparing with usual, non-fragmented IKE_AUTH 
message -
responder still can be forced by attacker to complete DH, calculate keys and
try to verify forged message. And fragmentation doesn't make it worse.

And even with unprotected fragments it is not a big deal for attacker to 
send
you a set of fragments that you will successfully reassemble to a 
good-looking
message and then you again will have to complete DH, calculate keys and
try to verify that garbage. No difference.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 14 Mar 2013 17:08:11 +0200

Paul Wouters writes:
> Note that requires an observer that can see your cookies/spi.

Yes.

> Which would

My PC has more than enough CPU power to verify MAC on the packets
coming in over the wireless link. On the other hand if attacker fills
the wireless link with junk packets, it is very easy to find him. If
attacker just sends on random packet every 2 seconds, it is much
harder to pinpoint who and where he is. 

The idea of DoS protection is to make the attack more expensive for
the attacker, and also make detecting him easier. Adding MAC to
fragments does both.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 14 Mar 2013 19:42:29 +0000

Our answer:

	paul

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 14 Mar 2013 23:13:18 +0200

Hi Paul,

Can't an off-path attacker DoS the gateway if they can guess the SPI 
values? We never mandated that SPIs should be random (except for RFC 
6290, in Sec. 9.3, but this is rarely implemented), so implementations 
are free to use very small integers for the SPIs. In fact I think we 
should reconsider mandating random SPIs once again.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Mar 2013 00:00:19 +0200

Paul Hoffman writes:
> <chair-hat on>
> 
> It is seeming that consensus is trending towards "let's document the
> fragmentation method some vendors are already doing instead of
> finishing IKEv2-over-TCP", but I would like to check that. Please
> respond to the informal poll below. 
> 
> --Paul Hoffman
> 
> - I would prefer the WG to stop working on IKEv2 over TCP and
>   instead work on standardizing IKEv2 fragmentation 
> - I would prefer the WG to continue working on IKEv2 over TCP and
>   also work on standardizing IKEv2 fragmentation 

Either 1 or 2, but not for 3. I.e. either one is fine for me, but I do
not want to have two ways of doing it in IKEv2. 
-- 
[email-masked]

---

From: Brian Weis <[email-masked]>
Date: Thu, 14 Mar 2013 18:36:02 -0400

My answer:

If this is not the consensus, I agree with Yoav: I would prefer that we clear up the situation with Microsoft's IPR before working on standardizing IKEv2 fragmentation.

Brian