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

[tirumal reddy <[e-mail]>]

On Thu, 15 Oct 2020 at 07:55, Benjamin Kaduk <[e-mail]> wrote:

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

An update to IPR disclosure (3318) will be published soon.

-Tiru


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