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

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : mercredi 3 juillet 2019 18:50
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]; Konda, Tirumaleswar Reddy;
> [e-mail]; [e-mail]; The IESG; [e-mail];
> Benjamin Kaduk
> Objet : Re: Behavior when keep-alives fail (RE: [Dots] Mirja Kühlewind's
> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> See below.
> 
> > On 3. Jul 2019, at 15:46, <[e-mail]>
> <[e-mail]> wrote:
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Mirja Kuehlewind [mailto:[e-mail]]
> >> Envoyé : mercredi 3 juillet 2019 14:46
> >> À : BOUCADAIR Mohamed TGI/OLN
> >> Cc : Konda, Tirumaleswar Reddy; Benjamin Kaduk; draft-ietf-dots-signal-
> >> [e-mail]; [e-mail]; [e-mail]; The IESG;
> >> [e-mail]
> >> Objet : Re: Behavior when keep-alives fail (RE: [Dots] Mirja
> Kühlewind's
> >> Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and
> COMMENT)
> >>
> >> Hi Med,
> >>
> >> See below.
> >>
> >>> On 3. Jul 2019, at 12:48, <[e-mail]>
> >> <[e-mail]> wrote:
> >>>
> >>> Mirja,
> >>>
> >>>> Actually to my understanding this will not work. Both TCP heartbeat
> and
> >>>> Coap Ping are transmitted reliably. If you don’t receive an ack for
> >> these
> >>>> transmissions you are not able to send any additional messages and
> can
> >>>> only choose the connection.
> >>>
> >>> This behavior is implemented and tested between two implementations.
> The
> >> exact procedure is described in the draft, fwiw:
> >>>
> >>> ==
> >>>  When a Confirmable "CoAP Ping" is sent, and if there is no response,
> >>>  the "CoAP Ping" is retransmitted max-retransmit number of times by
> >>>  the CoAP layer using an initial timeout set to a random duration
> >>>  between ack-timeout and (ack-timeout*ack-random-factor) and
> >>>  exponential back-off between retransmissions.  By choosing the
> >>>  recommended transmission parameters, the "CoAP Ping" will timeout
> >>>  after 45 seconds.  If the DOTS agent does not receive any response
> >>>  from the peer DOTS agent for 'missing-hb-allowed' number of
> >>>  consecutive "CoAP Ping" Confirmable messages, it concludes that the
> >>>  DOTS signal channel session is disconnected.  A DOTS client MUST NOT
> >>>  transmit a "CoAP Ping" while waiting for the previous "CoAP Ping"
> >>>  response from the same DOTS server.
> >>> ==
> >>
> >> First, can you explain why you need 'missing-hb-allowed’?
> >
> > [Med] because we need to make sure this a "real/durable" session
> defunct, not a false positive. For example, this would have implications
> on the server as it may erroneously start automated mitigations (because
> it concludes the session is lost).
> 
> If the reliable ping fails, this means already that there where X number
> of reties which exponential backoff. This really should be an indication
> of a real failure!
> 

[Med] We spent in the WG a lot of cycles and time 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.

Please note that 'missing-hb-allowed' is configurable parameter that can be negotiated with the server. Also, the HB procedure can even be deactivated during idle time.