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

[[e-mail]]

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

> -----Message d'origine-----
> De : Sabrina Tanamal via RT [mailto:[e-mail]]
> Envoyé : mercredi 16 décembre 2020 00:36
> Cc : BOUCADAIR Mohamed TGI/OLN <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : [IANA #1181897] expert review for draft-ietf-dots-signal-
> call-home (service-names-port-numbers)
> 
> 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:drafts-expert-
> [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.
> 
> <p></p>


_________________________________________________________________________________________________________________________

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.