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

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

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

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