Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
draft-ietf-dots-telemetry-25
Yes
No Objection
Note: This ballot was opened for revision 20 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
[S12, elsewhere; question] * For the CBOR Major & Type representation of "inet:ip-prefix"es (e.g. "source-prefix") have you considered using the representations from RFC 9164? https://www.rfc-editor.org/rfc/rfc9164.html#name-iana-considerations
Francesca Palombini (was Discuss) No Objection
Thank you for the work on this document, which I found particularly well written and easy to read despite its length. Many thanks to James Gruessing for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/MbTX3xfg6tMeG6mieAsT7hA3gXs/, and to the authors for addressing James' comments. To answer Ben's note - IMO the text about "enterprise numbers" and "Private Enterprise Numbers" is clear enough. I will keep the DISCUSS text below for the record and for Ben's attention, but I am clearing it, given that the additions in v-21 mostly address 1-7. and 8. has precedent for it in 9132. Francesca # Previous DISCUSS (keeping for the record) 1. ----- JSON encoding of YANG-modeled data is used to illustrate the various telemetry operations. FP: There is an inconsistency between this text and the use of "application/dots+cbor" in the examples. Either the Content-Format should be changed, or all the examples should be adapted to JSON Content-Format (I am not sure about what Content-Format you should use then, you probably know better). My preference is to keep CBOR and keep the Content-Format. I went through all the examples and reported below the inconsistencies. Section 7.1.2, Figure 4, 5, FP: If in CBOR, the percentiles should be expressed with the tagged item Decimal fraction (represented as a tagged array). 2. ----- Section 7.2.1, Figure 11, 13, 15, 17 FP: Same comment as 1: unit and peak-g should be unsigned in CBOR. 3. ----- Section 7.3.1, Figure 19, 20 FP: Same comment as 1: capacity and unit should be unsigned in CBOR. 4. ----- Section 7.2.1, Figure 11, 13, 15, 17 FP: Same comment as 1: unit and peak-g should be unsigned in CBOR. 5. ----- Section 7.3.1, Figure 19, 20 FP: Same comment as 1: capacity and unit should be unsigned in CBOR. 6. ----- Figure 36, figure 43 FP: Same comment as 1: unit, mid-percentile-g, start-time and attack-severity should be unsigned in CBOR. 7. ----- Figure 45, 47 FP: attack-status, unit, mid-percentile-g, peak-g should be unsigned. I also note that some of the attributes defined in 9132 are used here and on previous examples and have for values the full spelled out meaning for readability, instead of the actual parameter (for example "status", that should have value 2 for "attack-successfully-mitigated"), and I think that should be at least noted in the text before the example, or if you want to be more precise the "attack-successfully-mitigated" could be a comment next to the value 2. 8. ----- Section 7.1.3 client, it MUST respond with a 4.04 (Not Found) error Response Code. FP: I have a preference to remove this MUST here - it is expected behavior that if a resource is not present the server responds with 4.04, so it is not necessary to add the requirement here, actually redefining the response code (although it is the expected one in this case) should be discouraged. I suggest replacing: s/it MUST respond/it responds. (Note that 7.1.4 has the text I would expect, describing the behavior but not adding any already existing requirements). # Comment 9. ----- FP: Related to the DISCUSS point about encoding, it would be good to state somewhere in the text (possibly in section 5.6) that CBOR Key Values can be used instead of the parameter names (see section 13.1), but that for readability all examples use the full names. 10. ----- Section 7.1.2, tsid definition This is a mandatory attribute. 'tsid' MUST follow 'cuid'. FP: I am not sure I understand the use of the term "follow" here. Also I am confused by the fact that tsid here is named as an "attribute" while instead it is defined as a Uri-Path parameter, and does not appear in the list of attributes of Figure 3. 11. ----- Many of the pre-or-ongoing-mitigation telemetry data use a unit that falls under the unit class that is configured following the procedure described in Section 7.1.2. When generating telemetry data to send FP: Section 7.1.2 does not describe the procedure to configure the unit (which at this point in the text I can't find anywhere). All 7.1.2 says is: DOTS clients can also configure the unit class(es) to be used for traffic-related telemetry data among the following supported unit classes: packets per second, bits per second, and bytes per second. Supplying both bits per second and bytes per second unit-classes is allowed for a given telemetry data. However, receipt of conflicting values is treated as invalid parameters and rejected with 4.00 (Bad Request). what am I missing? 12. ----- Figure 33 FP: Please either add the Reponse header (HTTP/1.1 200 OK \ Content-Type: /yang-data+json + any other header field) (this is my preferred option) or change the caption to indicate that this is only the response content. 13. ----- Section 8.2 This is a mandatory attribute. 'tmid' MUST follow 'cuid'. FP: Same question as 10. 14. ----- Section 8.1.6 FP: Suggestion to add a sentence reminding the reader that this exchange happens over the data channel and that's why HTTP and JSON are used. (As Ben made me notice, this is very clearly explained in section 4.1, but I had forgotten by the time I got to this point in the text). 15. ----- FP: question for my understanding that comes from my low experience with YANG: I see that connection-all and connection-percentile-and-peak are groups of the exact same containers. Do they both need to be defined because the description (and hence the use) is different?
Lars Eggert (was Discuss) No Objection
Thanks to Robert Sparks for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/hTMaURDAcbvHbR1TQ52GA_fJOzk). ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2. , paragraph 10, nit: > igation service effectiveness. Bi-directional feedback between DOTS agents i > ^^^^^^^^^^^^^^^ This word is normally spelled as one. Section 2. , paragraph 13, nit: > ents as hints and cannot completely rely or trust the attack details conveye > ^^^^ The verb "rely" requires the preposition "on" (or "upon"). Section 3.1. , paragraph 4, nit: > sides, can use DOTS telemetry as a feedback to automate various control and > ^^^^^^^^^^ The noun "feedback" is uncountable and doesn't require an article. Section 3.1. , paragraph 7, nit: > raffic from attacker traffic on a per packet basis is complex. For example, a > ^^^^^^^^^^ In this context, "per-packet" forms an adjective and is spelled with a hyphen. Section 4.3. , paragraph 2, nit: > son for not including these keys is because they are not included in the mes > ^^^^^^^^^^ The word "because" means "for the reason that" and thus introduces redundancy. Section 7.1.2. , paragraph 1, nit: > percentile (10th percentile), mid percentile (50th percentile), high percen > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 7.2.1. , paragraph 12, nit: > appropriate unit is used. Total connections capacity: If the target is susce > ^^^^^^^^^^^ An apostrophe may be missing. Section 8.1.5. , paragraph 17, nit: > lue of the 'target-fqdn' parameter in an Uri-Query option. DOTS clients may a > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 9. , paragraph 7, nit: > default "50.00"; description "Mid percentile. If set to the same value as l > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 9. , paragraph 7, nit: > ype yang:gauge64; description "Mid percentile value."; } leaf high-percentil > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 9. , paragraph 20, nit: > ty-protocol { description "Total connections capacity per protocol. These dat > ^^^^^^^^^^^ An apostrophe may be missing. Section 9. , paragraph 22, nit: > Various details that describe the on-going attacks that need to be mitigated > ^^^^^^^^ Did you mean "ongoing"? Section 11.1. , paragraph 6, nit: > an IP resource. An IP resource can be be a router, a host, an IoT object, a > ^^^^^ Possible typo: you repeated a word. Section 11.1. , paragraph 46, nit: > DOTS telemetry for its IP addresses but a DDoS mitigator can exchange DOTS > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short).
Martin Duke No Objection
Robert Wilton No Objection
Hi,
Thanks for this document. I have no major comments, but do have a few minor ones.
1. I wonder if the abstract/introduction can be clearer that this is an extension to the data channel as well as the signal channel, although I appreciate that the vast majority of this document is about telemetry communicated via the signal channel.
2. I found the text in section 7.1.2 related to tsids to be somewhat unclear. When I first read this paragraph:
tsid: Telemetry Setup Identifier is an identifier for the DOTS
telemetry setup configuration data represented as an integer.
This identifier MUST be generated by DOTS clients. 'tsid'
values MUST increase monotonically (when a new PUT is generated
by a DOTS client to convey new configuration parameters for the
telemetry).
and
A PUT request with a higher numeric 'tsid' value overrides the DOTS
telemetry configuration data installed by a PUT request with a lower
numeric 'tsid' value. To avoid maintaining a long list of 'tsid'
requests for requests carrying telemetry configuration data from a
DOTS client, the lower numeric 'tsid' MUST be automatically deleted
and no longer be available at the DOTS server.
It gave me the impression that a new PUT request with a new tsid completely replaces all configuration provided by any lower tsid, but I don't think that is is the intent. Perhaps this could be made clearer?
3.
* If the DOTS server finds the 'tsid' parameter value conveyed in
the PUT request in its configuration data and if the DOTS server
has accepted the updated configuration parameters, 2.04 (Changed)
MUST be returned in the response.
I was wondering why not error this case and not except the config change (presumably this is a simple error if the client has used the same tsid)?
4. The YANG is obviously being used in a different way here than for regular network device configuration, but this still means that you end up with descriptions of various properties in two places in the document, once in the main part of the text and once in the YANG data model, which makes the document both somewhat more verbose and also runs the risk of discrepancies between what is in the YANG vs what is described earlier in the document. For regular YANG data models, the preferred approach is try and have the full normative definitions in the YANG module, and keeps the text outside of the model to be more informative/descriptive of the expected behavior, partly because of the expectation to be able to generate user documentation from the description statements. I don't know if you would ever be expected to generate a UI description from the YANG module for DOTS telemetry, but you might want to double check that have you the right balance between whether the text in the YANG module of the main description is definitive and whether there should be any statement in the document to indicate which text is regarded as definitive if there is any discrepancy between the two descriptions.
5. I agree with Warren's comments regarding whether allowing a choice of units and scaling causes additional complexity that could perhaps be avoided.
Regards,
Rob
Roman Danyliw (was Discuss) No Objection
Authors: thank you for the clarifying language in Section 4.4 explaining how the design of mapping YANG into CBOR Thank you for addressing my DISCUSS and select COMMENTs ** Section 8.1.6. An attack type appears to be characterized by a vendor-id, vendor-name, last-updated, attack-id and attack-description. Would an additional field of attack-id-revision (or attack-id-version) be beneficial too? I’m imagining a workflow where a vendor’s definition of an attack (and the associated detection rule/logic) changes overtime and it might be useful to version that – akin to the snort/suricata’s “rev:” field. A vendor could of course assign a new attack-id but this might impact down-stream analysis.
Warren Kumari (was Discuss) No Objection
Thanks for addressing my concerns (https://mailarchive.ietf.org/arch/msg/dots/QoY64nX2TS5-4qigInLQRCrHvME/)
Zaheduzzaman Sarker No Objection
Use of "Private Enterprise Numbers" as a term makes sense to me.
Éric Vyncke (was Discuss) No Objection
Thank you for the work put into this document. Based on Med Boucadair’s reply, I have cleared my DISCUSS. Please find below one blocking DISCUSS points (kept for archiving), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Please also have a look at Ted Lemon's INT directorate review at <https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-19-intdir-lc-lemon-2022-01-23/>. I share Ted's concern about have three independent topics in a single document rather than in 3 documents. Special thanks to Valery Smyslov for the shepherd's write-up including the section about the WG consensus even if I had appreciated a justification for the PS status. I hope that this helps to improve the document, Regards, -éric # Previous DISCUSS kept for archiving only ## Section 8.1.5 (and others) Please note that I am not a YANG expert, but it seems to me that "attack-detail* [vendor-id attack-id]" indicates that vendor-id & attack-id are the keys to attack-detail, i.e., there can only have one attack-detail per pair of vendor-id & attack-id. So, there is no way to have multiple sequential/simultaneous attacks, i.e., should the start-time be also part of the key? # COMMENT I am ambivalent with respect to the amount of context introduction in each (sub)-section: it is for sure good for a new reader, but it also lengthens the read for a more knowledgeable one. ## Abstract Should the abstract mention the presence of a YANG model ? ## Section 2 Should the text specifies that tsid and tmid are monotonically increasing values and not just a mere opaque identifier ? Ben Kaduk also pointed the IESG members' attention to the use of "PEN" or "Enterprise Number". As there is a § in this section about "Enterprise Number", this would be the right place to state that this document uses "Enterprise Number" or "Private Enterprise Number" or "PEN" for the same concept through the rest of the document and stick to one wording. My own taste prefers "PEN" even if RFC 5612 uses "Enterprise Number" but it is a matter of taste. ## Section 4.3 Should there be some words about using one upstream 'pipe' to reach the DOTS server protecting another 'pipe' ? Or is it too obvious ? ## Section 7.2 Possibly a bad reading the unit/capacity section of mine, but how can 1.0 and 1.499 be differentiated with this notation? I.e., both will be represented 1 with a 50% difference though... ## Section 7.3 Are the authors/WG expecting that all IP packets are equal ? I.e., that the downstream devices can handle IPv4 and IPv6 at the same rate ? Or should the baseline information be different based on IP protocol version ? Or will the normal use use only one-address-family 'target-prefix' ? Then, of course how to decide the sum of traffic to the same network but over IPv4 or IPv6? I would have preferred to use 'next-header' rather than 'protocol' or is the expected behaviour to parse the IPv6 extension header chain to find the transport protocol ? Same comment for other use of 'protocol' as in section 8.1. Quite often ICMP types (and codes) are used in ACL for the same purpose as transport-layer ports, was the use of ICMP types/codes considered? ## Section 7.3.1 Nice to see IPv6-only examples :-) ## Section 8 Suggestion to add some words about the "attack-detail* [vendor-id attack-id]" leaf early in the text without waiting for section 8.1.5 ## Section 8.1.6 Should figure 34 use the example PEN ? I.e., 32473 rather than 345 ? ## Section 11.1 Is it really useful to have both "bits" and "bytes" as units ? One is easily derived from the other and this would be easier for every application to only have "bits". Suggestion use "octet" rather than "byte".
(Benjamin Kaduk; former steering group member) Yes
IESG members are encouraged to provide further input on whether the document should refer to "enterprise numbers" or "Private Enterprise Numbers"; see last-call review thread at https://mailarchive.ietf.org/arch/msg/dots/ADAPijIjyZ-2vkcE-k16oIf-fx4/
(Martin Vigoureux; former steering group member) No Objection