Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-18.txt

From: <[email-masked]>
Date: Mon, 3 Jan 2022 16:42:27 +0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Dots <[email-masked]> De la part de Benjamin Kaduk
> Envoyé : mardi 28 décembre 2021 16:52
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-telemetry-18.txt
> 
> On Mon, Dec 13, 2021 at 10:51:00AM +0000, [email-masked]
> wrote:
> > Hi Ben, all,
> >
> > This version integrates the AD review.
> >
> > Please let us know if there are issues we didn't address. Thank you.
> 
> Thanks, and sorry for not tending to my email more quickly.
> 
> You probably already saw the handful of replies I sent to the email thread
> (and https://github.com/boucadair/draft-dots-telemetry/pull/10).
> 
> I do not think I saw a reply to this remark on Section 8.1:
> 
> ===
>    In order to signal telemetry data in a mitigation efficacy update, it
>    is RECOMMENDED that the DOTS client has already established a DOTS
>    telemetry setup session with the server in 'idle' time.
> 

[Med] This recommendation is to make sure that the server understands the telemetry attributes before using them. Otherwise, there is a risk that a message with the telemetry attributes will be rejected by a legacy server. 

> If I understand correctly, it seems that at least part of the need for
> having a preestablished telemetry session is that the mitigation efficacy
> update is identified only by the 'mid', and so we cannot specify a 'tmid'
> as part of such an efficacy update.  Thus, in order for the server to
> associate the telemetry data in the efficacy update with an ongoing
> telemetry status session, the 'tsid' must be associated with the 'mid'
> that is the subject of the efficacy update.
> If that is correct, then I think we should have some text here about how
> the efficacy update does not/cannot include the 'tmid', and so is
> associated with the 'mid' of the update.
> ===
> 
> Of the things in the email chain, I am most interested in getting clarity
> around:
> 
> - what to put in the "attack-id" field when we are sending an
>   "attack-description" string for a not-previously-characterized attack
> (or
>   make that field not mandatory at the YANG level).

[Med] The attack-id is assigned by vendors. This applies for both shared and new attacks. 

> 
> - when a server updates its published attack mappings, if there's a
>   requirement/expectation that already assigned attack-id values retain
> the
>   same meaning.

[Med] This was clarified in another message.

> 
> Thanks again,
> 
> Ben
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Tue, 4 Jan 2022 10:23:14 +0000

Hi Ben,

An updated version that I hope addresses your pending comments is online:

URL:            https://www.ietf.org/archive/id/draft-ietf-dots-telemetry-19.txt 
Status:         https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ 
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry 
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-19

Thank you.

Cheers,
Med

> De : Dots <[email-masked]> De la part de
> [email-masked]
> Envoyé : lundi 3 janvier 2022 17:42
> À : Benjamin Kaduk <[email-masked]>
> Cc : [email-masked]
> > De : Dots <[email-masked]> De la part de Benjamin Kaduk Envoyé
> > : mardi 28 décembre 2021 16:52 À : BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]> Cc : [email-masked] Objet : Re: [Dots]
> > I-D Action: draft-ietf-dots-telemetry-18.txt
> >
> > You probably already saw the handful of replies I sent to the email
> > thread (and https://github.com/boucadair/draft-dots-telemetry/pull/10).
> >
> [Med] This recommendation is to make sure that the server understands the
> telemetry attributes before using them. Otherwise, there is a risk that a
> message with the telemetry attributes will be rejected by a legacy server.
> 
> > having a preestablished telemetry session is that the mitigation
> > efficacy update is identified only by the 'mid', and so we cannot
> specify a 'tmid'
> > If that is correct, then I think we should have some text here about
> > how the efficacy update does not/cannot include the 'tmid', and so is
> >   "attack-description" string for a not-previously-characterized
> > attack (or
> >   requirement/expectation that already assigned attack-id values
> > retain the
> >   same meaning.
> 
> __________________________________________________________________________
> 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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Jan 2022 14:40:57 -0800

> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-19

Thanks, Med.

I think I figured out what was bothering me about 'attack-id', and your
latest messages helped me realize why it is not an issue; thanks for your
patience and multiple explanations.  In short, I was worried that at
runtime a DOTS server would see a "new attack" and try to generate a wholly
new description for it, which would require a new attack-id as well.  But
it's far more likely that the server is going to have a fixed set of
attacks it knows about, and just pick the entry from that set that most
closely matches the observed attack, even if the match is not very good
(i.e., a generic "other attack" case).  The new description would come from
the vendor after review and action by humans looking over the data, and
would not be synthesized at runtime by an automated procedure in the
server, so it really is the case that all attack-ids are assigned
(centrally) by the vendor.

I will go ahead and request the IETF Last Call.

-Ben

P.S. There is one nit in the new 'attack-id' description -- it should be
"independent of whether", not "independently whether".

---

From: <[email-masked]>
Date: Mon, 10 Jan 2022 06:36:34 +0000

Hi Ben, 

Thanks.  

Fixed the nit (and some few others) in the editor's copy: https://tinyurl.com/dots-telemetry-latest). 

Cheers,
Med

> De : Benjamin Kaduk <[email-masked]>
> Envoyé : vendredi 7 janvier 2022 23:41
> runtime a DOTS server would see a "new attack" and try to generate a
> wholly new description for it, which would require a new attack-id as
> well.  But it's far more likely that the server is going to have a fixed
> set of attacks it knows about, and just pick the entry from that set that
> most closely matches the observed attack, even if the match is not very
> good (i.e., a generic "other attack" case).  The new description would
> come from the vendor after review and action by humans looking over the
> data, and would not be synthesized at runtime by an automated procedure in
> the server, so it really is the case that all attack-ids are assigned