Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

["Valery Smyslov" <[e-mail]>]

Hi Michael,

>     > Is the main rational for not having fragmentation in IKE_SA_INIT that
>     > it could break the features of IKE that you list below?
> 
> 1) we are currently working on IKE over TCP because we already know that
>    IKE packets (and UDP encapsulated IPsec) are not get through.  Adding
>    IP fragmentation to the process will just make it worse.
> 
>    Adding IP-level fragmentation to the process adds additional state to the
>    gateway, often hidden to the IKE daemon itself.

That's true and that's one of the reason to avoid it by all means 
(the other and probably even more important reason - crippled
middleboxes that don't pass UDP fragments through).

>    Adding IKE-level fragmentation to the process adds an additional place
>    that DDoS attacks can hit.

We have DDoS protection mechanisms. I think it's possible to define 
IKE_SA_INIT fragmentation so that these mechanisms be still able to work.

>    So, one would have to have some mechanism to know what would get through,
>    and if to switch to TCP, etc. before even trying.

TCP has a lot of shortcomings. It's a last resort.

>     > The reason I ask, we’re working on the current draft and looking to
>     > implement optional fragmentation in the IKE_SA_INIT, but this would be
>     > friendly to cookies, TCP encaps, NAT-T etc
> 
> 2) I think it's not possible to do fragmentation on IKE_SA_INIT (and any
>    level) without opening up gateways up for DDoS attacks.
>    So, don't do it in IKE_SA_INIT in my opinion.

Repeating myself - I don't think it is impossible to define IKE_SA_INIT
fragmentation in such a way, that it won't weaken IKE DDoS protection.
There are two obstacles in my opinion.

1) Complexity. The exchange would most likely become overly complex
and even very unusual comparing to other exchanges (e.g. it is possible to 
acknowledge each fragment individually, this way a better DDoS protection
can be achieved,  but this is non-standard  behavior for IKE and could open 
its own can of worms).

2). Backward compatibility. It's difficult to negotiate using IKE fragmentation
in IKE_SA_INIT. Pre-configuration is a bad option. Most probably the cost 
would be an extra round trip + some tricks playing with invalid syntax and/or
 unknown exchange type).

> If you you want to do something, then it needs to be a new state between
> IKE_SA_INIT and IKE_AUTH.

Having an intermediate exchange that will reuse existing IKE Fragmentation
mechanism is a very attractive idea. It is even possible to leave out MessageID = 1 
for IKE_AUTH. The main problem with this approach is that it doesn't allow
to completely get rid of traditional DH in the future - we need to exchange 
KE to compute SK_* to use IKE fragmentation.

Regards,
Valery.