[conex] Preferential Drop

[Mirja Kühlewind <[e-mail]>]

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