Subject: [Dots] Signal Channel -23 MTU and Fragmentation

From: "Jon Shallow" <[email-masked]>
Date: Fri, 24 Aug 2018 09:38:42 +0100

Hi There,

7.3.  MTU and Fragmentation

Should we not also allow the use of RFC7959 - Block-Wise Transfers in the
Constrained Application Protocol?

The particular use case I am thinking of is "GET
/.well-known/dots/v1/mitigate/cuid=xxx" to retrieve all DOTS mitigation
requests (Figure 10) when the response will not fit into a single packet due
to the number of currently defined mitigations that also may have multiple
target-* definitions.

It also removes the restriction on the PUT size, but I would still recommend
that the PUT should only fit into a single packet due to the potential of
high network losses.

Even if the PUT fits into a single packet, a  GET response with additional
status fields could exceed the packet size.

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 24 Aug 2018 09:05:57 +0000

Hi Jon,

Block-Wise Transfer is only suitable for Confirmable messages. As you already know, In order to handle congestion during DDoS attacks, mitigation request/responses are marked as Non-confirmable messages.
I don’t see a problem using Block-Wise Transfer with “GET” but only during peacetime and marked as Confirmable request/response.

Cheers,
-Tiru

From: Dots <[email-masked]> On Behalf Of Jon Shallow
Sent: Friday, August 24, 2018 2:09 PM
To: [email-masked]
Subject: [Dots] Signal Channel -23 MTU and Fragmentation

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Hi There,

Should we not also allow the use of RFC7959 – Block-Wise Transfers in the Constrained Application Protocol?

The particular use case I am thinking of is “GET /.well-known/dots/v1/mitigate/cuid=xxx” to retrieve all DOTS mitigation requests (Figure 10) when the response will not fit into a single packet due to the number of currently defined mitigations that also may have multiple target-* definitions.

It also removes the restriction on the PUT size, but I would still recommend that the PUT should only fit into a single packet due to the potential of high network losses.

Even if the PUT fits into a single packet, a  GET response with additional status fields could exceed the packet size.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 24 Aug 2018 10:48:46 +0100

Hi Tiru,

Agreed that RFC7959 only says that non-confirmable may not be useful because of the escalation of non-delivery probability.  It does not (that  I can find) recommend only confirmable messages.  Non-confirmable is supported for “2.8  Combining Block2 with Multicast”.

  “The present

   specification minimizes the constraints it adds to those base

   exchanges; however, not all variants of using CoAP are very useful

   inside a block-wise transfer (e.g., using Non-confirmable requests

   within block-wise transfers outside the use case of Section 2.8 would

   escalate the overall non-delivery probability).”

As the DOTS client “anticipates” that there might be data loss and effectively does the confirmable recovery by either requesting the information again, or “observe” sends another response, I do not see why the use of Block-Wise should be restricted to peace-time only (but should always be using non-confirmable messages).

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 24 August 2018 10:06
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

Hi Jon,

Cheers,

-Tiru

  _____  

Hi There,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 24 Aug 2018 10:00:10 +0000

https://tools.ietf.org/html/rfc7959#section-2.8 uses NUM=0 for multicast messages to restrict the size of the request and response and multi-cast messages must be non-confirmable (see RFC7252).

-Tiru

From: Jon Shallow <[email-masked]>
Sent: Friday, August 24, 2018 3:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel -23 MTU and Fragmentation

  “The present

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 24 August 2018 10:06
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

Hi Jon,

Cheers,
-Tiru

From: Dots <[email-masked]<mailto:[email-masked]>> On Behalf Of Jon Shallow
Sent: Friday, August 24, 2018 2:09 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dots] Signal Channel -23 MTU and Fragmentation

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 24 Aug 2018 11:54:23 +0100

Hi Tiru,

Agreed BLOCK2 NUM=0 is for the initial multicast request (If the client sets it), or set in the initial response if the data is too large, and then NUM=1 etc. if the client wants further blocks using unicast requests.

If the multicast server (well, any server sending a response) decides that the response will not fit into a single packet, even if the GET does not use BLOCK2, then the server can send part the first part of the response with NUM=0 in the BLOCK2 option and it is then up to the client to request further if it wants to.

