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

[tirumal reddy <[e-mail]>]

On Wed, 14 Oct 2020 at 17:14, <[e-mail]> wrote:

> Hi Ben,
>
> Thank you for the detailed review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:[e-mail]]
> > Envoyé : mercredi 14 octobre 2020 01:08
> > À : [e-mail]
> > Cc : [e-mail]
> > Objet : AD evaluation of draft-ietf-dots-signal-call-home-09
> >
> > Hi all,
> >
> > Nothing super-earth-shattering in here, but there's enough that
> > we'll need a revised I-D and some more WG input before I'm ready to
> > start the IETF LC.
> >
> > -Ben
> >
> >
> > YANG lint says:
> >
> > [e-mail]:11: warning: imported module
> > "ietf-dots-signal-channel" not used
> >
> > AFAICT that's a yanglint bug, since we do augment nodes from the
> > signal channel.
>
> [Med] Yes, it is a pyang issue. We have a similar warning for RFC8791
> (where sx is defined):
>
> ==
> $ pyang -f tree --tree-print-structures example-module-aug\@2020-07-07.yang
> [e-mail]:9: warning: imported module
> "example-module" not used
> module: example-module-aug
>
>   augment-structure /exm:address-book/exm:address:
>     +-- county?    string
>     +-- zipcode?   string
> ==
>
> >
> > I see that this document has a few IPR notices against it; in
> > particular, the one at https://datatracker.ietf.org/ipr/3318/ does
> > not list any licensing terms ("Unwilling to Commit to the Provisions
> > of a), b), or c) Above", where a/b/c are "no license needed for
> > implementation"/"RAND with no fee"/"RAND with possible fee").
> > I believe we are working to see if the situation can be clarified
> > and the IPR disclosure updated, but I don't know that we need to
> > delay any progress until that has occurred.  That said, personally,
> > I'm not very comfortable about a protocol that potentially is
> > encumbered by IPR with unknown license terms.  However, I am willing
> > to at least advance the document to IETF LC if there is clear WG
> > support for doing so, even knowing that use of the protocol would
> > potentially be subject to arbitrary terms from the IPR holder.  I
> > would really like to hear from the WG members on this point.
>
> [Med] Actually, there is only one IPR disclosure (3328) that is directly
> made for the document. Some more information below:
> * The two IPR disclosures (3318/3337) were made in early stages of the
> development of the individual submission, especially before WG adoption.
> * 3328 is not a new disclosure but an update of 3337 to point to the
> wg-adopted version. A note was sent to the chairs to inform them about the
> update.
> * I'm not sure that IPR disclosures are transitive. 3318 is not filled
> directly against draft-ietf-dots-signal-call-home.
>
> >
> > I mention it in the section-by-section comments, but we introduce
> > the possibility of "wait for administrator approval" in the
> > mitigation-request processing pipeline, which could exceed a normal
> > CoAP request timeout.  I think we need to have some substantive text
> > discussion the expected behavior in this case.
>
> [Med] There is no request timeout because a request that requires an admin
> validation can be first replied with attack-mitigation-in-progress status.
> If the request is then rejected by the admin, the status will change to
> attack-mitigation-withdrawn with conflict-status set to the new code
> "mitigation-request-rejected" defined in the document.
>
> Will add more text.
>
> >
> > Section 1.1
> >
> >    Some of the DDoS attacks like spoofed RST or FIN packets,
> > Slowloris,
> >    and Transport Layer Security (TLS) re-negotiation are difficult
> > to
> >    detect on a home network device without adversely affecting its
> >
> > (side note) TLS renegotiation as an attack is just keeping a TLS
> > connection open and repeatedly re-negotiating to cause the server to
> > burn CPU on signing operations?
>
> [Med] Yes.
>
>   I don't think I've heard of that
> > one before.
>
> [Med] Some DoS tools are supporting this, but I don't have data about
> recent attacks exploiting it. Unless there is an objection (Tiru?), I would
> remove the example as we don't need to be exhaustive anyway.
>

