Re: [Dots] AD review of draft-ietf-dots-server-discovery-10

[[e-mail]]

Hi Ben, 

Thank for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[e-mail]]
> Envoyé : vendredi 18 septembre 2020 22:22
> À : [e-mail]
> Cc : [e-mail]
> Objet : AD review of draft-ietf-dots-server-discovery-10
> 
> Hi all,
> 
> Despite the first half of the review basically being entirely nits,
> there are some substantive comments in there later on.  (Would it be
> helpful if I tried harder to split the nits out into a separate
> section in the future?)
> 
> Overall it's pretty straightforward, so no major issues left to
> address; sorry for taking so long to get through it.
> 
> 
> One thing that we should definitely fix before getting more eyes on
> this document is that both TBD1 and TBD2 are overloaded -- we use
> them to refer to the port assignments from the signal channel and
> call home protocol assignments, but also for the DHCPv6 option
> codes.

[Med] We used TBA1/TBA2 in the core text for the codes to be assigned for DHCPv6. Fixed the IANA section, though.  

> 
> Abstract
> 
> The first paragraph seems to be generic about all of DOTS, not
> really very specific to discovery.  I wonder if we want to just
> remove the first paragraph or perhaps swap the order, the latter of
> which might look like:
> 
> % This document specifies mechanisms to configure Districuted Denial
> of % Service Open Threat Signaling (DOTS) clients with their DOTS
> servers.
> % The discovery procedure also covers the DOTS Signal Channel Call
> Home.
> %
> % Knowing the appropriate DOTS server for a given location can be
> useful % to engage mitigation actions even in cases where the DOTS
> client % cannot localize the attack, but only knows that some
> resources are % under attack and that help is needed.
> 

[Med] Works for me. Thanks. 

> Section 1
> 
>    appropriate mitigation actions are required.  Indeed, because the
>    lack of a common method to coordinate a real-time response among
>    involved actors and network domains inhibits the effectiveness of
>    DDoS attack mitigation, DOTS signal channel protocol
>    [I-D.ietf-dots-signal-channel] is meant to carry requests for
> DDoS
> 
> nit: missing "the" before "DOTS signal channel protocol".
> 

[Med] Fixed.

>    attack mitigation, thereby reducing the impact of an attack and
>    leading to more efficient defensive actions in various deployment
>    scenarios such as those discussed in [I-D.ietf-dots-use-cases].
> 
> nit: (also, this sentence is fairly long, though not necessarily
> problematic.)

[Med] Will consider splitting it. 

> 
>    Moreover, DOTS clients can instruct a DOTS server to install
>    filtering rules by means of the DOTS data channel protocol
>    [I-D.ietf-dots-data-channel].
> 
> nit: maybe "named filtering rules", since that is an important
> aspect of how we interact with them.

[Med] Indeed. 

> 
>    [I-D.ietf-dots-architecture] specifies that the DOTS client may
> be
>    provided with a list of DOTS servers; each associated with one or
> 
> nit: comma here, rather than semicolon.

[Med] OK. 

> 
>    This document assumes that security credentials to authenticate
> DOTS
>    server(s) are provisioned to a DOTS client using a variety of
> means
>    such as (but not limited to) those discussed in [RFC8572] or
> 
> nit: "using a variety of means" implies that all are used
> concurrently; do we really mean "any of" or "one of"?

[Med] Went for "one of".

> 
> Section 2
> 
>    The reader should be familiar with the terms defined in
>    [I-D.ietf-dots-architecture], [RFC3958], and
>    [I-D.ietf-dots-signal-call-home].
> 
> A bit surprising to not see RFCx 8782/8783 in there, too :)

[Med] That is normal. As the discovery does not require knowing about how the signals are working.  

> 
> Section 3
> 
>    o  Many use cases discussed in [I-D.ietf-dots-use-cases] do
> involve a
>       CPE device.  Multiple CPEs, connected to distinct network
> 
> nit(?): I think "Many of the use cases" reads better.

[Med] Fixed. 

> 
>       providers may even be considered.  It is intuitive to leverage
> on
> 
> nits: comma after "providers"; s/on$//

[Med] OK

> 
>    o  Resolving a DOTS server domain name offered by an upstream
> transit
>       provider provisioned to a DOTS client into IP address(es)
> require
> 
> nit: s/require/requires/

[Med] ACK.

> 
>    o  Some of the use cases may allow DOTS clients to have direct
>       communications with upstream DOTS servers; that is no DOTS
> gateway
> 
> nit: comma/semicolon usage; let's go for "DOTS servers, that is, no
> DOTS gateway"

[Med] Done. 

> 
>       is involved.  Leveraging on existing features that do not
> require
> 
> nit: s/Leveraging on/Leveraging/

