Draft: draft-ietf-quic-manageability

Commentary: thanks for the text . 
 talks at length about detecting and mitigating against ( D)DoS attacks , but this is written with the assumption of an uncooperative endpoint ( likely to be , but unstated , a server ) . All except the Retry text where the design specifically forces interventions to be cooperative . It is entirely reasonable for DoS classification to be done with full knowledge of valid connection IDs or at least valid connection ID lengths . If you allow for cooperation , the text might then explain how this might allow established flows to be separated from spoofed flows and new connection attempts . 
 +1 Perhaps either approach could be reasonable depending on the specific case ? - Which DoS / DDoS mitigation fits best for an enterprise / user might vary depending on many things - including the role played by the endpoint and who controls the network and devices . 
 Can someone propose text ? 
 In the last paragraph , it may be worth mentioning the 3x amplification limit during the handshake as well . Post - handshake DoS / DDoS is usually an application - level property which could affect TCP as much as QUIC , so the whole 5 - tuple / CID aspect seems like it could be ignored commonly post - handshake . Is there a DoS expert we could ask to look at this text to see if it made sense , since I worry none of us are that person ? 
 with TCP , the handshake could be completed by the DDoS " classification " engine without passing a bit of an information to the endpoint . That 's called " SYN proxying " . That was , uh , a cool feature since otherwise the endpoint would 've been flooded by handshake attempts . Even though TCP was n't cooperating , this feature was powerful enough to allow to build an impenetrable DDoS mitigation infrastructure . Please see also . 
 I was thinking of something a little like this ( and can make a PR if this is heading in a useful direction : " On - path observation of the transport headers of packets can be used for various security functions . For example , Denial of Service ( DOS ) and Distributed DOS ( DDOS ) attacks against the infrastructure or against an endpoint can be detected and mitigated by characterising anomalous traffic . Other uses include support for security audits ( e.g. , verifying the compliance with ciphersuites ) ; client and application fingerprinting for inventory ; and to provide alerts for network intrusion detection and other next generation firewall functions . When using an encrypted transport , it is possible for endpoints to directly support these security functions ; another method could use an on - path network device that relies on pattern inferences in the traffic and heuristics or machine learning instead of processing observed header information . " Thoughts ? 
 I think this text still does n't address MT 's original point fully - that an endpoint could even cooperate with an on - path device directly by e.g. sharing information about connection IDs . 
 Yes . Would happily add that the endpoint can " cooperate with an on - path device directly by e.g. sharing information about connection IDs " . Is there more ? 
 Re : comment above : SYN proxying wo n't work in QUIC for the obvious crypto reasons , but a related approach that dynamically starts sending Retry over a certain rate limit might be almost as good . Retries are already partially covered in section 4.7 . In this regime one could also drop  packets . Is this something it 'd make sense to add to this document , or in QUIC - LB instead ? 
 I do n't like where this was taken . As said , it is not responsive to my comments about cooperation . It still firmly assumes that DoS mitigation is being performed without cooperation from endpoints . That might be unavoidable for good reasons , but we should be clearer about the consequences of that AND we should recommend that DoS mitigation be performed with cooperation from endpoints .
Paragraph (version B):
On-path observation of the transport headers of packets can be used
for various security functions.  For example, Denial of Service (DOS)
and Distributed DOS (DDOS) attacks against the infrastructure or
against an endpoint can be detected and mitigated by characterising
anomalous traffic.  Other uses include support for security audits
(e.g., verifying the compliance with ciphersuites); client and
application fingerprinting for inventory; and to provide alerts for
network intrusion detection and other next generation firewall
functions.
Paragraph (version B):
Current practices in detection and mitigation of DDoS attacks
generally involve classification of incoming traffic (as packets,
flows, or some other aggregate) into "good" (productive) and "bad"
(DDoS) traffic, and then differential treatment of this traffic to
forward only good traffic.  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):
Efficient classification of this DDoS traffic in the mitigation
environment is key to the success of this approach.  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 B):
Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient and requires more state
to be maintained by DDoS defense systems.  For the common case of NAT
rebinding, where the client's address changes without the client's
intent or knowledge, DDoS defense systems can detect a change in the
client's endpoint address by linking flows based on the server's
connection IDs.  However, QUIC's linkability resistance ensures that
a deliberate connection migration is accompanied by a change in the
connection ID.  In this case, the connection ID can not be used to
distinguish valid, active traffic from new attack traffic.
Paragraph (version B):
Another potential method could use an on-path network device that
relies on pattern inferences in the traffic and heuristics or machine
learning instead of processing observed header information.
Paragraph (version B):
However, it is questionable whether connection migrations must be
supported during a DDoS attack.  However, for unintentional
mitigations, as is usually the case for NAT rebindings, the
connection ID can be used to track connections (see sec-flow-
association).  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):
Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937
are a well-established method of mitigating some kinds of TCP DDoS
attacks.  QUIC Retry packets are the functional analogue to
syncookies, forcing clients to prove possession of their IP address
before committing server state.  However, there are safeguards in
QUIC against unsolicited injection of these packets by intermediaries
who do not have consent of the end server.  See QUIC_LB for standard
ways for intermediaries to send Retry packets on behalf of consenting
servers.