Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt

From: <[email-masked]>
Date: Mon, 3 Feb 2020 09:36:39 +0000

Hi all, 

FYI, a review from Jon is available at: https://github.com/boucadair/draft-dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon-res%20Med.docx 

-02 will integrate almost all comments from  Jon. Please find below some points we would like to hear more from the working group:

(1) key value range for telemetry: Jon raised this point "These keys requires 3 bytes - and telemetry information is going to be difficult to fit into a packet.  I appreciate that comprehension-required
Is for numbers less than 0x8000 - perhaps the comprehension-required range is reduced and also has a section higher up so the total of 0x8000 still stands so less bytes can be used here."

   +----------------------+-------+-------+------------+---------------+
   | Parameter Name       | CBOR  | CBOR  | Change     | Specification |
   |                      | Key   | Major | Controller | Document(s)   |
   |                      | Value | Type  |            |               |
   +----------------------+-------+-------+------------+---------------+
   | ietf-dots-signal-cha | 32776 |   5   |    IESG    |   [RFCXXXX]   |
   | nnel:telemetry       |       |       |            |               | 

Med: This is a major one. We need to assess the gain, but it is possible in theory to update our assignment policies and reassign, e.g., 128-255 range to be comprehension-optional (specific for telemetry). This would mean that the telemetry spec will be tagged as updating the base signal channel spec. We need more discussion. 

(2) server-initiated-telemetry: "Having server-initiated-telemetry under max-config-values, but not min-config-values makes no sense to me.  I think it should be under telemetry-config at the level of current-config and possibly removed from current-config as well."

Med: 

A. It is in the max container because setting that value to "false" under that container has a special meaning: the server does not support sending pre-mitigation telemetry. We can put it under min as well but do we have a case where setting it to "true" has a meaning?
B. I do agree that 'server-initiated-telemetry' can be removed from the current configuration because the same functionality is achieved using a GET+Observe but we left it there for the moment as we need to work further the details for subscribing to pre-mitigation from the servers.  

(3) "vendor-id is missing from the cbor table":

