[Dots] 2-way heartbeats RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

[<[e-mail]>]

Mirja, 

Your initial DISCUSS point was: 

(1) "heartbeat should only be send in one direction (as the
Other end will send an ack)"

We clarified that we need both HBs because there are cases where the DOTS server needs to determine if the incoming link to the DOTS client is saturated (due to an ongoing DDoS attack). It can conclude so because it receives HBs from the client but no replies to its own HBs. The server uses that information to tweak its mitigation strategy (in case a mitigation is already in place). It also can conclude that the client didn't detected an attack.

To which you suggested the following:

(2) "what you described implies that the server should send the ping and client sends the pong. This is fine."

We clarified that pings from the server may be discarded by on path NATs/FWs. The HBs from the client are also meant to maintain a state alive in those functions.

We also reminded that 8085 recommends "to ** independently ** check both directions" for long-lived association. We are adhering to that recommendation. 

Can you please let us know how we can achieve the above with one single HB direction? Thank you.  

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind [mailto:[e-mail]]
> Envoyé : mardi 2 juillet 2019 16:00
> À : 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: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> 
> >
> >>
> >>>
> >>>>
> >>>>> 6) Section 4.7: "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
> >>>>> "DOTS servers MAY trigger their heartbeat requests immediately after
> >>>>>  receiving heartbeat probes from peer DOTS clients."
> >>>>> Actually heartbeat should only be send in one direction (as the
> other
> >>>>> end will send an ack) and the protocol should clearly specify which
> >>>>> endpoint is responsible for triggering the ping.
> >>>>
> >>>> I'm not sure I see resolution on this; do the authors still need to
> >> answer why
> >>>> the "pong" reply cannot serve as a reverse-path heartbeat?
> >>>
> >>> If the DOTS client domain is subjected to volumetric DDoS attack and
> the
> >> incoming link is saturated, the pong response from the server will not
> >> reach the client. DOTS server gets traffic from the client but receives
> no
> >> responses to its ping requests indicating the client has not detected
> the
> >> attack or, if an attack mitigation is in progress, it implies the
> applied
> >> DDoS mitigation actions are not yet effective to handle the DDoS attack
> >> volume.
> >>
> >> Yes, I understand what heartbeat are used for. However, what you
> described
> >> implies that the server should send the ping and client sends the pong.
> >> This is fine.
> >
> > [Med] Choosing the other way around may be problematic because of
> NAT/FWs. This is why the heartbeats from the server will fly right after
> the one from the client so that we can use the warm mappings. Having both
> directions allows to accommodate the scenario described by Tiru.
> >
> > As you know, RFC4787 mandates the NAT outbound refresh behavior (packets
> go from the internal side of the NAT to the external side of the NAT to
> refresh the timer value) but not the NAT inbound refresh behavior.
> >
> > The text however seems to imply that both server and client
> >> test their have connection separately and both send pings and pongs.
> That
> >> doesn’t seem to be need.
> >
> > [Med] In addition to the clarification above, we have also added a
> pointer to this part of 8085:
> >
> > ==
> >   A UDP application with a long-lived association between the sender
> >   and receiver, ought to be designed so that the sender periodically
> >   checks that the receiver still wants ("consents") to receive traffic
> >   and need to be designed to stop if there is no explicit confirmation
> >   of this [RFC7675].  Applications that require communications in two
> >   directions to implement protocol functions (such as reliability or
> >   congestion control) will need to independently check both directions
> >                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >   of communication, and may have to exchange keep-alive messages to
> >   ^^^^^^^^^^^^^^^^
> >   traverse middleboxes (see Section 3.5).
> > ==
> 
> Yes, you use keep-alive messages here. A ping on one direction and a
> pong/ack as reply in the direction. I’m not we are maybe talking past each
> other… I think the following is sufficient
> 
> 
> Client ping —————>
>             <———— server pong
> 
> 
> While what I read from the document is that you do this:
> 
> Client ping —————>
>             <———— server pong
> 
>             <———— server ping
> Client pong —————>
> 
> If that is not what your are doing you need to clarify this in the
> document.
> 
> If you actually want to have two different ping/pong’s you need to explain
> me why you need both.