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

From: <[email-masked]>
Date: Thu, 10 Dec 2020 13:47:33 +0000

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:[email-masked]]
> Envoyé : mercredi 25 novembre 2020 05:25
> Cc : [email-masked]; [email-masked]; [email-masked];
> BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> 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.

---

From: "Sabrina Tanamal via RT" <[email-masked]>
Date: Tue, 15 Dec 2020 23:35:31 +0000

Hi Med, all, 

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

On Thu Dec 10 13:47:58 2020, [email-masked] 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.
> 
> 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.).
> 
> 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).
> 
> 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.
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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,
> This message and its attachments may contain confidential or
> privileged information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 16 Dec 2020 12:23:59 +0000

Hi Sabrina, 

Thank you for relaying the response. 

DOTS call home is not a "reverse service" of DOTS signal channel and is a "fully decoupled" service. FWIW, simplified flow examples for how these services are accessed, are depicted below: 

(1) DOTS Signal Channel:
           +-----------+                        +-----------+
           |    DOTS   |                        |    DOTS   |
           |   client  |                        |   server  |
           +-----+-----+                        +-----+-----+
                 |                                    |
                 |            (D)TLS connection       |
                 |----------------------------------->|
                 |              ...                   |

(2) Call Home: 
           +-----------+                        +-----------+
           | Call Home |                        | Call Home |
           |    DOTS   |                        |    DOTS   |
           |   server  |                        |   client  |
           +-----+-----+                        +-----+-----+
                 |                                    |
                 |            (D)TLS connection       |
                 |----------------------------------->|
                 |              ...                   |

When a DTLS connection is received by a device enabling both services ("DOTS server" service and "call home DOTS client") on the same port, based on which criteria the request will be steered to the "DOTS server" service or the "call home DOTS client" service?

It is all about the (D)TLS session initiation using UDP connecting to two different, fully decoupled, services (a server and a client) and how received traffic is determined to be going to the server or the client service.  With UDP, only a single application can "listen" on a network stack for traffic being received on a dedicated port.

Cheers,
Jon, Tiru, and Med

> Envoyé : mercredi 16 décembre 2020 00:36
> Cc : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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.
> 
> ===
> 
> > (4) Why not using a dynamic port number following, e.g., draft-
> ietf-
> > dots-server-discovery?
> >
> 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
> > | the DOTS client following the procedure discussed in  Section
> 4.6 or
> > | (2) relayed to a unicast DOTS server.
> >
> > > Envoyé : mercredi 25 novembre 2020 05:25 Cc :
> [email-masked];
> > > [email-masked]; [email-masked]; BOUCADAIR Mohamed
> TGI/OLN
> > > <[email-masked]>; [email-masked];
> [email-masked];
> > > [email-masked] Objet : [IANA #1181897] expert review
> for
> > > draft-ietf-dots-signal- call-home (service-names-port-numbers)
> > >
> > > Dear Authors,
> > >
> ____________________________________________________________________
> __
> > ___________________________________________________
> >
> > 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.
> >
> > 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.
> 
> <p></p>