Subject: Re: [Dots] WGLC for draft-ietf-dots-multihoming-07

From: <[email-masked]>
Date: Tue, 16 Nov 2021 09:15:38 +0000

Hi Valery, 

Many thanks for the detailed review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Valery Smyslov <[email-masked]>
> Envoyé : vendredi 29 octobre 2021 15:26
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : RE: [Dots] WGLC for draft-ietf-dots-multihoming-07
> 
> Hi,
> 
> here is my review of the draft (sorry for delay).
> 
> [chair hat on]
> 
> First, I'm a bit confused why this is a Standards Track document.
> draft explicitly states that it defines no new protocol, it only contains
> recommendations how applications should deal with multihomed scenarios.
> 
> Isn't Informational or BCP status more appropriate for this document?

[Med] Informational is just OK as the intent is to complement the DOTS arch. Fixed.

> 
> A related issue - the draft has a normative reference to RFC 8811, which
> is an Informational RFC and is not listed in the downref registry.
> If this draft persists as Standards Track document, this should be worked
> around.

[Med] 8811 is cited as normative as we built on that reference architecture. 

> 
> [chair hat off]
> 
> Section 4.
> 
> I might be missing something very obvious, but from my reading of the
> scenarios I have an impression that only those situations when upstream
> network providers are also the DDoS mitigation providers are considered.
> What if you have multiple ISPs and a single independent DDOS mitigation
> provider?

[Med] This is a subcase of the ones that are discussed in the draft. Each of multiple ISPs will provision that independent DDoS server to the CE. The key assumption is that a DOTS server is unambiguously associated with the interconnection link over which it can be used.   

 Or you have several DDOS mitigation providers, and some of them
> are provided by ISPs and some are independent?

[Med] This is also allowed in the current draft as we don't make an assumption of the provisioned DOTS server's name nor wither the same/distinct one are provisioned over each interconnection link:

   *  Each of these provisioning domains assigns IP addresses/prefixes
      to the CPE and provides additional configuration information such
      as a list of DNS servers, DNS suffixes associated with the
      network, default gateway address, and DOTS server's name
                                            ^^^^^^^^^^^^^^^^^^
      [RFC8973].  These addresses/prefixes are assumed to be Provider-
      ^^^^^^^^
      Aggregatable (PA).

Please let me know if you think that an explicit statement is needed to the draft to further clarify the rationale. 

> 
> Section 5.1.
> 
>    For each provisioning domain, the DOTS client MUST resolve the DOTS
>    server's name provided by a provisioning domain ([RFC8973]) using the
>    DNS servers learned from the respective provisioning domain.
> 
> What if explicit configuration (RFC8973, Section 4, item 1) is used?
> If this case this recommendation is unnecessary.

[Med] This text refers to the DOTS server's name, that is also mentioned in (RFC8973, Section 4, item 1):

          "These may be
          specified either as a list of IP addresses or the DNS name of
          a DOTS server."

> 
> Section 5.1.
> 
>    Consequently, if a CPE detects a DDoS attack that spreads over all
>    its network attachments, it MUST contact both DOTS servers for
>    mitigation purposes.
> 
> s/both/all

[Med] Fixed. Thanks.

> 
> Then, it seems to be implied that all network attachments have provided
> CPE with DOTS servers. In this case how can happen what is described
> earlier:
> 
>   This implies that if no appropriate DOTS server is found,
>    the DOTS client MUST NOT send the mitigation request to any other
>    available DOTS server.
> 
> I think that this situation is only possible when some network attachments
> don't provide CPE with DOTS servers.

[Med] Agree. This is to echo this part from the introduction:

   2.  Identify DOTS deployment schemes in a multi-homing context, where
       DOTS services can be offered by all or a subset of upstream
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^      
       providers.

I added this NEW sentence to the intro text of Section 4:

"In the following subsections, all or a subset of interconnection links are associated with DOTS servers."