[Med] Ack.

> 
>       specific feature on the node embedding the DOTS client may
> ease
> 
> nit: we use "features" and "feature" in this sentence, which makes
> it a little hard to understand what's going on.  Are the initial
> "features"
> more of "protocol behaviors"?

[Med] Change to "Leveraging existing protocol behaviors that do not require specific feature on the node embedding the DOTS client may ease DOTS deployment."

> 
> Section 4
> 
>    A key point in the deployment of DOTS is the ability of network
>    operators to be able to configure DOTS clients with the correct
> DOTS
> 
> nit: "ability" and "to be able to" are redundant (I suggest s/to be
> able
> to/to/)

[Med] Indeed.

> 
>    All DOTS clients MUST support at least one of the three
> mechanisms
>    below to determine a DOTS server list.  All DOTS clients SHOULD
>    implement all three, or as many as are practical for any specific
>    device (e.g., a CPE will support the first two mechanisms, a host
>    within a LAN will support the last two mechanisms, or an
> application
>    server will support a local configuration.  More samples are
>    discussed in Section 3), of these ways to discover DOTS servers,
> in
>    order to facilitate the deployment of DOTS in large scale
>    environments:
> 
> nit: the way the parenthetical is structured is a bit unusual, with
> a sentence break occurring within the parentheses (and leaving quite
> a gap for processing in the middle of the thought "implement all
> three of these ways").  It's probably okay to just make the "SHOULD
> implement all three" a single standalone sentence, and leave the
> clarification of when implementing all three is
> infeasible/unnecessary to a follow-up sentence.

[Med] Will split to ease the readability. 

> 
>           server.  When only DOTS server's IP addresses are
> configured,
>           a reference identifier must also be configured for
>           authentication purposes.
> 
> Forestalling my common questions; good work!
> 
>        *  Automatic configuration (e.g., DHCP, an automation
> system):
>           The DOTS client attempts to discover DOTS server(s) names
> and/
>           or addresses from DHCP, as described in Section 5.
> 
> We may get questions about this one, since it is apparently equating
> DHCP with a (generic) "automation system".  Perhaps we want to say
> that the DHCP mechanism is used in the absence of manual or
> automated explicit configuration?

[Med] I deleted "an automation system".

> 
>    the relevant DOTS server is obtained directly.  Implementation
>    options may vary on a per device basis, as some devices may not
> have
>    DNS capabilities and/or proper configuration.
> 
> nit: maybe "proper DNS configuration" or "proper resolver
> configuration"?
> 

[Med] Yes. Changed to "proper DNS configuration".

>    combination of interface and address family.  A DOTS client may
>    choose to perform the discovery procedure only for a desired
>    interface/address combination if the client does not wish to
> discover
> 
> nit: I think "interface/address-family combination".

[Med] ACK.

> 
>    o  Expiry of a lease associated with a discovered DOTS agent.
> 
> Is this specifically a DHCP lease, or a more generic concept?

[Med] This is generic.  

> 
> Section 5
> 
>    As reported in Section 1.7.2 of [RFC6125]:
> 
>       "few certification authorities issue server certificates based
> on
>       IP addresses, but preliminary evidence indicates that such
> 
> I think the quote is actually "[s]ome", not "few" -- please check!

[Med] I don't know how "few" ended there, but you are right.  

> 
>    The list of the IP addresses returned by DHCP servers is
> typically
>    used to fed the DOTS server selection procedure or to provide
> DOTS
> 
> nit: s/fed/feed/

[Med] Ack.

> 
>    for the DOTS Call Home.  The DOTS client (or Call Home DOTS
> server)
>    will then use the address selection specified in Section 4.3 of
> 
> nit: "address selection procedure"

[Med] Ack. 

> 
>       Let's consider that the DOTS server is reachable at
>       2001:db8:122:300::1 while the Call Home DOTS client is
> reachable
>       at 2001:db8:122:300::2.  The DHCP server will then return one
> DOTS
>       reference identifier and a list that includes both
>       2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting
> DHCP
>       client.  That list is passed to the DOTS client (or Call Home
> DOTS
>       server) which will try to establish connections to the
> addresses
>       of that list and destination port number TBD1 (or TBD2).  As a
>       result, the DOTS client (or Call Home DOTS server) will select
>       2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server
> (or
>       Call Home DOTS client).
> 
> I mostly expect pushback from TSV-area reviewers about giving the
> allocated port numbers such importance in selecting the peer address
> to use.

[Med] We need to demux call-home from the base signal channel. We have text in the call home draft to explain this. We can point the reviewers to that section. 

> 
> Section 5.1.2
> 
>    format of this option is shown in Figure 5.  As a reminder, this
>    format follows the guidelines for creating new DHCPv6 options
>    (Section 5.1 of [RFC7227]).
> 
> We need the reminder for the second option but not the first one? ;)

