Subject: Re: [Dots] DOTS telemetry questions

From: <[email-masked]>
Date: Fri, 21 Feb 2020 07:00:07 +0000

Hi Jon,

(ccing the WG to track the changes).

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : jeudi 20 février 2020 21:58
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka
Objet : DOTS telemetry questions

Hi Guys,

1)      For example CBOR mappings

     Header: PUT (Code=0.03)
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "mitigate"
     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
     Uri-Path: "mid=123"
     If-Match:
     Content-Format: "application/dots+cbor"

     {
      "ietf-dots-signal-channel:mitigation-scope": {
        "scope": [
          {
            "alias-name": [
               "myserver"
             ],
            "attack-status": "under-attack",
            "ietf-dots-telemetry:total-attack-traffic": [
              {
                "ietf-dots-telemetry:unit": "megabytes-ps",
                "ietf-dots-telemetry:mid-percentile-g": "900"
              }
            ]
          }
        ]
      }
     }

    Figure 33: An Example of Mitigation Efficacy Update with Telemetry
                                Attributes

And yet the mapping table only has (no ietf-dots-telemetry: prefix)

    | total-attack-traffic | list        |32794 | 4 array       | Array  |

I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack traffic are the same CBOR value (or are they?)
[Med] The same value is used but I didn't check if there are side effects.

Please note that we have this note is section 10:

==
   o  Some of these attributes should be prepended with "ietf-dots-
      telemetry:"
==

but when mapping the CBOR back to JSON the variant of JSON parameter is context (Uri-Path: mitigate or tm) dependent.

2)      why do we not have a "enum megabit-ps" in "typedef unit" in the YANG Module?

[Med]  This can be added to the list as 'units()' are negotiated. *-bytes are more used for aggregates, but let's be consistent and have both bit/bytes in the units.

3)      I think that I have worked out that server-originated-telemetry if set allows telemetry included in the mitigation status rather than only returned using Uri-path: tm - correct?

[Med] I confirm. Note that including pre-mitigation returned using "Uri-path:tm" is controlled by PUT/GET (Section 7.3).

4)      I am confused by "pre-mitigation" which can be transmitted pre any mitigation taking place, or actually during when mitigation is taking place (or so I think) and would simply be better described as "attack-details" - especially with a statement such as

   DOTS agents MUST bind pre-mitigation telemetry data with mitigation

   requests relying upon the target clause.

[Med] That's an option but the current design allows to have the telemetry in // in order to supply more data ** without impacting the placement of a mitigation request ** hence the need to bind both (if any). If telemetry attributes are defined as mandatory (discussed in another thread), this would mean that the server will reject a mitigation that includes such attributes. With the current design, we have a functionality that can be safely enabled independently of the decision that we will make about whether telemetry attributes are mandatory to be supported or not.

Another point we can check to ease correlation between a mitigation request and pre-mitigation telemetry is to signal the "mid" in the telemetry message.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 21 Feb 2020 11:17:41 -0000

Hi Med et al,

See inline Jon>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 21 February 2020 07:00
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: [email-masked]
Subject: Re: [Dots] DOTS telemetry questions

Hi Jon,

Please see inline.

Cheers,

Med

Hi Guys,

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "mid=123"

     If-Match:

     {

        "scope": [

          {

            "alias-name": [

               "myserver"

             ],

              {

              }

            ]

          }

        ]

      }

     }

                                Attributes

I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack
traffic are the same CBOR value (or are they?)

[Med] The same value is used but I didn’t check if there are side effects. 

Jon> Need to think this through.  My implementation maps the CBOR into JSON
and then works on the JSON to do what is necessary and then converts the
JSON response back into CBOR.

Jon> We  have the same naming issues in
draft-ietf-dots-signal-filter-control-00 where we do not have the
ietf-dots-signal-control: prefix in the JSON examples (Fig 10)

==

      telemetry:"

==

but when mapping the CBOR back to JSON the variant of JSON parameter is
context (Uri-Path: mitigate or tm) dependent.

2)      why do we not have a “enum megabit-ps” in “typedef unit” in the YANG
Module?
[Med]  This can be added to the list as ‘units()’ are negotiated. *-bytes
are more used for aggregates, but let’s be consistent and have both
bit/bytes in the units.
Jon> Megabytes works with aggregates, megabits works with pipes.

3)      I think that I have worked out that server-originated-telemetry if
set allows telemetry included in the mitigation status rather than only
returned using Uri-path: tm – correct?
[Med] I confirm. Note that including pre-mitigation returned using
“Uri-path:tm” is controlled by PUT/GET (Section 7.3).
Jon> Agreed.  

4)      I am confused by “pre-mitigation” which can be transmitted pre any
mitigation taking place, or actually during when mitigation is taking place
(or so I think) and would simply be better described as “attack-details” –
especially with a statement such as

[Med] That’s an option but the current design allows to have the telemetry
in // in order to supply more data ** without impacting the placement of a
mitigation request ** hence the need to bind both (if any). If telemetry
attributes are defined as mandatory (discussed in another thread), this
would mean that the server will reject a mitigation that includes such
attributes. With the current design, we have a functionality that can be
safely enabled independently of the decision that we will make about whether
telemetry attributes are mandatory to be supported or not.
Jon> My primary point here was the use of the term “pre-mitigation” – this
telemetry is also needs during a mitigation and the attack keeps on morphing
into something else.
 
