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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Dots <[e-mail]> On Behalf Of
> [e-mail]
> Sent: Thursday, May 2, 2019 3:31 PM
> To: Mirja Kühlewind <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; Liang Xia
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> 
> 
> 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.
> >

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] 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
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots