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

[<[e-mail]>]

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.


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.  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/#stand-
> > > > > 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