Subject: Re: [Dots] AD review of draft-ietf-dots-telemetry-16 (Sections 7.1.5 - 7.3)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Dec 2021 19:01:06 -0800

Hi Med,

Also inline

On Thu, Nov 25, 2021 at 01:48:04PM +0000, [email-masked] wrote:
> Re-,
> 
> You can track the changes at: https://tinyurl.com/dots-telemetry-latest.
> 
> Please see inline for more context for Sections 7.1.5 to 7.3. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots <[email-masked]> De la part de Benjamin Kaduk
> > Envoyé : mercredi 24 novembre 2021 23:42
> > À : [email-masked]
> > Cc : [email-masked]
> > Objet : [Dots] AD review of draft-ietf-dots-telemetry-16
> > 
> > Hi all,
> > 
> ...
> > 
> > Section 7.1.5
> > 
> >    vendor-id:  Vendor ID is a security vendor's Enterprise Number as
> >       registered with IANA [Enterprise-Numbers].  It is a four-byte
> >       integer value.
> > 
> >    attack-id:  Unique identifier assigned for the attack.
> > 
> > If the vendor-id is being used as a scoping value to let each vendor
> > assign attack-id values, then we should say so here, the first place we
> > really handle this part of the YANG tree.  Even if not, we should probably
> > say more about why we care what the vendor-id is, and we should also say
> > who assigns the attack-id.  (Maybe it's scoped to the DOTS server; I don't
> > know yet at this point in the document!)
> 
> [Med] The is assigned by the vendor. We don't have globally unique attack-ids and we don't ambition to have such a registry. 
> 
> We have the following in the YANG module "Unique identifier assigned by the vendor for the attack". 
> 
> Updated the text to align. 
> 
> > 
> > Furthermore, the module structure where attack-id and vendor-id are always
> > required, but there is going to need to be the ability to assign a new
> > attack description at runtime, seems to force us to conflate
> > externally/statically assigned attack-ids and dynamically assigned ones in
> > the same number space.  Should we give any guidance to vendors about how
> > to allocate IDs in a way that will not produce collisions between
> > predistributed/fixed attack IDs and new ones created at runtime?  Or is
> > the thought that there will be no dynamic attack-ids since that just
> > corresponds to the attack-description string and a generic description can
> > be used if there is not a better one available?
> 
> [Med] We really don't want to interfere with how these ids are assigned by vendors. For new attacks, and because the client may not have the mapping we do allow for the following:
> 
>    When conveying attack details in DOTS telemetry messages (Sections
>    7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack-
>    description' attribute unless the corresponding attack mapping
>    details were not previously shared with the peer DOTS agent.

This is good, but it's of the form "only include the string version if you
can't use a preestablished mapping"; I don't remember any guidance about
not providing an integer attack-id in this case.  In particular, since
'attack-id' is a list key, it seems to be a mandatory YANG element,
implying that there needs to be *some* value to put in there even for a new
attack.

> > 
> > Regardless, I think we should have more verbiage as to what the scope of
> > the attack-id is -- what information is it supposed to indicate or
> > replace?
> > 
> >    start-time:  The time the attack started.  The attack's start time is
> >       expressed in seconds relative to 1970-01-01T00:00Z in UTC time
> > 
> > (nit) "in UTC time" and "Z" seem redundant (which does not necessarily
> > imply that we should only use one of them...).
> 
> [Med] We preferred to echo 3.4.2 of RFC8949 cited right after
> 
> > 
> >       (Section 3.4.2 of [RFC8949]).  The CBOR encoding is modified so
> >       that the leading tag 1 (epoch-based date/time) MUST be omitted.
> > 
> > (nit) Maybe we should move the CBOR section reference to after we start
> > talking about CBOR encoding.  (And we should do the same for 'end-time',
> > if we do anything.)
> 
> [Med] The section where we discuss CBOR encoding is 4.5. I prefer to keep this mention here. Thanks. 
> 
> > 
> >    top-talker:  A list of top talkers among attack sources.  The top
> >       talkers are represented using the 'source-prefix'.
> > 
> > Is there a good reference or short description for the notion of top-
> > talkers?  I know it's a well-established term of art in many different
> > circles, but it's hard to be fully confident that all readers will be
> > familiar with it.
> 
> [Med] What about:
> 
>       A list of attack sources that are involved in an attack
>       and which are generating an important part of the attack traffic.

I'll take it; thanks.

> > 
> > Also, should we say anything about how the number of talkers to include is
> > determined?  (I assume it is best left to the discretion of the sender,
> > but we probably want to set a clear expectation that the list is not all
> > talkers or a complete list in any other way.)
> 
> [Med] We don't include any hint as this is deployment-specific. 
> 
> > 
> >       'spoofed-status' indicates whether a top talker is a spoofed IP
> >       address (e.g., reflection attacks) or not.
> > 
> > Is this something that can be unambiguously determined by all parties that
> > might be producing this telemetry data, or should we use a tri-statae (for
> > "unknown") rather than a boolean to represent it?
> 
> [Med] The unknown status is handled by not including the leaf. Update the text to indicate so. 

Ah, that makes sense.

> > 
> >    In order to optimize the size of telemetry data conveyed over the
> >    DOTS signal channel, DOTS agents MAY use the DOTS data channel
> >    [RFC8783] to exchange vendor specific attack mapping details (that
> >    is, {vendor identifier, attack identifier} ==> attack description).
> >    As such, DOTS agents do not have to convey systematically an attack
> >    description in their telemetry messages over the DOTS signal channel.
> > 
> > It's a little surprising to me that this is only a MAY.  Does it make
> > sense as a SHOULD (expected to usually happen, but leaving open the
> > flexibility when an observed attack does not match a previously
> > characterized attack description)?
> 
> [Med] We went for "MAY" because this is an optimization for a an optional feature. 
> 
> > 
> > Also, when reading this I assumed that the "attack description" being
> > mapped to could include things like the target port/protocol, whether it
> > was spoofed, etc.
> 
> [Med] Some of the details you cited can be discovered during an attack. 
> 
>   But reading on to the ietf-dots-mapping module, it
> > seems that this is intended to just be the single "attack-description"
> > string.
> 
> [Med] This is the portion that consumes most packet size and is thus problematic. 
> 
>   If so, we might give some more indications of that, e.g., by
> > spelling it that way and having some prose about it being a "string", or
> > similar.
> 
> [Med] OK.
> 
> > 
> > Also^2, from here to the end of the section might benefit from being split
> > off into a dedicated subsection on using the data channel to pre-populate
> > vendor and attack description information
> 
> [Med] Makes sense. 
> 
> > 
> >    tables are at different revisions.  The DOTS client SHOULD transmit
> >    telemetry information using the vendor mapping(s) that it provided to
> >    the DOTS server and the DOTS server SHOULD use the vendor mappings(s)
> >    provided to the DOTS client when transmitting telemetry data to peer
> >    DOTS agent.
> > 
> > Having read a bit further on, I'm not actually sure where in the protocol
> > the client has provided vendor mappings to the server, and the server
> > provided vendor mappings to the client.  It *might* be the GET and POST
> > from/to dots-data/ietf-dots-mapping:vendor-mapping, but we don't really
> > give a clear indication of that.  I think we should try to be more precise
> > about what we mean by "provided".
> 
> [Med] added: (e.g., using a POST as depicted in Figure 34) 
> 
> > (editorial) would this then be "SHOULD use any vendor mapping(s)"
> > (s/the/any/)?
> 
> [Med] Yeah.
> 
> > 
> >      augment /data-channel:dots-data/data-channel:capabilities:
> >        +--ro vendor-mapping-enabled?   boolean {dots-telemetry}?
> > 
> > None of the other capabilities in this tree (as specified by RFC 8783)
> > include a name suffix like "-enabled".  Should this just be "vendor-
> > mapping"?
> 
> [Med] We could, but we went for -enabled to ease referencing this data node in the text. See for example:
> 
>    attack mapping details is supported by the server (i.e., check the
>    value of 'vendor-mapping-enabled'). 
> 
> Otherwise, we would need to provide the full hierarchy because we do have "vendor-mapping" in 
> 
>      augment /data-channel:dots-data:
>        +--ro vendor-mapping {dots-telemetry}?

Okay.  We can see if anyone complains later on.

> > 
> >            "vendor-id": 1234,
> >            "vendor-name": "mitigator-s",
> >            "last-updated": "1576856561",
> >            "attack-mapping": []
> > 
> > [this last updated is from December 2019; we could probably pick something
> > more current if we wanted, but it doesn't really matter.]
> 
> [Med] OK
> 
> > 
> >    The DOTS client reiterates the above procedure regularly (e.g., once
> >    a week) to update the DOTS server's vendor attack mapping details.
> > 
> > Do the udpates have to preserve any existing assignments?
> 
> [Med] No. The client can even determine that a given vendor is not used anymore.

I was trying to ask if the server has to preserve its existing assignments
when the client asks for the current mapping.  In some sense it's just a
"quality of implementation" matter for the server, but on the other hand if
it's allowed to change, we may have to give clients a warning to prepare
for that.

> > 
> >    If the DOTS client concludes that the DOTS server does not have any
> >    reference to the specific vendor attack mapping details, the DOTS
> >    client uses a POST request to install its vendor attack mapping
> >    details.  [...]
> > 
> > This suggests that a client would not bother sending its own vendor
> > mapping if the server already has one
> 
> [Med] yes, because there same mapping is used in both sides.

Ah, I think I see where this came from, now.  My question was asked with
the idea of dynamic attack-id assignment still in mind.  It sounds like
this is basically just something that each vendor maintains in a
mini-registry and is expected to be fairly stable.

> , and at least to me further implies
> > that the client would use the sever-provided mapping for the messages that
> > the client generates.  This seems at odds with the earlier guidance that
> > the client should send using the vendor-mapping it provided to the server,
> > and the server should send using the vendor-mapping it provided to the
> > client.  Which one is it?
> > 
> >    The DOTS server indicates the result of processing the POST request
> >    using the status-line.  Concretely, "201 Created" status-line MUST be
> >    returned in the response if the DOTS server has accepted the vendor
> >    attack mapping details.  If the request is missing a mandatory
> >    attribute or contains an invalid or unknown parameter, "400 Bad
> >    Request" status-line MUST be returned by the DOTS server in the
> >    response.  [...]
> > 
> > I think (but did not specifically check) that these specific status code
> > values are preexisting requirements of core RESTCONF (and HTTP), so we may
> > not need to write new "MUST" keywords.
> 
> [Med] We tried to be consistent with RFC8782, where we can find:
> 
>    If the request is missing a mandatory attribute or it contains an
>    invalid or unknown parameter, a "400 Bad Request" status-line MUST be
>    returned by the DOTS server.
> 
> > 
> >    If the request is received via a server-domain DOTS gateway, but the
> >    DOTS server does not maintain a 'cdid' for this 'cuid' while a 'cdid'
> >    is expected to be supplied, the DOTS server MUST reply with "403
> >    Forbidden" status-line and the error-tag "access-denied".  Upon
> >    receipt of this message, the DOTS client MUST register (Section 5.1
> >    of [RFC8783]).
> > 
> > (nit) the analogous text in RFC 8783 itself refers only to "Section 5"
> > (not 5.1).
> 
> [Med] I prefer to keep 5.1 because 5 covers both registration and de-registration.
> 
> > 
> >    The DOTS client uses the PUT request to modify its vendor attack
> >    mapping details maintained by the DOTS server (e.g., add a new
> >    mapping).
> > 
> > As above, is this really just an example behavior or a hard requirement to
> > preserve existing mappings?
> 
> [Med] We are not using any normative language for POST, hence this wording for PUT.  

(For what it's worth, it looks like I was asking about the "e.g., add a new
mapping" phrase specifically.  If there is a requirement for the
server/vendor to preserve existing mappings, then it seems that the only
kind of modification possible would be to add a new mapping, so we wouldn't
need the "e.g." modifier.  But this is probably not worth spending more
time on.)

Everything else looks okay.  Thanks,

Ben

> 
> > 
> > Section 7.2
> > 
> >            "attack-detail": [
> >              {
> >                "vendor-id": 1234,
> > 
> > The vendor-ID is supposed to be an IANA-assigned PEN, and 1234 is assigned
> > to Linkage Software Inc.  We have other options, like 32473, "Example
> > Enterprise Number for Documentation Use" (RFC 5612).
> 
> [Med] This is better. Added a note to Section 4.6 as well. 
> 
> > 
> >                "start-time": "1957811234",
> > 
> > This value represents a time in 2032; should we be using something a
> > little more current?
> 
> [Med] No problem. Updated.  
> 
> > 
> > Section 7.3
> > 
> >    This request MUST be maintained active by the DOTS server until a
> >    delete request is received from the same DOTS client to clear this
> >    pre-or-ongoing-mitigation telemetry.
> > 
> > It seems like we might want to allow some provision for a server to clean
> > up state associated with a client that disappears entirely without
> > cleaning itself up.
> 
> [Med] this was a hidden behavior. Thanks for catching this. Updated as follows: 
> 
>    This request MUST be maintained in an active state by the DOTS server
>    until a delete request is received from the same DOTS client to clear
>    this pre-or-ongoing-mitigation telemetry or when the DOTS client is
>    considered inactive (e.g., Section 3.5 of [RFC8783]).
> 
>   For example, is the server allowed to discard state
> > when it reboots, or does this requirement extend to writing the state to
> > persistent storage?
> > 
> >       If more than one Uri-Query option is included in a request, these
> >       options are interpreted in the same way as when multiple target
> >       attributes are included in a message body.
> > 
> > I a little bit wonder if we could put a section reference here for
> > "interpreted in the same way", since the reader may not remember what that
> > way is, at least on the first reading.
> > 
> 
> [Med] Added a pointer to 4.4.1 of 9132 where there is some text about appending target values. 
> 
> >       parameters.  DOTS clients MUST NOT include a name in which the "*"
> >       character is included in a label other than the leftmost label.
> > 
> > Do we want to say what the server should do if it gets one anyway?
> > (It's not really clear that we need to say anything, strictly speaking.)
> > 
> 
> [Med] This is covered by:
> 
>    Requests with invalid query types (e.g., not supported, malformed)
>    received by the DOTS server MUST be rejected with a 4.00 (Bad
>    Request) response code.
> 
> >                "vendor-id": 1234,
> >                "attack-id": 77,
> >                "start-time": "1957818434",
> > 
> > [same as above]
> 
> [Med] OK
> 
> > 
> >    A DOTS client that is not interested to receive pre-or-ongoing-
> >    mitigation telemetry data for a target MUST send a delete request
> >    similar to the one depicted in Figure 37.
> > 
> > I'm not sure that this strictly needs to be a "MUST"; it seems like we
> > could say that such a client "sends a delete request" and leave it at
> > that.
> > 
> 
> [Med] OK 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>