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

[[e-mail]]

Hi Valery,

Thank you for the follow-up. 

The changes to address your comments can be tracked at: https://tinyurl.com/dots-multihoming-latest.

Please see inline for more context. 

Cheers,
Med

> -----Message d'origine-----
> De : Valery Smyslov <[e-mail]>
> Envoyé : vendredi 19 novembre 2021 09:51
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; 'Valery
> Smyslov' <[e-mail]>; [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : RE: [Dots] WGLC for draft-ietf-dots-multihoming-07
> 
> HI Med,
> 
> please see inline.
> 
> > Hi Valery,
> >
> > Many thanks for the detailed review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > 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?
> >
> > [Med] Informational is just OK as the intent is to complement the DOTS
> arch. Fixed.
> 
> Good.
> 
> > > 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.
> >
> > [Med] 8811 is cited as normative as we built on that reference
> architecture.
> 
> That's OK if you changed intended status to Informational.

[Med] ACK.

> 
> > > [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?
> >
> > [Med] This is a subcase of the ones that are discussed in the draft.
> > Each of multiple ISPs will provision that independent DDoS server to
> > the CE. The key assumption is that a DOTS server is unambiguously
> associated with the interconnection link over which it can be used.
> 
> Well, what if the independent DOTS server is configured manually, not
> provisioned by ISPs?
> Is it possible (and how) to use it with only subset of ISPs?

[Med] Added this NEW text:

A multihomed network may enable DOTS for all or a subset of its	
upstream interconnection links.  In such a case, DOTS servers can be	
explicitly configured or dynamically discovered by a DOTS client	
using means such as those discussed in [RFC8973].  These DOTS servers	
can be owned by the upstream provider, managed by a third-party	
(e.g., mitigation service provider), or a combination thereof.	
	 		
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.

> 
> >  Or you have several DDOS mitigation providers, and some of them
> > > are provided by ISPs and some are independent?
> >
> > [Med] This is also allowed in the current draft as we don't make an
> > assumption of the provisioned DOTS server's name nor wither the
> same/distinct one are provisioned over each interconnection link:
> >
> >    *  Each of these provisioning domains assigns IP addresses/prefixes
> >       to the CPE and provides additional configuration information such
> >       as a list of DNS servers, DNS suffixes associated with the
> >       network, default gateway address, and DOTS server's name
> >                                             ^^^^^^^^^^^^^^^^^^
> >       [RFC8973].  These addresses/prefixes are assumed to be Provider-
> >       ^^^^^^^^
> >       Aggregatable (PA).
> >
> > Please let me know if you think that an explicit statement is needed
> > to the draft to further clarify the rationale.
> 
> I think it's worth to to clarify situation with manually configured
> independent DOTS servers, when some of them can be used with only a subset
> of ISPs.

[Med] Covered by the NEW text above and this one: 

In the following subsections, all or a subset of interconnection	
links are associated with DOTS servers.

> 
> > > 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.
> >
> > [Med] This text refers to the DOTS server's name, that is also mentioned
> in (RFC8973, Section 4, item 1):
> >
> >           "These may be
> >           specified either as a list of IP addresses or the DNS name of
> >           a DOTS server."
> 
> That's what my concern is. The draft says that you MUST resolve DOTS
> server's name provided by a PD using the DNS servers from the same PD. So,
> what if DOTS server's name was configured manually, not learned from PD -
> what DNS server to use to resolve it? Any? Should this be more explicit in
> the text?

[Med] Made this change:

OLD:
   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.

NEW:
   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 (or the
   DNS servers associated with the interface(s) for which a DOTS server
   was explicitly configured).


> 
> > > 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.
> >
> > [Med] Agree. This is to echo this part from the introduction:
> >
> >    2.  Identify DOTS deployment schemes in a multi-homing context, where
> >        DOTS services can be offered by all or a subset of upstream
> >                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        providers.
> >
> > I added this NEW sentence to the intro text of Section 4:
> >
> > "In the following subsections, all or a subset of interconnection links
> are associated with DOTS servers."
> 
> OK.
> 
> > > 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?
> >
> > [Med] An interface can also be indicated when explicit configuration
> > is used. If no such information is provided, this means that the address
> applies for any active interface.
> 
> Please, add this clarification.

[Med] Done. 

> 
> > As a reminder, RFC8973 says the following:
> >
> >    The results of the discovery procedure are a function of the
> >                                               ^^^^^^^^^^^^^^^^
> >    interface/address family.  Contacting a discovered DOTS server via an
> >    ^^^^^^^^^^
> >    interface to which it is not bound may exacerbate the delay required
> >    to establish a DOTS channel.  Moreover, such behavior may reveal that
> >    a DOTS service is enabled by a DOTS client domain and exposes the
> >    identity of the DOTS service provider (which can be inferred from the
> >    name and the destination IP address) to external networks.
> >
> > >
> > > 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.
> >
> > [Med] It applies to both figure 7/8. Clients in Figure 8 may still
> > receive detection alarms on resources that are not handled by their peer
> DOTS server.
> 
> It is not clear. Previously the draft says:
> 
>    Another deployment approach is to enable many DOTS clients; each of
>    them is responsible for handling communications with a specific DOTS
> 
> ^^^^^^^
>    server (see Figure 8).
> 
> Probably some clarification is needed.

[Med] Added "For both deployments depicted in Figures 7 and 8 ..."

> 
> > > Related question - why SHOULD (and not MUST)?.  What if clients are
> > > not provided with these policies?
> >
> > [Med] SHOULD is used because in Figure 8 some filters may be applied
> when directing alarms to DOTS clients.
> 
> I read the sentence "Each DOTS client SHOULD be provided with policies..."
> that under some conditions it's OK to not provide clients with policies
> (filters) at all, that's why my question. My understanding, that they MUST
> be provided always, but the policies may differ. Am I missing something?

[Med] This can't be a MUST as the filtering can be on the alarms themselves before being known to the DOTS client.

> 
> > > 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.
> > >
> >
> > [Med] The risk here is that the mitigation request will be rejected by
> > the DOTS server to which the CPE decided to froward the request. If
> > the CPE embeds a DOTS gateways, the situation can be better as it may
> use a sequential mode. I think that NOT RECOMMENDED is appropriate.
> 
> So it's just an explanation why using anycast is not recommended?
> Then, can you move it closer to the recommendation not to use anycast?

[Med] Done. Thanks.

> 
> > > 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?
> >
> > [Med] It means that it is not a valid technical solution to fulfil the
> > "MUST contact all" requirement, as by definition, only one will be
> selected.
> >
> >  MUST NOT be used? Or impossible to use?
> 
> "Cannot be used, because <explanation>" ?

[Med] Updated the text as suggested. 

> 
> > > 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)?
> >
> > [Med] In such case, the "information specific to a given link" will
> > point to the target (PI@) that is authorized to be revealed to all
> servers.
> 
> OK.
> 
> Regards,
> Valery.
> 

_________________________________________________________________________________________________________________________

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.