> 
> Section 5.1.
> 
>    DOTS signaling session to a
>    given DOTS server must be established using the interface from which
>    the DOTS server was provisioned.
> 
> What about explicit configuration, when DOTS server IP is not associated
> with a network interface?

[Med] An interface can also be indicated when explicit configuration is used. If no such information is provided, this means that the address applies for any active interface.  

As a reminder, RFC8973 says the following:

   The results of the discovery procedure are a function of the
                                              ^^^^^^^^^^^^^^^^
   interface/address family.  Contacting a discovered DOTS server via an
   ^^^^^^^^^^
   interface to which it is not bound may exacerbate the delay required
   to establish a DOTS channel.  Moreover, such behavior may reveal that
   a DOTS service is enabled by a DOTS client domain and exposes the
   identity of the DOTS service provider (which can be inferred from the
   name and the destination IP address) to external networks.

> 
> Section 5.2.
> 
> I think the readability would benefit from moving pictures 6 and 7 closer
> to the text that refers to them. Currently they are almost half page
> apart.

[Med] Sure. Moved up. 

> 
> Section 5.2.
> 
>    Each DOTS client SHOULD be provided with policies (e.g., a prefix
>    filter that will be against DDoS detection alarms) that will trigger
>    DOTS communications with the DOTS servers.  Such policies will help
>    the DOTS client to select the appropriate destination DOTS server.
> 
> It's unclear for me to which scenario this recommendation applies.
> In Figure 8 each DOTS client may communicate only with a single DOTS
> server.

[Med] It applies to both figure 7/8. Clients in Figure 8 may still receive detection alarms on resources that are not handled by their peer DOTS server.  

> 
> Related question - why SHOULD (and not MUST)?.  What if clients are not
> provided with these policies?

[Med] SHOULD is used because in Figure 8 some filters may be applied when directing alarms to DOTS clients. 

> 
> Section 5.2.
> 
>    The CPE MUST select the appropriate source IP address when forwarding
>    DOTS messages received from an internal DOTS client.  If anycast
>    addresses are used to reach multiple DOTS servers, the CPE may not be
>    able to select the appropriate provisioning domain to which the
>    mitigation request should be forwarded.  As a consequence, the
>    request may not be forwarded to the appropriate DOTS server.
> 
> I'm confused. What to do in this case? Using anycast addresses is NOT
> RECOMMENDED (earlier), but is not prohibited.
> I believe better recommendations should be given for this case.
> 

[Med] The risk here is that the mitigation request will be rejected by the DOTS server to which the CPE decided to froward the request. If the CPE embeds a DOTS gateways, the situation can be better as it may use a sequential mode. I think that NOT RECOMMENDED is appropriate. 

> Section 5.3.
> 
> Again, I think it's worth to move Figure 9 closer to the text that refers
> to it.

[Med] Done. 

> 
> Section 5.3.
> 
>    The use of anycast addresses
>    to establish DOTS sessions between DOTS clients and DOTS gateways is
>    not an option.
> 
> What does "is not an option" mean?

[Med] It means that it is not a valid technical solution to fulfil the "MUST contact all" requirement, as by definition, only one will be selected. 

 MUST NOT be used? Or impossible to use?

> 
> Section 6.
> 
>    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.
> 
> How this rule can be followed when DOTS clients send requests to all
> available DOTS servers (with PI scenarios)?

[Med] In such case, the "information specific to a given link" will point to the target (PI@) that is authorized to be revealed to all servers. 

> 
> Regards,
> Valery.
> 
> 
> > Hi,
> >
> > this message starts a two-week working group last call for draft-ietf-
> dots-multihoming-07.
> > The WGLC will end on Monday, October 25. Please, review the draft and
> > send your comments to the mailing list.
> >
> > Regards,
> > Frank & Valery.
> >
> > _______________________________________________
> > Dots mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots

_________________________________________________________________________________________________________________________

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: "Valery Smyslov" <[email-masked]>
Date: Fri, 19 Nov 2021 11:50:52 +0300

HI Med,

