Re: [conex] Preferential Drop

[Mirja Kuehlewind <[e-mail]>]

Hi Dirk,

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


On Wednesday 12 February 2014 13:36:42 Dirk Kutscher wrote:
> Hi,
>
> Thanks. Just a few comments:
>
> - 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


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



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

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------