[Dots] [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers)

[Sabrina Tanamal via RT <[e-mail]>]

Hi Med, all, 

We have a response from the IESG-designated port expert: 

This doesn’t look like a new service; it appears more like a reverse version of the existing service. IMO, if that’s the case, they should use the existing assignment because the two services would not be fully decoupled.

===

Please let us know if you have any further comments/questions for the expert. 

Best regards, 

Sabrina Tanamal
Senior IANA Services Specialist

On Thu Dec 10 13:47:58 2020, [e-mail] wrote:
> Hi Sabrina,
> 
> Apologies for the delay to reply, but we were assessing and analyzing
> whether/how to follow this suggestion from the Expert review: "use two
> different messages on the same port". We also contacted the
> implementers to help us in the assessment. We dived as well into other
> WGs archives to see if we can leverage whatever tweak they have found
> to solve similar problem in their context. In particular, we checked
> netconf wg archives to see how they dealt with disambiguating
> NETCONF/RESTONF vs. NETCONF/RESTONF Call Home) (RFC8071).
> 
> Our conclusion is that the above suggestion can't be followed,
> especially that we don't define the transport but rely upon existing
> ones.
> 
> Please find below more about our rationale.
> 
> (1) Is this a new service or could an existing service suffice?
> 
> DOTS Call Home is a new service.
> 
> The DOTS signal traffic is primarily DTLS/UDP and there are two
> distinct services - DOTS client and DOTS server.  In the normal DOTS
> environment, the DOTS client initiates the DTLS connection to the DOTS
> server who, by default, is waiting for traffic to arrive on 4646/udp.
> 
> In the DOTS call-home environment (i.e., this specification), the DOTS
> call-home server initiates the DTLS connection to the DOTS call-home
> client and then the DOTS (call-home) client communicates in the same
> way with the DOTS (call-home) server as for the normal environment
> apart from a couple of specific differences (to do with session
> restart, etc.).
> 
> (2)  Is this service independently useful?
> 
> Yes.
> 
> This service is about mitigating DDoS attacks close to their source.
> Concretely, this service is about protecting the Internet from DDoS
> attacks coming from a given domain (outbound), while DOTS signal
> (4646/udp) is about protecting a given domain from DDoS attacks coming
> from the Internet (Inbound).
> 
> Both services (outbound protection/inbound protection) are useful.
> 
> A customer can subscribe to both or only one of them.
> 
> (3) Why two port numbers are needed?
> 
> It is likely that a DOTS server service will co-exist with a DOTS
> call-home client service behind the same IP address and be receiving
> both types of inbound traffic concurrently - some being DOTS server,
> and some being DOTS call-home client. It is possible that a DOTS
> client service can co-exist with a DOTS call-home server service on an
> appliance.
> 
> When a DTLS connection is received by a device hosting both DOTS
> server service and DOTS call-home client service, it does not know
> which service is invoked. ** Disambiguating these two services is thus
> required **.
> 
> As there is no simple way to steer inbound UDP/DTLS traffic going to
> the same UDP port on the same IP to 2 separate, incompatible services,
> the DOTS server and DOTS call-home client have to be listening on 2
> discrete ports.
> 
> The overhead of re-directing traffic to use a different port (DTLS
> handshake setup, application redirect packet, new DTLS handshake
> setup) is unacceptable given that the DOTS protocols will get used in
> environments where there are DDoS attacks and hence traffic loss.
> 
> This is already discussed in Appendix A of the draft.
> 
> (4) Why not using a dynamic port number following, e.g., draft-ietf-
> dots-server-discovery?
> 
> That might be possible in some contexts (e.g., the mitigation provider
> is also the access provider), nevertheless such tools are not useful,
> e.g., when no ** explicit IP address configuration ** is involved and
> the agent auto-discovers its. This is similar to these cases discussed
> in RFC8782:
> 
> |  Particularly, the use of a default port number is meant to
> |  simplify DOTS deployment in scenarios where no explicit IP
> |  address configuration is required.  For example, the use of the
> |  default router as the DOTS server aims to ease DOTS deployment
> |  within LANs (in which CPEs embed a DOTS gateway as illustrated
> |  in Figures 1 and 2) without requiring a sophisticated discovery
> |  method and configuration tasks within the LAN.  It is also
> |  possible to use anycast addresses for DOTS servers to simplify
> |  DOTS client configuration, including service discovery.  In
> |  such an anycast-based scenario, a DOTS client initiating a DOTS
> |  session to the DOTS server anycast address may, for example, be
> |  (1) redirected to the DOTS server unicast address to be used by
> |  the DOTS client following the procedure discussed in
> |  Section 4.6 or (2) relayed to a unicast DOTS server.
> 
> Even for cases where draft-ietf-dots-server-discovery can be used,
> learning the port number will require to pass the discovered reference
> to a DNS library (DNS-SD or S-NAPTR). If a DDoS attack is occurring,
> DNS services may not be available for the call-home DOTS server to
> use. Which is problematic to provide the service if the session is not
> established prior to an attack is detected. Obviously, no issue is
> encountered if the session is established din idle time.
> 
> Of course, if manual configuration is used for IP address
> configuration, the port number can be supplied as well.
> 
> (5) Why not mandating running the services on distinct devices?
> 
> As discussed in the draft, a deployment option is to run the services
> using distinct IP addresses. In such case, no problem is encountered
> even if the same port number is used for both services.
> 
> Nevertheless, we can't mandate this deployment option and it is up to
> the taste of operator to decide whether to run the services on the
> same or distinct machines.
> 
> (6) Disambiguating at DOTS Gateways
> 
> The presence of gateways on the path is also challenging even if the
> ultimate services are running on distinct IP addresses. Gateways must
> have means to decide whether a message is to be destined to DOTS
> server service or DOTS call-home DOTS client service.
> 
> Requiring segregating gateways for each of the services is not viable.
> 
> (7) Implementation complexity
> 
> Let's assume that by some "magic" we can demux the two services.
> 
> After the receiving the response from the Expert, the authors have
> checked with the two main designers of the two different DOTS
> implementations (one proprietary and one open source) and both of them
> have said that it would take significant work to merge the DOTS client
> and server service logic into a single entity.  They are also
> concerned with combined server/client service functionality running on
> constrained devices where there are RAM space limitations, etc.
> 
> Cheers,
> Jon, Tiru, and Med
> 
> > -----Message d'origine-----
> > De : Sabrina Tanamal via RT [mailto:[e-mail]]
> > Envoyé : mercredi 25 novembre 2020 05:25
> > Cc : [e-mail]; [e-mail]; [e-mail];
> > BOUCADAIR Mohamed TGI/OLN <[e-mail]>;
> > [e-mail]; [e-mail]; [e-mail]
> > Objet : [IANA #1181897] expert review for draft-ietf-dots-signal-
> > call-home (service-names-port-numbers)
> >
> > Dear Authors,
> >
> > Have you had a chance to review the expert's comments below?
> > Let us know if you have any comments/questions for the expert.
> >
> > Thank you,
> >
> > Sabrina Tanamal
> > Senior IANA Services Specialist
> >
> > On Thu Nov 12 22:42:48 2020, sabrina.tanamal wrote:
> > > Dear Authors,
> > >
> > > We have a response from the IESG-designated port expert:
> > >
> > > I do not see sufficient reason for a second port assignment to be
> > made
> > > for this single system. At best, they should just use two
> > different
> > > messages on the same port.
> > >
> > > This request should not be considered in isolation; it is coupled
> > to
> > > https://tools.ietf.org/html/draft-ietf-dots-server-discovery.
> > >
> > > One service, one port.
> > >
> > > ===
> > >
> > > Best regards,
> > >
> > > Sabrina Tanamal
> > > Senior IANA Services Specialist
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> Thank you.