Subject: Re: [Dots] Opsdir early review of draft-ietf-dots-multihoming-09

From: <[email-masked]>
Date: Mon, 3 Jan 2022 13:28:02 +0000

Hi Joel, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Joel Jaeggli via Datatracker <[email-masked]>
> Envoyé : jeudi 23 décembre 2021 21:19
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Opsdir early review of draft-ietf-dots-multihoming-09
> 
> Reviewer: Joel Jaeggli
> Review result: Has Nits
> 
> I have reviewed draft-ietf-dots-multihoming-09 for on behalf of the
> operations and and management area directorate. While I think this
> document is largely complete, I have a couple of questions ab out the ways
> in which is proposes to implment the various cases which may or may not
> add clarity to the document.
> 
> It would seem that the chief difference between the residential CPE case
> and the enterprise case would seem to be the intercession of BGP,  Who
> manages the CPE from the vantage point of configuration,

[Med] As indicated in the introduction of Section 4, the main difference between the two is that provider independent addressing is only used for enterprises, not residential CPEs. Other aspects such as CE-PE routing, management control, etc. are not specific. There are of course some differences in the technical realization such as activating a dynamic routing protocol in the CE-PE link vs. static routing but we don't think that's important when it comes to signaling attacks. 

> 
> In practice I don't see a meaningful difference between a single CPE and
> multiple CPEs in the enterprise case (5.2/5.3)

[Med] There are similarities but there are also implications, e.g., when it comes to deploying gateways in each of these CPEs or when each of these CPEs is manipulating a dedicated prefix, etc. 

, source address selection
> is a coordination problem in either case?

[Med] This one is applicable to both, however the multi-CPE has also to deal with the selection of the appropriate exit (CPE). This is called out in: 

   The deployments depicted in Figures 7 and 8 also apply to the
   scenario described in Section 4.3.  One specific problem for this
   scenario is to select the appropriate exit router when contacting a
   given DOTS server.

 but in fact that's mostly a
> coordination problem.  selecting the path to the dots server(s) can be
> achieved via route selection if no mechanism for signaling routes between
> CPEs that seems like a serious limitation.
> 
> In a multihoming scenario involving a provider assigned prefix the prefix
> may well be both deaggrated for a large provider assignment and advertised
> to both providers (e.g. I have an office which receives a /24 assignment
> from lumen and also advertises that self same prefix to zayo), in this
> case the prefix must be advertised de-aggregated to both providers.
> enterprise pa assignments of this form are necessarily equivalent to pi
> prefixes from a usage standpoint. which ip is used for dots signaling in
> cases like this is necessarily a problem of coordination whether it be the
> cpe/router peer interface, router loopback, or some other source ip
> enclosed within the assigned prefix (or indeed some other prefix).
> 
> > When PI addresses/prefixes are used, DOTS clients MUST contact all the
> > DOTS
> gateways to send a DOTS message.
> 
> When engaged in DOS related signaling not all dos attacks are in fact
> distributed, when attack traffic is unspoffed as it is in most upper layer
> targeting attacks it must necessarily follow a consistent path per
> attacker, moreover, your telemetry may well tell you which ingress
> interface and therefore provider needs to receive which signaling sending
> them to un-impacted providers unnecessary and may result in unintentional
> information leakage.

[Med] The clients do not know the gateway(s) from which the attack traffic is received. This is why they have to solicit all the gateways. 

> 
> >   The use of anycast addresses is NOT RECOMMENDED to reach DOTS
> gateways.
> 
> provider specific anycasts do not in principle seem worse then  provider

[Med] It is in this case as it prevents contacting all gateways while unicast allows for it. This is covered by this text:

   Note that anycast addresses
   cannot be used to establish DOTS sessions between DOTS clients and
   DOTS gateways because only one DOTS gateway will receive the
   mitigation request.

Please note that all these gateways are part of the same network. 

> specific unicasts, they allow a provider reduce the ammount of
> coordination required within their own infrastructure.

[Med] Agree. Added a pointer to Section 3.2.4 of RFC8811 for this part.

 assigning a well
> know anycast for this purpose among all providers on the other hand sounds
> like a terrible idea, for the reasons that well known-anycasts are
> generally bad.
> 

_________________________________________________________________________________________________________________________

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: Joel Jaeggli <[email-masked]>
Date: Mon, 3 Jan 2022 10:06:52 -0800

