Re: [Dots] Paul Wouters' Discuss on draft-ietf-dots-multihoming-11: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Paul, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters via Datatracker <[e-mail]>
> Envoyé : jeudi 21 avril 2022 03:24
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Paul Wouters' Discuss on draft-ietf-dots-multihoming-11:
> (with DISCUSS and COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-dots-multihoming-11: Discuss
> 
> 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/
> 
> 
> 
> ------------------------------------------------------------------
> ----
> DISCUSS:
> ------------------------------------------------------------------
> ----
> 
> Thanks for a clear document and thanks to Kathleen for the SecDir
> review. I
> have one minor DISCUSS item that can probably be resolved easily
> by adding a
> sentence or two.
> 
> [1]
>    The DOTS client SHOULD use the certificate
>    provided by a provisioning domain to authenticate itself to the
> DOTS
>    server(s) provided by the same provisioning domain.
> 
> This sentence suggests there is either another authentication
> method

[Med] Yes. RFC9132 includes the following: 

   Implementations compliant with this profile MUST implement all of the
   following items:
   ... 
   *  At least one of raw public keys [RFC7250] or PSK handshake
      [RFC4279] with (EC)DHE key exchange.  This reduces the size of the
      ServerHello.  Also, this can be used by DOTS agents that cannot
      obtain certificates. 

Added this NEW:

   The reader may refer to Section 7.1 of [RFC9132] for
   more details about DOTS authentication methods.

, or it
> allows for unauthenticated DOTS clients. If the latter, than I
> would expect a
> significant Security Considerations section on how to avoid/reduce
> malicious
> clients impact of such a setup. eg I could envision a compromised
> device from
> falsely reporting a DDOS attack from a certain network to block
> the compromised
> device/network from receiving traffic from certain remote
> networks.
> 
> 
> ------------------------------------------------------------------
> ----
> COMMENT:
> ------------------------------------------------------------------
> ----
> 
> Some links seem broken in the rendering of the htmlized version in
> the
> datatracker, for example "[RFC8174]" in Section 2.
> 

[Med] Thanks. Will double check. 

> It talks about DOTS clients, DOTS servers, and then suddenly DOTS
> agents. Are
> those clients or servers or something else? "agents" are not
> mentioned in the
> Introduction or Terminology sections. (Unfortunately, looking at
> RFC 8811 did
> not help me as it has the exact same problem of only defining DOTS
> clients and
> DOTS servers and then mentioning DOTS agents.

[Med] This was defined in RFC8612: 

   DOTS agent:  Any DOTS-aware software module capable of participating
      in a DOTS signal or data channel.  It can be a DOTS client, DOTS
      server, or, as a logical agent, a DOTS gateway.

We are pointing to 8811, which itself includes the following:  

    This document uses the terms defined in [RFC8612].

Added a direct pointer to 8612 for the reader's convenience. 

> 
> Similarly, the term "DOTS Gateway" appears without explanation. Is
> this a proxy
> like DOTS server for clients and a DOTS client to the real DOTS
> server?

[Med] This is also defined in RFC8612. 

> 
> I'm a bit confused about the applicability of the enduser CPE
> case. Wouldn't a
> lot of deployments have the CPE in bridging mode so that the
> customers own
> favourite device gets the actual IP address on it instead of being
> behind the
> CPE with NAT? Is there a deployment scenario possible for that?

[Med] The intent is not to be exhaustive as mentioned in the document:

   This section describes some multi-homing scenarios that are relevant
   to DOTS.  In the following subsections, only the connections of
   border routers are shown; internal network topologies are not
   elaborated.

We approached the topologies from L3 (hence the use on purpose of "router" in this text). 

> 
> I would move Figure 5 up to the start of the section. I now had to
> scroll down
> a lot and then back up again, and then when done reading had to
> skip the figure
> 5.

[Med] Sure. Done. 

> 
>    If PI addresses/prefixes are in use, the DOTS client MUST send
> a
>    mitigation request to all the DOTS servers.  The use of anycast
>    addresses to reach these DOTS servers is NOT RECOMMENDED.
> 
> Why is the recommendation about anycast addresses limited to PI
> space?

[Med] Because for the PA case, multiple IP addresses/prefixes can be assigned directly to the client (IPv6 case). The source address can be set as function of the mitigation to be sent.

 Couldn't
> there by multicast addresses in both PA and PI space?

[Med] That taxonomy does not apply for multicast addresses. (I guess your question is whether we can have multicast addresses that are specific to a network, the answer is yes: unicast-prefix-based multicast. However, that's not related to the topic of this draft)  

> 
>    a prefix filter that will be against DDoS detection alarms
> 
> I don't quite parse/understand "will be against" ?

[Med] Changed to "a prefix filter that is used to filter DDoS detection alarms". 

> 
> 


_________________________________________________________________________________________________________________________

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.