Subject: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 07:42:31 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dots-signal-channel-31: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) Port usage (see section 3):
The port request for DOTS was reviewed by the port expert team. Some members of
the team were concerned about the assignment of a separate port number for DOTS
as Coap is used and already has a designated port number. I believe that Coap
is used as a transport in the case and DOTS provides a separate service
compared to what Coap is usually used for, however, it is not clear why DOTS
needs a designated port. Section 3 says that the port can either be
preconfigured or dynamically detected, therefore it is not clear why a fixed
port is needed (see also section 7.1. of RFC7605). In the port review process
the authored argued that a port is needed to differentiate the DOTS service in
the network. However, this is not an endorsed usage for port numbers (see
section 6.2. of RFC7605). Further, I believe assigning a fixed port might
actually add an attack vector for DOTS, either by DDoSing the respective port
at the DOTS server, or any attempt to block DOTS traffic on the network from
the DOTS client to the DOTS server.

2) Section 4.3 says:
"In reference to Figure 4, the DOTS client sends two TCP SYNs and two
   DTLS ClientHello messages at the same time over IPv6 and IPv4."
However, RFC8305 explicitly states that connection attempts SHOULD NOT be made
simultaneously (see sec 5).

Further Figure 4 shows a different order of request as recommended in the text
(text says: "UDP over IPv6, UDP over IPv4, TCP over IPv6, and finally TCP over
IPv4"). Also why are the UDP connection attempts repeated? I guess that is
meant to be the retransmission of the DTLS Hello? However, usually you should
receive the TCP SYNACK before you retransmit or in the best case even before
you start the next connection attempt. Therefore that should be not displayed
like this in the figure or needs further explanation.

3) Why are these statements SHOULDs and not MUSTs (see section 4.4)?
  "DOTS agents SHOULD follow the data transmission guidelines discussed
   in Section 3.1.3 of [RFC8085] and control transmission behavior by
   not sending more than one UDP datagram per round-trip time (RTT) to
   the peer DOTS agent on average."
and
  "If the DOTS client cannot maintain an RTT estimate, it
   SHOULD NOT send more than one Non-confirmable request every 3
   seconds"
as well as in section 4.4.2.1:
  "If the DOTS server cannot maintain an RTT
   estimate, it SHOULD NOT send more than one asynchronous notification
   every 3 seconds"
and again in section 4.4.2.2:
 "The frequency of polling the DOTS server to get the
   mitigation status SHOULD follow the transmission guidelines in
   Section 3.1.3 of [RFC8085].
However, most of the communication pattern used by DOTS rely on a request/reply
pattern and Coap specifies for this case that only one request can be
outstanding at a time (until the reply is received or message is assumed to be
lost) (see section 4.7 and 4.2 of RFC7252) which therefore will be used in this
case. Only migration updates are send without reply, and here a MUST would be
more appropriate.

Please also note that if there can only be one request outstanding (before a
reply is received) it is also not possible that requests are received out of
order (see e.g. 4.4.3: "If UDP is used as transport, CoAP requests may arrive
out-of-order.").

4) draft-ietf-core-hop-limit is used in section 10:
"The presence of DOTS gateways may lead to infinite forwarding loops,
   which is undesirable.  To prevent and detect such loops, this
   document uses the Hop-Limit Option."
This sounds like it should be required (and normative language should be used)
and therefore draft-ietf-core-hop-limit should also be a normative reference.
Also draft-ietf-core-comi should probably another normative reference.

5)Section 4.5.2: You give recommendations for min and max in a note, however,
these values should be specified normatively and in best with a MUST.

6) Section 4.7: "the DOTS
   agent sends a heartbeat over the signal channel to maintain its half
   of the channel.  The DOTS agent similarly expects a heartbeat from
   its peer DOTS agent"
and
"DOTS servers MAY trigger their heartbeat requests immediately after
   receiving heartbeat probes from peer DOTS clients."
Actually heartbeat should only be send in one direction (as the other end will
send an ack) and the protocol should clearly specify which endpoint is
responsible for triggering the ping.

7) sec 7.3:"To avoid DOTS signal message fragmentation and the subsequent
   decreased probability of message delivery, DOTS agents MUST ensure
   that the DTLS record MUST fit within a single datagram."
This should be handled by the DTLS record layer and not by DOTS that works on
top of DTLS (actually Coap), therefor it seems straight to have a normative
requirement here in the DOTS spec. Also note that the calculation provided is
not valid for early data (0-RTT) as the hello messages could be transmitted in
the same datagram.

8) Also sec 7.3: "If the path
   MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
   be assumed."
  Actually this is only true for IPv6. The later note mentions that the
  situation is different from IPV4, however, it should probably be made clear
  from the beginning that 1280 can only be assumed for IPv6.

9) sec 9.6: What's the registration policy for the newly created registries?

10) The document should more explicitly provide more guidance about when a
client should start a session and what should be done (from the client side) if
a session is detected as inactive (other than during migration which is
discussed a bit in 4.7). Is the assumption to have basically permanently an
active session or connect for migration and configuration requests separately
at a time?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) I really recommend to add subsections to section 4.4.1.

2) section 4.4.1: "The lifetime of the
         deactivated mitigation request will be updated to (retry-timer
         + 45 seconds), so the DOTS client can refresh the deactivated
         mitigation request after retry-timer seconds before expiry of
         lifetime and check if the conflict is resolved."
This wording is not fully clear to me. If the life time of a deactivated
request in updated, isn't it active again? And if it is active and another
request is sent, isn't that request rejected again. Can you please further
clarify.

3) section 4.4.2: "lifetime:  The remaining lifetime of the mitigation request,
in
      seconds."
Shouldn't lifetime we rather a timestamp because there is some unknown
transmission delay between the time when the reply is generated and the reply
is received, and as such a lifetime in seconds is quite meaningless for the
client.

4) section 4.4.2.1: " For DOTS server
   application, the message type MUST always be set to Non-confirmable
   even if the underlying COAP library elects a notification to be sent
   in a Confirmable message."
I'm not sure I understand this sentence. Can you please further explain?

5) section 4.4.4: "For example, if there is a financial
   relationship between the DOTS client and server domains, the DOTS
   client stops incurring cost at this point."
I find this sentence a bit problematic given the active-but-terminating period
is defined by server. Wouldn't that mean the server can make me pay for
undefined period of time? Also the max of 300 sec doesn't seem to be a MUST...?

6) In section Section 4.5 you talk about Caop Ping/Pong. However, these terms
are not used in RFC7252. Maybe clarify that empty confirmable  messages are
used and provide a pointer to section 4.2. of RFC7252 right here (instead of
only later).

7) High-level question: Given this doc specifies a YANG model, why are
configuration are not retrieved and changed using NETCONF or RESTCONF?

---

From: <[email-masked]>
Date: Thu, 2 May 2019 10:00:46 +0000

Hi Mirja, 

