Subject: Re: [Dots] Full Pipe Scenario

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 1 Nov 2017 13:44:17 +0000

Thanks Jon, updated draft uploaded to https://github.com/dotswg/dots-signal-channel. It also addresses various other issues discussed in the WG (use of .well-known, default port for DOTS, comments from Kaname to map alt-server, alt-server-record, ttl, addr to CBOR etc.).

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Monday, October 30, 2017 1:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Full Pipe Scenario

Hi Tiru,

This looks good to me.  Thanks.

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 30 October 2017 07:26
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Full Pipe Scenario

Thanks Jon, I have modified the proposed text as follows:

In case of a volumetric DDoS attack saturating the incoming link to the DOTS client, all traffic from the DOTS server to the DOTS client will likely be dropped, although the DOTS server receives heartbeat requests and DOTS messages from the DOTS client.
In this scenario, the DOTS agents MUST behave differently to handle message transmission and DOTS session liveliness during link saturation :

* The DOTS client MUST NOT consider the DOTS session terminated even after maximum "missing-hb-allowed" threshold is reached. DOTS client SHOULD continue to use the current DOTS session, and send heartbeat requests over the current DOTS session, so the DOTS server knows the DOTS client has not disconnected the DOTS session. After the maximum "missing-hb-allowed" threshold is reached, the DOTS client SHOULD try (D)TLS session resumption. The DOTS client SHOULD send mitigation requests over the current DOTS session, and in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1.3 to piggyback the mitigation request in the ClientHello message.  Once the link is no longer statured, if traffic from the DOTS server reaches the DOTS client over the current DOTS session, the DOTS client can stop (D)TLS session resumption or if (D)TLS session resumption is successful then disconnect the current DOTS session.

* If the DOTS server does not receive any traffic from the DOTS client, then the DOTS server sends heartbeat requests to the DOTS client and if "trigger-mitigation" is set to "false", then trigger DDoS mitigation after maximum "missing-hb-allowed" threshold is reached.

-Tiru

From: Jon Shallow [mailto:[email-masked]]
Sent: Friday, October 27, 2017 5:27 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Full Pipe Scenario

Hi Tiru,

I propose then that we add to the end of the first paragraph of [5.6 Heartbeat Mechanism] something similar to

Orig: "To provide a metric of signal health and distinguish an 'idle' signal
   channel from a 'disconnected' or 'defunct' session, the DOTS agent
   sends a heartbeat over the signal channel to maintain its half of the
   channel.  The DOTS agent similarly expects a heartbeat from its peer
   DOTS agent, and may consider a session terminated in the extended
   absence of a peer agent heartbeat."

New: "With the attack scenario of the pipe going from the DOTS server to the DOTS client running full, the DOTS server will be seeing the heartbeat requests from the DOTS client, but no responses from the DOTS server initiated heartbeats.  The DOTS server SHOULT NOT consider the session terminated after "missing-hb-allowed" has been exceeded, but SHOULD continue with the session and SHOULD continue sending heartbeats on the assumption that it is a pipe full scenario and there potentially could be new mitigation requests from the DOTS client.  Any "trigger-mitigation" set to "false" MUST still be triggered when "missing-hb-allowed" has been exceeded.

Similarly, the DOTS client will be seeing nothing coming from the DOTS server.  After "missing-hb-allowed" has been exceeded, the DOTS client SHOULD try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbeats using the "missing-hb-allowed" failing session so that the DOTS server knows there still is communication.  If the DOTS client has a new mitigation request, the DOTS client SHOULD "blindly" send the new mitigation request over the "failing" session in addition to the session resumption.  Only when traffic starts to arrive again from the DOTS server should the "failing" session be dropped and a new session established.

Orig: "   While the communication between the DOTS agents is quiescent, the
   DOTS client will probe the DOTS server to ensure it has maintained
   cryptographic state and vice versa.  Such probes can also keep alive
   firewall and/or NAT bindings.  This probing reduces the frequency of
   establishing a new handshake when a DOTS signal needs to be conveyed
   to the DOTS server."

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 October 2017 07:07
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Full Pipe Scenario

Heartbeat mechanism is triggered only when the communication b/w the DOTS agents is idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-channel-05#section-5.6).
In this case, the DOTS client does not receive any mitigation response from the DOTS server, and the DOTS client knows the inbound pipe is saturated, but the DOTS client does not know if the DOTS session is disconnected. To handle both the problems, and maximize reachability, the DOTS client can continue to use the same DOTS session even if no response is received for the heartbeat but at the same time try (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello.
When the inbound pipe is no longer saturated, but the DOTS client does not receive any heartbeat responses from the DOTS server then it should consider the session is defunct
after missing-hb-allowed number of times.

-Tiru

From: Dots [mailto:[email-masked]] On Behalf Of Jon Shallow
Sent: Friday, October 27, 2017 2:06 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Full Pipe Scenario

Hi,

DOTS Client (C) ---------  Pipe -------- DOTS Server (S)

We have been testing DOTS server and DOTS client signal channel interaction with a full inbound pipe scenario where all traffic from DOTS server to DOTS client is dropped, but traffic from DOTS client is getting through to the DOTS server.

The outbound pipe may be lossy, but testing was done with very little loss outbound.

If the outbound pipe is running full, then the DOTS Client environment has to control this traffic as the DOTS Server is very unlikely to be able to do anything here - so this scenario ignored!

With this full inbound pipe (direction S to C), we are seeing the following

*       DOTS server sees the Heartbeat requests from the DOTS client

*       DOTS server sees any mitigation requests from the DOTS client

*       DOTS server thinks the signal channel is dead as there are no responses to the DOTS server's Heartbeats

*       DOTS client thinks the signal channel is dead as there are no responses to the DOTS client's Heartbeats

*       DOTS client is unable to establish a new signal channel with the server (this may be down to the fact that we internally have not (yet) got session resumption working over DTLS) and so cannot send mitigation requests over  this channel

If the DOTS server is seeing and noting the DOTS client Heartbeat requests, it can determine the session is still alive and keep it going, even if its own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Failing' after the missing heartbeat counter has expired).  Should we be doing this noting of DOTS Client heartbeats?

[TR] Yes, it s

-The DOTS server can safely assume there is a pipe full scenario (or network routing issue) if it continues to see the DOTS client heartbeats.

If the DOTS server is still keeping the session going, and receives a DOTS client mitigation request it can be acted on, even though there is a full pipe.  Is this a good thing?

Should the DOTS client continue to send Heartbeats after the DOTS client has determined the session has 'Heartbeat Failed' - so that that the DOTS server is kept "warm" in case a mitigation request has to blindly be sent.

If the DOTS client closes the session after Heartbeat failure, fails to establish a new session, then there is no mechanism to send a mitigation request - the DOTS client may have discovered a new IP or subnet under attack.
- I appreciate that we have a trigger-mitigation flag which may help here.
- If the new session gets going, then the "Heartbeat Failure" session should be closed down.

Keeping the Heartbeats going, even after the determination that Heartbeats are failing has benefits in supporting additional mitigation requests, but potentially conflicts with the DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat responses.  I know SIG-003 is the subject of another debate - do we need heartbeats at all.

   SIG-003  Channel Health Monitoring: Peer DOTS agents MUST regularly
      send heartbeats to each other after mutual authentication in order
      to keep the DOTS signal channel active.  A signal channel MUST be
      considered active until a DOTS agent explicitly ends the session,
      or either DOTS agent fails to receive heartbeats from the other
      after a mutually agreed upon timeout period has elapsed.

Regards

Jon