As DOTS is (correctly) specifying these requests and responses as non-confirmable, I do not see why the DOTS server cannot elect to send back a non-confirmable response with NUM=0 if the GET response does not fit into a packet.  If the DOTS client cannot re-assemble all the “payloads” into a “body” (RFC7959 2. Block-Wise definitions), that is no real difference to a single packet containing the entire “body” getting lost.

If we do not allow this, then the signal draft certainly does not specify what to do  - partial data will mess up CBOR in the DOTS client. 

The DOTS client never should need to use BLOCK2 in the initial request, it is up to the DOTS server to use BLOCK2 in a response if the “body” will not fit into a single packet.

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 24 August 2018 11:00
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

-Tiru

  _____  

Hi Tiru,

  “The present

Regards

Jon

Hi Jon,

Cheers,

-Tiru

  _____  

Hi There,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 25 Aug 2018 13:50:26 +0000

Hi Jon,

Agree with your analysis of using Block-wise transfer, proposed NEW text:

The DOTS client can use Block-wise transfer to get the list of all its mitigations maintained by a DOTS server, it can send Block2 Option in a GET request with NUM = 0 to aid in limiting the size of the response.
If the representation of all the active mitigation requests associated with the DOTS client does not fit within a single datagram, the DOTS server MUST use the Block2 Option with NUM = 0 in the GET response. The Size2 Option may be conveyed in the response to indicate the total size of the resource representation. The DOTS client retrieves the rest of the representation by sending additional GET requests with Block2 Options
containing NUM values greater than zero. The DOTS client MUST adhere to the block size preferences indicated by the DOTS server in the response.

Cheers,
-Tiru

From: Jon Shallow <[email-masked]>
Sent: Friday, August 24, 2018 4:24 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel -23 MTU and Fragmentation

Regards

Jon

-Tiru

From: Jon Shallow <[email-masked]<mailto:[email-masked]>>
Sent: Friday, August 24, 2018 3:19 PM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Dots] Signal Channel -23 MTU and Fragmentation

  “The present

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Sun, 26 Aug 2018 18:08:30 +0100

Hi Tiru,

Thanks for the new text.  I think it also needs to refers to RFC7959.   I would like to see additional text as well:-

The DOTS server MUST include the ETag Option in the response if Block2 is being used so that the DOTS client can re-assemble the response correctly.  The DOTS client SHOULD include the same ETag entity in the GET requests that are not for NUM = 0 when getting the remainder of the response.  To minimize the need to use the Block2 option in the response (and hence the need for the DOTS sever to cache the response) that contains changing information (i.e. config false definitions), the DOTS client SHOULD use the c=c Query for getting the configuration data and SHOULD use the c=n Query for getting the statistical information and not the (implied if not defined) c=a Query on the GET to get everything.

(RFC7959 only says SHOULD include ETag, however, we are working with non-confirmable messages here)

(Figure 10 should be updated to use c=c)

(Normative references etc. updated with RFC7959)

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 25 August 2018 14:50
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

Hi Jon,

Cheers,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

  _____  

Hi Tiru,

  “The present

Regards

Jon

Hi Jon,

Cheers,

-Tiru

  _____  

Hi There,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 27 Aug 2018 12:57:22 +0000

Hi Jon,

Please see inline [TR]

From: Dots <[email-masked]> On Behalf Of Jon Shallow
Sent: Sunday, August 26, 2018 10:39 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

Thanks for the new text.  I think it also needs to refers to RFC7959.

[TR] Yup.

I would like to see additional text as well:-

The DOTS server MUST include the ETag Option in the response if Block2 is being used so that the DOTS client can re-assemble the response correctly.  The DOTS client SHOULD include the same ETag entity in the GET requests that are not for NUM = 0 when getting the remainder of the response.

[TR] ETag option is only required for dynamically changing resources, in our case “c=n” or “c=a” value (see the second paragraph in page 12 of RFC7959).

To minimize the need to use the Block2 option in the response (and hence the need for the DOTS sever to cache the response) that contains changing information (i.e. config false definitions), the DOTS client SHOULD use the c=c Query for getting the configuration data and SHOULD use the c=n Query for getting the statistical information and not the (implied if not defined) c=a Query on the GET to get everything.

