Re: [Dots] DOTS telemetry questions

[<[e-mail]>]

Hi Jon,

(ccing the WG to track the changes).

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[e-mail]]
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