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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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