Re: [Dots] Robert Wilton's No Objection on draft-ietf-dots-multihoming-11: (with COMMENT)

[[e-mail]]

Hi Rob, 

Thanks for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Robert Wilton via Datatracker <[e-mail]>
> Envoyé : mercredi 20 avril 2022 18:52
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Robert Wilton's No Objection on draft-ietf-dots-
> multihoming-11: (with COMMENT)
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-dots-multihoming-11: No Objection
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-multihoming/
> 
> 
> 
> ------------------------------------------------------------------
> ----
> COMMENT:
> ------------------------------------------------------------------
> ----
> 
> Hi,
> 
> Thanks for this document.
> 
> Two comments on section 5.1:
> 
> 1.
>    The DOTS client MUST resolve the DOTS server's name provided by
> each
>    provisioning domain using either the DNS servers learned from
> the
>    respective provisioning domain or from the DNS servers
> associated
>    with the interface(s) for which a DOTS server was explicitly
>    configured (Section 4).
> 
> It wasn't clear to me why the DNS lookup MUST be done relative to
> each
> provisioning domain?
> 

[Med] This is because randomly using any available DNS server may lead to failures or exacerbate resolution delays. Note that the name may be local to an attachment network. 

> 2.
>    DOTS signaling
>    session to a given DOTS server must be established using the
>    interface from which the DOTS server was provisioned.
> 
> If I have read and understood the draft correctly that it also
> seems that
> requests to ask a DOTS server to mitigate an attack must also be
> done on the
> same interface on which that attack is occurring.  Is my
> understanding correct,

[Med] I guess you noted that no normative language is used in that text. The base requirement is that the mitigation request is sent to the DOTS server that is responsible for managing the resources under attack:

   When conveying a mitigation request to protect the attack target(s),
   the DOTS client MUST select an available DOTS server whose network
   has assigned the IP prefixes from which target prefixes/addresses are
   derived.

Depending on the location of the DOTS client, the available paths to reach that server may be constrained (or not). The text you quoted is in reference to the residential CPE case, where the ** DOTS client is on the CPE **:

* If a DOTS server was provisioned by an upstream network using DHCP/PCE/etc., then the same interface must be used. There are considerations related to the use of private addressing, filters at upstream networks to let pass only mitigation requests received from customer-facing interfaces not Internet-facing ones, etc.
* If a DOTS server is explicitly configured and no interface restriction is provided, then any active interface can be used to place the mitigation request as per:    

   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.

Please note that the use of the same interface from where an attack traffic may be observed is required in cases where automatically triggering mitigations on signal loss is enabled (see the following text from RFC9132):   

==
   trigger-mitigation:  If the parameter value is set to 'false', DDoS
      mitigation will not be triggered for the mitigation request unless
      the DOTS signal channel session is lost.

      If the DOTS client ceases to respond to heartbeat messages, the
      DOTS server can detect that the DOTS signal channel session is
      lost.  More details are discussed in Section 4.7.

      The default value of the parameter is 'true' (that is, the
      mitigation starts immediately).  If 'trigger-mitigation' is not
      present in a request, this is equivalent to receiving a request
      with 'trigger-mitigation' set to 'true'.
== 

> and if so, why is this a requirement?  I.e., communicating to a
> DOTS server via
> a separate link that isn't under attack would seem to be
> beneficial (when that
> is possible).  Is the reasoning here that these are stub networks
> and hence
> will only be routable via the interface provided by the ISP's
> gateway?
> 
> Regards,
> Rob
> 
> 


_________________________________________________________________________________________________________________________

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.