Re: [Dots] DOTS Telemetry: URI Path

[<[e-mail]>]

Hi Kaname,

Please see inline.

Cheers,
Med

De : kaname nishizuka [mailto:[e-mail]]
Envoyé : vendredi 31 janvier 2020 03:10
À : BOUCADAIR Mohamed TGI/OLN; [e-mail]
Objet : Re: DOTS Telemetry: URI Path

Hi Med,

As per the hackathon report of the last IETF, Server to Client telemetry would require another URI in order to convey asynchronous notification of attack-details from a DOTS server.
https://datatracker.ietf.org/meeting/106/materials/slides-106-dots-dots-telemetry-related-hackathon-activity-report-00
slide 9.
I'd like to hear notions whether that is already taken into account or not.
[Med] I confirm that we have recorded that issue. The approach to be published in -01 can be seen at: https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-01.txt. This approach does not require a new uri: a client that is interested to receive pre-mitigation telemetry will enable an attribute called "server-initiated-telemetry". The server can then send telemetry data to the client using the same uri (/tm).
Of course, this design can be challenged. The plan is to work further on that part in -02.

Second, regarding with machine learning capability of DOTS, we've noticed some costomized feature like a ratio of SYN versus ACK in TCP flag is contributing for precise attack detection (in a feature construction process which is for obtaining contributing features from several metrics).
At the last meeting, we've discussed that conveying normal metric is already done by IPFIX.
But should adding this kind of DDoS dedicated metric be done in IPFIX or DOTS?
[Med]If this is about tweaking the detection machinery, I'm afraid this is not part of DOTS. We need more discussion to understand the use case.

thanks,
Kaname
On 2020/01/29 23:47, [e-mail]<mailto:[e-mail]> wrote:
Hi all,

We are currently in the process of updating the draft. I'm afraid that we will finaly need to go with more operation path URIs. See inline for more details.

Cheers,
Med

De : Dots [mailto:[e-mail]] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : jeudi 23 janvier 2020 16:41
À : [e-mail]<mailto:[e-mail]>; 'kaname nishizuka'
Objet : [Dots] DOTS Telemetry: URI Path

Hi all,

In the current version of the telemetry draft, we are using '/telemetry' for telemetry-related operations. Kaname suggested to define three operation suffixes for that. I do think that two are sufficient as indicated below:

         +-------------------------+----------------+
         | Operation               | Operation Path |
         +-------------------------+----------------+
         | Telemetry Setup         | /tm-setup      |
         +-------------------------+----------------+
         | Telemetry               | /tm            |
         +-------------------------+----------------+

A dedicated uri (/tm-setup) will be used for telemetry setup operations (baseline, configuration): see the excerpt below:

  augment /ietf-signal:dots-signal/ietf-signal:message-type:
    +--:(telemetry-setup) {dots-telemetry}?
    |  +--rw telemetry* [cuid tsid]
    |     +--rw cuid                string
    |     +--rw cdid?               string
    |     +--rw tsid                uint32
    |     +--rw telemetry-config
    |     |  +--rw low-percentile?    percentile
    |     |  +--rw mid-percentile?    percentile
    |     |  +--rw high-percentile?   percentile
    |     |  +--rw unit-config* [unit]
    |     |     +--rw unit           unit
    |     |     +--rw unit-status?   Boolean
            ...
    |     +--rw baseline
    |        +--rw total-pipe-capability* [unit]
    |        |  +--rw unit    unit
    |        |  +--rw pipe?   uint64
    |        +--rw total-traffic-normal-baseline* [unit protocol]
    |        |  +--rw unit                 unit
    |        |  +--rw protocol             uint8
    |        |  +--rw low-percentile-g?    yang:gauge64
    |        |  +--rw mid-percentile-g?    yang:gauge64
    |        |  +--rw high-percentile-g?   yang:gauge64
    |        |  +--rw peak-g?              yang:gauge64
    |        +--rw total-connection-capacity* [protocol]
    |           +--rw protocol                     uint8
      ...
[Med] The current updated tree structure is as follows:

  augment /ietf-signal:dots-signal/ietf-signal:message-type:
    +--:(telemetry-setup) {dots-telemetry}?
    |  +--rw telemetry* [cuid tsid]
    |     +--rw cuid                   string
    |     +--rw cdid?                  string
    |     +--rw tsid                   uint32
    |     +--rw telemetry-config
    |     |  +--rw measurement-interval?   interval
    |     |  +--rw measurement-sample?     sample
    |     |  +--rw low-percentile?         percentile
    |     |  +--rw mid-percentile?         percentile
    |     |  +--rw high-percentile?        percentile
    |     |  +--rw unit-config* [unit]
    |     |     +--rw unit           unit
    |     |     +--rw unit-status?   boolean
    |     +--rw total-pipe-capacity* [link-id unit]
    |     |  +--rw link-id    nt:link-id
    |     |  +--rw unit       unit
    |     |  +--rw pipe?      uint64
    |     +--rw baseline
    |        +--rw target-prefix*                   inet:ip-prefix
    |        +--rw target-port-range* [lower-port]
    |        |  +--rw lower-port    inet:port-number
    |        |  +--rw upper-port?   inet:port-number
    |        +--rw target-protocol*                 uint8
    |        +--rw target-fqdn*                     inet:domain-name
    |        +--rw target-uri*                      inet:uri
    |        +--rw total-traffic-normal-baseline* [unit protocol]
    |        |  +--rw unit                 unit
    |        |  +--rw protocol             uint8
    |        |  +--rw low-percentile-g?    yang:gauge64
    |        |  +--rw mid-percentile-g?    yang:gauge64
    |        |  +--rw high-percentile-g?   yang:gauge64
    |        |  +--rw peak-g?              yang:gauge64
    |        +--rw total-connection-capacity* [protocol]
    |           +--rw protocol                     uint8
    |           +--rw connection?                  uint64
    |           +--rw connection-client?           uint64
    |           +--rw embryonic?                   uint64
    |           +--rw embryonic-client?            uint64
    |           +--rw connection-ps?               uint64
    |           +--rw connection-client-ps?        uint64
    |           +--rw request-ps?                  uint64
    |           +--rw request-client-ps?           uint64
    |           +--rw partial-request-ps?          uint64
    |           +--rw partial-request-client-ps?   uint64

