Re: [conex] Preferential Drop

[Dirk Kutscher <[e-mail]>]

Hi,

Thanks. Just a few comments:

- it's probably useful to state in the table that "1" == top priority

- "... it MAY preferentially drop packets" -- I actually think this should read "it SHOULD preferentially drop packet" -- we want to recommend it -- not say that it is really optional. (You would need to change the parentheses later in the text then, too...)

- I don't think we need "if a router implements preferential drop it SHOULD also support ECN-marking" -- it's kind of implicit. The text later also seems to assume that ECN is implemented anyway.

Dirk


> -----Original Message-----
> From: conex [mailto:[e-mail]] On Behalf Of Mirja Kühlewind
> Sent: Mittwoch, 12. Februar 2014 12:39
> To: [e-mail]
> Subject: [conex] Preferential Drop
> 
> Hi group,
> 
> I'm currently integrating text from the re-ECN documents on preferential
> drop into the IPv6 CDO draft.
> 
> Find the references from the re-ECN drafts here:
> http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-02#section-5.3
> http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-motiv-02#section-5.1
> 
> Here is my current text:
> "7.  DDoS mitigation by using preferential drop
> 
>    If a router queue experiences very high load so that it has to drop
>    arriving packets, it MAY preferentially drop packets within the same
>    Diffserv PHB using the preference order given in Table 1 (1 means
>    drop first).  Additionally, if a router implements preferential drop
>    it SHOULD also support ECN-marking.  Preferential dropping can be
>    difficult to implement on some hardware, but if feasible it would
>    discriminate against attack traffic if done as part of the overall
>    policing framework as described in [RFC6789].  If nowhere else,
>    routers at the egress of a network SHOULD implement preferential drop
>    (stronger than the MAY above).
> 
>                    +----------------------+------------+
>                    |                      | Preference |
>                    +----------------------+------------+
>                    | Not-ConEx or no CDO  |     1      |
>                    | X (but not L,E or C) |     2      |
>                    | X and L,E or C       |     3      |
>                    +----------------------+------------+
> 
>                 Table 1: Drop preference for ConEx packets
> 
>    A flooding attack is inherently about congestion of a resource.  As
>    load focuses on a victim, upstream queues grow, requiring honest
>    sources to pre-load packets with a higher fraction of ConEx-marks.
> 
>    If ECN marking is supported by the downstream queues preferential
>    dropping provides the most benefits because if the queue is so
>    congested that it drops traffic, it will be CE-marking 100% of the
>    forwarded traffic.  Honest sources will therefore be sending 100%
>    ConEx E-marked packets (and therefore being rate-limited at an
>    ingress policer).  Senders under malicious control can either do the
>    same as honest sources, and be rate-limited at ingress, or they can
>    understate congestion.  If the preferential drop ranking is
>    implemented on queues, these queues will preserve E/L-marked traffic
>    until last.  So, the traffic from malicious sources will all be
>    automatically dropped first.  Either way, the malicious sources
>    cannot send more than honest sources."
> 
> The text in the re-ECN drafts assumes that a ConEx/re-ECN-capable router
> will automatically also support ECN. The preferential drop works best if the
> router uses ECN, because such a router will mark all packets before anything
> gets dropped. If the router is not ECN-capable, it still might help but not that
> much. Thus I added the following sentence:
> "if a router implements preferential drop it SHOULD also support ECN-
> marking"
> 
> Not sure if I should write something like this because requiring to support
> ECN might stop people from implementing the preferential drop. On the
> otherhand ECN support would be helpful for ConEx anyway. But without a
> deployed accurate ECN it's kind of useless....
> 
> Any thoughts?
> 
> Mirja
> 
> 
> _______________________________________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/conex