Subject: Re: [Dots] Coding and Interoperability Challenges

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 1 Oct 2017 12:47:41 +0000

> -----Original Message-----
> From: Jon Shallow [mailto:[email-masked]]
> Sent: Saturday, September 30, 2017 6:24 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: RE: [Dots] Coding and Interoperability Challenges
> 
> Hi Tiru,
> 
> I will look at the updated draft later.  However, in response to some of your
> comments
> 
> >> If the DOTS client receives 3 responses of 4.22 in a row on the same
> session,
> >> the DOTS client MUST stop trying to configure the session to prevent
> >> a continuous retry loop."
> 
> > I don't see why the client would pick unacceptable values after
> > getting
> the min/max parameters from the DOTS server.
> 
> I just wanted to prevent a continuous retry in case there is some buggy
> software out there / faulty hardware based on certain bit patterns etc.
> This is the only place in the spec where the client retries sending again when
> a failure message is returned from the server.

The server has to defend itself from attackers and compromised DOTS clients, it can return 4.29 (Too many requests).

> 
> >> "heartbeat-refresh": {"MinValue": 2, "MaxValue" : 60},
> >> heartbeat-refresh:   Heartbeat refresh rate in seconds.  This is an
> optional
> >> attribute.
> 
> > Added heartbeat-interval (e.g. {"CurrentValue": 90, "MinValue": 60,
> "MaxValue" : 240}).
> 
> A lot of firewalls I have worked with in the past have a default of 30 sec for
> UDP session timeouts.  Therefore the minimum value should be less than
> 30 - say 10 or 15 secs to prevent firewall session expiry.

The Min/Max values are examples, the draft only recommends default values. Further, 10 to 15 seconds is too small in a network congested due to volumetric DDoS attacks. If default transmission parameters defined in RFC7252 are used then the maximum transmission span for a single "CoAP ping" confirmable message itself is 91 seconds (see MAX-TRANSMIT-SPAN in https://tools.ietf.org/html/rfc7252#section-4.8.2). The firewall I had worked on had a default timeout of 120 seconds for UDP protocol (with minimum duration of 60 seconds), even https://tools.ietf.org/html/rfc4787 mandates that NAT UDP mapping timer must not expire in less than two minutes.

-Tiru

> Regards
> Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sun, 1 Oct 2017 16:52:37 +0100

Hi Tiru,

Thanks for the responses

>> 
>> I just wanted to prevent a continuous retry in case there is some 
>> buggy software out there / faulty hardware based on certain bit patterns
etc.
>> This is the only place in the spec where the client retries sending 
>> again when a failure message is returned from the server.

> The server has to defend itself from attackers and compromised DOTS
clients, it can return 4.29 (Too many requests).

Good point - I will make sure that that kind of defensive logic is in the
appropriate places in the DOTS server.

>> 
>> A lot of firewalls I have worked with in the past have a default of 30 
>> sec for UDP session timeouts.  Therefore the minimum value should be 
>> less than

> The Min/Max values are examples, the draft only recommends default values.
Further, 10 to 15  > seconds is too small in a network congested due to
volumetric DDoS attacks. If default
> transmission parameters defined in RFC7252 are used then the maximum
transmission span for a
> single "CoAP ping" confirmable message itself is 91 seconds (see
MAX-TRANSMIT-SPAN in 
> https://tools.ietf.org/html/rfc7252#section-4.8.2). The firewall I had
worked on had a default
> timeout of 120 seconds for UDP protocol (with minimum duration of 60
seconds), even 
> https://tools.ietf.org/html/rfc4787 mandates that NAT UDP mapping timer
must not expire in
> less than two minutes.

I guess I am showing my age - I did not know about RFC4787 which came out
some 17 years after I started work with firewalls!

Regards

Jon