Re: [Dots] AD evaluation of draft-ietf-dots-signal-call-home-09: Section 3

[[e-mail]]

Re-

Please see inline.

Cheers,
Med
 
>    remains the same.  Furthermore, existing certificate chains and
>    mutual authentication mechanisms between the DOTS agents are
>    unaffected by the Call Home function.  This Call Home function
> 
> This may merit a bit more text, or at least a bit more thought,
> since we are now asking the certificate validation to be used for a
> different logical purpose.  While it's true that the entity acting
> as a (D)TLS server is likely to be the same device as a regular DOTS
> server (or at least operated by the same DMS provider), and so there
> is a fairly strong analogue there in terms of the (D)TLS server
> certificate validation procedures, the (D)TLS client is something of
> a different entity than a traditional DOTS client.  It's true that
> RFC 8782 leaves the specifics of the mutual authentication a bit
> under-specified (and essentially just says that it has to happen
> somehow), but one might imagine that the number of DOTS clients are
> fairly small and tied to specific legal contracts, so manual
> provisioning (or provisioning during
> onboarding) of client certificate information is reasonable.  For
> the call home case, we should expect a lot more call home DOTS
> servers (i.e., (D)TLS clients) and thus should probably have a
> better story for automating the mutual authentication check.
> Defining an extendedKeyUsage value that indicate authorization to
> act as a call home server would be one typical way to do so (it's
> perhaps unfortunate that we didn't define an EKU for DOTS client
> usage), but if we're not going to do that we should at least put
> some words in about how the mutual authentication requirement
> remains but a different ACL may be needed for call home than for
> traditional DOTS sessions.

Med: I admit that I don't see a difference between the two. I let Tiru and Jon share their views on this. 

> 
>    enables the DOTS server co-located with a network element
> (possibly
> 
> (Still Call Home server, right?)

Med: Yes. Update the text for better clarity: 

   This Call Home function enables the Call Home DOTS server
   co-located with a network element (possibly behind NATs and
   firewalls) reachable by only the intended Call Home DOTS client and
   hence the Call Home DOTS server cannot be subjected to these DDoS
   attacks.

> 
> Section 3.2.1
> 
>    If the Call Home DOTS server does not receive any traffic from
> the
>    peer Call Home DOTS client during the time span required to
> exhaust
>    the maximum 'missing-hb-allowed' threshold, the Call Home DOTS
> server
>    concludes the session is disconnected.  Then, the Call Home DOTS
>    server MUST try to resume the (D)TLS session.
> 
> Why resume specifically, as opposed to the broader "initate a new
> (D)TLS connection" that could encompass both resumption and a full
> handshake?

[Med] A new connection will be used if resumption fails. This is handled by the DTLS layer.   

Jon, can please confirm/infirm this how your implementation works? Thanks. 

> 
> Section 3.2.2
> 
>    If a Call Home DOTS client wants to redirect a Call Home DOTS
> server
>    to another Call Home DOTS client, it MUST send a Non-confirmable
> PUT
>    request to the predefined resource ".well-known/dots/redirect"
> with
>    the new Call Home DOTS client FQDN or IP address in the body of
> the
>    PUT similar to what is described in Section 4.6 of
>    [I-D.ietf-dots-rfc8782-bis].  [...]
> 
> I suggest that we mention the actual element in the YANG module that
> contains the structure that will be used as the PUT body, as this
> text in isolation feels like it's attempting to define the protocol
> by way of example and analogy, which is not a great pattern for
> protocol design.

[Med] Fair comment. Added this new text: 

   the following attributes in the body of the PUT request:

   alt-ch-client:  The FQDN of an alternate Call Home DOTS client.

      This is a mandatory attribute for DOTS signal Call Home.  It MUST
      NOT be used for base DOTS signal channel operations.

   alt-ch-client-record:  List of records for the alternate Call Home
      DOTS client.

      This is an optional attribute for DOTS signal Call Home.  It MUST
      NOT be used for base DOTS signal channel operations.

   ttl:  The Time to live (TTL) of the alternate Call Home DOTS client.
      That is, the time interval that the alternate Call Home DOTS
      client may be cached for use by a Call Home DOTS server.

      This is an optional attribute for DOTS signal Call Home.  It MUST
      NOT be used for base DOTS signal channel operations. 

> 
> Section 3.3.1
> 
> 
> In
>       addition, the DOTS client MUST validate that attacker prefixes
> are
>       within the scope of the DOTS server domain.
> 
> What does "within the scope" mean in the context of the base signal
> channel?

[Med] The analogy with the base signal channel is to make sure that the IP resources are associated with the DOTS client domain. For the call home case, these resources must be bound to the call home dots server domain. 

> 
>    (i.e., the Call Home scenario depicted in Figure 7).  The
> 'target-
>    uri' or 'target-fqdn' parameters can be included in a mitigation
>    request for diagnostic purposes to notify the Call Home DOTS
> server
>    domain administrator, but SHOULD NOT be used to determine the
> target
>    IP addresses.  Note that 'target-prefix' becomes a mandatory
>    attribute in the mitigation request signaling the attack
> information
>    because 'target-uri' and 'target-fqdn' are optional attributes
> and
>    'alias-name' will not be conveyed in a mitigation request.
> 
> I think we have to use normative language that 'target-prefix' is
> mandatory for call home, since the "don't rely on target-fqdn or
> target-uri' is not a MUST.  (Actually, I think they would have to be
> "MUST NOT send", not just "MUST NOT rely on for identification", in
> order for us to be able to get away with the current wording that
> states it like a fact.)

