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

[Benjamin Kaduk <[e-mail]>]

Hi Med,

Also inline.

On Wed, Oct 14, 2020 at 11:44:05AM +0000, [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):

Thanks for confirming.

> ==
> $ 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 believe that the tooling assumes they are transitive (and is right to do
so).  In essence, "we" don't know which parts of the individual draft the
IPR is supposed to apply to without getting legal advice, so if any part of
the individual draft's machinery appears in the WG draft we are forced to
assume that it is "tainted" by the IPR claim.

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

Okay.  I wasn't sure if (among other things)
"attack-mitigation-in-progress" is appropriate for "I'm not actually
mitigating anything yet, just waiting for approval".  Thanks for adding
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. 

I think it's okay to keep the example; it helps get people thinking outside
the box.

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

(Maybe "otherwise adhere"?)

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

Thanks a bunch; this does seem to meet the "crystal clear" criterion.
I am sure that you considered "DOTS Call Home server"/client in the one
sentence that uses "DOTS server"/client before the call-home-specific terms
are introduced, and don't want to try to nitpick further.

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

Sorry, I meant that the figure occurs before the terminology section in the
flow of the document.  Even expanding "DMS" specifically in the terminology
section doesn't change that.  (But I don't have a particular proposal to
improve things, and am willing to leave it as you have it in the editor's
copy.)

Thanks,

Ben

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