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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Med,

Thanks for the explanations.

Rob

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: 21 April 2022 07:24
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Robert Wilton's No Objection on draft-ietf-dots-multihoming-11:
> (with COMMENT)
> 
> 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.