Thank you for the detailed review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kühlewind via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 1 mai 2019 16:43
> À : The IESG
> Cc : [email-masked]; Liang Xia; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with
> DISCUSS and COMMENT)
> 

[Med] FWIW, below the reasons why we believe that a DOTS port is needed: 

========
(1) 

We are familiar with RFC7605. We confirm that the port we are asking for is:

   o  ... not intended to differentiate
      performance variations within the same service, e.g., high-speed
      versus ordinary speed.  Performance variations can be supported
      within a single assigned port number in context of separate
      pairwise endpoint associations.

The example about differentiated policies is not related to ** performance ** but about being able to deliver a ** basic/normal ** DOTS service. Such DOTS service takes place in attack times...during which links are saturated by nature.

The purpose of DOTS is as such different from the typical usage of CoAP by IoT devices, DOTS signal channel is a new service.

(2)

The WG already considered in previous versions of the specification to use the existing CoAP port number (in compliance with RFC7605), but that design was abandoned by the WG for the reasons documented in the draft. 

(3)

The built-in discovery of services and resources discussed in RFC 7252 requires request and response between the peers, but DOTS protocol is designed to work in congested networks (because of DDoS attack) and the DOTS client during a volumetric DDoS attack may not be able to discover services and resources. 

During a DDoS attack, the incoming link is likely to be saturated and the DOTS client can only send requests but not receive responses from the server. Assigning a DOTS service port avoids the need for resource discovery and additional RTT involved before the mitigation request can be sent to the DOTS server. 

(4)

During a DDoS attack, the traffic from the endpoints and IoT devices can be rate-limited or blocked, but DOTS protocol traffic needs to be allowed. Assigning a DOTS service port helps middleboxes to identify and not rate-limit the DOTS protocol traffic during DDoS attack.

(5)

Given the rise of DDoS attacks targeting CoAP-capable IoT objects (usually, low-cost, not maintained,..), policies to filter "legacy" CoAP messages (at the CPE + access/transit networks) will have implications on the delivery of DOTS service which is a key component for the emergence of protective networking architectures. Having means to differentiate traditional CoAP service from DOTS are important from a deployment standpoint.
====

> simultaneously (see sec 5).

[Med] This one is discussed in another thread. 

> IPv4").

[Med] Actually, the text says:

  "In reference to Figure 4, the DOTS client sends two TCP SYNs and two
   DTLS ClientHello messages at the same time over IPv6 and IPv4. "

We will add annotations to the figure. 

 Also why are the UDP connection attempts repeated? I guess that is
> meant to be the retransmission of the DTLS Hello?

[Med] Yes. 

 However, usually you should
> receive the TCP SYNACK before you retransmit 

[Med] What is retransmitted is DTLS. 

or in the best case even before
> like this in the figure or needs further explanation.

[Med] We will add annotations to the figure. 

>    the peer DOTS agent on average."

[Med] because we are aligned with 8085 which says:

" SHOULD still control their transmission behavior by not
   sending on average more than one UDP datagram per RTT to a
   destination "

>    SHOULD NOT send more than one Non-confirmable request every 3

[Med] because 8085 says:

"Such applications SHOULD NOT send more than one UDP
       datagram every 3 seconds"

>    estimate, it SHOULD NOT send more than one asynchronous notification

[Med] Idem as above.

>    Section 3.1.3 of [RFC8085].

[Med] This is to accommodate the case where a local policy is provided to the DOTS agent. 

> Also draft-ietf-core-comi should probably another normative reference.

[Med] These two items are already covered in the reply to Alexey's review. 

> these values should be specified normatively and in best with a MUST.

[Med] We can use RECOMMENDED.

> responsible for triggering the ping.

[Med] The current behavior us aligned with "SIG-004  Channel Health Monitoring" of https://tools.ietf.org/html/draft-ietf-dots-requirements-22. 

> not valid for early data (0-RTT) as the hello messages could be transmitted

[Med] Will check this. 

>   from the beginning that 1280 can only be assumed for IPv6.

[Med] Actually, we are echoing RFC7252: 

   If the Path MTU is not known for a destination, an IP MTU of 1280
   bytes SHOULD be assumed; if nothing is known about the size of the
   headers, good upper bounds are 1152 bytes for the message size and
   1024 bytes for the payload size.

> 9) sec 9.6: What's the registration policy for the newly created registries?

[Med] The text says the following: 

   New codes can be assigned via Standards Action [RFC8126].

> active session or connect for migration and configuration requests separately

[Med] In order to avoid cryptographic handshake for new mitigation requests, the session is assumed to be established and maintained. 

> request in updated, isn't it active again?

[Med] A request can be updated but the status may be flagged as active or deactivate. 

 And if it is active and another
> request is sent, isn't that request rejected again.

[Med] Likely

 Can you please further
> is received, and as such a lifetime in seconds is quite meaningless for the

[Med] We prefer lifetime because otherwise time synchronization will be needed. The use of lifetime is aligned with other similar usage: e.g., RFC6887, RFC8512, etc. 

> I'm not sure I understand this sentence. Can you please further explain?

[Med] What is meant is to relax this behavior from RFC 7641:

   A server that transmits notifications mostly in non-confirmable
   messages MUST send a notification in a confirmable message instead of
   a non-confirmable message at least every 24 hours. 

DOTS application will override that behavior. 

> undefined period of time?

[Med] That is only an example if agreed between the client and server. Such considerations are out of scope. 

 Also the max of 300 sec doesn't seem to be a
> MUST...?

[Med] Other values can be used in specific deployments/agreements. 

