Draft: draft-ietf-quic-manageability

Commentary: This is not how it works . A few examples : 
 I 'm not sure I see support for " this is not how it works " in your examples : SYN cookies on their own are a 1990s technique for end - system DoS prevention , which , while useful at transport - terminating front ends as part of a larger DoS prevention strategy , are n't really usable on their own at scale . The paper you link to here ( from ICWET , and itself a old ) primarily deals with the separation of good from bad flows at layer 7 , not necessarily how the front - end handles these flows once classified . But you 're definitely right that this is not only how it works : the DoS mitigation landscape is wide and varied ( even if at the end of the day the only strategy we have found to work at scale is " eat the DoS " . That said , this text could be improved : it discounts detection and classification mechanisms other than based on flow designators derived from passive measurement , does not mention protocols other than IPFIX and the flow model that comes along with it when classifying traffic , etc . The text should also be more applicable to UDP reflection DoS , which is a primary concern in wire image differentiation in QUIC ( and which also is n't otherwise addressed in the document or in this issue ) . Adding a path - observable SYN cookie equivalent to QUIC , while useful , seems difficult to achieve given the working group 's history of consensus about path - observable wire image features , so other classification mechanisms are what we 'll be left with . 
 Exactly my point . The passive measurements are generally only useful to prevent the collateral damage to the network infrastructure of an ISP or a datacenter network under an attack . While the infrastructure impact of QUIC is itself an intriguing research topic , DDoS affects not only transit networks but also the endpoints in ways that could not be prevented with any passive flow classification . 
 The intent of this section is to cover DoS mitigation on the " downstream " segment , all the way from transit to endpoint , with access and front - end networks in between ; the further you get from the endpoint the harder classification is , but the larger the impact of filtering operations . AIUI transit networks generally only get involved at the BGP level ( i.e. , when an affected destination prefix is temporarily announced via a mitigation / filtering network to route traffic for scrubbing ) , but we should n't look at just the endpoint / frontend , either , This document probably should n't go all the way down the DoS prevention architecture rabbithole ( note to self : check to see whether DOTS has something we can refer to here ) . But I 'll put some effort into making this more general . 
 This is more of an " e.g. " than " i.e. " , but fine . I must say this is also a place where the infrastructure could be affected by the HTTP protocol upgrade . E.g. if the risk model assumes large transport layer floods , then the optical links towards the scrubbing center should be upgraded to carry ~22x more traffic . 
 actually , no ; improve section 4.4 as well . 
  . " Current practices in detection and mitigation of Distributed Denial of Service ( DDoS ) attacks generally involves classification of incoming traffic ( as packets , flows , or some other aggregate ) into " good " ( productive ) and " bad " ( DDoS ) traffic " No . It generally does not . There are active and passive countermeasures , there are SYN cookies , truncated DNS responses , captchas , etc . The draft is still missing all of those . 
 I think what is still missing is to note that this document is generally scoped to in - network manageability and therefore does not discuss measures that can be applied directly at the end hosts . Maybe we can clarify this by add one simple word like this : s / Current practices in detection and mitigation / Current in - network practices in detection and mitigation/ ? 
 No , this is still not fair . Active countermeasures like SYN proxying still belong to the network . Probably the only way to do this properly would be to say that " Current practices in passive detection and mitigation " do whatever they do , and to add later in the section that there are also practices in active mitigation which are not supported by the protocol ( the last paragraph basically sums it up ) when the endpoint is not cooperating . It 'd be also a good idea to highlight the impact of the lack of active mitigation features , and to hint to how the endpoint could cooperate .
Paragraph (version A):
Current practices in detection and mitigation of Distributed Denial
of Service (DDoS) attacks generally involve passive measurement using
network flow data RFC7011, classification of traffic into "good"
(productive) and "bad" (DoS) flows, and filtering of these bad flows
in a "scrubbing" environment.  Key to successful DDoS mitigation is
efficient classification of this traffic.
Paragraph (version A):
Limited first-packet garbage detection as in sec-garbage and stateful
tracking of QUIC traffic as in sec-stateful above can be used in this
classification step.
Paragraph (version B):
Current practices in detection and mitigation of Distributed Denial
of Service (DDoS) attacks generally involves classification of
incoming traffic (as packets, flows, or some other aggregate) into
"good" (productive) and "bad" (DDoS) traffic, then differential
treatment of this traffic to forward only good traffic, to the extent
possible.  This operation is often done in a separate specialized
mitigation environment through which all traffic is filtered; a
generalized architecture for separation of concerns in mitigation is
given in DOTS-ARCH.
Paragraph (version B):
Key to successful DDoS mitigation is efficient classification of this
traffic in the mitigation environment.  Limited first-packet garbage
detection as in sec-garbage and stateful tracking of QUIC traffic as
in sec-stateful above may be useful during classification.
Paragraph (version A):
the load balancer I-D.ietf-quic-load-balancers.
Paragraph (version A):
It is questionable if connection migrations must be supported during
a DDoS attack.  If the connection migration is not visible to the
network that performs the DDoS detection, an active, migrated QUIC
connection may be blocked by such a system under attack.  As soon as
the connection blocking is detected by the client, the client may
rely on the fast resumption mechanism provided by QUIC.  When clients
migrate to a new path, they should be prepared for the migration to
fail and attempt to reconnect quickly.
Paragraph (version B):
the load balancer I-D.ietf-quic-load-balancers.  This may be
complicated where mitigation and load balancing environments are
logically separate.
Paragraph (version B):
It is questionable whether connection migrations must be supported
during a DDoS attack.  If the connection migration is not visible to
the network that performs the DDoS detection, an active, migrated
QUIC connection may be blocked by such a system under attack.  As
soon as the connection blocking is detected by the client, the client
may rely on the fast resumption mechanism provided by QUIC.  When
clients migrate to a new path, they should be prepared for the
migration to fail and attempt to reconnect quickly.