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

[<[e-mail]>]

Hi Mirja, 

Thank you for the detailed review. 

Please see inline.

Cheers,
Med

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

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

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

[Med] This one is discussed in another thread. 

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

[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
> you start the next connection attempt. Therefore that should be not displayed
> like this in the figure or needs further explanation.

[Med] We will add annotations to the figure. 

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

[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 "

> and
>   "If the DOTS client cannot maintain an RTT estimate, it
>    SHOULD NOT send more than one Non-confirmable request every 3
>    seconds"

[Med] because 8085 says:

"Such applications SHOULD NOT send more than one UDP
       datagram 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"

[Med] Idem as above.

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

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

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

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

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

[Med] We can use RECOMMENDED.

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

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

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

[Med] Will check this. 

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

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


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

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

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

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

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

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

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

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

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

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

[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