> used and provide a pointer to section 4.2. of RFC7252 right here (instead of

[Med] Will do. Thanks.

> configuration are not retrieved and changed using NETCONF or RESTCONF?

[Med] The draft says the following: 

   This YANG module (ietf-dots-signal-channel) defines the DOTS client
   interaction with the DOTS server as seen by the DOTS client.  A DOTS
   server is allowed to update the non-configurable 'ro' entities in the
   responses.  This YANG module is not intended to be used via NETCONF/
   RESTCONF for DOTS server management purposes; such module is out of
   the scope of this document.  It serves only to provide a data model
   and encoding, but not a management data model.

Thank you again for the detailed review. 

Cheers,
Med

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 May 2019 13:24:46 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, May 2, 2019 3:31 PM
> To: Mirja Kühlewind <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Liang Xia
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> 
> 
> Hi Mirja,
> 
> > De : Mirja Kühlewind via Datatracker [mailto:[email-masked]] Envoyé
> > : mercredi 1 mai 2019 16:43 À : The IESG Cc :
> > [email-masked]; Liang Xia; dots-
> > [email-masked]; [email-masked]; [email-masked] Objet :
> > Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with
> > DISCUSS and COMMENT)
> >
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > The port request for DOTS was reviewed by the port expert team. Some
> > members of the team were concerned about the assignment of a separate
> > port number for DOTS as Coap is used and already has a designated port
> > number. I believe that Coap is used as a transport in the case and
> > DOTS provides a separate service compared to what Coap is usually used
> > for, however, it is not clear why DOTS needs a designated port.
> > Section 3 says that the port can either be preconfigured or
> > dynamically detected, therefore it is not clear why a fixed port is
> > needed (see also section 7.1. of RFC7605). In the port review process
> > the authored argued that a port is needed to differentiate the DOTS
> > service in the network. However, this is not an endorsed usage for
> > port numbers (see section 6.2. of RFC7605). Further, I believe
> > assigning a fixed port might actually add an attack vector for DOTS,
> > either by DDoSing the respective port at the DOTS server, or any
> > attempt to block DOTS traffic on the network from the DOTS client to
> > the DOTS server.
> 
> The example about differentiated policies is not related to ** performance
> ** but about being able to deliver a ** basic/normal ** DOTS service. Such
> DOTS service takes place in attack times...during which links are saturated by
> nature.
> 
> The purpose of DOTS is as such different from the typical usage of CoAP by
> IoT devices, DOTS signal channel is a new service.
> 
> (2)
> 
> The WG already considered in previous versions of the specification to use
> the existing CoAP port number (in compliance with RFC7605), but that design
> was abandoned by the WG for the reasons documented in the draft.
> 
> (3)
> 
> The built-in discovery of services and resources discussed in RFC 7252
> requires request and response between the peers, but DOTS protocol is
> designed to work in congested networks (because of DDoS attack) and the
> DOTS client during a volumetric DDoS attack may not be able to discover
> services and resources.
> 
> During a DDoS attack, the incoming link is likely to be saturated and the DOTS
> client can only send requests but not receive responses from the server.
> Assigning a DOTS service port avoids the need for resource discovery and
> additional RTT involved before the mitigation request can be sent to the
> DOTS server.
> 
> (4)
> 
> During a DDoS attack, the traffic from the endpoints and IoT devices can be
> rate-limited or blocked, but DOTS protocol traffic needs to be allowed.
> Assigning a DOTS service port helps middleboxes to identify and not rate-
> limit the DOTS protocol traffic during DDoS attack.
> 
> (5)
> 
> Given the rise of DDoS attacks targeting CoAP-capable IoT objects (usually,
> low-cost, not maintained,..), policies to filter "legacy" CoAP messages (at the
> CPE + access/transit networks) will have implications on the delivery of DOTS
> service which is a key component for the emergence of protective
> networking architectures. Having means to differentiate traditional CoAP
> service from DOTS are important from a deployment standpoint.
> ====
> 
> >
> > 2) Section 4.3 says:
> > However, RFC8305 explicitly states that connection attempts SHOULD NOT
> > be made simultaneously (see sec 5).
> >
> 
> [Med] The current behavior us aligned with "SIG-004  Channel Health
> Monitoring" of https://tools.ietf.org/html/draft-ietf-dots-requirements-22.
> 

DTLS handles fragmentation and reassembly only for handshake messages and not for the application data (please see https://tools.ietf.org/html/rfc6347#section-4.1.1). 

-Tiru

> [Med] In order to avoid cryptographic handshake for new mitigation
> requests, the session is assumed to be established and maintained.
> 
> >
> >
> [Med] We prefer lifetime because otherwise time synchronization will be
> needed. The use of lifetime is aligned with other similar usage: e.g., RFC6887,
> RFC8512, etc.
> 
> >
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 6 May 2019 15:52:10 +0200

Hi Med,

Please see inline.

> On 2. May 2019, at 12:00, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Mirja, 
> 

I’ve read the communication with the experts. As I wrote in my discuss point above, I agree with you that dots is a separate service and should not use the Coap port, however, I have a different question which is why do you need a dedicated fixed port? Please see further below.

> The purpose of DOTS is as such different from the typical usage of CoAP by IoT devices, DOTS signal channel is a new service.

Yes.

> The WG already considered in previous versions of the specification to use the existing CoAP port number (in compliance with RFC7605), but that design was abandoned by the WG for the reasons docume…

Okay. 

> During a DDoS attack, the incoming link is likely to be saturated and the DOTS client can only send requests but not receive responses from the server. Assigning a DOTS service port avoids the need…

My understanding is that you anyway need to communication to the Dots server at least once before you can request mitigation. So discovery should have been done previously and not when under attack. Further you also need to pre-configure or discover the server address.

> During a DDoS attack, the traffic from the endpoints and IoT devices can be rate-limited or blocked, but DOTS protocol traffic needs to be allowed. Assigning a DOTS service port helps middleboxes t…

This is not a great approach and the additional attack vector I’ve been taking about. If everything but the dots port is block or rate-limited, then an attacker is probably tempted to run their attack using the designated dots port.

> Given the rise of DDoS attacks targeting CoAP-capable IoT objects (usually, low-cost, not maintained,..), policies to filter "legacy" CoAP messages (at the CPE + access/transit networks) will have…

This is not a good approach either. The port number at maximum could be used as a hint but you really need to apply different means to identify dots traffic as everybody including attack traffic could just use the dots port.

> [Med] This one is discussed in another thread. 

My discuss point was actually different. Due over network overload, probing should NOT be done simultaneously. However, I’ve seen that you now also changed the mechanism to only use simultaneous probing when under attack. That may be fine, however, it is not fully clear why happy eyeballs would be needed at all during an attack as the assumption is that you always have an active session (starting before the attack). I would further like to see it made even more clear that probing MUST be performed sequentially (as described in RFC8305) otherwise.
 
>   destination “

RFC8085 uses SHOULD because it’s a gnernic guideline document for all protocols that use UPD. If there is no good reason to do otherwise in a specific protocol spec, as dots is, you need to pick suitable values and define them with a MUST.

>       datagram every 3 seconds”

Same as above.
>>   estimate, it SHOULD NOT send more than one asynchronous notification

Same as above.

> [Med] This is to accommodate the case where a local policy is provided to the DOTS agent. 

You need specify this further. A reference to RFC8085 alone is never enough.

>> out-of-order.”).

However, again as I said, the causes above should anyway not resend message based on a 3 second timer because most of them are request/reply pattern and Coap specifies that there should always only be one request outstanding.

> [Med] These two items are already covered in the reply to Alexey's review. 

Okay, please move draft-ietf-core-hop-limit to normative.

I don’t see any discussion about draft-ietf-core-comi…?

> [Med] We can use RECOMMENDED.

Yes, please use normative language here as well. Also why is actually a maximum specified?

> [Med] The current behavior us aligned with "SIG-004  Channel Health Monitoring" of https://tools.ietf.org/html/draft-ietf-dots-requirements-22. 

Usually one ends send the heartbeats (ping) and the other end send an ack (pong). There is no need for both ends to send heartbeats independently as the heartbeat and retransmission rate is known and therefore both ends can infer independently that the connection failed if no messages are received anymore. That also how I read SIG-004.

