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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 03 July 2019 10:08 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 401481201EF; Wed, 3 Jul 2019 03:08:30 -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 AhZ9hGsnTMSb; Wed, 3 Jul 2019 03:08:27 -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 46A7212029A; Wed, 3 Jul 2019 03:08:27 -0700 (PDT)
Received: from 200116b82468ed0068c3f61f5d01a906.dip.versatel-1u1.de ([2001:16b8:2468:ed00:68c3:f61f:5d01:a906]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hicBa-0000wj-Rh; Wed, 03 Jul 2019 12:08:22 +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: <787AE7BB302AE849A7480A190F8B93302EAB2BDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Wed, 3 Jul 2019 12:08:22 +0200
Cc: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "dots@ietf.org" <dots@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <747CDE21-58FB-4C6A-B0D8-2686FAA38CCD@kuehlewind.net>
References: <787AE7BB302AE849A7480A190F8B93302EAB2BDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com, Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1562148507;6ffbf5e7;
X-HE-SMSGID: 1hicBa-0000wj-Rh
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/I6O8XBiuDc41XDJY7e0MKFcstJA>
Subject: Re: [Dots] =?utf-8?q?default_port_number_RE=3A___Mirja_K=C3=BChlewin?= =?utf-8?q?d=27s_Discuss_on_draft-ietf-dots-signal-channel-31=3A_=28with_D?= =?utf-8?q?ISCUSS_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: Wed, 03 Jul 2019 10:08:30 -0000

Hi Med,

See below.

> On 3. Jul 2019, at 11:42, <mohamed.boucadair@orange.com>; <mohamed.boucadair@orange.com>; wrote:
> 
> Re-,
> 
> Let's recap:
> 
> (1) The initial objection from the expert is to reuse default CoAP port (5684)
> (2) We clarified why this is not an option
> (3) You agreed "port 5684 is no alternative". 
> (4) You think that dynamic port would be preferable instead of "fixed" (assuming you meant default) because an IP address will be configured anyway. 
> (5) In the meantime you argued that protocols like SIP have "good reason for a fixed port", while RFC3261 says explicitly the following:
> 
> ==
>   A server SHOULD be prepared to receive requests on any IP address,
>                                                     ^^^^ 
>   port and transport combination that can be the result of a DNS lookup
>   ^^^^
>   on a SIP or SIPS URI [4] that is handed out for the purposes of
>   communicating with that server.
> == 

Yes SIP can also use dynamic ports. Anyway... no need to discuss SIP here.

> 
> (6) We provided two address selection logics that can be followed by a DOTS client to ease deployments ** without ** requiring configuring an IP address: 
>  - Assume the default gateway is the DOTS server. This is typically the case where a CPE embeds a DOTS gateway. For this case, the client does not need to be configured explicitly with an IP address/port. Internal hosts/CPE won't be required to be upgraded to support a mechanism to discover the DOTS server. An example of procedure to contact a server would be:
>    --- use any server/port that use explicitly configured
>    --- if not, try the default router.
>  - Make use of anycast for DOTS: /draft-ietf-dots-architecture-14#section-3.2.4 says the following:
> 
>   "benefits, anycast signaling potentially offers the following:
> 
>   o  Simplified DOTS client configuration, including service discovery
>      through the methods described in [RFC7094].  In this scenario, the
>      "instance discovery" message would be a DOTS client initiating a
>      DOTS session to the DOTS server anycast Service Address, to which
>      the DOTS server would reply with a redirection to the DOTS server
>      unicast address the client should use for DOTS."
> 
> Do you want us to include NEW text to discuss this in the draft?

Yes, these are good cases to request a default port. Thanks for clarifying. Unfortunately they are no discussed in this document. I did not read draft-ietf-dots-architecture in detail yet because it has not been in IESG evaluation yet. However, providing a pointer to draft-ietf-dots-architecture-14#section-3.2.4 in this document in section 4.1. would be certainly good. I also didn’t find any discussion in any document about the first case (use of default router). Please also add text in section 4.1 or provide a pointer respectively (maybe I just didn’t find it quickly).

Also looking that these documents it seem to me that draft-ietf-dots-architecture and draf-ietf-dots-server-discovery should probably both be normative references.

And looking att he list of informative references I find it also weird to see draft-ietf-dots-data-channel, draft-ietf-tls-dtls13 (which is now RFC 8446) and draft-ietf-core-yang-cbor there. Looks like you simply put all drafts in the informative category. That’s not how this is supposed to work.

Ben, please double-check the references and provide advise!

Mirja


> 
> Thank you. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Mirja Kuehlewind [mailto:ietf@kuehlewind.net]
>> Envoyé : mardi 2 juillet 2019 16:00
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Konda, Tirumaleswar Reddy; Benjamin Kaduk; 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 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.