Re: [Dots] 2-way heartbeats 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 12:13
> À : 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: 2-way heartbeats RE: [Dots] Mirja Kühlewind's Discuss on
> draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
> 
> Hi Med,
> 
> Please see below.
> 
> > On 3. Jul 2019, at 10:50, <[e-mail]>
> <[e-mail]> wrote:
> >
> > 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.
> 
> Here is the point that I don't understand: Let’s assume both ends are
> sending pings but the client does not receive any pings from the server. I
> would also that in this case the client would also not received any pongs
> from the server (in response to their own ping),

[Med] Yes. The draft says:

   In case of a massive DDoS attack that saturates the incoming link(s)
   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 in addition to DOTS messages sent by the DOTS
   client.  

 therefore believe that
> the connection is Brocken, then close the connection and stop sending
> pings, which then will be detected by the server. What do I miss?

[Med] No, we request the client to not close the connection under such conditions but continue to send the HBs to the server so that it can detect the link saturation issue:

====
   In this scenario, DOTS clients MUST behave differently to
   handle message transmission and DOTS signal channel session
   liveliness during link saturation:

      The DOTS client MUST NOT consider the DOTS signal channel session
      terminated even after a maximum 'missing-hb-allowed' threshold is
      reached.  The DOTS client SHOULD keep on using the current DOTS
      signal channel session to send heartbeat requests over it, so that
      the DOTS server knows the DOTS client has not disconnected the
      DOTS signal channel session.

      After the maximum 'missing-hb-allowed' threshold is reached, the
      DOTS client SHOULD try to resume the (D)TLS session.  The DOTS
      client SHOULD send mitigation requests over the current DOTS
      signal channel session, and in parallel, for example, try to
      resume the (D)TLS session or use 0-RTT mode in DTLS 1.3 to
      piggyback the mitigation request in the ClientHello message

=====

> 
> Mirja
> 
> 
> 
> >
> > 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.
> >