Re: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt

[[e-mail]]

Hi Jon, 

Moving the discussion to the WG list as this is an important design change we need to make. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[e-mail]]
> Envoyé : jeudi 2 avril 2020 21:49
> À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname
> nishizuka
> Objet : RE: [Dots] New Version Notification for draft-ietf-dots-
> telemetry-05.txt
> 
> Stepping back to look at the bigger picture, I think that I would be
> more interested in the detail of a potentially multi-vectored mutating
> attack, and so question whether having target-protocol as an overall
> restrictive view of all the detail makes sense.  It is easier to
> filter out data that I do not want / care about after receiving it.
> The remote peer may not have the same view of what to send v what I am
> interested in.
> 
> [I am concerned about over-filling a packet and having to go into CoAP
> Block2 mode though which will fail on a saturated link.  I have not
> done any sizing of that yet with genuine attack information]
> 
> So, for the /tm and /tm-setup stuff do we really need target-protocol
> and could just have protocol as an optional, but array, entity?

[Med] It is important to provide details per protocol as this will help identifying abnormal patterns. 

We could associate 0 to mean "all" protocols but I know this will hurt many. We can consider the following change:

OLD

    |           +--rw baseline* [id]
    |              +--rw id                               uint32
    |              +--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

NEW:

    |        +--:(baseline)
    |           +--rw baseline* [id]
    |              +--rw id                                   uint32
    |              +--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 alias-name*                          string
    |              +--rw total-traffic-normal* [unit]
    |              |  +--rw unit                 unit
    |              |  +--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-traffic-normal-per-protocol* [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

Of course, the protocol must be listed in target-protocol (if present).

> 
> Then for /mitigate, target-protocol is ignored in deciding what to
> send back, but the use of an optional protocol array can reduce some
> of the packet size.
> 
> total-attack-connection  / total-connection-capacity will only be for
> connection based connections - primarily TCP I suspect. 

[Med] Agree.

 However
> (target) ports may be relevant here - a server may be able to support
> X HTTPS connections, but only Y DNS (TCP) connections - or a load-
> balancer in the path is only  capable of handling Z connections - no
> matter what the port is..  So, do we want to introduce optional ports?

[Med] These ports have to be listed in target-port-range (if present). If we include port to the existing list, we can't maintain two entries for the same protocol but with distinct port. It may be more simple to make this change:

OLD:
    |              +--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

NEW:

    |              +--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
    |              +--rw total-connection-capacity-per-port* [protocol lower-port]
    |                 +--rw protocol                     uint8
    |                 +--rw lower-port                   inet:port-number
    |                 +--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

> 
> > > NEW:
> > > "Sending a DELETE with no 'tmid' indicates that all 'tmids' must
> be
> > > deactivated."
> > >
> 
> I found this (but I prefer your addition for consistency)
> 
>    A DOTS client that lost the state of its active 'tmids' or has to
> set
>    'tmid' back to zero (e.g., crash or restart) MUST send a GET
> request
>    to the DOTS server to retrieve the list of active 'tmid'.  The DOTS
>    client may then delete 'tmids' that should not be active anymore.
> 

[Med] Yes. The NEW text will be right after this one. 

> Other minor nits
> 
> OLD
>    attack-severity:  Attack severity.  These values are supported:
>       Emergency (1), critical (2), and alert (3).
> NEW (case of emergency)
>    attack-severity:  Attack severity.  These values are supported:
>       emergency (1), critical (2), and alert (3).
> 
> OLD
>    tmid:  Telemetry Identifier is an identifier for the DOTS pre-or-
>         ongoing-mitigation telemetry data represented as an integer.
>         This identifier MUST be generated by DOTS clients. 'tsid'
> values
> NEW tsid -> tmid
>    tmid:  Telemetry Identifier is an identifier for the DOTS pre-or-
>         ongoing-mitigation telemetry data represented as an integer.
>         This identifier MUST be generated by DOTS clients. 'tmid'
> values
> 

[Med] Fixed. Thanks.  

> Regards
> 
> Jon
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > Sent: 02 April 2020 19:42
> > To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka
> > Subject: RE: [Dots] New Version Notification for draft-ietf-dots-
> telemetry-05.txt
> >
> > Re-,
> >
> > The same issue applies as well for the baseline component:
> >
> > If we convey multiple protocols in target-prefix and want to signal
> all total-
> > traffic-normal-baseline + total-traffic-normal-baseline of each
> protocol listed in
> > target-prefix, we will need to have to use an index in addition to
> the unit.
> > Protocol can then become optional. The same apply for total-
> connection-
> > capacity.
> >
> > I need to think about this further.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : BOUCADAIR Mohamed TGI/OLN
> > > Envoyé : jeudi 2 avril 2020 19:29
> > > À : 'Jon Shallow'; Konda, Tirumaleswar Reddy; kaname nishizuka
> > > Objet : RE: [Dots] New Version Notification for draft-ietf-dots-
> > > telemetry-05.txt
> > >
> > > Hi Jon,
> > >
> > > Please see inline.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Jon Shallow [mailto:[e-mail]]
> > > > Envoyé : mercredi 1 avril 2020 23:01
> > > > À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname
> > > > nishizuka
> > > > Objet : RE: [Dots] New Version Notification for draft-ietf-dots-
> > > > telemetry-05.txt
> > > >
> > > > Hi Med et al,
> > > >
> > > > Other nits (as well as 2 following sections)
> > > >
> > > > OLD:
> > > >
> > > >    ongoing-mitigation telemetry data from the DOTS server.  The
> GET
> > > >    request specify a 'tmid' (Figure 31) or not (Figure 32).
> > > >
> > > > NEW:
> > > >
> > > >    ongoing-mitigation telemetry data from the DOTS server.  The
> GET
> > > >    request specifies a 'tmid' (Figure 31) or not (Figure 32).
> > > >
> > >
> > > [Med] Fixed.
> > >
> > >
> > > > DELETE /tm
> > > >
> > > > Does no tmid= delete all tmids ?
> > > > - In particular after a restart of a client?
> > > >
> > >
> > > [Med] Yes, they should be "deactivated".
> > >
> > > NEW:
> > > "Sending a DELETE with no 'tmid' indicates that all 'tmids' must
> be
> > > deactivated."
> > >
> > > > >
> > > > > .. The below is coming from what the server sends to the
> client
> > > > perspective.  I
> > > > > accept that in the client sending to the server having target-
> > > > protocol and
> > > > > protocol may give rise to some potential confusion...
> > > > >
> > >
> > > [Med] Let's see how to avoid the inconsistency. The YANG module is
> > > currently reflecting the text we have I draft-ietf-dots-telemetry-
> > > 04#section-7.1. We need to check that section to see where the
> per-
> > > transport is mentioned and make sure we don't break things.
> > >
> > > For example, if protocol is present in the target, we to avoid
> > > conflicting (and redundant) information to be supplied in the
> > > telemetry data.
> > >
> > > > > >
> > > > > > In terms of protocol, there are still some consistencies
> even if
> > > > you accept the
> > > > > > argument that protocol is already defined in the mitigation
> > > scope
> > > > (which I am
> > > > > > not happy with).
> > > > > >
> > > > > > 1) target-protocol is optionally set and it is an array
> whereas
> > > > protocol is
> > > > > singular
> > > > > >
> > > > > > 2) protocol is defined mitigation scope augment as per
> > > > > > module: ietf-dots-telemetry
> > > > > >   augment /ietf-signal:dots-signal/ietf-signal:message-
> > > type/ietf-
> > > > > signal:mitigation-
> > > > > > scope/ietf-signal:scope:
> > > > > >     +--ro total-traffic* [unit protocol] {dots-telemetry}?
> > > > > >     |  +--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
> > > > > >     +--rw total-attack-traffic* [unit] {dots-telemetry}?
> > > > > >     |  +--rw unit                 unit
> > > > > >     |  +--rw low-percentile-g?    yang:gauge64
> > > > > > And so there is no consistency between total-traffic and
> total-
> > > > attack-traffic
> > >
> > > [Med] The idea was to have a view of total traffic bound to a
> target
> > > prefix/domain. We should clarify or remove the protocol for this
> one.
> > > Fair enough.
> > >
> > > > > >
> > > > > > 3) For /tm you have
> > > > > >     +--:(telemetry) {dots-telemetry}?
> > > > > >        +--rw pre-or-ongoing-mitigation* [cuid tmid]
> > > > > > ..
> > > > > >           |  +--rw target-protocol*     uint8
> > > > > > ..
> > > > > >           +--rw total-traffic* [unit protocol]
> > > > > >           |  +--rw unit                 unit
> > > > > >           |  +--rw protocol             uint8
> > > > > > ..
> > > > > >           +--rw total-attack-traffic* [unit protocol]
> > > > > >           |  +--rw unit                 unit
> > > > > >           |  +--rw protocol             uint8
> > > > > >
> > > > > > And so could argue here that protocol is not needed
> > >
> > > [Med] but we may have many protocols listed under target-protocol.
> > >
> > > > > >
> > > > > > 4) If target-protocol is not specified, then it refers to
> any
> > > > protocol.  If target-
> > > > > > protocol is not defined in /mitigate, then I have no way of
> > > > indicating which is a
> > > > > > problematic protocol if protocol is not supported.
> > >
> > > [Med] Good point. This one (and the following one) justifies that
> we
> > > need to revisit the design.
> > >
> > > We ca group the data by target-protocol and send many tmids if
> many
> > > protocols need to be returned. Protocol can be then optional.
> > >
> > > Would that be better?
> > >
> > >
>