The new structure is designed with the following objectives:

·         Allow a multi-homed client domain to signal the capacity of each interconnection link.

·         The normal traffic base line can be provided for the overall domain (an aggregated prefix, or no target-clause included at all) or for specific targets (IP addresses, prefixes)

·         These parameters can be communicated using the same or distinct request. Checks on overlapping targets and links are covered.

Nevertheless, this design brings some complexity if a request overlaps with an existing pipe request but a new baseline traffic. We may either go for an additional uri or maintain one single uri but go with the following design (which is my favorite):

  augment /ietf-signal:dots-signal/ietf-signal:message-type:
    +--:(telemetry-setup) {dots-telemetry}?
    |  +--rw telemetry* [cuid tsid]
    |     +--rw cuid                          string
    |     +--rw cdid?                         string
    |     +--rw tsid                          uint32
    |     +--rw (setup-type)?
    |        +--:(telemetry-config)
    |        |  +--rw measurement-interval?   interval
    |        |  +--rw measurement-sample?     sample
    |        |  +--rw low-percentile?         percentile
    |        |  +--rw mid-percentile?         percentile
    |        |  +--rw high-percentile?        percentile
    |        |  +--rw unit-config* [unit]
    |        |     +--rw unit           unit
    |        |     +--rw unit-status?   boolean
    |        +--:(pipe)
    |        |  +--rw total-pipe-capacity* [link-id unit]
    |        |     +--rw link-id    nt:link-id
    |        |     +--rw unit       unit
    |        |     +--rw pipe?      uint64
    |        +--:(baseline)
    |           +--rw baseline
    |              +--rw target-prefix*                   inet:ip-prefix
    |              +--rw target-port-range* [lower-port]
    |              |  +--rw lower-port    inet:port-number
    |              |  +--rw upper-port?   inet:port-number
    |              +--rw target-protocol*                 uint8
    |              +--rw target-fqdn*                     inet:domain-name
    |              +--rw target-uri*                      inet:uri
    |              +--rw total-traffic-normal-baseline* [unit protocol]
    |              |  +--rw unit                 unit
    |              |  +--rw protocol             uint8
    |              |  +--rw low-percentile-g?    yang:gauge64
    |              |  +--rw mid-percentile-g?    yang:gauge64
    |              |  +--rw high-percentile-g?   yang:gauge64
    |              |  +--rw peak-g?              yang:gauge64
    |              +--rw total-connection-capacity* [protocol]
    |                 +--rw protocol                     uint8
    |                 +--rw connection?                  uint64
    |                 +--rw connection-client?           uint64
    |                 +--rw embryonic?                   uint64
    |                 +--rw embryonic-client?            uint64
    |                 +--rw connection-ps?               uint64
    |                 +--rw connection-client-ps?        uint64
    |                 +--rw request-ps?                  uint64
    |                 +--rw request-client-ps?           uint64
    |                 +--rw partial-request-ps?          uint64
Thoughts?

While '/tm' can be used for sharing pre-mitigation telemetry data (an excerpt of the tree is shown below).

    +--:(telemetry) {dots-telemetry}?
       +--rw pre-mitigation* [cuid telemetry-id]
          +--rw cuid                       string
          +--rw cdid?                      string
          +--rw telemetry-id               uint32
          +--rw target
          |  +--rw target-prefix*       inet:ip-prefix
          |  +--rw target-port-range* [lower-port]
          |  |  +--rw lower-port    inet:port-number
          |  |  +--rw upper-port?   inet:port-number
          |  +--rw target-protocol*     uint8
          |  +--rw target-fqdn*         inet:domain-name
          |  +--rw target-uri*          inet:uri
          +--ro total-attack-traffic* [unit protocol]
          |  +--ro unit                 unit
          |  +--ro protocol             uint8
          |  +--ro low-percentile-g?    yang:gauge64
          |  +--ro mid-percentile-g?    yang:gauge64
          |  +--ro high-percentile-g?   yang:gauge64
          |  +--ro peak-g?              yang:gauge64
          +--ro total-traffic* [unit protocol]
          ...
          +--ro attack-detail
             +--ro vendor-id?         uint32
             +--ro attack-id?         string
             +--ro attack-name?       string
             +--ro attack-severity?   attack-severity
             +--ro start-time?        uint64
             +--ro end-time?          uint64
             +--ro source-count
             |  +--ro low-percentile-g?    yang:gauge64
             |  +--ro mid-percentile-g?    yang:gauge64
             |  +--ro high-percentile-g?   yang:gauge64
             |  +--ro peak-g?              yang:gauge64
             +--ro top-talker
                +--ro source-prefix* [source-prefix]
                   +--ro spoofed-status?            boolean
                   +--ro source-prefix              inet:ip-prefix
                ...

Unless there are objections, we will implement this change in the next iteration of the draft.

Cheers,
Med