>   1024 bytes for the payload size.

The difference is that you previously say:

"To avoid DOTS signal message fragmentation and the subsequent
   decreased probability of message delivery, DOTS agents MUST ensure
   that the DTLS record MUST fit within a single datagram.”

If this is a hard requirement (using MUST), you also MUST limit your message for IPv4 to 576 bytes. 

RFC7252, however says this instead:
"A CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
   one UDP payload) obviously needs to fit within a single IP datagram.”

Using SHOULD.
 
>   New codes can be assigned via Standards Action [RFC8126].

Okay. Missed that as it was below the table. May move the text above the table. But this is of course fully editorial only.
> [Med] In order to avoid cryptographic handshake for new mitigation requests, the session is assumed to be established and maintained. 

If the assumption is that you always have an active session, then I actually don’t understand how you can have an happy eyeball procedure during an attack. Shouldn’t there already been an active session or at least a previous session which pre-cached information? Also if the connection is detected to be inactive, which peer should try to re-establish the connection? I guess only the client would, right? That need to be further specified!

> [Med] A request can be updated but the status may be flagged as active or deactivate. 

Please specify explicitly what the status should be after adding the 45 seconds.
>> request is sent, isn't that request rejected again.

Then I don’t understand how this is supposed to work.
> [Med] We prefer lifetime because otherwise time synchronization will be needed. The use of lifetime is aligned with other similar usage: e.g., RFC6887, RFC8512, etc. 

I guess it also depends on what kind of time span we are talking about. If it is only a few seconds, transmission delay might have a big impact. However, it probably could be good in any case to advise that a refresh of a mitigation request should not be send “last minute” as there is some fuzziness because of transmission delays.

> DOTS application will override that behavior. 

Okay. Would be good to provide a pointer to RFC7641 and further clarify this in the document.

> [Med] That is only an example if agreed between the client and server. Such considerations are out of scope. 

What I’m saying is that this is not a very good example for the mechanism you provide. So either if that is a valid example, you should probably reconsider your mechanism or I’d advise you to not use this as an example.

> [Med] Other values can be used in specific deployments/agreements. 

The text says: 

“.. MAY exponentially
   increase (the base of the exponent is 2) the active-but-terminating
   period up to a maximum of 300 seconds (5 minutes).”

Which sounds like an explicit maximum and to clarify this I would recommend use of normative language. If that is not meant to be an actual must, then I would recommend rephrasing this sentence.

>   and encoding, but not a management data model.

Yes, I understand why you want to use Coap when under attack. However, the configuration part (Figure 19/20) is not done during the attack, therefore NETCONF/RESTCONF could be used (or it could even be part of the dots data channel).

Mirja

---

From: <[email-masked]>
Date: Mon, 6 May 2019 14:17:42 +0000

Hi Mirja, 

Focusing on this particular DISCUSS point. 

A typical case when a connection is done during attack time is redirection. That is, the nominal DOTS server may redirect a DOTS client to another server with 5.03. Connection attempts will need to be established with the new server as fast as possible so that a mitigation request is placed.

Cheers,
Med

> De : Mirja Kuehlewind [mailto:[email-masked]]
> Envoyé : lundi 6 mai 2019 15:52
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : The IESG; [email-masked]; Liang Xia; dots-
> [email-masked]; [email-masked]
> Objet : Re: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31:
> (with DISCUSS and COMMENT)
> 
> >>
> My discuss point was actually different. Due over network overload, probing
> should NOT be done simultaneously. However, I’ve seen that you now also
> changed the mechanism to only use simultaneous probing when under attack.
> That may be fine, however, it is not fully clear why happy eyeballs would be
> needed at all during an attack as the assumption is that you always have an
> active session (starting before the attack). I would further like to see it
> made even more clear that probing MUST be performed sequentially (as
> described in RFC8305) otherwise.
>

---

From: <[email-masked]>
Date: Mon, 6 May 2019 14:23:47 +0000

Re-,

This was part of Alexey's DISCUSS. We went with this proposal from Alexey:

==
If you don't want Normative dependency, you should fully specify syntax in your
draft and keep the reference Informative.
==

You may check the changes to address this comment at:
https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel-31.pdf 

Cheers,
Med

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 10:50:34 -0500

To add on to Mirja's discussion...

> My understanding is that you anyway need to communication to the Dots server at least once before you can request mitigation. So discovery should have been done previously and not when under attack…

To reiterate: you have to learn a contact point for the DOTS server
somehow (configuration of a hostname, automated discovery, etc.).  Why
can't the mechanism that gives you this contact information give you the
full contact information, including port?

(To be fair, even if the answer to the above is "it can give you that
information", we may still want a dedicated port for operator convenience,
but we should be clear about what the actual justification/need is.)

> This is not a great approach and the additional attack vector I’ve been taking about. If everything but the dots port is block or rate-limited, then an attacker is probably tempted to run their att…

I would actually split this into at least two related attack vectors:

(1) if DOTS operates on a well-known port, that port is a target of attack,
to disrupt the DOTS operation
(2) if the well-known DOTS port receives preferential treatment, it becomes
an attractive tool to use as part of an attack, since attack traffic could
get prioritized over regular traffic.

> My discuss point was actually different. Due over network overload, probing should NOT be done simultaneously. However, I’ve seen that you now also changed the mechanism to only use simultaneous pr…

Another (I think) way to phrase this would be: "if the network is under
attack, it's already in congestion crisis.  Transmitting lots of stuff
simultaneously sounds like making the congestive collapse worse, rather
than helping."

> RFC8085 uses SHOULD because it’s a gnernic guideline document for all protocols that use UPD. If there is no good reason to do otherwise in a specific protocol spec, as dots is, you need to pick su…

+1

> However, again as I said, the causes above should anyway not resend message based on a 3 second timer because most of them are request/reply pattern and Coap specifies that there should always only…

FWIW, I think this "may arrive out-of-order" is my fault, as I think I asked for
it during AD review (having missed the part where CoAP only admits one
outstanding request).

> Please specify explicitly what the status should be after adding the 45 seconds.

I had a hard time with this wording, too; maybe my suggestions ended up
making things worse eventually.  IIUC, the situation is "keep the request
active and add another 45 seconds to the remaining lifetime".

> I guess it also depends on what kind of time span we are talking about. If it is only a few seconds, transmission delay might have a big impact. However, it probably could be good in any case to ad…

There's definitely a tradeoff here.  I think I'm leaning towards lifetime
rather than timestamp for this use case.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 7 May 2019 10:47:50 +0000

Hi Ben,

Please see inline

