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

[<[e-mail]>]

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.

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