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

[[e-mail]]

Re-,

Please see two comments inline.

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk <[e-mail]>
> Envoyé : mardi 28 décembre 2021 04:01
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]; [e-mail]
> Objet : Re: [Dots] AD review of draft-ietf-dots-telemetry-16 (Sections
> 7.1.5 - 7.3)
> 
> Hi Med,
> 
> Also inline
> 
> On Thu, Nov 25, 2021 at 01:48:04PM +0000, [e-mail]
> 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 <[e-mail]> De la part de Benjamin Kaduk
> > > Envoyé : mercredi 24 novembre 2021 23:42 À :
> > > [e-mail]
> > > Cc : [e-mail]
> > > 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.

[Med] attack-id must always be provided, otherwise the message won't be valid. The value that will be included in the attack-id is a value that will be assigned by a vendor for a new attack. 

  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.
> 

[Med] A server may install a new mapping table (a new vendor, for example). This is why the client is asked to send regularly GETs to the server to detect changes. 


_________________________________________________________________________________________________________________________

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.