Another point we can check to ease correlation between a mitigation request
and pre-mitigation telemetry is to signal the “mid” in the telemetry
message.
Jon> could be – need to think this through
 
Regards
 
Jon

---

From: <[email-masked]>
Date: Fri, 21 Feb 2020 13:32:22 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : vendredi 21 février 2020 12:18
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Objet : RE: [Dots] DOTS telemetry questions

Hi Med et al,

See inline Jon>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
Sent: 21 February 2020 07:00
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: [email-masked]
Subject: Re: [Dots] DOTS telemetry questions

Hi Jon,

Please see inline.

Cheers,
Med

Hi Guys,

     Header: PUT (Code=0.03)
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "mitigate"

     {

I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack traffic are the same CBOR value (or are they?)
[Med] The same value is used but I didn't check if there are side effects.
Jon> Need to think this through.  My implementation maps the CBOR into JSON and then works on the JSON to do what is necessary and then converts the JSON response back into CBOR.
[Med] An issue with namespaces will be the encountered if the conversion is the same for the attribute when it is carried in a "pure" telemetry message or in an existing signal channel message.

Jon> We  have the same naming issues in draft-ietf-dots-signal-filter-control-00 where we do not have the ietf-dots-signal-control: prefix in the JSON examples (Fig 10)

[Med] Fig 10 is a "normal" mitigation request. Why should it need to include "ietf-dots-signal-control:" prefix?

==

[Med] I added the unit to the module. BTW, in order to easily define new units, I updated the module so that units are defined as identities, not enumerations. The updated mapping table is: https://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt)

Jon> Agreed.

Jon> My primary point here was the use of the term "pre-mitigation" - this telemetry is also needs during a mitigation and the attack keeps on morphing into something else.

[Med] I see your point. We will see if we can find a better term.

Jon> could be - need to think this through

[Med] Let's think about this one further.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 21 Feb 2020 15:45:32 -0000

Hi,

See inline Jon1>

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 21 February 2020 13:32
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
Subject: Re: [Dots] DOTS telemetry questions

Re-,

Please see inline. 

Cheers,

Med

De : Jon Shallow [mailto:[email-masked]] 
Envoyé : vendredi 21 février 2020 12:18
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka;
[email-masked]
Objet : RE: [Dots] DOTS telemetry questions

Hi Med et al,

See inline Jon>

Regards

Jon

Hi Jon,

Please see inline.

Cheers,

Med

Hi Guys,

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "mid=123"

     If-Match:

     {

        "scope": [

          {

            "alias-name": [

               "myserver"

             ],

              {

              }

            ]

          }

        ]

      }

     }

                                Attributes

[Med] An issue with namespaces will be the encountered if the conversion is
the same for the attribute when it is carried in a “pure” telemetry message
or in an existing signal channel message.

Jon1> Correct – I don’t like the concept of having 2 mapping tables for
mapping the CBOR value back into JSON.

Jon> We  have the same naming issues in
draft-ietf-dots-signal-filter-control-00 where we do not have the
ietf-dots-signal-control: prefix in the JSON examples (Fig 10)
[Med] Fig 10 is a “normal” mitigation request. Why should it need to include
“ietf-dots-signal-control:” prefix?

Jon1> My bad – I was looking at draft-ietf-dots-signal-filter-control-00,
not draft-ietf-dots-signal-filter-control-02.  However,
https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-02#section
-5.1 only defines “activation-type” without the prefix, and acl-list and
acl-name have the incorrect prefix: added to, for example, Figure 1.

==

      telemetry:"

==

2)      why do we not have a “enum megabit-ps” in “typedef unit” in the YANG
Module?
[Med]  This can be added to the list as ‘units()’ are negotiated. *-bytes
are more used for aggregates, but let’s be consistent and have both
bit/bytes in the units.
Jon> Megabytes works with aggregates, megabits works with pipes.
[Med] I added the unit to the module. BTW, in order to easily define new
units, I updated the module so that units are defined as identities, not
enumerations. The updated mapping table is:
https://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.
txt (or
https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-dot
s-telemetry-03.txt) 
Jon1> Typo in megabite-ps
Jon1> I am not sure about the usage of identityref.
https://tools.ietf.org/html/rfc7951#section-6.8 states that the value is
represented as a string (currently the CBOR mapping entry says it is an
integer), and furthermore it is likely that the namespace-qualified form is
required. This is a huge increase in the number of bytes needed whenever
unit (and measurement-interval Etc.) are used.  I think that this is a bad
change.  

 
Jon1> Agreed – it is the “pre” that certainly does not work for me.
Something like “attack information” ?

Another point we can check to ease correlation between a mitigation request
and pre-mitigation telemetry is to signal the “mid” in the telemetry
message.
Jon> could be – need to think this through
[Med] Let’s think about this one further.
Jon1> Sure – this may come out in the wash as we try to implement this
stuff.
 
Regards
 
Jon