On 18 Jun 2010, at 05:19 , Paul Jakma wrote:
> 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.
Quality of implementation matters, for any protocol.
I'm glad you agree with me about that.
> However, that's not relevant to the question.
It is DIRECTLY relevant to the question:
(1) it shows that real systems today can protect themselves
against flooding attacks that have more state per-new-session
than ILNP does,
(2) and can do so without specialty mechanisms such as
TCP offloading or the "SYN cookies"method.
(3) and also shows that different implementations need the
freedom to use mechanisms best suited for that particular
implementation, rather than having a one-size-fits-all
solution imposed from above.
> 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.
Disagree, at least as phrased above.
It means that one has to manage state, which one has to do anyway,
and isn't quite the same thing, and it also means that one wants
to avoid having huge amounts of state per-session. ILNP meets all
of those criteria already.
For example, some folks think of UDP as "stateless",
but it actually has nearly as much state as TCP in
a typical end system (e.g. in the Transport Control Block).
> 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?
First, recall that ILNP session state is generally short-lived
anyway.
Work done at U. St Andrews on real world systems has experimentally
confirmed a previous MIT LCS trace-driven analysis indicating that
DNS caching (for things other than NS records) is essentially
ineffective. So there is no reason to keep things like inactive
Locator state around for long periods of time even if a node is not
being flooded. The St Andrews work indicates that DNS TTLs as
low as zero work fine even for *server* A records in a real-world
operational environment. (Details of the study will be published
eventually.)
For reasons like multi-homing and mobility, one would imagine that
normal ILNP implementations will have Locator lifetimes that are
quite short -- less than a minute in some cases.
Lost ILNP state will look rather like the situation where
a node moved, and the location update was dropped due to
congestion somewhere along the path. This scenario is
already covered in reasonable detail.
>> 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)).
The same conceptual approach can work fine for ILNP. It is entirely
an implementation-specific matter whether that particular approach
is adopted for ILNP.
> Further, the per-host costs of mounting attacks is irrelevant - you can hire
> botnets with tens of thousands of hosts. Host resources are cheap.
Not irrelevant. The work function of the attacker ALWAYS matters,
at lest to attackers, because they do consistently employ the
attack with the lowest work function for themselves.
> 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.
You've missed my point:
The same approaches that work for TCP today also can work
for ILNP. So TCP is an existence proof that thoughtful
ILNP implementations will be fine.
>> 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.
The standards-track TCP specifications don't include any special
text for SYN Floods.
While RFC-4987, which is Informational status, was published in
August 2007 and does cover the topic, that RFC appeared over a
decade AFTER most TCP implementations were hardened. That document
describes a number of different protective mechanisms, but is
not proscriptive and doesn't mandate any particular implementation
approach.
Just as details of TCP implementations (and their protections)
vary widely, details of ILNP implementations will vary widely.
If the ILNP specifications required use of some particular
mechanism today, then the effect would be to prevent implementers
from tailoring defenses most suitable for their particular
implementation. Such specification is at least very premature today.
(Now, if you seek to add some specific text someplace, it really
would be simpler procedurally for you to propose adding some
specific text at some specific location in some specific I-D,
than to make me guess what text you are seeking where. My
crystal ball has been broken for years. :-)
Yours,
Ran
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
