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

Mirja Kuehlewind <ietf@kuehlewind.net> Tue, 02 July 2019 14:00 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F021200B6; Tue, 2 Jul 2019 07:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIxk82CPGaum; Tue, 2 Jul 2019 07:00:39 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814CD12009E; Tue, 2 Jul 2019 07:00:39 -0700 (PDT)
Received: from 200116b82c0abb008104c3e4d35e4aa2.dip.versatel-1u1.de ([2001:16b8:2c0a:bb00:8104:c3e4:d35e:4aa2]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hiJKj-0000Hn-4y; Tue, 02 Jul 2019 16:00:33 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAB0EA4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Tue, 2 Jul 2019 16:00:30 +0200
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Benjamin Kaduk <kaduk@mit.edu>, "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <35E40EAD-6D7B-4DE7-A9C9-5358AF566AFA@kuehlewind.net>
References: <155672175129.924.6789867477696592350.idtracker@ietfa.amsl.com> <20190628222124.GB10013@kduck.mit.edu> <DM5PR16MB1705ABD7DD4CB93E065006E4EAFF0@DM5PR16MB1705.namprd16.prod.outlook.com> <DDE85C27-EE95-4CF1-896E-10056B017860@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EAB0EA4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562076039;7b7d9a79;
X-HE-SMSGID: 1hiJKj-0000Hn-4y
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/76MTYI1U0B3PN13A0rAV1uGkTqE>
Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-signal-channel-31=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2019 14:00:43 -0000

Hi Med,

See below.

> On 2. Jul 2019, at 11:38, <mohamed.boucadair@orange.com>; <mohamed.boucadair@orange.com>; wrote:
> 
> Hi Mirja, all,
> 
> (removing resolved items).
> 
> Please see inline. 
> 
> Cheers,
> Tiru & Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
>> Envoyé : lundi 1 juillet 2019 18:21
>> À : Konda, Tirumaleswar Reddy; Benjamin Kaduk
>> Cc : draft-ietf-dots-signal-channel@ietf.org; frank.xialiang@huawei.com;
>> dots@ietf.org; The IESG; dots-chairs@ietf.org
>> Objet : Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
>> channel-31: (with DISCUSS and COMMENT)
>> 
>> Hi Ben, hi Tiru,
>> 
>> Please see below.
>> 
>>> On 29. Jun 2019, at 14:10, Konda, Tirumaleswar Reddy
>> <TirumaleswarReddy_Konda@McAfee.com>; wrote:
>>> 
>>> Please see inline
>>> 
>>>> -----Original Message-----
>>>> From: Dots <dots-bounces@ietf.org>; On Behalf Of Benjamin Kaduk
>>>> Sent: Saturday, June 29, 2019 3:51 AM
>>>> To: Mirja Kühlewind <ietf@kuehlewind.net>;
>>>> Cc: draft-ietf-dots-signal-channel@ietf.org; frank.xialiang@huawei.com;
>>>> dots-chairs@ietf.org; The IESG <iesg@ietf.org>;; dots@ietf.org
>>>> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-
>> signal-
>>>> channel-31: (with DISCUSS and COMMENT)
>>>> 
>>>> 
>>>> 
>>>> Hi Mirja,
>>>> 
>>>> I wanted to check in with the status of the remaining Discuss points
>> for this
>>>> document.  I tried to go through the previous discussions and have made
>> my
>>>> own analysis of where things stand, so hopefully we can compare notes.
>>>> 
>>>> On Wed, May 01, 2019 at 07:42:31AM -0700, Mirja Kühlewind via
>> Datatracker
>>>> wrote:
>>>>> 
>>>>> 
>>>>> ----------------------------------------------------------------------
>>>>> 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.
>>>> 
>>>> If I understand correctly you were supporting a port allocation, but
>> wanted
>>>> the document to be more clear about its usage and necessity.
>>>> 
>>>> There were some text changes, so that we now have:
>>>> 
>>>>  In some cases, a DOTS client and server may have mutual agreement to
>>>>  use a specific port number, such as by explicit configuration or
>>>>  dynamic discovery [I-D.ietf-dots-server-discovery].  Absent such
>>>>  mutual agreement, the DOTS signal channel MUST run over port number
>>>>  TBD as defined in Section 9.1, for both UDP and TCP.  In order to use
>>>>  a distinct port number (as opposed to TBD), DOTS clients and servers
>>>>  SHOULD support a configurable parameter to supply the port number to
>>>>  use.  The rationale for not using the default port number 5684
>>>>  ((D)TLS CoAP) is to allow for differentiated behaviors in
>>>>  environments where both a DOTS gateway and an IoT gateway (e.g.,
>>>>  Figure 3 of [RFC7452]) are present.
>>>> 
>>>> Does that address your concerns?
>> 
>> I think this still leaves my original question open. I agree that using
>> port 5684 is no alternative. However, I still don’t see why a fixed port
>> is needed at all. In all scenarios described either the server IP address
>> needs to be configured or a detection mechanism is used. In both cases
>> this could be used to also configure or detect the port.
>> 
> 
> [Med] This comment would apply to other protocols as well such as SIP (for which more than one port was assigned), TURN (2 ports assigned), etc. The same reasons for allocating ports for those protocols would apply for DOTS.

The protocols have good reason for a fixed port. E.g. SIP contact information can be guessed/derived from other information but then a known port is needed. Turns need to avoid conflicts with other ports. None of these kind of reason are true for dots, as the IP address needs always to be discovered or configured any in both cases I don’t see a reason why the port number cannot be identified in the same process.

> 
> Having a fixed port allows for minimal setup for DOTS session establishment.

I don’t see configuring an IP more minimal than configuring an IP and a port number.

> Moreover, the fixed port allocation helps with default settings such as on-path firewalls.  

This is dangerous because it opens exactly a port you want to protect. It’s also not recommended to use port number to identify network traffic, see also rfc7605 section 6.2.

> 
> The specification does not mandate a discovery mechanism. Furthermore, the server IP address may not be required to be explicitly configured if (1) an anycast address is assigned for DOTS,

I don’t see this draft requesting an assignment of an anycast address. So I guess this anycast address need to be configured as well?

> (2) if the client assumes that its default router is its DOTS server (e.g., LAN scenarios with DOTS gateways on CPEs),

This is also not discussed in this draft…?

> or (3) redirect for which this specification returns only an alternate IP address (but not any alternate port number).

Then you would need to add port information to the redirect.
> 
> Even if a way (e.g., DHCP) is used to configure the IP address, DHCP options are not designed to provision a port number. You may check the list at: https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

I’m not an expert her but I guess you could even design a new DHCP option that includes a port number.
> 
> If the DDoS attack is targeting the victim's infrastructure, the DNS server may not be reachable or available.
> 
> We need to accommodate a variety of target deployment scenarios, hence this request. 

Yes, but now of them seem to ned fixed port number to me because you can always find a way to discover the IP and the port in the same step.

If there is a good reason for dots to have a fixed port instead of using dynamic ports, I’m happy to assign one but you didn’t really provide me a reason yet.

Also please note my initial point that use of a fixed port makes it easier to attack the dots service and traffic directly. If you want to open a firewall for dots traffic specifically, it is safer to configure your firewall based on the port used in the specific deployment setup than using a fixed port for all dots services everywhere.

> 
>>>> 
>>>>> 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].
>>>> 
>>>> These changes made, except for the last one, IIUC.
>> 
>> This one is a weird MUST now because RFC8085 only gives guidelines:
>>  "DOTS agents MUST 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.”
>> 
>> I would rather recommend something like
>>  "DOTS agents MUST not
>>   sending more than one UDP datagram per round-trip time (RTT) to the
>>   peer DOTS agent on average following the data transmission guidelines
>> discussed in Section 3.1.3 of [RFC8085].”
>> 
> 
> [Med] OK. 