> From: Dots <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: Monday, May 6, 2019 9:21 PM
> To: [email-masked]
> Cc: [email-masked]; Mirja Kuehlewind <[email-masked]>;
> [email-masked]; The IESG <[email-masked]>
> 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.
> 
> > >> Envoyé : mercredi 1 mai 2019 16:43 À : The IESG Cc :
> > >> Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31:
> > >> The port request for DOTS was reviewed by the port expert team.
> > >> Some members of the team were concerned about the assignment of a
> > >> separate port number for DOTS as Coap is used and already has a
> > >> designated port number. I believe that Coap is used as a transport
> > >> in the case and DOTS provides a separate service compared to what
> > >> Coap is usually used for, however, it is not clear why DOTS needs a
> > >> designated port. Section 3 says that the port can either be
> > >> preconfigured or dynamically detected, therefore it is not clear
> > >> why a fixed port is needed (see also section 7.1. of RFC7605). In
> > >> the port review process the authored argued that a port is needed
> > >> to differentiate the DOTS service in the network. However, this is
> > >> not an endorsed usage for port numbers (see section 6.2. of
> > >> RFC7605). Further, I believe assigning a fixed port might actually
> > >> add an attack vector for DOTS, either by DDoSing the respective
> > >> port at the DOTS server, or any attempt to block DOTS traffic on
> > >> the network from the DOTS client to the DOTS server.
> > >
> > I’ve read the communication with the experts. As I wrote in my discuss
> point above, I agree with you that dots is a separate service and should not
> use the Coap port, however, I have a different question which is why do you
> need a dedicated fixed port? Please see further below.
> >
> > >
> > > ========
> > > (1)
> > >
> > > The example about differentiated policies is not related to **
> performance ** but about being able to deliver a ** basic/normal ** DOTS
> service. Such DOTS service takes place in attack times...during which links are
> saturated by nature.
> > >
> > > The purpose of DOTS is as such different from the typical usage of CoAP
> by IoT devices, DOTS signal channel is a new service.
> >
> > Yes.
> >
> > >
> > > (2)
> > >
> > > The WG already considered in previous versions of the specification to
> use the existing CoAP port number (in compliance with RFC7605), but that
> design was abandoned by the WG for the reasons documented in the draft.
> >
> >
> > Okay.
> >
> > >
> > > (3)
> > >
> > > During a DDoS attack, the incoming link is likely to be saturated and the
> DOTS client can only send requests but not receive responses from the
> server. Assigning a DOTS service port avoids the need for resource discovery
> and additional RTT involved before the mitigation request can be sent to the
> DOTS server.
> >
> > My understanding is that you anyway need to communication to the Dots
> server at least once before you can request mitigation. 
> So discovery should
> have been done previously and not when under attack. Further you also
> need to pre-configure or discover the server address.

No, the DOTS client may or may not establish the signal channel session with the DOTS server when no attack traffic is present. 

> 
> To reiterate: you have to learn a contact point for the DOTS server somehow
> (configuration of a hostname, automated discovery, etc.).  Why can't the
> mechanism that gives you this contact information give you the full contact
> information, including port ?

Yes, discovery of the DOTS port information is possible using https://tools.ietf.org/html/draft-ietf-dots-server-discovery-01 but DOTS server discovery is optional and DOTS server discovery may not succeed during DDoS attack time (DNS server may not be reachable). Further, using a dedicated port for DOTS avoids discovery of services and resources discussed in RFC7252, and reduces the local configuration to only the DOTS server domain name (and optionally DOTS server IP addresses), similar to the way DNS-over-(D)TLS server is configured just with authentication domain name (ADN) (see https://tools.ietf.org/html/rfc8310). 

> > > During a DDoS attack, the traffic from the endpoints and IoT devices can
> be rate-limited or blocked, but DOTS protocol traffic needs to be allowed.
> > This is not a great approach and the additional attack vector I’ve been
> taking about. If everything but the dots port is block or rate-limited, then an
> attacker is probably tempted to run their attack using the designated dots
> port.
> 
> (1) if DOTS operates on a well-known port, that port is a target of attack, to
> disrupt the DOTS operation
> an attractive tool to use as part of an attack, since attack traffic could get
> prioritized over regular traffic.

The above attack vectors are also possible if DOTS uses the CoAP port number 5684. If the DDoS mitigation provider is capable of protecting the target network resources, it will anyways be capable of protecting its own DOTS server from DDoS attacks. Further, the DOTS server in the ISP will only be reachable to its subscribers, and not visible to the external world.

> 
> > >
> > > (5)
> > >
> > > Given the rise of DDoS attacks targeting CoAP-capable IoT objects
> (usually, low-cost, not maintained,..), policies to filter "legacy" CoAP
> messages (at the CPE + access/transit networks) will have implications on the
> delivery of DOTS service which is a key component for the emergence of
> protective networking architectures. Having means to differentiate
> traditional CoAP service from DOTS are important from a deployment
> standpoint.
> >
> > This is not a good approach either. The port number at maximum could be
> used as a hint but you really need to apply different means to identify dots
> traffic as everybody including attack traffic could just use the dots port.

Agreed, having a separate port number is a good hint for the middle-boxes (middle-box knows the port is only used for DOTS traffic, and any other type of 
traffic can be blocked). 

> > >> However, RFC8305 explicitly states that connection attempts SHOULD
> > >> NOT be made simultaneously (see sec 5).
> > >>
> > >
> > My discuss point was actually different. Due over network overload,
> probing should NOT be done simultaneously. However, I’ve seen that you
> now also changed the mechanism to only use simultaneous probing when
> under attack. That may be fine, however, it is not fully clear why happy
> eyeballs would be needed at all during an attack as the assumption is that
> you always have an active session (starting before the attack). I would
> further like to see it made even more clear that probing MUST be performed
> sequentially (as described in RFC8305) otherwise.
> 
> Another (I think) way to phrase this would be: "if the network is under attack,
> it's already in congestion crisis.  Transmitting lots of stuff simultaneously
> sounds like making the congestive collapse worse, rather than helping."

Several DDoS attacks do not congest the network (e.g. Slowloris), we can update the text as follows:

 When connection attempts are made during an attack congesting the network, the DOTS client
 SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms. 