[TR] I-D.ietf-core-comi is non-normative and the DOTS agents may or may not support the draft. We can say the following instead:
If the DOTS client supports the optional filtering capability, it SHOULD use “c=n” or “c=c” values when the DDoS attack is active to limit the size of the response.

[TR] DOTS client can use c=c (e.g. during peace time or the DDoS attack not congesting its incoming link but targeting a resource in the client domain).

[TR] Yes.

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon

-Tiru

  “The present

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Aug 2018 10:30:44 +0100

Hi Tiru,

See inline Jon>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 August 2018 13:57
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

Hi Jon,

Please see inline [TR]

  _____  

Hi Tiru,

[TR] Yup. 

Jon> OK.  But we do still need to state that it is required for dynamically changing data.

Jon> I think I prefer (because of the ETag for c=n):-

If the DOTS client supports the optional filtering capability, it SHOULD use “c=n” query (to get back only the dynamically changing data) or “c=c” query (to get back the static configuration values) when the DDoS attack is active to limit the size of the response.

Jon> Figure 10 refers to getting all the mitigations (as opposed to Figure 11 asking for a single mitigation), to reduce output it makes sense to me to use c=c for Figure 10.

~Jon

[TR] Yes. 

-Tiru

Regards

Jon

Hi Jon,

Cheers,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

  _____  

Hi Tiru,

  “The present

Regards

Jon

Hi Jon,

Cheers,

-Tiru

  _____  

Hi There,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Aug 2018 14:50:46 +0000

Hi Jon,

Please see inline [TR2]

From: Jon Shallow <[email-masked]>
Sent: Tuesday, August 28, 2018 3:01 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel -23 MTU and Fragmentation

See inline Jon>

Regards

Jon

Hi Jon,

Please see inline [TR]

[TR] Yup.

[TR2] Yes, we can update your proposed line as follows:
If the DOTS server uses the Block2 Option in the GET response and the response is for a dynamically changing resource (e.g. “c=n” query), the DOTS server MUST include the ETag Option in the response. The DOTS client MUST include the same Etag value in subsequent GET requests to retrieve the rest of the representation.

[TR2] Looks good.

[TR2] They  are only examples ☺

Cheers,
-Tiru

~Jon

[TR] Yes.

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon

-Tiru

  “The present

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 28 Aug 2018 16:05:20 +0100

Hi Tiru,

With a small change – see inline Jon2>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 28 August 2018 15:51
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] Signal Channel -23 MTU and Fragmentation

Hi Jon,

Please see inline [TR2]

  _____  

Hi Tiru,

See inline Jon>

Regards

Jon

Hi Jon,

Please see inline [TR]

  _____  

Hi Tiru,

[TR] Yup. 

Jon2> If the DOTS server uses the Block2 Option in the GET response and the response is for a dynamically changing resource (e.g. “c=n” or “c=a”  query), the DOTS server MUST include the ETag Option in the response. The DOTS client MUST include the same ETag value in subsequent GET requests to retrieve the rest of the representation

Jon2> (as “c=a” also contains dynamic data)

[TR2] Looks good.

[TR2] They  are only examples J

Jon2> OK.

~Jon2

Cheers,

-Tiru

~Jon

[TR] Yes. 

-Tiru

Regards

Jon

Hi Jon,

Cheers,

-Tiru

  _____  

Hi Tiru,

Regards

Jon

-Tiru

  _____  

Hi Tiru,

  “The present

Regards

Jon

Hi Jon,

Cheers,

-Tiru

  _____  

Hi There,

Regards

Jon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Aug 2018 15:15:04 +0000

Looks good. This issue can be closed.

Thanks and Regards,
-Tiru

From: Jon Shallow <[email-masked]>
Sent: Tuesday, August 28, 2018 8:35 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: [Dots] Signal Channel -23 MTU and Fragmentation

Regards

Jon

Hi Jon,

Please see inline [TR2]

See inline Jon>

Regards

Jon

Hi Jon,

Please see inline [TR]

[TR] Yup.

[TR2] Looks good.

Cheers,
-Tiru

~Jon

[TR] Yes.

-Tiru

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon

-Tiru

  “The present

Regards

Jon

Hi Jon,

Cheers,
-Tiru

Regards

Jon