[Med] Because we don't have a section to cite. There is only a list discussed in 5.10 but we don't only need one name. 

> 
> Section 5.1.3
> 
>    are used to reach the peer DOTS agent.  In other words, the name
>    conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying
>    resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a
>    response.
> 
> I'm not sure how much of this needs to end up in the document
> itself, but can we walk through the scenarios here, especially when
> the DNS-resolution addresses for the name in question differ from
> the addresses in OPTION_V6_DOTS_ADDRESS?

[Med] Actually, we want to avoid the aliasing issues discussed in RFC7227#section-7 (the resolution may lead to different addresses if the logic for binding a client to server is not visible to "public" resolvers). 

When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. The client must not try to resolve the OPTION_V6_DOTS_RI. 

  I don't understand yet
> why/how this scheme ends up being safe, and am hoping that you have
> a head start over me on doing the analysis :)

[Med] Returning both the address and the RI in the DHCP prevents redirecting a client to a "fake" server if the DNS queries are intercepted. We don't have this issue if both the address and the RI are returned in DHCP. 

> 
>    If the DHCP client receives OPTION_V6_DOTS_RI only, but
>    OPTION_V6_DOTS_RI option contains more than one name, as
> 
> nit: insert "the" at the start of the second line.

[Med] deleted "option". 

> 
>    If the DHCP client receives OPTION_V6_DOTS_RI only, but
>    OPTION_V6_DOTS_RI option contains more than one name, as
>    distinguished by the presence of multiple root labels, the DHCP
>    client MUST use only the first name.  Once the name is validated
> 
> Is there a reason to make this "use the first one" vs. "ignore the
> whole thing as malformed?

[Med] If the message is ignored, the service won't be provided. 

> 
>    (Section 8 of [RFC8415]), the name is passed to a name resolution
>    library.  Moreover, that name is also used as a reference
> identifier
>    for authentication purposes.
> 
> Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 that
> looks relevant here.  Was perhaps a different document intended?

[Med] It used to be "Section 8 of 3315", but since 3315 was obsoleted by 8415, it should read "Section 10 of 8415". Good catch. Thanks. 

> 
> Section 5.2.1
> 
> A reference to 2132 here would be timely, not least for
> understanding the figure.
> 

[Med] OK.

>      The values s1, s2, s3, etc. represent the domain name labels in
> the
>      domain name encoding.
> 
> super-nitty-nit: maybe "the octets of the domain name labels"?  IIUC
> the RFC 2132 convention is to give such names to the individual
> bytes of the DHCP option, but this wording implies that we are
> naming labels, which are multi-byte (except for the root).

[Med] I see your point but the figure uses the convention used in many other dhc wg document. I will leave it. Bernie (dhc co-chair)  reviewed the dhcp part of the document and he didn't raise a comment about this.  

> 
> Section 5.2.2
> 
> I wonder if anyone will complain that we are using a more "modern"
> structure for the figure, instead of keeping with the "traditional"
> DHCP option diagrams.

[Med] At least, Bernie didn't complain when he reviewed the document. 

> 
> Section 5.2.3
> 
>    To discover a peer DOTS agent, the DHCPv4 client MUST include
> both
>    OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter
> Request
>    List Option [RFC2132].
> 
> Why is the v4 case a MUST but the v6 case was only MAY?

[Med] Because we start the v4 text with "To discover a peer DOTS agent,". We could align both, though. 

> 
>    If the DHCP client receives more than one instance of
>    OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use
>    only the first instance of that option.
> 
> I think the parenthetical needs to be dropped, since in the previous
> section we say that this is a concatenation-requiring option.

[Med] Agree. 

> 
>    If the DHCP client receives OPTION_V4_DOTS_RI only, but
>    OPTION_V4_DOTS_RI option contains more than one name, as
>    distinguished by the presence of multiple root labels, the DHCP
>    client MUST use only the first name.  Once the name is validated
>    (Section 10 of [RFC8415]), the name is passed to a name
> resolution
>    library.  Moreover, that name is also used as a reference
> identifier
>    for authentication purposes.
> 
> [same comments about "use first" as for v4] I see that here we
> reference §10, rather than 8, of RFC 8415, though it still doesn't
> say much explicitly about a "validation procedure".

[Med] The validation is basically check it follows Section 3.1 of [RFC1035] and compression is not used.  

> 
> The diff between §5.1.3 and 5.2.3 includes "(e.g., PKIX [RFRC6125])"
> only in 5.1.3; it seems like it would also apply here.

[Med] Indeed. 

> 
>    The DHCP client MUST silently discard multicast and host loopback
>    addresses conveyed in OPTION_V4_DOTS_ADDRESS.
> 
> Can we put a reference for "multicast and host loopback" addresses
> as we did for the v6 case?

