Graham Bartlett (grbartle) <grbar...@cisco.com> wrote:
> 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.
Adding IKE-level fragmentation to the process adds an additional place
that DDoS attacks can hit.
So, one would have to have some mechanism to know what would get through,
and if to switch to TCP, etc. before even trying.
> 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.
If you you want to do something, then it needs to be a new state between
IKE_SA_INIT and IKE_AUTH.
> I agree. All of the DoS (cookie, etc.) defense and switch to TCP, and
> detection of NAT-T, etc. is in the IKE_SA_INIT, and so doing any kind of
> framentation in IKE_SA_INIT is a bad idea.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