> 
> > >
> > >> Further Figure 4 shows a different order of request as recommended
> > >> in the text (text says: "UDP over IPv6, UDP over IPv4, TCP over
> > >> IPv6, and finally TCP over IPv4").
> > >
> > >> you start the next connection attempt. Therefore that should be not
> > >> displayed like this in the figure or needs further explanation.
> > >
> > RFC8085 uses SHOULD because it’s a gnernic guideline document for all
> protocols that use UPD. If there is no good reason to do otherwise in a
> specific protocol spec, as dots is, you need to pick suitable values and define
> them with a MUST.
> 
> +1

I don't have a good reason to pick different values, will replace "SHOULD" with "MUST". 

> > >       datagram every 3 seconds”

I don't have a valid reason to be more aggressive, will replace "SHOULD" with "MUST".

> > >>   estimate, it SHOULD NOT send more than one asynchronous

I don't have a valid reason to be more aggressive, will replace "SHOULD" with "MUST".

> > >> However, most of the communication pattern used by DOTS rely on a
> > >> request/reply pattern and Coap specifies for this case that only
> > >> one request can be outstanding at a time (until the reply is
> > >> received or message is assumed to be
> > >> lost) (see section 4.7 and 4.2 of RFC7252) which therefore will be
> > >> used in this case. Only migration updates are send without reply,
> > >> and here a MUST would be more appropriate.
> > >>
> > >> Please also note that if there can only be one request outstanding
> > >> (before a reply is received) it is also not possible that requests
> > >> are received out of order (see e.g. 4.4.3: "If UDP is used as
> > >> transport, CoAP requests may arrive out-of-order.”).
> >
> > However, again as I said, the causes above should anyway not resend
> message based on a 3 second timer because most of them are request/reply
> pattern and Coap specifies that there should always only be one request
> outstanding.
> 

No, non-confirmable CoAP requests can arrive out-of-order at the server, please see https://tools.ietf.org/html/rfc7252#section-4.3 and 
https://tools.ietf.org/html/draft-ietf-lwig-coap-06#section-3.5 

Cheers,
-Tiru

> > >> This sounds like it should be required (and normative language
> > >> should be
> > >> used)
> > >> 5)Section 4.5.2: You give recommendations for min and max in a
> > >> note, however, these values should be specified normatively and in
> best with a MUST.
> > >
> > >> Actually heartbeat should only be send in one direction (as the
> > >> other end will send an ack) and the protocol should clearly specify
> > >> which endpoint is responsible for triggering the ping.
> > >>
> > >
> > Usually one ends send the heartbeats (ping) and the other end send an ack
> (pong). There is no need for both ends to send heartbeats independently as
> the heartbeat and retransmission rate is known and therefore both ends can
> infer independently that the connection failed if no messages are received
> anymore. That also how I read SIG-004.
> >
> > >
> > >> This should be handled by the DTLS record layer and not by DOTS
> > >> that works on top of DTLS (actually Coap), therefor it seems
> > >> straight to have a normative requirement here in the DOTS spec.
> > >> Also note that the calculation provided is not valid for early data
> > >> (0-RTT) as the hello messages could be transmitted in the same
> > >> datagram.
> > >>
> > >
> > > [Med] Will check this.
> > >
> > >>  Actually this is only true for IPv6. The later note mentions that
> > >> the  situation is different from IPV4, however, it should probably
> > >> be made clear  from the beginning that 1280 can only be assumed for
> IPv6.
> > >
> > Okay. Missed that as it was below the table. May move the text above the
> table. But this is of course fully editorial only.
> > >
> > >
> > >> 10) The document should more explicitly provide more guidance about
> > >> when a client should start a session and what should be done (from
> > >> the client side) if a session is detected as inactive (other than
> > >> during migration which is discussed a bit in 4.7). Is the
> > >> assumption to have basically permanently an active session or
> > >> connect for migration and configuration requests separately at a
> > >> time?
> > >
> > If the assumption is that you always have an active session, then I actually
> don’t understand how you can have an happy eyeball procedure during an
> attack. Shouldn’t there already been an active session or at least a previous
> session which pre-cached information? Also if the connection is detected to
> be inactive, which peer should try to re-establish the connection? I guess
> only the client would, right? That need to be further specified!
> >
> >
> > >
> > >>
> > >>
> > >> This wording is not fully clear to me. If the life time of a
> > >> deactivated request in updated, isn't it active again?
> > >
> > >> 3) section 4.4.2: "lifetime:  The remaining lifetime of the
> > >> mitigation request, in
> > >>      seconds."
> > >> Shouldn't lifetime we rather a timestamp because there is some
> > >> unknown transmission delay between the time when the reply is
> > >> generated and the reply is received, and as such a lifetime in
> > >> seconds is quite meaningless for the client.
> > >
> > I guess it also depends on what kind of time span we are talking about. If it
> is only a few seconds, transmission delay might have a big impact. However,
> it probably could be good in any case to advise that a refresh of a mitigation
> request should not be send “last minute” as there is some fuzziness because
> of transmission delays.
> 
> There's definitely a tradeoff here.  I think I'm leaning towards lifetime rather
> than timestamp for this use case.
> 
> -Ben
> 
> > >
> > >>
> > >> I find this sentence a bit problematic given the
> > >> active-but-terminating period is defined by server. Wouldn't that
> > >> mean the server can make me pay for undefined period of time?
> > >
> > What I’m saying is that this is not a very good example for the mechanism
> you provide. So either if that is a valid example, you should probably
> reconsider your mechanism or I’d advise you to not use this as an example.
> >
> > >
> > Which sounds like an explicit maximum and to clarify this I would
> recommend use of normative language. If that is not meant to be an actual
> must, then I would recommend rephrasing this sentence.
> >
> >
> >
> > >
> > >> 6) In section Section 4.5 you talk about Caop Ping/Pong. However,
> > >> these terms are not used in RFC7252. Maybe clarify that empty
> > >> confirmable  messages are used and provide a pointer to section
> > >> 4.2. of RFC7252 right here (instead of only later).
> > >
> > > [Med] Will do. Thanks.
> > >
> > >>
> > >> 7) High-level question: Given this doc specifies a YANG model, why
> > >> are configuration are not retrieved and changed using NETCONF or
> RESTCONF?
> > >>
> > >
> > Yes, I understand why you want to use Coap when under attack. However,
> the configuration part (Figure 19/20) is not done during the attack, therefore
> NETCONF/RESTCONF could be used (or it could even be part of the dots data
> channel).
> >
> > Mirja
> >
> >
> > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 7 May 2019 11:27:23 -0500

> No, the DOTS client may or may not establish the signal channel session with the DOTS server when no attack traffic is present. 

(Hmm, the quoting looks weird -- I am pretty sure that what you reply to
here was from Mirja, not me.)

> Yes, discovery of the DOTS port information is possible using https://tools.ietf.org/html/draft-ietf-dots-server-discovery-01 but DOTS server discovery is optional and DOTS server discovery may not…

I'm going to focuses on "reduces the local configuration to only the DOTS
server domain name".  I'm familiar with many configuration interfaces that
allow for "host:port" to be given as easily as just "host", and my
understanding of Mirja's question is about local configuration of
"host:port" (since local configuration of "host" would otherwise be used).
(This assumes that fully automated discovery would handle everything, so it
less interesting for the matter at hand.)

>  SHOULD use a "Connection Attempt Delay" [RFC8305] set to 100 ms. 

Thanks for pointing out that not all attacks are brute bandwidth (or pps).
I'd like to hear from Mirja at this point.

> I don't have a good reason to pick different values, will replace "SHOULD" with "MUST". 

Thanks.

-Ben

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 8 May 2019 07:30:24 +0000