Med: This was done on purpose to try to optimize the number of CBOR key values + encourage attributes reuse. E.g., We replaced "telemetry-id", "baseline-id", and "vendor-id" with a single "id" (as we only use those for the moment in the message body) but the YANG module includes the meaning of each "id" in the definition clause. We may need to revise this if we conclude that, e.g., "telemetry-id" (tmid) has to be defined as Path-URI.  

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : vendredi 31 janvier 2020 16:18
> À : [email-masked]
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> 
> Hi all,
> 
> We prepared with Tiru a major revision of the telemetry draft. A diff
> is provided below to track the changes. We will now focus on sections
> 7 and 8.
> 
> Please review and share comments.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:[email-masked]] De la part de internet-
> > [email-masked]
> > Envoyé : vendredi 31 janvier 2020 15:52
> > À : [email-masked]
> > Cc : [email-masked]
> > Objet : [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the DDoS Open Threat Signaling WG of
> the
> > IETF.
> >
> >         Title           : Distributed Denial-of-Service Open Threat
> > Signaling (DOTS) Telemetry
> >         Authors         : Mohamed Boucadair
> >                           Tirumaleswar Reddy
> >                           Ehud Doron
> >                           Meiling Chen
> > 	Filename        : draft-ietf-dots-telemetry-01.txt
> > 	Pages           : 70
> > 	Date            : 2020-01-31
> >
> > Abstract:
> >    This document aims to enrich DOTS signal channel protocol with
> >    various telemetry attributes allowing optimal DDoS attack
> > mitigation.
> >    This document specifies the normal traffic baseline and attack
> >    traffic telemetry attributes a DOTS client can convey to its DOTS
> >    server in the mitigation request, the mitigation status telemetry
> >    attributes a DOTS server can communicate to a DOTS client, and
> the
> >    mitigation efficacy telemetry attributes a DOTS client can
> >    communicate to a DOTS server.  The telemetry attributes can
> assist
> >    the mitigator to choose the DDoS mitigation techniques and
> perform
> >    optimal DDoS attack mitigation.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dots-telemetry-01
> > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-01
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Dots mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 5 Feb 2020 06:58:42 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> Sent: Monday, February 3, 2020 3:07 PM
> To: Jon Shallow ([email-masked]) <[email-masked]>;
> [email-masked]
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hi all,
> 
> FYI, a review from Jon is available at: https://github.com/boucadair/draft-
> dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon-
> res%20Med.docx
> 
> -02 will integrate almost all comments from  Jon. Please find below some
> points we would like to hear more from the working group:
> 
> (1) key value range for telemetry: Jon raised this point "These keys requires 3
> bytes - and telemetry information is going to be difficult to fit into a packet.  I
> appreciate that comprehension-required Is for numbers less than 0x8000 -
> perhaps the comprehension-required range is reduced and also has a section
> higher up so the total of 0x8000 still stands so less bytes can be used here."
> 
> Med: This is a major one. We need to assess the gain, but it is possible in
> theory to update our assignment policies and reassign, e.g., 128-255 range to
> be comprehension-optional (specific for telemetry). This would mean that
> the telemetry spec will be tagged as updating the base signal channel spec.
> We need more discussion.

Why not change the DOTS telemetry attributes to comprehension-required ?
If the server does not understand the DOTS telemetry attributes, it will respond with 4.00 error response, and the client can re-send the request without the DOTS telemetry attributes.

Cheers,
-Tiru

> 
> (2) server-initiated-telemetry: "Having server-initiated-telemetry under
> max-config-values, but not min-config-values makes no sense to me.  I think
> it should be under telemetry-config at the level of current-config and
> possibly removed from current-config as well."
> 
> Med:
> 
> A. It is in the max container because setting that value to "false" under that
> container has a special meaning: the server does not support sending pre-
> mitigation telemetry. We can put it under min as well but do we have a case
> where setting it to "true" has a meaning?
> B. I do agree that 'server-initiated-telemetry' can be removed from the
> current configuration because the same functionality is achieved using a
> GET+Observe but we left it there for the moment as we need to work
> further the details for subscribing to pre-mitigation from the servers.
> 
> Med: This was done on purpose to try to optimize the number of CBOR key
> values + encourage attributes reuse. E.g., We replaced "telemetry-id",
> "baseline-id", and "vendor-id" with a single "id" (as we only use those for the
> moment in the message body) but the YANG module includes the meaning
> of each "id" in the definition clause. We may need to revise this if we
> conclude that, e.g., "telemetry-id" (tmid) has to be defined as Path-URI.
> 
> Cheers,
> Med
> 
> > [email-masked] Envoyé : vendredi 31 janvier 2020 16:18
> À
> > : [email-masked] Objet : Re: [Dots] I-D Action:
> > draft-ietf-dots-telemetry-01.txt
> >
> > Hi all,
> >
> > > [email-masked] Envoyé : vendredi 31 janvier 2020 15:52 À :
> > > [email-masked] Cc : [email-masked] Objet : [Dots] I-D Action:
> > > draft-ietf-dots-telemetry-01.txt
> > >
> > >
> > > submission until the htmlized version and diff are available at
> > > tools.ietf.org.
> > >

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 5 Feb 2020 20:24:08 -0000

See inline

Regards

Jon

> From: Dots [mailto: [email-masked]] On Behalf Of Konda,
> Tirumaleswar Reddy
> Sent: 05 February 2020 06:59
> To: [email-masked]; Jon Shallow (supjps-
> [email-masked]); [email-masked]
> > theory to update our assignment policies and reassign, e.g., 128-255
range
> to
> If the server does not understand the DOTS telemetry attributes, it will
> respond with 4.00 error response, and the client can re-send the request
> without the DOTS telemetry attributes.

Jon> Telemetry is also gated by a different sets of Path-URIs.  However,
source-prefix attribute comes from draft-ietf-dots-signal-call-home and also
occupies 3 bytes - do we change the source-prefix CBOR Key type to
comprehension-required?

> > A. It is in the max container because setting that value to "false"
under
> that
> > "baseline-id", and "vendor-id" with a single "id" (as we only use those
for
> > conclude that, e.g., "telemetry-id" (tmid) has to be defined as
Path-URI.

Jon>  Hmm - need to think through tmid + Path-URI.
~jon

---

From: <[email-masked]>
Date: Thu, 6 Feb 2020 06:39:02 +0000

Hi Jon, all, 

Please see inline. 

Cheers,
Med

> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : mercredi 5 février 2020 21:24
> À : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed TGI/OLN;
> [email-masked]
> Objet : RE: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> 
> See inline
> 
> Regards
> 
> Jon
> 
...
> > >
> > > (1) key value range for telemetry: Jon raised this point "These
> keys
> > requires 3
> > > bytes - and telemetry information is going to be difficult to fit
> into a
> > packet.  I
> > > higher up so the total of 0x8000 still stands so less bytes can be
> used
> > here."
> > >
> > >    |                      | Value | Type  |            |
> |
> > > Med: This is a major one. We need to assess the gain, but it is
> possible
> in
> > > the telemetry spec will be tagged as updating the base signal
> channel
> > spec.
> > > We need more discussion.
> >
> > Why not change the DOTS telemetry attributes to comprehension-
> required
> > ?

[Med] Telemetry attributes are not mandatory for the signal channel to function. A signal channel message enriched with telemetry data should not exacerbate message failure. 

> Jon> Telemetry is also gated by a different sets of Path-URIs.

[Med] Except when telemetry is also included in an update during a mitigation (S-C or S-C). What I have for this one in my local copy is as follows:

   In order to make use of this feature, DOTS clients MUST establish a
   telemetry setup session with the DOTS server in 'idle' time and MUST
   set the 'server-originated-telemetry' attribute to 'true'.

   DOTS servers MUST NOT include telemetry attributes in mitigation
   status updates sent to DOTS clients for which 'server-originated-
   telemetry' attribute is set to 'false'. 

> However,

[Med] Including a source prefix in a signal channel message while not supported by the server must not lead to an error. That attribute cannot be set a comprehension-required. I suggest we don't touch that part.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 7 Feb 2020 10:49:25 +0000

> From: [email-masked]
> <[email-masked]>
> Sent: Thursday, February 6, 2020 12:09 PM
> To: Jon Shallow <[email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: RE: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> 
> > Envoyé : mercredi 5 février 2020 21:24 À : 'Konda, Tirumaleswar
> > Reddy'; BOUCADAIR Mohamed TGI/OLN; [email-masked] Objet : RE: [Dots]
> > I-D Action: draft-ietf-dots-telemetry-01.txt
> >
> > See inline
> >
> > Regards
> >
> > Jon
> >
> ...
> > > >
> [Med] Telemetry attributes are not mandatory for the signal channel to
> function. A signal channel message enriched with telemetry data should not
> exacerbate message failure.
> 
> [Med] Except when telemetry is also included in an update during a
> mitigation (S-C or S-C). What I have for this one in my local copy is as follows:
> 
> > source-prefix attribute comes from draft-ietf-dots-signal-call-home
> > and also occupies 3 bytes - do we change the source-prefix CBOR Key
> > type to comprehension-required?
> >
> 
> [Med] Including a source prefix in a signal channel message while not
> supported by the server must not lead to an error. That attribute cannot be
> set a comprehension-required. I suggest we don't touch that part.

Works for me.

-Tiru