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

mohamed.boucadair@orange.com Thu, 10 December 2020 13:47 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 7696C3A0E05 for <dots@ietfa.amsl.com>; Thu, 10 Dec 2020 05:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Level:
X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 k30g2VNxH1Gs for <dots@ietfa.amsl.com>; Thu, 10 Dec 2020 05:47:37 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E5C3A0DBD for <dots@ietf.org>; Thu, 10 Dec 2020 05:47:37 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4CsFbV4nDNz8tPR; Thu, 10 Dec 2020 14:47:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607608054; bh=zt9eCeZmqtYz0nTyyxGA4T59rW9wp4qhicfvKz2x1Ao=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gDzrOuJDT7AVy3BwPrJEGQVZ7CVorWrVSpxGfnOq4CPV0zUMWZ4VrnJSa4bgtALLX +wcq7hjnyNp/xkHtLrKgyzZPK4Mx2EFO3A0tm26FqhRB9/6rDEbFyvG/pmOxdfFFtj ouS18Ke3dB2tPKMhRGF52xvKuQ0EehlQSe0zeDgesiiSJRNj3JOJmSWGI14/R2MA6Z wcRR2LJBErS4mVsIoMU59ZHKsm2JLxgBsvI0cA9Az448NdXmbmpn5pQAELHhUU067b o3SQ64TvghfjZcZ6/T8MXPmpLGUvwtiJoSFVLJTIBSXKWGrKkCWFcfzG5QI6jsrGRD vaCXy/HQIo66g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4CsFbV2vLrz2xCF; Thu, 10 Dec 2020 14:47:34 +0100 (CET)
From: <mohamed.boucadair@orange.com>
To: "drafts-expert-review@iana.org" <drafts-expert-review@iana.org>
CC: "valery@smyslov.net" <valery@smyslov.net>, "supjps-ietf@jpshallow.com" <supjps-ietf@jpshallow.com>, "rdd@cert.org" <rdd@cert.org>, "kondtir@gmail.com" <kondtir@gmail.com>, "kaduk@mit.edu" <kaduk@mit.edu>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers)
Thread-Index: AQHWwuLkY+Qj0c2wkEKUoOjXl2KQnanwahAQ
Date: Thu, 10 Dec 2020 13:47:33 +0000
Message-ID: <7476_1607608054_5FD226F6_7476_116_1_787AE7BB302AE849A7480A190F8B93303159B1FD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <RT-Ticket-1181897@icann.org> <rt-4.4.3-16672-1604531738-1164.1181897-37-0@icann.org> <rt-4.4.3-20454-1605220968-1234.1181897-37-0@icann.org> <rt-4.4.3-11631-1606278277-1846.1181897-37-0@icann.org>
In-Reply-To: <rt-4.4.3-11631-1606278277-1846.1181897-37-0@icann.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c>
Subject: Re: [Dots] [IANA #1181897] expert review for draft-ietf-dots-signal-call-home (service-names-port-numbers)
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: Thu, 10 Dec 2020 13:47:42 -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:drafts-expert-review@iana.org]
> Envoyé : mercredi 25 novembre 2020 05:25
> Cc : valery@smyslov.net; supjps-ietf@jpshallow.com; rdd@cert.org;
> BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>om>;
> kondtir@gmail.com; kaduk@mit.edu; frank.xialiang@huawei.com
> 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.