[Med] I'm afraid this is redundant with RFC8782 that says: 

   In the PUT request, at least one of the attributes 'target-prefix',
   'target-fqdn','target-uri', or 'alias-name' MUST be present. 

> 
> Also, we might want to explain why 'alias-name' cannot be used (and
> we don't need normative language to ensure it): they are created
> using the data channel but there is no call home data channel (yet,
> at least).

[Med] The target can be any address, not only those managed by a call home DOTS client. Even if RESTCONF Call Home (RFC8071)+ DOTS Data Channel are enabled, there is no viable use case for a call home DOTS client to create aliases and for the server (a CPE, for example) to store them. 

I propose to change to "and 'alias-name' is unlikely to be conveyed in a mitigation request.".

Not sure if it is worth to add a note. 

> 
>    In order to help attack source identification by a Call Home DOTS
>    server, the Call Home DOTS client SHOULD include in its
> mitigation
>    request additional information such as 'source-port-range' or
>    'source-icmp-type-range'.  The Call Home DOTS client may not
> include
>    such information if 'source-prefix' conveys an IPv6
> address/prefix.
> 
> I'm not sure what the "may not" is intending to convey, here.

[Med] This to say that an IPv6 address would be sufficient to identify an internal host. 

  Are
> these mandaroy for IPv4 prefixes?

[Med] Because of the NAT, a singled source address may be shared. Providing these additional attributes is recommended to hep identifying the internal IP address.

> 
>    The Call Home DOTS server MUST check that the 'source-prefix' is
>    within the scope of the Call Home DOTS server domain.  Note that
> in a
> 
> (nit) this "MUST" seems redundant with the text I quoted previously.

[Med] The first one was on the client side. This one at the server side. 

> 
>    The Call Home DOTS server MUST check that the 'source-prefix' is
>    within the scope of the Call Home DOTS server domain.  Note that
> in a
>    DOTS Call Home scenario, the Call Home DOTS server considers, by
>    default, that any routeable IP prefix enclosed in 'target-prefix'
> is
>    within the scope of the Call Home DOTS client.  [...]
> 
> We say "by default" -- how would some other behavior be activated?

[Med] local configuration. 

> 
>    with or without DOTS server domain administrator consent.  If the
>    attack traffic is blocked, the Call Home DOTS server informs the
> Call
>    Home DOTS client that the attack is being mitigated.
> 
> This is just a normal 2.xx response code (and body) to the
> mitigation request?  It might be worth clarifying.

Med: Fixed. 

> 
>    If the attack traffic information is identified by the Call Home
> DOTS
>    server or the Call Home DOTS server domain administrator as
>    legitimate traffic, the mitigation request is rejected, and 4.09
>    (Conflict) is returned to the Call Home DOTS client.  The
> conflict-
> 
> There may be quite some delay involved if the administrator needs to
> decide.  Should we say more about (e.g.) using 5.03 and Max-Age in
> this case?

Med: Already answer in the first part.

> 
>    Once the request is validated by the Call Home DOTS server,
>    appropriate actions are enforced to block the attack traffic
> within
>    the source network.  The Call Home DOTS client is informed about
> the
>    progress of the attack mitigation following the rules in
>    [I-D.ietf-dots-rfc8782-bis].  For example, if the Call Home DOTS
>    server is embedded in a CPE, it can program the packet processor
> to
>    punt all the traffic from the compromised device to the target to
> 
> I think the sentence about "informed about the progress" might be
> misplaced at this location within the paragraph -- the example given
> seems to just be talking about the "appropriate actions" that are
> taken for blocking traffic, not any mitigation-status updates.

Med: Rearranged the text accordingly. 

> 
> Section 3.3.2
> 
>    If a Carrier Grade NAT (CGN, including NAT64) is located between
> the
>    DOTS client domain and DOTS server domain, communicating an
> external
>    IP address in a mitigation request is likely to be discarded by
> the
>    Call Home DOTS server because the external IP address is not
> visible
>    locally to the Call Home DOTS server (see Figure 10).  The Call
> Home
>    DOTS server is only aware of the internal IP addresses/prefixes
> bound
>    to its domain.  Thus, the Call Home DOTS client MUST NOT include
> the
>    external IP address and/or port number identifying the suspect
> attack
>    source, but MUST include the internal IP address and/or port
> number.
> 
> We're likely to get similar complaints about "how will they know
> there's a NAT" that we did for the base signal channel.  I don't
> have any great suggestions for trying to forestall such comments,
> though I do note that
> 8782 has some explicit text about "[t]his document does not make any
> recommendations about possible translator discovery mechanisms".

Med: The target deployment model is a service provider that want to preserve the reputation of its network. The CGN and the Call Home DOTS client are likely to be owned by that same SP. In such case, the information about the presence of address sharing is given.  

> 
> Also, it's amusing that for the base signal channel we said to *not*
> use internal addresses,

Med: which is normal because the internal addresses are private ones and local to the LAN. These addresses can be overlapping between LANs and are not useful to identify a target based on destination IP address.  

 but for call home we say you have to use
> internal addresses. 

Med: The addresses assigned by the CGN may not be visible locally while this information is available for the call home DOTS client. Providing an external IP @ + port number to the Call Home DOTS server won't be useful to determine the internal IP address + internal port number.

 In the base signal channel we also said that we
> did not give recommendations on how to discover possible translator
> mechanisms...

Med: We need to demonstrate that it is possible to provide useful information that will be used to identify the attack source. 

> 
>    To that aim, the Call Home DOTS client SHOULD rely on mechanisms,
>    such as [RFC8512] or [RFC8513], to retrieve the internal IP
> address
> 
> ... yet here we seem to be making such recommendations!

Med: For the reasons mentioned above. 

> 
>    If a MAP Border Relay [RFC7597] or lwAFTR [RFC7596] is enabled in
> the
>    provider's domain to service its customers, the identification of
> an
>    attack source bound to an IPv4 address/prefix MUST also rely on
>    source port numbers because the same IPv4 address is assigned to
>    multiple customers.  The port information is required to
>    unambiguously identify the source of an attack.
> 
> [same question about how to know that they are in use]

Med: Same answer :-)

