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

[[e-mail]]

Hi Valery, 

FWIW, the changes are now available online: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-multihoming-09

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[e-mail]> De la part de
> [e-mail]
> Envoyé : mardi 23 novembre 2021 15:07
> À : Valery Smyslov <[e-mail]>; 'Valery Smyslov'
> <[e-mail]>; [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : Re: [Dots] WGLC for draft-ietf-dots-multihoming-07
> 
> 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.
> 
> _______________________________________________
> 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.