please see inline.

> [Med] Informational is just OK as the intent is to complement the DOTS arch. Fixed.

Good.

> [Med] 8811 is cited as normative as we built on that reference architecture.

That's OK if you changed intended status to Informational.

> [Med] This is a subcase of the ones that are discussed in the draft. Each of multiple ISPs will provision that
> independent DDoS server to the CE. The key assumption is that a DOTS server is unambiguously associated
> with the interconnection link over which it can be used.

Well, what if the independent DOTS server is configured manually, not provisioned by ISPs?
Is it possible (and how) to use it with only subset of ISPs?

> [Med] This is also allowed in the current draft as we don't make an assumption of the provisioned DOTS
> server's name nor wither the same/distinct one are provisioned over each interconnection link:
> 

I think it's worth to to clarify situation with manually configured independent DOTS servers,
when some of them can be used with only a subset of ISPs. 

>           specified either as a list of IP addresses or the DNS name of

That's what my concern is. The draft says that you MUST resolve DOTS server's name provided by a PD
using the DNS servers from the same PD. So, what if DOTS server's name was configured manually,
not learned from PD - what DNS server to use to resolve it? Any? Should this be more explicit in the text?

>        DOTS services can be offered by all or a subset of upstream

OK.

> [Med] An interface can also be indicated when explicit configuration is used. If no such information is
> provided, this means that the address applies for any active interface.

Please, add this clarification.

>    The results of the discovery procedure are a function of the

It is not clear. Previously the draft says:

   Another deployment approach is to enable many DOTS clients; each of
   them is responsible for handling communications with a specific DOTS
                                                                                                           ^^^^^^^
   server (see Figure 8).

Probably some clarification is needed.

> [Med] SHOULD is used because in Figure 8 some filters may be applied when directing alarms to DOTS clients.

I read the sentence "Each DOTS client SHOULD be provided with policies..."
that under some conditions it's OK to not provide clients with policies (filters) at all,
that's why my question. My understanding, that they MUST be provided
always, but the policies may differ. Am I missing something?

> [Med] The risk here is that the mitigation request will be rejected by the DOTS server to which the CPE
> decided to froward the request. If the CPE embeds a DOTS gateways, the situation can be better as it may use
> a sequential mode. I think that NOT RECOMMENDED is appropriate.

So it's just an explanation why using anycast is not recommended?
Then, can you move it closer to the recommendation not to use anycast?

>  MUST NOT be used? Or impossible to use?

"Cannot be used, because <explanation>" ?

> be revealed to all servers.

OK.

Regards,
Valery.

---

From: <[email-masked]>
Date: Tue, 23 Nov 2021 14:07:03 +0000

Hi Valery,

Thank you for the follow-up. 

The changes to address your comments can be tracked at: https://tinyurl.com/dots-multihoming-latest.

Please see inline for more context. 

Cheers,
Med

> De : Valery Smyslov <[email-masked]>
> Envoyé : vendredi 19 novembre 2021 09:51
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; 'Valery
> Smyslov' <[email-masked]>; [email-masked]
> > > draft explicitly states that it defines no new protocol, it only
> > > contains recommendations how applications should deal with multihomed
> scenarios.
> > >
> > > A related issue - the draft has a normative reference to RFC 8811,
> > > which is an Informational RFC and is not listed in the downref
> registry.
> > > If this draft persists as Standards Track document, this should be
> > > worked around.
> >

[Med] ACK.

> 
> > > [chair hat off]
> > >
> > > Section 4.
> > >
> > > I might be missing something very obvious, but from my reading of
> > > the scenarios I have an impression that only those situations when
> > > upstream network providers are also the DDoS mitigation providers are
> considered.
> > > What if you have multiple ISPs and a single independent DDOS
> > > mitigation provider?
> >
> > [Med] This is a subcase of the ones that are discussed in the draft.
> > Each of multiple ISPs will provision that independent DDoS server to
> > the CE. The key assumption is that a DOTS server is unambiguously
> associated with the interconnection link over which it can be used.
> 