> 
>    If a translator is enabled on the boundaries of the domain
> hosting
>    the Call Home DOTS server (e.g., a CPE with NAT enabled as shown
> in
>    Figures 11 and 12), the Call Home DOTS server uses the attack
> traffic
>    information conveyed in a mitigation request to find the internal
>    source IP address of the compromised device and blocks the
> traffic
> 
> In a similar vein, I expect to get some questions about how the call
> home DOTS server finds the internal source IP address from the
> attack traffic information conveyed. 

Med: because it is collocated with the NAT function and can thus proceed with lookup on the NAT table. 

 I don't have a specific change
> to propose at this time, since I don't know, myself, but we should
> at least have some answer to give in response to such questions.
> 
> The text is also a little unclear on why we provide both Figures 11
> and
> 12 -- while both cases are valid, we don't seem to have any
> discussion that highlights differences between the cases.

Med: Figure 10 is about a provider that controls both the CGN and the Call Home DOTS Client, while Figure 11 is focusing more on NAT considerations at attack source. 

  So
> perhaps we should say that the behavior of the call home DOTS server
> is the same whether or not the call home DOTS server is integrated
> with the CPE/NAT (if true)?

Med: This is not that true. The presence of a NAT at the attack source requires additional processing to identify the source and enforce appropriate actions. 

