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

Hi Med,

I agree with all your responses except the alternate design is a duplicate functionality. The alternate design proposed by her to use non-confirmable message with ping and pong at the application layer itself will not work in the first place.
The client can perform application level ping/pong (e.g. GET /heartbeat) but the server cannot perform application level ping/ping. The server cannot send non-confirmable requests or empty messages to the client.

1) As per RFC7252, client can only send requests, and the server can only send responses.
2) (Section 4.3 in RFC7252) A Non-confirmable message always carries either a request or response and MUST NOT be Empty.  A Non-confirmable message MUST NOT be acknowledged by the recipient.
3) (Section 4.3 in RFC7252) Rejecting a Non-confirmable message MAY involve sending a matching Reset message, and apart from the Reset message the rejected message MUST be silently ignored.

1), 2) and 3) make non-confirmable ping at the application layer from server impossible to use.

Cheers,
-Tiru

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Friday, July 19, 2019 12:27 PM
> To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>; dots-
> chairs@ietf.org; dots@ietf.org
> Subject: [Dots] 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
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots