Subject: [conex] Preferential Drop

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Feb 2014 12:39:21 +0100

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

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 12 Feb 2014 12:36:42 +0000

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:[email-masked]] On Behalf Of Mirja Kühlewind
> Sent: Mittwoch, 12. Februar 2014 12:39
> To: [email-masked]
> Subject: [conex] Preferential Drop
> 
> Hi group,
> 
> I'm currently integrating text from the re-ECN documents on preferential
> drop into the IPv6 CDO draft.
> 
> 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
> gets dropped. If the router is not ECN-capable, it still might help but not that
> much. Thus I added the following sentence:
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 14 Feb 2014 11:43:52 +0100

Hi Dirk,

thanks for your feedback. Please see in line...

> - it's probably useful to state in the table that "1" == top priority
It's in the text, but I will also but it in the table.

>
> - "... 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...)
That was intended to have to really optional. There is not need to implement 
preferential drop to have ConEx working. It only to potentially have some 
additional benefits if desired be the operator... 
Moreover, it might be quite complicated to implement preferential drop into 
existing architectures (we had this discussion recently on the rmcat list). 
And we definitely don't want to keep people from using the ConEx information 
by requiring preferential drop.

>
> - 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.
No, you can have preferential drop without ECN. It is just more useful with 
ECN and that why the later text mostly relies on assuming ECN. Thus I think 
if we would like to have ECN, we have to write it in the text (as it is not 
implicit). The question is: do we want to push ECN deployment by this? Or 
should the decision to use ECN be taken as independent. Because then, the 
text would read like: "If ECN is also (already) supported, this mechanism 
provides better DDoS migration..." or something like this....

Mirja

> > 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:
> > 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
> >
> >

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------