On 17 Jun 2010, at 17:40 , Paul Jakma wrote: > On Thu, 17 Jun 2010, RJ Atkinson wrote: >> Scaling should be just fine. >> >> Existing TCP/IPv4 implementations for web servers already keep a significant >> amount of session state for each TCP session. This is known to scale >> adequately for very large numbers of TCP sessions in several major operating >> systems (for example, in Solaris and FreeBSD). > > What I have in mind is the fact that TCP state can be burdensome enough that > several OSes implement mechanisms to 'offload' that state back onto clients, > through the "SYN Cookies" technique. > > I.e. state is particularly troublesome when it is in kernel (unpageable > memory in many OSes) and instantiable by arbitrary remote hosts. So I'm > wondering what happens if malicious remote hosts deliberately set out to > exhaust an ILNP resources by causing it to create more and more ILNP session > cache entries. ?
Specifically... Several existing OSs that do not use the "SYN Cookies" technique (that you mention above have) and do not have TCP offload long been robust against TCP SYN flood attacks. So there are other implementation strategies, not involving either TCP Offload or SYN Cookies that work just fine to make a TCP implementation robust against SYN flood attacks. As an example, stock FreeBSD on commodity x86 silicon, without SYN Cookies or TCP Offload, is widely considered to be robust in the face of a TCP SYN flood attack. An ILNP Session flood attack consumes more attacker resources than a TCP SYN flood attack consumes. So a TCP SYN flood attack would be cheaper/easier for an adversary to mount. Attackers generally aren't dumb, they generally are good at conserving their own energy and resources. Separately, an ILNP Session flood attack impacts an ILNP-capable host less (in terms of state to manage) than the equivalent TCP SYN flood attack affects a TCP-capable host. More generally... All useful networking protocols can at least theoretically be subjected to (Distributed) Denial of Service attacks, which is what you have postulated for ILNP. If I recall, this goes back at least to the Voydock & Kent paper over two decades ago. (D)DOS attacks aren't preventable. Instead, the trick is to not create a new lowest work function opportunity for the attacker. ILNP clearly meets that criterion. Thoughtful implementers ought not have difficulty handling this. Quality of implementation matters today in our TCP/IPv4 world. It matters for folks deploying IPv6. It will continue to matter in an ILNP world. Just as the details of how to make a TCP implementation robust against a SYN flood attack are very implementation-specific, the details of how to make an ILNP implementation robust against a new session flood attack likely will be very implementation-specific. So I don't think that any implementation technique would apply to all ILNP implementation environments. Cheers, Ran _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
