Re: [Dots] Review of draft-ietf-dots-multihoming

[[e-mail]]

Hi Jon, 

Thank you for the review. All good suggestions. You may track the changes at: https://tinyurl.com/dots-multihoming-latest. 

BTW, do we need to include some notes about the handling of mid (and other related identifiers(?)) as it may be tempting, for example, to use the same ids when a request is sent to multiple servers for the PI case. We may include a reminder that ids should be handled per dots server/provisioning domain, not per target prefix. 

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[e-mail]] De la part de Jon Shallow
> Envoyé : vendredi 2 juillet 2021 18:02
> À : [e-mail]
> Objet : [Dots] Review of draft-ietf-dots-multihoming
> 
> Hi all,
> 
> I have done a review of draft-ietf-dots-multihoming and have come up
> with some things that I think need to be corrected/updated.
> 
> s/I-D.ietf-dots-use-cases/RFC8903/g
> s/RFC8782/I-D.ietf-dots-rfc8782-bis/g
> 
> 1. Introduction
> 
> OLD - needs rewording
> 
>    In many deployments, it may not be possible for a network to
>    determine the cause of a distributed Denial-of-Service (DoS)
> attack
>    [RFC4732].  Rather, the network may just realize that some
> resources
>    seem to be under attack.  To improve such situation, the IETF is
>    specifying the DDoS Open Threat Signaling (DOTS) architecture
>    [RFC8811], where a DOTS client can inform a DOTS server that the
>    network is under a potential attack and that appropriate
> mitigation
>    actions are required.  Indeed, because the lack of a common
> method to
>    coordinate a real-time response among involved actors and network
>    domains jeopardizes the efficiency of DDoS attack mitigation
> actions,
>    the DOTS protocol is meant to carry requests for DDoS attack
>    mitigation, thereby reducing the impact of an attack and leading
> to
>    more efficient responsive actions.
> 
> NEW
> 
>    In many deployments, it may not be possible for a network to
>    determine the root cause of a distributed Denial-of-Service (DoS)
> attack
>    [RFC4732].  Rather, the network may just realize that some
> resources
>    appear to be under attack.  To help with such situations, the
> IETF has
>    specified the DDoS Open Threat Signaling (DOTS) architecture
>    [RFC8811], where a DOTS client can inform an upstream DOTS server
> that its
>    network is under a potential attack and that appropriate
> mitigation
>    actions are required.  The DOTS protocols can be used to
> coordinate real-time mitigation efforts which can evolve at the
> attacks mutate,
>   thereby reducing the impact of an attack and leading to
>    more efficient responsive actions.
> 
> OLD
> 
> provided DOTS server(s) addresses (e.g.,
>    [RFC8973]).
> 
> NEW
> 
> provided DOTS server(s) addresses (e.g., by using
>    [RFC8973]).
> 
> OLD
> 
>           * Send a DOTS mitigation request to an arbitrary DOTS
> server
>           won't help mitigating a DDoS attack.
> 
> NEW
> 
>           * Sending a DOTS mitigation request to an arbitrary DOTS
> server
>           Will not necessarily help in  mitigating a DDoS attack.
> 
> s/Sketch guidelines and recommendations/Give guidelines and
> recommendations/
> 
> s/ Identify cases where anycast is not recommended./ Identify cases
> where anycast is not recommended for DOTS./
> 
> 3. Terminology
> 
> Define PA and PI addresses (I know we define them in Section 1, but
> this may help  the reader).
> 
> 4.2 Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs
> 
> s/is connected to the Internet using one single router is connected
> to the Internet using a single router/
> 
> 4.4 Multi-homed Enterprise with the Same ISP
> 
> Do we need to consider 4.1 in the same light - ISPs here in the UK
> are now offering wired plus backup 4G options to the Residential
> user?  In other words, I think we need to add in to the relevant
> places "Multi-Homed Residential, Single provisioning domain".
> 
> 5.1 Residential CPE
> 
> s/ be established and maintained with each of the DOTS servers
> because/ be established and MUST be maintained with each of the DOTS
> servers because/
> 
> s/ the mitigation scope of these servers is restricted./ the
> mitigation scope of each of these servers is restricted./
> 
> OLD
> 
>   the DOTS client among the DOTS servers available MUST select a
> DOTS
>    server whose network has assigned the IP prefixes from which
> target
> 
> NEW
> 
>   the DOTS client MUST select an available DOTS
>    server whose network has assigned the IP prefixes from which
> target
> 
> s/ domain another domain than the one that owns those addresses/
> domain other than the one that owns those addresses/
> 
> " Nevertheless, if the DDoS attack is
>    received from one single network, then only the DOTS server of
> that
>    network MUST be contacted."
> 
> Does not make sense to me and either needs to be re-written or
> removed.
> 
> 5.2 Multi-Homed Enterprise: Single CPE, Multiple Upstream ISPs
> 
> s/ One of more DOTS clients/ One or more DOTS clients/
> 
> s/ some issues arise to steer traffic towards the appropriate DOTS
> server/ some issues may arise in how to steer traffic towards the
> appropriate DOTS server
> 
> 6. Security Considerations
> 
> OLD
> 
>    DOTS client should not leak information specific to a given link
> to
>    DOTS servers not authorized to mitigate attacks received on that
>    link.
> 
> NEW
> 
>    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.
> 
> 
> 
> Regards
> 
> Jon
> 
> 
> _______________________________________________
> 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.