> [Med] The clients do not know the gateway(s) from which the attack traffic is received. This is why they have to solicit all the gateways.
I find that dubious if you're receiving packet related telemetery in 
order to identify ddos in the first place finding where it ingressed 
your network is fairly critical (we do this with IPFIX, have been doing 
it for more than a decade) source based rtbh/bgp flow spec 
implementation which is the precursor to this work more or less assume 
you can identify the provider to signal. Assuming that you cannot, the 
question of information leakage persists, and should be noted, as you 
are signaling to a provider that  may or may not be a conduit of the 
attack that you are being attacked, and likewise may unintentionally 
make the attack more effective by applying ip based mitigitations to 
paths over which legitimate rather than attack traffic is traversing.
> Please note that all these gateways are part of the same network.
in practice you probably don't need signal all of them, potentially in a 
large provider there are hundreds, if you have one or few ingress points 
from a provider to your network you don't need to signals many upsteam 
dots servers in order for the provider to install a mitigiation, one is 
sufficient.

---

From: <[email-masked]>
Date: Tue, 4 Jan 2022 08:40:18 +0000

Hi Joel,

Thank you for the follow-up. Much appreciated. 

Made some changes to address your comments. The changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-multihoming-10.

Please see inline for more context. 

Cheers,
Med

> De : Joel Jaeggli <[email-masked]>
> Envoyé : lundi 3 janvier 2022 19:07
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; ops-
> [email-masked]
> Objet : Re: Opsdir early review of draft-ietf-dots-multihoming-09
> 
> 
[...]
> >>
> >>> When PI addresses/prefixes are used, DOTS clients MUST contact all
> >>> the DOTS
> >> distributed, when attack traffic is unspoffed as it is in most upper
> >> layer targeting attacks it must necessarily follow a consistent path
> >> per attacker, moreover, your telemetry may well tell you which
> >> ingress interface and therefore provider needs to receive which
> >> signaling sending them to un-impacted providers unnecessary and may
> >> result in unintentional information leakage.
> > [Med] The clients do not know the gateway(s) from which the attack
> traffic is received. This is why they have to solicit all the gateways.
> I find that dubious if you're receiving packet related telemetery in order
> to identify ddos in the first place finding where it ingressed your
> network is fairly critical (we do this with IPFIX, have been doing it for
> more than a decade) source based rtbh/bgp flow spec implementation which
> is the precursor to this work more or less assume you can identify the
> provider to signal.

[Med] Yes but not all client domains have these capabilities. The DOTS client can be embedded in a router, a host, etc. 

 Assuming that you cannot, the question of information
> leakage persists

[Med] The leakage does not happen when an internal client signals an attack to an internal gateway (which the text you quoted is about). Updated the draft to make it clear the gateways are "client-domain DOTS gateways". 

The leakage concern is more between the gateway and an external server. I think this issue is covered by this text:

   DOTS clients should control the information that they share with peer
   DOTS servers.  In particular, if a DOTS client maintains DOTS
   associations with specific DOTS servers per interconnection link, the
   DOTS client SHOULD NOT leak information specific to a given link to
   DOTS servers on different interconnection links that are not
   authorized to mitigate attacks for that given link.  Whether this
   constraint is relaxed is deployment-specific and must be subject to
   explicit consent from the DOTS client domain administrator.  How to
   seek for such consent is implementation- and deployment-specific.

This text applies to the "client" side of a dots gateway. As a reminder, RFC8612 says the following:

   DOTS gateway:  A DOTS-aware software module resulting from the
      logical concatenation of the functionality of a DOTS server and a
      DOTS client into a single DOTS agent.  This functionality is
      analogous to a Session Initiation Protocol (SIP) [RFC3261] Back-
      to-Back User Agent (B2BUA) [RFC7092].  A DOTS gateway has a
      client-facing side, which behaves as a DOTS server for downstream
      clients, and a server-facing side, which performs the role of a
      DOTS client for upstream DOTS servers.  Client-domain DOTS
      gateways are DOTS gateways that are in the DOTS client's domain,
      while server-domain DOTS gateways denote DOTS gateways that are in
      the DOTS server's domain.  A DOTS gateway may terminate multiple
      discrete DOTS client connections and may aggregate these into one
      or more connections.  DOTS gateways are described further in
      [DOTS-ARCH].

, and should be noted, as you are signaling to a provider
> that  may or may not be a conduit of the attack that you are being
> attacked, and likewise may unintentionally make the attack more effective
> by applying ip based mitigitations to paths over which legitimate rather
> than attack traffic is traversing.

[Med] Made this change so that propagating the signal is policy-based:   

OLD: 
   DOTS gateways will then
   relay the request to the DOTS servers.

NEW:
   DOTS gateways will then
   relay the request to the DOTS servers as a function of local policy.

> > [Med] It is in this case as it prevents contacting all gateways while
> unicast allows for it. This is covered by this text:
> >

[Med] I agree but the case we are describing here assumes that each gateway is interfaced with a distinct provisioning domain. For this case, contacting only one server won’t be sufficient if the attack traffic is received via all links.  

> >> know anycast for this purpose among all providers on the other hand
> >> sounds like a terrible idea, for the reasons that well known-anycasts
> >> are generally bad.
> >>
> >