Subject: [Dots] Opsdir last call review of draft-ietf-dots-rfc8782-bis-01

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Thu, 12 Nov 2020 03:19:29 -0800

Reviewer: Dan Romascanu
Review result: Has Issues

This document specifies the Distributed Denial-of-Service Open Threat Signaling
(DOTS) signal channel, a protocol for signaling the need for protection against
Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling
network traffic mitigation on behalf of the requesting client. The DOTS data
channel is defined in an associated document. The document updates RFC 8872.

The document is almost Ready from an OPS perspective, but there are a couple of
issues worth clarification before approval.

1. Appendix A describes the changes from RFC 8782. I could not find however any
information in the document concerning backwards compatibility and the path of
upgrade that an operator should be aware about when migrating an existing
client, server or the whole network from RFC 8782 support. If I missed it,
please point and maybe detail this information in the Appendix. If not, it
would be useful to add.

2. I could not find any information about the supplementary overload that the
changes in signaling brought by this update may bring. If such an analysis was
made, it would be useful to mention its results. No significant extra-load is
fine. If anything different, it would be useful to add more details.

---

From: <[email-masked]>
Date: Thu, 12 Nov 2020 12:00:52 +0000

Hi Dan,

Thank you for the review. 

There are no changes to the on wire protocol because the YANG modeled data is mapped to CBOR (Section 3): 

   This document specifies a YANG module for representing DOTS
   mitigation scopes, DOTS signal channel session configuration data,
   and DOTS redirected signaling (Section 5).  All parameters in the
                                               ^^^^^^^^^^^^^^^^^^^^
   payload of the DOTS signal channel are mapped to CBOR types as
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   specified in Table 5 (Section 6).
   ^^^^^^^^^^^^^^^^^^^^  

and that we managed the update with the following in mind (Appendix A.  Summary of Changes From RFC8782): 

   These modifications are made with the constraint to avoid changes to
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the mapping table defined in Table 5 (Section 6).  A DOTS signal^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   channel attribute that may be present in both requests and responses
   will thus have the same CBOR key value and CBOR major type.

Even if an implementation relies on the YANG module to generate the mapping table, it must anyway to comply with Table 5 (RFC8782):

      Note: Implementers must check that the mapping output provided by
      their YANG-to-CBOR encoding schemes is aligned with the content of
      Table 5.  For example, some CBOR and JSON types for enumerations
      and the 64-bit quantities can differ depending on the encoder
      used.

Cheers,
Med

> -----Message d'origine-----
> De : Dan Romascanu via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 12 novembre 2020 12:19
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
> 
> Reviewer: Dan Romascanu
> (DOTS) signal channel, a protocol for signaling the need for
> protection against Distributed Denial-of-Service (DDoS) attacks to a
> server capable of enabling network traffic mitigation on behalf of
> the requesting client. The DOTS data channel is defined in an
> associated document. The document updates RFC 8872.
> 
> The document is almost Ready from an OPS perspective, but there are
> a couple of issues worth clarification before approval.
> 
> 1. Appendix A describes the changes from RFC 8782. I could not find
> however any information in the document concerning backwards
> compatibility and the path of upgrade that an operator should be
> aware about when migrating an existing client, server or the whole
> network from RFC 8782 support. If I missed it, please point and
> maybe detail this information in the Appendix. If not, it would be
> useful to add.
> 
> 2. I could not find any information about the supplementary overload
> that the changes in signaling brought by this update may bring. If
> such an analysis was made, it would be useful to mention its
> results. No significant extra-load is fine. If anything different,
> it would be useful to add more details.
> 

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Tue, 17 Nov 2020 16:37:20 +0000

Hi Dan, 

We moved the text that I already quoted from the appendix to the main text and updated with more text to better address your issue #1. 

The changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-02 

Thank you. 

Cheers,
Med

> De : [email-masked]
> [mailto:[email-masked]]
> Envoyé : jeudi 12 novembre 2020 13:01
> À : Dan Romascanu <[email-masked]>; [email-masked]
> [email-masked]
> Objet : RE: Opsdir last call review of draft-ietf-dots-rfc8782-bis-
> 01
> 
> Hi Dan,
> 
> There are no changes to the on wire protocol because the YANG
> modeled data is mapped to CBOR (Section 3):
> 
> Even if an implementation relies on the YANG module to generate the
> mapping table, it must anyway to comply with Table 5 (RFC8782):
> 
> Envoyé :
> > jeudi 12 novembre 2020 12:19 À : [email-masked] Cc :
> > [email-masked]; [email-masked];
> > This document specifies the Distributed Denial-of-Service Open
> Threat
> > Signaling
> the
> > requesting client. The DOTS data channel is defined in an
> associated
> > The document is almost Ready from an OPS perspective, but there
> are a
> > couple of issues worth clarification before approval.
> >
> aware
> > about when migrating an existing client, server or the whole
> network
> > from RFC 8782 support. If I missed it, please point and maybe
> detail
> > this information in the Appendix. If not, it would be useful to
> add.
> >
> results.
> > No significant extra-load is fine. If anything different, it would
> be
> > useful to add more details.
> >
> 
> 
> ____________________________________________________________________
> _____________________________________________________
> 
> 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.

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 17 Nov 2020 18:52:49 +0200

Thank you. Looks good.

Regards,

Dan

On Tue, Nov 17, 2020 at 6:37 PM <[email-masked]> wrote:

> Hi Dan,
>
> We moved the text that I already quoted from the appendix to the main text
> and updated with more text to better address your issue #1.
>
> The changes can be tracked at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-02
>
> Thank you.
>
> Cheers,
> Med
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;