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

[Valery Smyslov <[e-mail]>]

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.

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

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

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

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

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

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

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

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

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

> > Regards,
> > Valery.
> >
> >
> > > 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.
> > >
> > > _______________________________________________
> > > 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.
> 
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots