On Thu, 17 Jun 2010, RJ Atkinson wrote:
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.
FreeBSD has its own measures agaisnt SYN attacks though.
However, that's not relevant to the question. The question is:
When you have state that can be induced, then you need to consider
how you will deal with malicious remote hosts (e.g. TCP SYN attacks;
hosts with unbounded ARP caches have seen attacks on that state). In
particular, it implies you will have to discard state.
So my question is: What happens to ILNP when a host is forced to
discard an entry in the ILNP session cache? What's the behaviour?
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.
TCP SYN attacks are no longer a problem, because OSes take
precautions and because it is well defined what happens when TCP
implementations drop SYN state (e.g. it becomes harder to connect
successfully to the host, but established connections are not
affected (modulo any bandwidth impact of SYN floods)).
Further, the per-host costs of mounting attacks is irrelevant - you
can hire botnets with tens of thousands of hosts. Host resources are
cheap.
My question is, what will ILNP do in such a scenario? I stress again
that TCP is just an example to show that protocols need to think
about this, and my question is about what thought there is on how
ILNP will behave.
Note that I am not trying to attack ILNP by considering attacks
against it - just trying to strenghten the specs. :)
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.
I am interested in how ILNP degrades when attacks are made on its
state.
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.
I think it helps if the protocol allows graceful degradation. So I
think it's worth considering what happens to a protocol as/when any
state it holds is discarded.
regards,
--
Paul Jakma [email protected] Key ID: 64A2FF6A
Fortune:
What sane person could live in this world and not be crazy?
-- Ursula K. LeGuin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