[Med] Added this NEW text:

A multihomed network may enable DOTS for all or a subset of its	
upstream interconnection links.  In such a case, DOTS servers can be	
explicitly configured or dynamically discovered by a DOTS client	
using means such as those discussed in [RFC8973].  These DOTS servers	
can be owned by the upstream provider, managed by a third-party	
(e.g., mitigation service provider), or a combination thereof.	
	 		
If a DOTS server is explicitly configured, it is assumed that an	
interface is also provided to bind the DOTS service to an	
interconnection link.  If no interface is provided, this means that	
the DOTS server can be reached via any active interface.

> > [Med] This is also allowed in the current draft as we don't make an
> > assumption of the provisioned DOTS server's name nor wither the
> same/distinct one are provisioned over each interconnection link:
> >
> > Please let me know if you think that an explicit statement is needed
> > to the draft to further clarify the rationale.
> 
> I think it's worth to to clarify situation with manually configured
> independent DOTS servers, when some of them can be used with only a subset
> of ISPs.

[Med] Covered by the NEW text above and this one: 

In the following subsections, all or a subset of interconnection	
links are associated with DOTS servers.

> That's what my concern is. The draft says that you MUST resolve DOTS
> server's name provided by a PD using the DNS servers from the same PD. So,
> what if DOTS server's name was configured manually, not learned from PD -
> what DNS server to use to resolve it? Any? Should this be more explicit in
> the text?

[Med] Made this change:

OLD:
   For each provisioning domain, the DOTS client MUST resolve the DOTS
   server's name provided by a provisioning domain [RFC8973] using the
   DNS servers learned from the respective provisioning domain.

NEW:
   For each provisioning domain, the DOTS client MUST resolve the DOTS
   server's name provided by a provisioning domain [RFC8973] using the
   DNS servers learned from the respective provisioning domain (or the
   DNS servers associated with the interface(s) for which a DOTS server
   was explicitly configured).

> 
> > > Then, it seems to be implied that all network attachments have
> > > provided CPE with DOTS servers. In this case how can happen what is
> > > described
> > > earlier:
> > >
> > > I think that this situation is only possible when some network
> > > attachments don't provide CPE with DOTS servers.
> >
> > > What about explicit configuration, when DOTS server IP is not
> > > associated with a network interface?
> >
> > [Med] An interface can also be indicated when explicit configuration
> > is used. If no such information is provided, this means that the address
> applies for any active interface.
> 

[Med] Done. 

> > [Med] It applies to both figure 7/8. Clients in Figure 8 may still
> > receive detection alarms on resources that are not handled by their peer
> DOTS server.
> 

[Med] Added "For both deployments depicted in Figures 7 and 8 ..."

> 
> > > Related question - why SHOULD (and not MUST)?.  What if clients are
> > > not provided with these policies?
> >
> that under some conditions it's OK to not provide clients with policies
> (filters) at all, that's why my question. My understanding, that they MUST
> be provided always, but the policies may differ. Am I missing something?

[Med] This can't be a MUST as the filtering can be on the alarms themselves before being known to the DOTS client.

> > > I'm confused. What to do in this case? Using anycast addresses is
> > > NOT RECOMMENDED (earlier), but is not prohibited.
> > [Med] The risk here is that the mitigation request will be rejected by
> > the DOTS server to which the CPE decided to froward the request. If
> > the CPE embeds a DOTS gateways, the situation can be better as it may
> use a sequential mode. I think that NOT RECOMMENDED is appropriate.
> 

[Med] Done. Thanks.

> > [Med] It means that it is not a valid technical solution to fulfil the
> > "MUST contact all" requirement, as by definition, only one will be
> selected.
> >

[Med] Updated the text as suggested. 

> > [Med] In such case, the "information specific to a given link" will
> > point to the target (PI@) that is authorized to be revealed to all
> servers.
> 
> OK.
> 
> Regards,
> Valery.
>