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

[[e-mail]]

Hi Valery, 

Many thanks for the detailed review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Valery Smyslov <[e-mail]>
> Envoyé : vendredi 29 octobre 2021 15:26
> À : [e-mail]
> Cc : [e-mail]; [e-mail]
> 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
> > [e-mail]
> > 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.