Great.

> 
>> And I think the last one (4.4.2.2) also needs a more concrete statement.
>> 
> 
> [Med] Can be updated as follows: 
> 
> OLD:
>   Absent such policy, the frequency of polling the DOTS server to get
>   the mitigation status SHOULD follow the transmission guidelines in
>   Section 3.1.3 of [RFC8085].
> 
> NEW:
>   Absent such policy, the frequency of polling the DOTS server to get
>   the mitigation status SHOULD NOT be more than one UDP datagram per RTT
>   as discussed in Section 3.1.3 of [RFC8085].
> 
> (Note: SHOULD is used here because of a comment from Alissa related to a similar wording).

Actually, that actually a good point. I think the minimum polling frequency must always be one datagram per RTT. I think no policy should be allowed to have a smaller frequency. What would be the reason to poll more often?

> 
>> 
>>> 
>>>> 
>>>>> 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.
>>>> 
>>>> I'm not sure I see resolution on this; do the authors still need to
>> answer why
>>>> the "pong" reply cannot serve as a reverse-path heartbeat?
>>> 
>>> If the DOTS client domain is subjected to volumetric DDoS attack and the
>> incoming link is saturated, the pong response from the server will not
>> reach the client. DOTS server gets traffic from the client but receives no
>> responses to its ping requests indicating the client has not detected the
>> attack or, if an attack mitigation is in progress, it implies the applied
>> DDoS mitigation actions are not yet effective to handle the DDoS attack
>> volume.
>> 
>> Yes, I understand what heartbeat are used for. However, what you described
>> implies that the server should send the ping and client sends the pong.
>> This is fine.
> 
> [Med] Choosing the other way around may be problematic because of NAT/FWs. This is why the heartbeats from the server will fly right after the one from the client so that we can use the warm mappings. Having both directions allows to accommodate the scenario described by Tiru.
> 
> As you know, RFC4787 mandates the NAT outbound refresh behavior (packets go from the internal side of the NAT to the external side of the NAT to refresh the timer value) but not the NAT inbound refresh behavior.
> 
> The text however seems to imply that both server and client
>> test their have connection separately and both send pings and pongs. That
>> doesn’t seem to be need.
> 
> [Med] In addition to the clarification above, we have also added a pointer to this part of 8085: 
> 
> ==
>   A UDP application with a long-lived association between the sender
>   and receiver, ought to be designed so that the sender periodically
>   checks that the receiver still wants ("consents") to receive traffic
>   and need to be designed to stop if there is no explicit confirmation
>   of this [RFC7675].  Applications that require communications in two
>   directions to implement protocol functions (such as reliability or
>   congestion control) will need to independently check both directions
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              
>   of communication, and may have to exchange keep-alive messages to
>   ^^^^^^^^^^^^^^^^
>   traverse middleboxes (see Section 3.5).
> ==