> From: Benjamin Kaduk <[email-masked]>
> Sent: Tuesday, May 7, 2019 9:57 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; [email-masked]; Mirja
> Kuehlewind <[email-masked]>; [email-masked]; The IESG <[email-masked]>
> > > 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.
> > >
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >> DISCUSS:
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >>
> > > > >> Some members of the team were concerned about the assignment
> of
> > > > >> a separate port number for DOTS as Coap is used and already has
> > > > >> a designated port number. I believe that Coap is used as a
> > > > >> transport in the case and DOTS provides a separate service
> > > > >> compared to what Coap is usually used for, however, it is not
> > > > >> clear why DOTS needs a designated port. Section 3 says that the
> > > > >> port can either be preconfigured or dynamically detected,
> > > > >> therefore it is not clear why a fixed port is needed (see also
> > > > >> section 7.1. of RFC7605). In the port review process the
> > > > >> authored argued that a port is needed to differentiate the DOTS
> > > > >> service in the network. However, this is not an endorsed usage
> > > > >> for port numbers (see section 6.2. of RFC7605). Further, I
> > > > >> believe assigning a fixed port might actually add an attack
> > > > >> vector for DOTS, either by DDoSing the respective port at the
> > > > >> DOTS server, or any attempt to block DOTS traffic on the network
> from the DOTS client to the DOTS server.
> > > > >
> > > point above, I agree with you that dots is a separate service and
> > > should not use the Coap port, however, I have a different question
> > > which is why do you need a dedicated fixed port? Please see further
> below.
> > > >
> > > > >
> > > > > ========
> > > > > (1)
> > > > >
> > > > > We are familiar with RFC7605. We confirm that the port we are
> > > > > asking for
> > > is:
> > > > >
> > > performance ** but about being able to deliver a ** basic/normal **
> > > DOTS service. Such DOTS service takes place in attack times...during
> > > which links are saturated by nature.
> > > > >
> > > use the existing CoAP port number (in compliance with RFC7605), but
> > > that design was abandoned by the WG for the reasons documented in
> the draft.
> > > >
> > > >
> > > > Okay.
> > > >
> > > > >
> > > > > (3)
> > > > >
> > > requires request and response between the peers, but DOTS protocol
> > > is designed to work in congested networks (because of DDoS attack)
> > > and the DOTS client during a volumetric DDoS attack may not be able
> > > to discover services and resources.
> > > > >
> > > DOTS client can only send requests but not receive responses from
> > > the server. Assigning a DOTS service port avoids the need for
> > > resource discovery and additional RTT involved before the mitigation
> > > request can be sent to the DOTS server.
> > > >
> > > have been done previously and not when under attack. Further you
> > > also need to pre-configure or discover the server address.
> >
> > No, the DOTS client may or may not establish the signal channel session
> with the DOTS server when no attack traffic is present.
> 
> > > somehow (configuration of a hostname, automated discovery, etc.).
> > > Why can't the mechanism that gives you this contact information give
> > > you the full contact information, including port ?
> >
> > Yes, discovery of the DOTS port information is possible using
> https://tools.ietf.org/html/draft-ietf-dots-server-discovery-01 but DOTS
> server discovery is optional and DOTS server discovery may not succeed
> during DDoS attack time (DNS server may not be reachable). Further, using a
> dedicated port for DOTS avoids discovery of services and resources discussed
> in RFC7252, and reduces the local configuration to only the DOTS server
> domain name (and optionally DOTS server IP addresses), similar to the way
> DNS-over-(D)TLS server is configured just with authentication domain name
> (ADN) (see https://tools.ietf.org/html/rfc8310).
> 
> understanding of Mirja's question is about local configuration of "host:port"
> (since local configuration of "host" would otherwise be used).

The local configuration with ports gets more complicated with DOTS call home (please see https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-01#section-4.1). 

> less interesting for the matter at hand.)

If default port is not assigned, discovery of the DOTS server port using S-NAPTR or DNS-SD becomes mandatory, and the challenge during an attack is the DNS server itself may be unreachable or 
the DNS server could be subjected to DDoS attacks (making it incapable to respond to DNS queries from the DOTS client). 

-Tiru

> 
> > >
> > > (To be fair, even if the answer to the above is "it can give you
> > > that information", we may still want a dedicated port for operator
> > > convenience, but we should be clear about what the actual
> > > justification/need is.)
> > >
> > > > >
> > > > > (4)
> > > > >
> > > Assigning a DOTS service port helps middleboxes to identify and not
> > > rate- limit the DOTS protocol traffic during DDoS attack.
> > > >
> > > taking about. If everything but the dots port is block or
> > > rate-limited, then an attacker is probably tempted to run their
> > > attack using the designated dots port.
> > >
> > > (1) if DOTS operates on a well-known port, that port is a target of
> > > attack, to disrupt the DOTS operation
> > > (2) if the well-known DOTS port receives preferential treatment, it
> > > becomes an attractive tool to use as part of an attack, since attack
> > > traffic could get prioritized over regular traffic.
> >
> > The above attack vectors are also possible if DOTS uses the CoAP port
> number 5684. If the DDoS mitigation provider is capable of protecting the
> target network resources, it will anyways be capable of protecting its own
> DOTS server from DDoS attacks. Further, the DOTS server in the ISP will only
> be reachable to its subscribers, and not visible to the external world.
> >
> > >
> > > > >
> > > > > (5)
> > > > >
> > > (usually, low-cost, not maintained,..), policies to filter "legacy"
> > > CoAP messages (at the CPE + access/transit networks) will have
> > > implications on the delivery of DOTS service which is a key
> > > component for the emergence of protective networking architectures.
> > > Having means to differentiate traditional CoAP service from DOTS are
> > > important from a deployment standpoint.
> > > >
> > > used as a hint but you really need to apply different means to
> > > identify dots traffic as everybody including attack traffic could just use the
> dots port.
> >
> > Agreed, having a separate port number is a good hint for the
> > middle-boxes (middle-box knows the port is only used for DOTS traffic, and
> any other type of traffic can be blocked).
> >
> > > >
> > > > > ====
> > > > >
> > > > >>
> > > > >> 2) Section 4.3 says:
> > > > >> However, RFC8305 explicitly states that connection attempts
> > > > >> SHOULD NOT be made simultaneously (see sec 5).
> > > > >>
> > > > >
> > > probing should NOT be done simultaneously. However, I’ve seen that
> > > you now also changed the mechanism to only use simultaneous probing
> > > when under attack. That may be fine, however, it is not fully clear
> > > why happy eyeballs would be needed at all during an attack as the
> > > assumption is that you always have an active session (starting
> > > before the attack). I would further like to see it made even more
> > > clear that probing MUST be performed sequentially (as described in
> RFC8305) otherwise.
> > >
> > > Another (I think) way to phrase this would be: "if the network is
> > > under attack, it's already in congestion crisis.  Transmitting lots
> > > of stuff simultaneously sounds like making the congestive collapse worse,
> rather than helping."
> >
> >  When connection attempts are made during an attack congesting the
> > network, the DOTS client  SHOULD use a "Connection Attempt Delay"
> [RFC8305] set to 100 ms.
> 
> > > > >> Further Figure 4 shows a different order of request as
> > > > >> recommended in the text (text says: "UDP over IPv6, UDP over
> > > > >> IPv4, TCP over IPv6, and finally TCP over IPv4").
> > > > >
> > > > >> you start the next connection attempt. Therefore that should be
> > > > >> not displayed like this in the figure or needs further explanation.
> > > > >
> > > protocols that use UPD. If there is no good reason to do otherwise
> > > in a specific protocol spec, as dots is, you need to pick suitable
> > > values and define them with a MUST.
> > >
> > > +1
> >
> > > > > [Med] This is to accommodate the case where a local policy is
> > > > > provided to
> > > the DOTS agent.
> > > >
> > > > You need specify this further. A reference to RFC8085 alone is
> > > > never
> > > enough.
> > > >
> > > > >
> > > > >> However, most of the communication pattern used by DOTS rely on
> > > > >> a request/reply pattern and Coap specifies for this case that
> > > > >> only one request can be outstanding at a time (until the reply
> > > > >> is received or message is assumed to be
> > > > >> lost) (see section 4.7 and 4.2 of RFC7252) which therefore will
> > > > >> be used in this case. Only migration updates are send without
> > > > >> reply, and here a MUST would be more appropriate.
> > > > >>
> > > > >> Please also note that if there can only be one request
> > > > >> outstanding (before a reply is received) it is also not
> > > > >> possible that requests are received out of order (see e.g.
> > > > >> 4.4.3: "If UDP is used as transport, CoAP requests may arrive out-of-
> order.”).
> > > >
> > > message based on a 3 second timer because most of them are
> > > request/reply pattern and Coap specifies that there should always
> > > only be one request outstanding.
> > >
> > > FWIW, I think this "may arrive out-of-order" is my fault, as I think
> > > I asked for it during AD review (having missed the part where CoAP
> > > only admits one outstanding request).
> >
> > No, non-confirmable CoAP requests can arrive out-of-order at the
> > server, please see https://tools.ietf.org/html/rfc7252#section-4.3 and
> > > > >> and therefore draft-ietf-core-hop-limit should also be a
> > > > >> normative
> > > reference.
> > > > > [Med] These two items are already covered in the reply to
> > > > > Alexey's
> > > review.
> > > >
> > > > Yes, please use normative language here as well. Also why is
> > > > actually a
> > > maximum specified?
> > > >
> > > > >
> > > > >>
> > > > >> other end will send an ack) and the protocol should clearly
> > > > >> specify which endpoint is responsible for triggering the ping.
> > > > >>
> > > > >
> > > (pong). There is no need for both ends to send heartbeats
> > > independently as the heartbeat and retransmission rate is known and
> > > therefore both ends can infer independently that the connection
> > > failed if no messages are received anymore. That also how I read SIG-004.
> > > >
> > > > >
> > > > >>  Actually this is only true for IPv6. The later note mentions
> > > > >> that the  situation is different from IPV4, however, it should
> > > > >> probably be made clear  from the beginning that 1280 can only
> > > > >> be assumed for
> > > IPv6.
> > > > >
> > > > If this is a hard requirement (using MUST), you also MUST limit
> > > > your
> > > message for IPv4 to 576 bytes.
> > > >
> > > > >> 10) The document should more explicitly provide more guidance
> > > > >> about when a client should start a session and what should be
> > > > >> done (from the client side) if a session is detected as
> > > > >> inactive (other than during migration which is discussed a bit
> > > > >> in 4.7). Is the assumption to have basically permanently an
> > > > >> active session or connect for migration and configuration
> > > > >> requests separately at a time?
> > > > >
> > > don’t understand how you can have an happy eyeball procedure during
> > > an attack. Shouldn’t there already been an active session or at
> > > least a previous session which pre-cached information? Also if the
> > > connection is detected to be inactive, which peer should try to
> > > re-establish the connection? I guess only the client would, right? That
> need to be further specified!
> > > >
> > > >
> > > > >
> > > > >>
> > > > >>
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >> COMMENT:
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >>
> > > > > [Med] A request can be updated but the status may be flagged as
> > > > > active
> > > or deactivate.
> > > >
> > > > Please specify explicitly what the status should be after adding
> > > > the 45
> > > seconds.
> > >
> > > I had a hard time with this wording, too; maybe my suggestions ended
> > > up making things worse eventually.  IIUC, the situation is "keep the
> > > request active and add another 45 seconds to the remaining lifetime".
> > >
> > > needed. The use of lifetime is aligned with other similar usage:
> > > e.g., RFC6887, RFC8512, etc.
> > > >
> > > is only a few seconds, transmission delay might have a big impact.
> > > However, it probably could be good in any case to advise that a
> > > refresh of a mitigation request should not be send “last minute” as
> > > there is some fuzziness because of transmission delays.
> > >
> > > There's definitely a tradeoff here.  I think I'm leaning towards
> > > lifetime rather than timestamp for this use case.
> > >
> > > -Ben
> > >
> > > > >
> > > > >>
> > > > Okay. Would be good to provide a pointer to RFC7641 and further
> > > > clarify
> > > this in the document.
> > > >
> > > > >
> > > > >>
> > > > >> active-but-terminating period is defined by server. Wouldn't
> > > > >> that mean the server can make me pay for undefined period of time?
> > > > >
> > > > > [Med] That is only an example if agreed between the client and
> server.
> > > Such considerations are out of scope.
> > > >
> > > you provide. So either if that is a valid example, you should
> > > probably reconsider your mechanism or I’d advise you to not use this as
> an example.
> > > >
> > > > >
> > > recommend use of normative language. If that is not meant to be an
> > > actual must, then I would recommend rephrasing this sentence.
> > > >
> > > >
> > > >
> > > > >
> > > > >> 6) In section Section 4.5 you talk about Caop Ping/Pong.
> > > > >> However, these terms are not used in RFC7252. Maybe clarify
> > > > >> that empty confirmable  messages are used and provide a pointer
> > > > >> to section 4.2. of RFC7252 right here (instead of only later).
> > > > >
> > > > > [Med] Will do. Thanks.
> > > > >
> > > > >>
> > > > >> 7) High-level question: Given this doc specifies a YANG model,
> > > > >> why are configuration are not retrieved and changed using
> > > > >> NETCONF or
> > > RESTCONF?
> > > > >>
> > > > >
> > > > >   RESTCONF for DOTS server management purposes; such module is
> > > > > out
> > > of
> > > the configuration part (Figure 19/20) is not done during the attack,
> > > therefore NETCONF/RESTCONF could be used (or it could even be part
> > > of the dots data channel).
> > > >
> > > > Mirja
> > > >
> > > >
> > > > >