> 
> Section 3.3.3
> 
> I think the YANG module might benefit from being moved up a level or
> two in the section hierarchy.

Med: OK.

> 
> Section 3.3.3.1
> 
> Should we give some indication that 'signal' is the import prefix
> for "ietf-dots-signal-channel" before going into the tree diagram?
> (I do not know what the convention is in this regard.)

Med: We can add it a mention. 

> 
> Section 3.3.3.2
> 
> I suggest reiterating the note from 8782 about needing to check the
> mapping output provided by YANG-to-CBOR in light of the situations
> where differing CBOR/JSON types can arise (e.g., enumerations and
> 64-bit quantities).

Med: OK

> 
> I guess it's implicit that we reuse the CBOR map keys 8 and 9 for
> lower-port and upper-port in the source-port-range array?

Med: Yes. 

> 
> Section 3.3.3.3
> 
>    This module uses the common YANG types defined in [RFC6991] and
> the
>    data structure defined in [RFC8791].
> 
> (nit) I think we need another word here, maybe "data structure
> extension" or "data structure statement"?

Med: OK for "extension"

> 
>        list source-icmp-type-range {
>          key "lower-type";
>          description
>            "ICMP type range. When only lower-type is
>             present, it represents a single ICMP type.";
> 
> It seems that the interpretation of the source-icmp-type-range list
> is dependent on the IP address family in use.

Med: Yes. 

  Presumably one is
> supposed to infer this from the source-prefix

Med: It is inferred from the target-prefix (which is mandatory).

 (though we don't say
> so), but the source-prefix is optional when these fields are used in
> the base signal channel.  It is not entirely clear whether it is
> safe to rely on the target-prefix for address-family determination,
> though (I do not recall any reason why DOTS signal channel doesn't
> work in the presence of a NAPT function).  Should the icmp
> attributes only be allowed if the source-prefix is present?
> 
>      sx:augment-structure "/signal:dots-signal/signal:message-type/"
>                         + "signal:redirected-signal" {
>        description
>          "The alternate Call Home DOTS client.";
> 
> Is there something we can/should do for the redirected-signal
> augmentation to indicate that the alt-server and alt-server-record
> nodes are removed/useless?

Med: We do have the following in the bis:

           |     +--:(server-to-client-only)
           |        +-- alt-server           string
           |        +-- alt-server-record*   inet:ip-address

And in the following in this draft: 

          +--:(call-home-only)
             +-- alt-ch-client?          string
             +-- alt-ch-client-record*   inet:ip-address
             +-- ttl?                    uint32

But we can add some text to restate this. 

> 
>            leaf alt-ch-client {
>              type string;
>              description
>                "FQDN of an alternate Call Home DOTS client.";
> 
> Can we discuss a bit what the implications of redirection are for
> (D)TLS mutual authentication of the post-redirection channel?  It
> seems that in most cases the alt-ch-client FQDN will be needed to
> perform certificate validation.  Perhaps, though, there would be a
> case where a call home server has a set of preconfigured call home
> clients (each with IP
> address(es) and credentials), so a redirection by IP address to a
> different client in that set would still be functional.  So, I am
> not sure that we need to make alt-ch-client a mandatory field
> (whether in the YANG or in the prose), but we probably do need to
> have some text earlier in the document covering the implications for
> authenticating the redirected-to peer.  I note that in the base
> signal channel, alt-server is mandatory, so we would have some
> precendent for just making als-ch-client mandatory as well.
> 

Med: As you can read in the NEW text above, alt-ch-client is mandatory for the same reasons as in the base spec: certificate validation.  


_________________________________________________________________________________________________________________________

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.