Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

[<[e-mail]>]

Re-,

> Yes, but 30 seconds of timeout looks too aggressive. I suggest we use 2
> minutes (UDP uses 105 seconds) of heartbeat-interval.

30 seconds is recommended value for UDP (as this is our favorite transport).

If TCP is used, this falls into the following: 

      DOTS agents may
      negotiate longer heartbeat-interval values to prevent any network
      overload with too frequent keepalives.

Even if we include another recommended value for TCP, I'm afraid it is not possible to reflect this in the YANG module: 

         leaf current-value {
           type uint16;
           units "seconds";
           default "30";
           description
             "Current heartbeat-interval value.

              '0' means that heartbeat mechanism is deactivated.";
         }

Cheers,
Med

> -----Message d'origine-----
> De : Konda, Tirumaleswar Reddy [mailto:[e-mail]]
> Envoyé : lundi 22 juillet 2019 15:27
> À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk'; dots-
> [e-mail]; [e-mail]
> Objet : RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> > -----Original Message-----
> > From: [e-mail]
> > <[e-mail]>
> > Sent: Monday, July 22, 2019 4:32 PM
> > To: Konda, Tirumaleswar Reddy
> > <[e-mail]>; Valery Smyslov
> > <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>; dots-
> > [e-mail]; [e-mail]
> > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> >
> >
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Konda, Tirumaleswar Reddy
> > > [mailto:[e-mail]]
> > > Envoyé : lundi 22 juillet 2019 12:25
> > > À : BOUCADAIR Mohamed TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > dots-
> > > [e-mail]; [e-mail] Objet : RE: [Dots] Mirja's DISCUSS:
> > > Pending Point (AD Help Needed)
> > >
> > > > -----Original Message-----
> > > > From: Dots <[e-mail]> On Behalf Of
> > > > [e-mail]
> > > > Sent: Monday, July 22, 2019 3:16 PM
> > > > To: Konda, Tirumaleswar Reddy
> > > > <[e-mail]>; Valery Smyslov
> > > > <[e-mail]>; 'Benjamin Kaduk' <[e-mail]>; dots-
> > > > [e-mail]; [e-mail]
> > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > > >
> > > > This email originated from outside of the organization. Do not click
> > > links or
> > > > open attachments unless you recognize the sender and know the
> > > > content is safe.
> > > >
> > > > Re-,
> > > >
> > > > Please see inline.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Konda, Tirumaleswar Reddy
> > > > > [mailto:[e-mail]]
> > > > > Envoyé : lundi 22 juillet 2019 10:58 À : BOUCADAIR Mohamed
> > > > > TGI/OLN; Valery Smyslov; 'Benjamin Kaduk';
> > > > dots-
> > > > > [e-mail]; [e-mail] Objet : RE: [Dots] Mirja's DISCUSS:
> > > > > Pending Point (AD Help Needed)
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail]
> > > > > > <[e-mail]>
> > > > > > Sent: Monday, July 22, 2019 12:38 PM
> > > > > > To: Valery Smyslov <[e-mail]>; Konda, Tirumaleswar
> > > > > > Reddy <[e-mail]>; 'Benjamin
> > Kaduk'
> > > > > > <[e-mail]>; [e-mail]; [e-mail]
> > > > > > Subject: RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help
> > > > > > Needed)
> > > > > >
> > > > > > This email originated from outside of the organization. Do not
> > > > > > click
> > > > > links or
> > > > > > open attachments unless you recognize the sender and know the
> > > > > > content is safe.
> > > > > >
> > > > > > Hi Valery,
> > > > > >
> > > > > > Actually, we have clarified that (see for example,
> > > > > > https://mailarchive.ietf.org/arch/msg/dots/21wgxXEy-
> > > > > > vWecFZK9BeviBFMdnA)
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > > We can add this NEW text to Section 4.5 If this would help:
> > > > > >
> > > > > >    When the DOTS signal channel is established over a reliable
> > > transport
> > > > > >    (e.g., TCP), there is no need for the reliability mechanisms
> > > provided
> > > > > >    by CoAP over UDP since the underlying TCP connection provides
> > > > > >    retransmissions and deduplication [RFC8323].  As such, the
> > > > > >    transmission-related parameters (missing-hb-allowed and
> > > acceptable
> > > > > >    signal loss ratio) are negotiated only for DOTS over
> unreliable
> > > > > >    transports.
> > > > >
> > > > > I propose to slightly modify the text as follows:
> > > > >
> > > > >     When the DOTS signal channel is established over a reliable
> > > transport
> > > > >     (e.g., TCP), there is no need for the reliability mechanisms
> > > provided
> > > > >     by CoAP over UDP since the underlying TCP connection provides
> > > > >     retransmissions and deduplication [RFC8323].  As a reminder,
> > > > > Confirmable  and Non-confirmable message types are specific to
> > > > > unreliable transport, and
> > > > >     are not supported in CoAP over TCP.  As such, the message
> > > > >     transmission-related parameters (missing heartbeats allowed
> > > > > and acceptable
> > > > >     signal loss ratio) are negotiated only for DOTS over
> unreliable
> > > > >     transports.
> > > >
> > > > [Med] OK. I went with the following:
> > > >
> > > >    When the DOTS signal channel is established over a reliable
> transport
> > > >    (e.g., TCP), there is no need for the reliability mechanisms
> provided
> > > >    by CoAP over UDP since the underlying TCP connection provides
> > > >    retransmissions and deduplication [RFC8323].  As a reminder, CoAP
> > > >    over reliable transports does not support Confirmable or Non-
> > > >    confirmable message types.  As such, the transmission-related
> > > >    parameters (missing-hb-allowed and acceptable signal loss ratio)
> are
> > > >    negotiated only for DOTS over unreliable transports.
> > >
> > > Looks good.
> > >
> > > >
> > > >
> > > > If the CoAP ping us unacknowledged for a specific duration
> > > > > (i.e. TCP user timeout expires), TCP will forcefully close the
> > > > > connection, and the DOTS client will have
> > > > >      to re-establish the TCP connection.
> > > > >
> > > >
> > > > [Med] and made this change:
> > > >
> > > > OLD:
> > > >    In DOTS over TCP, heartbeat messages MUST be exchanged between
> > the
> > > >    DOTS agents using the Ping and Pong messages specified in Section
> 5.4
> > > >    of [RFC8323].  That is, the DOTS agent sends a Ping message and
> the
> > > >    peer DOTS agent would respond by sending a single Pong message.
> > > >
> > > > NEW:
> > > >    In DOTS over TCP, heartbeat messages MUST be exchanged between
> > the
> > > >    DOTS agents using the Ping and Pong messages specified in Section
> 5.4
> > > >    of [RFC8323].  That is, the DOTS agent sends a Ping message and
> the
> > > >    peer DOTS agent would respond by sending a single Pong message.
> The
> > > >    sender of a Ping message has to allow up to 'heartbeat-interval'
> > > >    seconds when waiting for a Pong reply.
> > >
> > > The last line does not look correct, the default heartbeat-interval is
> > > 30 seconds and the default user timeout is 5 minutes (TCP connection
> > > will be closed only after 5 minutes, see
> > > https://tools.ietf.org/html/rfc5482), 30 seconds looks aggressive to
> > > determine the connection is lost.
> > >
> >
> > [Med] This is a configurable parameter. When TCP is used, the server
> will
> > return the appropriate value to use.
> 
> Yes, but 30 seconds of timeout looks too aggressive. I suggest we use 2
> minutes (UDP uses 105 seconds) of heartbeat-interval.
> 
> Cheers,
> -Tiru
> 
> >
> > > Cheers,
> > > -Tiru
> > >
> > > >    When a failure is detected by
> > > >    a DOTS client, it proceeds with the session recovery following
> the
> > > >    same approach as the one used for unreliable transports.
> > > >
> > > > Better?
> > > >
> > > > > Cheers,
> > > > > -Tiru
> > > > >
> > > > > >
> > > > > > Cheers,
> > > > > > Med
> > > > > >
> > > > > > > -----Message d'origine-----
> > > > > > > De : Valery Smyslov [mailto:[e-mail]] Envoyé :
> > > > > > > samedi 20 juillet 2019 04:26 À : 'Konda, Tirumaleswar Reddy';
> > > > > > > BOUCADAIR Mohamed TGI/OLN; 'Benjamin Kaduk';
> > > > > > > [e-mail];
> > > > [e-mail] Objet :
> > > > > > > RE: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> > > > > > >
> > > > > > > Hi Tiru,
> > > > > > >
> > > > > > > thank you for clarification regarding TCP. It seems the this
> > > > > > > clarification somehow escaped from the discussion with Mirja
> > > > > > > (at least I cannot recall it was mentioned).
> > > > > > >
> > > > > > > Regards,
> > > > > > > Valery.
> > > > > > >
> > > > > > > > Hi Valery,
> > > > > > > >
> > > > > > > > The message transmission parameters including
> > > > > > > > missing-hb-allowed is only
> > > > > > > for
> > > > > > > > UDP transport (not for TCP). For the UDP, she is suggesting
> > > > > > > > us to go
> > > > > > > with a
> > > > > > > > mechanism that checks both side of the connectivity using
> > > > > > > > non-
> > > > > > > confirmable
> > > > > > > > message with ping and pong at the application layer instead
> > > > > > > > of relying
> > > > > > > on the
> > > > > > > > CoAP ping/pong.
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > -Tiru
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Dots <[e-mail]> On Behalf Of Valery
> > > > > > > > > Smyslov
> > > > > > > > > Sent: Friday, July 19, 2019 5:13 PM
> > > > > > > > > To: [e-mail]; 'Benjamin Kaduk'
> > > > > > > > > <[e-mail]>; [e-mail]; [e-mail]
> > > > > > > > > Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD
> > > > > > > > > Help
> > > > > > > > > Needed)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Med,
> > > > > > > > >
> > > > > > > > > I believe Mirja's main point was that if you use liveness
> > > > > > > > > check mechanism in the transport layer, then if it reports
> > > > > > > > > that liveness check fails, then it _also_ closes the
> > > > > > > > > transport
> > > session.
> > > > > > > > >
> > > > > > > > > Quotes from her emails:
> > > > > > > > > "Yes, as Coap Ping is used, the agent should not only
> > > > > > > > > conclude that the DOTS signal session is disconnected but
> > > > > > > > > also the Coap session and not send any further Coap
> messages
> > anymore."
> > > > > > > > >
> > > > > > > > > and
> > > > > > > > >
> > > > > > > > > "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 close
> > > > > > > > > the
> > > connection."
> > > > > > > > >
> > > > > > > > > I'm not familiar with CoAP, but I suspect she's right
> > > > > > > > > about TCP - if TCP layer itself doesn't receive ACK for
> > > > > > > > > the sent data after several retransmissions, the
> connection is
> > closed.
> > > > > > > > >
> > > > > > > > > As far as I understand the current draft allows underlying
> > > > > > > > > liveness check to fail and has a parameter to restart this
> > > > > > > > > check several times if this happens. It seems that a new
> > > > > > > > > transport session will be created in this case (at least
> > > > > > > > > if TCP is used). In my reading of the draft this seems not
> > > > > > > > > been assumed, it is assumed that the session remains the
> > > > > > > > > same. So, I think that main Mirja's concern is that it
> > > > > > > > > won't work
> > > > > > > (at least
> > > > > > > > with TCP).
> > > > > > > > >
> > > > > > > > > I didn't participate in the WG discussion on this, so I
> > > > > > > > > don't know what was discussed regarding this issue. If it
> > > > > > > > > was discussed and the WG has come to conclusion that this
> > > > > > > > > is not an issue, then I believe more text should be added
> > > > > > > > > to the draft so, that people like Mirja, who didn't
> > > > > > > > > participate in the discussion, don't have any concerns
> > > > > > > > > while
> > > > > > > reading
> > > > > > > > the draft.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Valery.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: [e-mail]
> > > > > > > > > > <[e-mail]>
> > > > > > > > > > Sent: Friday, July 19, 2019 9:57 AM
> > > > > > > > > > To: Benjamin Kaduk ([e-mail]) <[e-mail]>;
> > > > > > > > > > dots- [e-mail]; [e-mail]
> > > > > > > > > > Subject: Mirja's DISCUSS: Pending Point (AD Help Needed)
> > > > > > > > > >
> > > > > > > > > > Hi Ben, chairs, all,
> > > > > > > > > >
> > > > > > > > > > (restricting the discussion to the AD/chairs/WG)
> > > > > > > > > >
> > > > > > > > > > * Status:
> > > > > > > > > >
> > > > > > > > > > All DISCUSS points from Mirja's review were fixed,
> > > > > > > > > > except the one discussed in this message.
> > > > > > > > > >
> > > > > > > > > > * Pending Point:
> > > > > > > > > >
> > > > > > > > > > Rather than going into much details, I consider the
> > > > > > > > > > following as the summary of the remaining DISCUSS point
> > > > > > > > > > from
> > > > Mirja:
> > > > > > > > > >
> > > > > > > > > > > I believe there are flaws in the design. First it’s a
> > > > > > > > > > > layer violation, but if more an idealistic concern but
> > > > > > > > > > > usually designing in layers is a good approach. But
> > > > > > > > > > > more importantly, you end up with un-frequent messages
> > > > > > > > > > > which may still terminate the connection at some
> > > > > > > > > > > point, while what you want is to simply send messages
> > > > > > > > > > > frequently in an unreliable fashion but a low rate
> > > > > > > > > > > until the
> > > > > > > attack is over.
> > > > > > > > > >
> > > > > > > > > > * Discussion:
> > > > > > > > > >
> > > > > > > > > > (1) First of all, let's remind that RFC7252 does not
> > > > > > > > > > define how CoAP ping must be used. It does only say:
> > > > > > > > > >
> > > > > > > > > > ==
> > > > > > > > > >       Provoking a Reset
> > > > > > > > > >       message (e.g., by sending an Empty Confirmable
> > > > > > > > > > message) is
> > > > > > > also
> > > > > > > > > >       useful as an inexpensive check of the liveness of
> > > > > > > > > > an
> > > > > endpoint
> > > > > > > > > >       ("CoAP ping").
> > > > > > > > > > ==
> > > > > > > > > >
> > > > > > > > > > How the liveness is assessed is left to applications.
> > > > > > > > > > So, there is
> > > > > > > > > > ** no layer violation **.
> > > > > > > > > >
> > > > > > > > > > (2) What we need isn't (text from Mirja):
> > > > > > > > > >
> > > > > > > > > > > to simply send messages frequently in an unreliable
> > > > > > > > > > > fashion but a low rate until the attack is over "
> > > > > > > > > >
> > > > > > > > > > It is actually the other way around. The spec says:
> > > > > > > > > >
> > > > > > > > > >   "... This is particularly useful for DOTS
> > > > > > > > > >    servers that might want to reduce heartbeat frequency
> > > > > > > > > > or
> > > > > cease
> > > > > > > > > >    heartbeat exchanges when an active DOTS client has
> > > > > > > > > > not
> > > > > requested
> > > > > > > > > >    mitigation."
> > > > > > > > > >
> > > > > > > > > > What we want can be formalized as:
> > > > > > > > > >  - Taking into account DDoS traffic conditions, a check
> > > > > > > > > > to assess the liveness of the peer DOTS agent + maintain
> > > > > > > > > > NAT/FW state on on-path
> > > > > > > > > devices.
> > > > > > > > > >
> > > > > > > > > > An much more elaborated version is documented in SIG-004
> > > > > > > > > > of RFC
> > > > > > > 8612.
> > > > > > > > > >
> > > > > > > > > > * My analysis:
> > > > > > > > > >
> > > > > > > > > > - The intended functionality is naturally provided by
> > > > > > > > > > existing CoAP
> > > > > > > > > messages.
> > > > > > > > > > - Informed WG decision: The WG spent a lot of cycles
> > > > > > > > > > when specifying the current behavior to be meet the
> > > > > > > > > > requirements set
> > > > > in
> > > > > > RFC8612.
> > > > > > > > > > - Why not an alternative design: We can always define
> > > > > > > > > > messages with duplicated functionality, but that is not
> > > > > > > > > > a good design approach especially when there is no
> > > > > > > > > > evident
> > > benefit.
> > > > > > > > > > - The specification is not broken: it was implemented
> > > > > > > > > > and
> > > > > tested.
> > > > > > > > > >
> > > > > > > > > > And a logistic comment: this issue fits IMHO under the
> > > > > > > > > > non-discuss criteria in
> > > > > > > > > > https://www.ietf.org/blog/discuss-criteria-iesg-review/#
> > > > > > > > > > stan
> > > > > > > > > > d-
> > > > > > > > > undisc.
> > > > > > > > > >
> > > > > > > > > > * What's Next?
> > > > > > > > > >
> > > > > > > > > > As an editor, I don't think a change is needed but I'd
> > > > > > > > > > like to hear from Ben, chairs, and the WG.
> > > > > > > > > >
> > > > > > > > > > Please share your thoughts and whether you
> > > > > > > > > > agree/disagree with the above analysis.
> > > > > > > > > >
> > > > > > > > > > Cheers,
> > > > > > > > > > Med
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Dots mailing list
> > > > > > > > > [e-mail]
> > > > > > > > > https://www.ietf.org/mailman/listinfo/dots
> > > >
> > > > _______________________________________________
> > > > Dots mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dots