Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Mirja,

Glad to see that we are progressing. With regards to the remaining issue, let's recap on the intended functionality and general observations.

* What is the intended functionality?

(1) What we need is a check to assess the liveness of the peer DOTS agent + maintain NAT/FW state on on-path devices. 
 
(2) CoAP does not impose how CoAP Ping messages should be sent, how their response (or lack of) should be interpreted, etc. This is left to the application.

(3) In a DDoS context, failure to receive heartbeats ** should not ** be systematically interpreted as the session is defunct. To that aim, a specific behavior is followed at the DOTS layer (not CoAP layer). The DOTS layer instructs the CoAP layer (DOTS session, and mitigation operations) accordingly.   

* Why CoAP Pings?

CoAP Pings naturally achieve (1). These messages are interesting because they have small message sizes. CoAP Ping uses Empty Confirmable message (no request) and the response is a Reset message (which is empty).

CoAP Ping can be used ** as-is ** during idle time (no attack). Multiple Ping failures and Ping exchange in both directions is required only during the attack time to really detect if the peer is dead or alive (because of (3)).

This is aligned with (2).

* Why not DOTS-specific messages?

If we have to define such message, it needs to be the smallest footprint as practical. An Empty message is inexpensive, nevertheless empty Non-confirmable messages are not allowed (See rfc7252#section-4.3) and sending the Reset message is optional. 

Furthermore, if heartbeats were non-confirmable that means that we would need to get the application layer to do any recovery work. It is much simpler to make them confirmable and delegate the recovery work to CoAP layer. 

So, even if we did it in the DOTS layer it will be the same as "CoAP ping".

The WG did not see a reason to re-do the same in the application layer. In DOTS, the CoAP ping is initiated by the application (DOTS layer itself) and CoAP layer only handles the retransmissions. The proposed mechanism does not require an update to the CoAP stack other with the assumption that callback handlers are supported to give visibility of when a ping or pong was received by the CoAP layer in the application layer. As such, the current design is pragmatic. 

The DOTS layer has the ** full control required for the intended functionality **.

* Why separating heartbeats parameters from CoAP transmission ones?

We need to allow for a differentiated handling of heartbeats during idle/mitigation times. To that aim, we defined specific heartbeat parameters for each of these times without touching the CoAP connection parameters. All the message transmission parameters including missing-hb-allowed are configurable using the DOTS signal channel (see draft-ietf-dots-signal-channel-35#section-4.5) and these message transmission parameter including the missing-hb-allowed is only used for UDP transport.

One last comment about adjusting CoAP parameter values, we spent in the WG a lot of cycles to discuss this particular point. The conclusion of the WG is that 4 retransmits (that corresponds to the default value of MAX_RETRANSMIT) are not sufficient to detect the session is disconnected during volumetric 
DDoS attack saturating the incoming link, and which will lead to high packet loss. This is why multiple heartbeat losses are required to detect the session is defunct.

Unless there is a flaw with the current design (fail to achieve the intended functionality, implementation complexity, side effects, ...), we don't see a reason to change the current approach. 

Thank you. 

Cheers,
Jon/Tiru/Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : mardi 16 juillet 2019 17:41
> À : Konda, Tirumaleswar Reddy
> Cc : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; draft-ietf-dots-signal-
> [e-mail]; [e-mail]; [e-mail]; The IESG;
> [e-mail]; Benjamin Kaduk
> Objet : Re: [Dots] Behavior when keep-alives fail (RE: Mirja Kühlewind's
> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
> 
> Hi Tiru,
> 
> Thanks for the updates. I think there is one remaining issue on the use of
> ping/heart-beats (see also my other message). However, I believe all other
> discuss points have been addressed now. Thanks for that!
> 
> Mirja
> 
>