SSL renegotiation is a popular DDoS attack, see
https://blog.radware.com/security/ssl/2020/08/ssl-protective-technology-turned-attack-vector/


-Tiru


> >
> > Section 1.2
> >
> >    'DOTS signal channel Call Home' (or DOTS Call Home, for short)
> > refers
> >    to a DOTS signal channel established at the initiative of a DOTS
> >    server.  That is, the DOTS server initiates a secure connection
> > to a
> >    DOTS client, and uses that connection to receive the attack
> > traffic
> >    information (e.g., attack sources) from the DOTS client.  More
> >    details are provided in Section 3.
> >
> > I think this introductory section needs to be crystal clear for the
> > reader about the relationship between the "conventional" signal
> > channel DOTS client and the corresponding call home DOTS client for
> > a given mitigation process.  Some people will expect both things
> > with "client"
> > in the name to be on the same device, and some people will expect
> > the (call home) client to be the device that makes mitigation
> > requests, but both cannot be right.  The phrase "role reversal"
> > might be useful in describing these interpretations, as might a
> > forward reference to section 1.4.  (Yes, I understand that there is
> > no need for either DOTS call home peer to be colocated with any base
> > signal channel element, but I think that the default scenario in
> > many readers' minds will be the simple role-reversal setup.)
> >
>
> [Med] The NEW text is as follows:
>
> NEW:
>    'DOTS signal channel Call Home' (or DOTS Call Home, for short) refers
>    to a DOTS signal channel established at the initiative of a DOTS
>    server thanks to a role reversal at the (D)TLS layer (Section 3.1).
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    That is, the DOTS server initiates a secure connection to a DOTS
>    client, and uses that connection to receive the attack traffic
>    information (e.g., attack sources) from the DOTS client.
>
>    DOTS agents involved in the DOTS Call Home adhere to the DOTS roles
>    as defined in [RFC8612].  For clarity, this document uses "Call Home
>    DOTS client" (or "Call Home DOTS server") to refer to a DOTS client
>    (or DOTS server) deployed in a Call Home scenario (Figure 1).  DOTS
>    Call Home agents may (or not) be co-located with DOTS agents that are
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    compliant with [I-D.ietf-dots-rfc8782-bis] (see Section 1.4 for more
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    details).
>
>
> > Section 1.3
> >
> > It's a little unfortunate that we are using the "DMS" acronym in the
> > figure here, when we only mention the terminology of RFC 8612 in
> > section 2.  (That said, I'm willing to leave it as-is for now and
> > see if anyone
> > complains.)
>
> [Med] Added this NEW text to the terminology section:
>
>    DDoS Mitigation System (DMS) refers to a system that performs DDoS
>    mitigation.
>
> >
> > Section 3.1
> >
> >    The DOTS signal channel Call Home preserves all but one of the
> > DOTS
> >    client/server roles in the DOTS protocol stack, as compared to
> > DOTS
> >    client-initiated DOTS signal channel protocol
> >
> > I suppose one could quibble about whether "party allowed to behave
> > passively with respect to heartbeats" qualifies as a "client/server
> > role" ... I think I'm okay leaving this as-is for now, though.
> >
> >    For example, a home network element (e.g., home router) co-
> > located
> >    with a Call Home DOTS server is the (D)TLS server.  However, when
> >
> > Figure 7 has a box labelled "Call Home DOTS server" and also "(D)TLS
> > client" (not server).  At first I thought this was trying to make an
> > analogy to a (normal) signal channel DOTS server as being the (D)TLS
> > server, but that would not be in a home network element.  So maybe
> > this is just a typo?
>
> [Med] This is a typo in the text. The figure is correct. Thanks for
> catching this.
>
> >
> >    calling home, the DOTS server initially assumes the role of the
> >    (D)TLS client, but the network element's role as a DOTS server
> >
> > We may want to continue using "DOTS Call Home server" in these two
> > lines.
>
> [Med] OK.
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>