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, 03 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] default port number RE: Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)
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.
- [Dots] default port number RE: Mirja Kühlewind's … mohamed.boucadair
- Re: [Dots] default port number RE: Mirja Kühlewin… Mirja Kuehlewind
- Re: [Dots] default port number RE: Mirja Kühlewin… Mirja Kuehlewind
- Re: [Dots] default port number RE: Mirja Kühlewin… mohamed.boucadair