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

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 11 Oct 2021 14:33:12 +0300

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.

---

From: <[email-masked]>
Date: Tue, 12 Oct 2021 10:48:27 +0100

Hi Frank / Valery / Authors,

I have had another good read through this document.  Essentially it is
looking good.

I have the following Comments

General: I-D.ietf-dots-rfc8782-bis -> RFC9132

5.1: Will readers know what "Protocol Configuration Option" is?

5.2: The CPE MUST select ...  I have to assume that CPE is referring to the
DOTS Gateway., and a more appropriate location for this statement would be
following Figure 6 before branching off into the alternative deployment
models which do not have a DOTS gateway per se and are clients talking
direct to one or more servers.  Furthermore, in this alternative deployment
section it already states
"The use of anycast addresses to reach the DOTS servers is NOT RECOMMENDED."

5.3: This is repeated several times:-
"The use of anycast addresses is NOT RECOMMENDED to reach
   DOTS gateways."
I think it actually is only needed in the PA with specific filter rules case
(why cannot anycast be used in the PI case?)

I have the following Nits

1.: Old
upstream provider.  It can also be enabled
New (clarity on what It refers to)
upstream provider.  DOTS can also be enabled

3.: Old
Provider-Aggregatable (PA) addresses  are globally-unique
New(remove double space)
Provider-Aggregatable (PA) addresses are globally-unique

5.2: Old
   DOTS messages received from an internal DOTS client.  If anycast
   addresses are used to reach DOTS servers, the CPE may not be able to
New
   DOTS messages received from an internal DOTS client.  If anycast
   addresses are used to reach DOTS servers which cover multiple
   provisioning domains, the CPE may not be able to

Regards

Jon

> -----Original Message-----
> From: Valery Smyslov [mailto: [email-masked]]
> Sent: 11 October 2021 12:33
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Dots] WGLC for draft-ietf-dots-multihoming-07
> 
> Hi,
> 
> this message starts a two-week working group last call for
draft-ietf-dots-
> multihoming-07.
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Mon, 25 Oct 2021 06:05:15 +0000

Hi Jon, all,

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[email-masked]> De la part de [email-masked]
> Envoyé : mardi 12 octobre 2021 11:48
> À : 'Valery Smyslov' <[email-masked]>; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Re: [Dots] WGLC for draft-ietf-dots-multihoming-07
> 

[Med] Fixed.

> 5.1: Will readers know what "Protocol Configuration Option" is?

[Med] Added a new reference for PCO:

   [TS.24008]
              3GPP, "Mobile radio interface Layer 3 specification; Core
              network protocols; Stage 3 (Release 16)", December 2019,
              <http://www.3gpp.org/DynaReport/24008.htm>.

> 
> 5.2: The CPE MUST select ...  I have to assume that CPE is referring to
> the DOTS Gateway.

[Med] There is no DOTS gateway in this case. Internal DOTS client communicates directly with DOTS servers. There are some implications at the CPE to appropriately forward the requests.

, and a more appropriate location for this statement
> would be following Figure 6 before branching off into the alternative
> deployment models which do not have a DOTS gateway per se and are clients
> talking direct to one or more servers.  Furthermore, in this alternative
> deployment section it already states "The use of anycast addresses to
> reach the DOTS servers is NOT RECOMMENDED."

[Med] Yes, but that text was in reference to Figure 7. This text is to insist on the issues in reference to Figure 8.

> I think it actually is only needed in the PA with specific filter rules
> case (why cannot anycast be used in the PI case?)
> 

[Med] This is problematic even in the PI case. Think about distinct CPEs (and thus DOTS gateways) that are used to connect a DOTS client domain to the Internet. Only one gateway will be selected by the internal routing, and thus only one server will be contacted. The DDoS traffic will still be forwarded via the other interconnection link as this is a an attack targeting a PI resource. 

Now rereading the text, and given that we say that ** all ** gateways must be contacted, I suggest we go for this change:

NEW:
The use of anycast addresses to establish DOTS sessions between DOTS clients and DOTS gateways is not an option.

> upstream provider.  It can also be enabled New (clarity on what It refers
> to) upstream provider.  DOTS can also be enabled

[Med] Fixed. Thanks. 

> 
> 3.: Old
> Provider-Aggregatable (PA) addresses  are globally-unique New(remove
> double space) Provider-Aggregatable (PA) addresses are globally-unique

[Med] This was added by xml2rfc. Will see how to make this better. 

>    provisioning domains, the CPE may not be able to

[Med] I went for: 

"If anycast addresses are used to reach multiple DOTS servers..."

> > send your comments to the mailing list.

_________________________________________________________________________________________________________________________

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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 29 Oct 2021 16:26:09 +0300

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?

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.

[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? Or you have several
DDOS mitigation providers, and some of them are provided by ISPs and some are
independent? 

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.

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

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.

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?

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.

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.

Related question - why SHOULD (and not MUST)?.  What if clients
are not provided with these policies?

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.

Section 5.3.

Again, I think it's worth to move Figure 9 closer to the text that 
refers to it.

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? 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)?

Regards,
Valery.