Yes, you use keep-alive messages here. A ping on one direction and a pong/ack as reply in the direction. I’m not we are maybe talking past each other… I think the following is sufficient


Client ping —————>
            <———— server pong


While what I read from the document is that you do this:

Client ping —————>
            <———— server pong

            <———— server ping
Client pong —————>

If that is not what your are doing you need to clarify this in the document. 

If you actually want to have two different ping/pong’s you need to explain me why you need both.

> 
>> 
>> 
>>> 
>>>> 
>>>>> 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.
>>>> 
>>>> There was some clarifying discussion here; do you still see an issue?
>> 
>> I was wrong that DTLS helps you, however rfc7252 (soap) does and specifies
>> message sizes. While for Coap this is a SHOULD, you have a MUST here. I
>> think that is correctly and therefore it’s fine to specify it normatively.
>> Not need to change. Still I recommend to highlight this difference!
> 
> [Med] Will add some text to highlight this.  

Thanks!

> 
> 
>>>> 
>>>>> 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?
>>>> 
>>>> I think there was some clarifying text added, but please confirm if you
>> think it
>>>> is sufficient.
>> 
>> Sorry, don’t see where text was added. Can you provide a pointer?
> 
> [Med] We do have this text, for example:
> 
>   The DOTS signal channel can be established between two DOTS agents
>   prior or during an attack.  The DOTS signal channel is initiated by
>   the DOTS client.  The DOTS client can then negotiate, configure, and
>   retrieve the DOTS signal channel session behavior with its DOTS peer
>   (Section 4.5).  Once the signal channel is established, the DOTS
>   agents periodically send heartbeats to keep the channel active
>   (Section 4.7).  At any time, the DOTS client may send a mitigation
>   request message (Section 4.4) to a DOTS server over the active signal
>   channel.  While mitigation is active (because of the higher
>   likelihood of packet loss during a DDoS attack), the DOTS server
>   periodically sends status messages to the client, including basic
>   mitigation feedback details.  Mitigation remains active until the
>   DOTS client explicitly terminates mitigation, or the mitigation
>   lifetime expires.  Also, the DOTS server may rely on the signal
>   channel session loss to trigger mitigation for pre-configured
>   mitigation requests (if any).

Okay thanks for for the pointer. What I think is missing are some sentences about what the client (or server) should do if the keep-alive fails. Try to reconnect directly or just with the next request or whatever. Basically who should reconnect and when?

Mirja


>