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

[Mirja Kuehlewind <[e-mail]>]

Hi Med,

See below.

> On 3. Jul 2019, at 11:42, <[e-mail]> <[e-mail]> 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:[e-mail]]
>> Envoyé : mardi 2 juillet 2019 16:00
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Konda, Tirumaleswar Reddy; Benjamin Kaduk; draft-ietf-dots-signal-
>> [e-mail]; [e-mail]; [e-mail]; The IESG;
>> [e-mail]
>> 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, <[e-mail]>
>> <[e-mail]> wrote:
>>> 
>>> Hi Mirja, all,
>>> 
>>> (removing resolved items).
>>> 
>>> Please see inline.
>>> 
>>> Cheers,
>>> Tiru & Med
>>> 
>>>> -----Message d'origine-----
>>>> De : Mirja Kuehlewind [mailto:[e-mail]]
>>>> Envoyé : lundi 1 juillet 2019 18:21
>>>> À : Konda, Tirumaleswar Reddy; Benjamin Kaduk
>>>> Cc : [e-mail];
>> [e-mail];
>>>> [e-mail]; The IESG; [e-mail]
>>>> 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
>>>> <[e-mail]> wrote:
>>>>> 
>>>>> Please see inline
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Dots <[e-mail]> On Behalf Of Benjamin Kaduk
>>>>>> Sent: Saturday, June 29, 2019 3:51 AM
>>>>>> To: Mirja Kühlewind <[e-mail]>
>>>>>> Cc: [e-mail];
>> [e-mail];
>>>>>> [e-mail]; The IESG <[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,
>>>>>> 
>>>>>> 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.