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

[Mirja Kuehlewind <[e-mail]>]

Hi Med,

See below.

> On 3. Jul 2019, at 12:54, <[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 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
> 
> =====

I believe this is now the same conversation as in the other thread about use of keep-alives in vernal, so let’s keep to there.

Mirja


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