[Med] Sure. 

> 
> Section 6
> 
>    1.  A DNS domain name is retrieved for each combination of
> interface
>        and address family.  A DOTS agent has to determine the domain
> in
>        which it is located relying on dynamic means such as DHCP
>        (Section 5) . [...]
> 
> Hmm, this may be worth a closer look.  If I understand correctly, if
> the procedures in Section 5 only give you a name, you're supposed to
> use DNS to get IP addresses to talk to, from that name.  So is this
> procedure only applicable when the A/AAAA lookup fails?  Otherwise
> I'm not sure how you would get only a name but not full contact
> information, from the section 5 procedure.  Or, if the intent of
> "the name is passed to a name resolution library" in Section 5 is to
> induce the S-NAPTR lookups defined here, Section 5 should be more
> clear about that.

[Med] S-NAPTR lookups is covered by "... to a name resolution library". Nevertheless, some deployments may not require S-NAPTR lookups and A/AAAA resolution would be just fine.    

> 
>    Once the DOTS agent has retrieved its DNS domain or discovered
> the
>    peer DOTS agent name that needs to be resolved (e.g., Section 5),
> an
> 
> (The parenthetical seems redundant with step (1).)

[Med] Fixed. 

> 
>    S-NAPTR lookup with 'DOTS' application service and the desired
>    [...]
>    This specification defines "DOTS" and "DOTS-CALL-HOME" as
> application
>    service tags (Sections 9.4.1 and 9.4.2).  It also defines
> 
> We should probably mention "DOTS-CALL-HOME" in both places, or just
> say something generic like "the appropriate application service" in
> the first instance, instead of only saying 'DOTS' the first time.
> 

[Med] Went for "the appropriate application service". 

>    a.example.net.
>    IN AAAA  2001:db8::1
> 
> I'm sure my INT-area colleagues will appreciate the IPv6 examples :)
> 
> Section 8
> 
> Having a clearly defined priority order for using the different
> discovery mechanisms covers most of the potential security
> considerations inherently, but I think some text is in order about
> whether an attacker can block/modify traffic to force a "lower
> priority"
> mechanism to be used (but would not be able to modify the "higher
> priority" mechanism's results with the same capabilities).

[Med] Good point. I added the folliwng: 

"An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The security implications of such attack are those inherent to the fallback discovery mechanism discussed in the following subsections. "

> 
> We may also want to reiterate that discovery results are scoped by
> interface and address family, and that bad things can happen if you
> use a result from one interface for traffic from a different
> interface.

[Med] We can add 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 bind 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 (that can be inferred from the name and the destination IP address) to external networks."

> 
> There are probably not particularly interesting privacy
> considerations of advertising/exposing DOTS server names in these
> various discovery mechanisms, but a brief section on privacy
> considerations is likely in order regardless.

[Med] The NEW text above touched on "privacy". I'm not sure what we need to say more. 

> 
> Section 8.2
> 
>    The primary attack against the methods described in Section 6 is
> one
>    that would lead to impersonation of a peer DOTS agent.  An
> attacker
>    could attempt to compromise the S-NAPTR resolution.  The use of
>    mutual authentication makes it difficult to redirect a DOTS
> client
>    (or a Call Home DOTS server) to an illegitimate DOTS server (or a
>    Call Home DOTS client).
> 
> IIUC this property only holds if the domain name used for
> authenticating the peer (i.e., the input to the RFC 6125 procedures)
> is the one used as input to the procedure in Section 6, not the
> intermediate names produced during that procedure (e.g.,
> "example.net" as input and "a.example.net"
> as intermediate, from Figure 10).  I don't think we specify anywhere
> that this must be the case, so on the face of it it seems that in
> the absence of DNSSEC, an attacker spoofing DNS responses can
> redirect the client to an arbitrary name controlled by the attacker,
> for which the attacker has valid PKIX credentials.  (We also allow
> SRV-IDs for validation, so the SRV names are also affected.) I also
> note that the analogous question for mail servers (whether they
> authenticate as example.net or a.example.net) is a recurring source
> of trouble, so our hand may be forced by deployment realities.

[Med] Good point. Will update the text. 

> 
> Section 8.3
> 
> I was going to say that we should reference the RFC 6763 security
> considerations, too, but they are just saying the same things we
> already say.
> 
> Section 12.2
> 
> I expect at least one AD to suggest that the architecture draft
> should be normative since we require it for terminology, but I don't
> insist on changing its classification at this time.  (Likewise for
> Call Home.)
> 

[Med] Will let them as they are. Let's see if we will get comments on this. 

> -Ben

_________________________________________________________________________________________________________________________

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.