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

[<[e-mail]>]

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.
== 

(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?

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.