Subject: [Dots] /tm RE: New Version Notification for draft-ietf-dots-telemetry-05.txt

From: <[email-masked]>
Date: Fri, 3 Apr 2020 13:27:08 +0000

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : vendredi 3 avril 2020 13:51
> À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname
> nishizuka; [email-masked]
> Objet : RE: [Dots] New Version Notification for draft-ietf-dots-
> telemetry-05.txt
> 
> Hi Med,
> 
> Thanks for this.  It looks as if it might be going in the right
> direction - I need to check if it can be sensibly coded up.
> 

[Med] Great, thanks. 

> Hi all,
> 
> Some further thoughts.
> 
> /tm
> ===
> 
> For /tm we are trying to use the same YANG model for 2 purposes.
> 1-  Client indicating to Server attack telemetry information
> 2- Server indicating to Client attack telemetry information.
> 
> With Server -> Client, this is initiated by GET.  There is no reason
> as to why Uri-Query: cannot be used for prefix=, port=, protocol=,
> fqdn=, uri=, and alias-name= where each query can be repeated multiple
> times and port= can be a range.  Obviously the queries need to be
> validated that they are valid for the client in the same way that PUT
> gets validated.
> 
> The GET response (and any Observed response) can then populate target
> as appropriate and fill out the remaining information with non-zero
> values (or certainly values of consequence).
> 1-  For single port and/or single protocol in the query, do we just
> use total-traffic, total-traffic-protocol or (missing) total-traffic-
> port etc. in the response?

[Med] total-traffic should be sufficient, unless a more granularity is available single port-multiple protocols.

> 2-  Same true for the other variants (e.g. total-attack-traffic) as
> well.
> It may be that only total-traffic makes sense and total-traffic-
> protocol can be dropped (same with other variants).  There is nothing
> stopping the Client doing different GET queries and observing all the
> different query combinations (other than volumes of traffic).

[Med] Indeed. The current model is flexible: you may consume one tmid or use as many you want. 

> 
> Then I believe that attack-detail should be an array [id] as multiple
> attack vectors may be concurrent

[Med] I guess you mean attack-id. That's would be OK.

> 
> With Client -> Server, the information can easily be reduced by use of
> target-* information in the PUT, so I again question whether total-
> traffic-protocol etc. is really needed.

[Med] These are not mandatory. It depends on what the clients put in the request(s). 

  Multiple PUTs can be done
> with different target definitions which will not get caught by the
> target overlapping rule.

[Med] Agree.  

> 
> I am making a basic assumption that any traffic based information
> portrayed in the PUT is kept by the DOTS server for its internal use,
> but any GET responses reflect the actual situation, not a
> regurgitation of what the Client sent the Server.
> 
> It unclear to me what the difference is between embryonic and partial
> connections.  Embryonic is well defined, but partial is not.  Can the
> text be tidied up here?

[Med] These may seem to have similarities, but we wanted to cover protocols such as QUIC that can be subjected to partial request attacks, but not embryonic ones. Agree that we need to clarify this further in the draft. 

> 
> There is no notion of /tm refresh (as in /mitigate or /config refresh)
> - is this correct?

[Med] It is up to the agents to maintain their tmids active or no:

   How long a DOTS server maintains a 'tmid' as active or logs the
   enclosed telemetry information is implementation-specific.

---

From: "Jon Shallow" <[email-masked]>
Date: Fri, 3 Apr 2020 15:06:20 +0100

Hi Med et all,

Please see inline Jon>

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
> Sent: 03 April 2020 14:27
> To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; [email-masked]
> Subject: [Dots] /tm RE: New Version Notification for draft-ietf-dots-telemetry-
> 05.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 

Jon> What do you think about using Uri-Query: ?

> single port-multiple protocols.

Jon> OK.

Jon> I think then that it needs to be stated that "total-traffic" is filtered by whatever is in "target", which in turn is generated from any Uri-Query: rather than what was used in the PUT (unless there are no URI-Query:).  It maybe that the GET URI-Query: list is constrained by the PUT for that tmid. 

Jon> That then raises the question as to what is returned for a GET with no tmid= - currently all the tmids are returned, but should they be further filtered by Uri-Query;?
> [Med] I guess you mean attack-id. That's would be OK.
Jon> Correct - attack-id.

> [Med] These are not mandatory. It depends on what the clients put in the

Jon> Again, as there have to be target definitions, what does "total-traffic" refer to - need clarity in the text as to whether the is overall traffic, or traffic as filtered by the target definition(s).
> [Med] These may seem to have similarities, but we wanted to cover protocols
> such as QUIC that can be subjected to partial request attacks, but not embryonic
> ones. Agree that we need to clarify this further in the draft.
> 
> >

Jon> I can work with that, I was just thinking about consistency with the way things are done in the signal and data channels.
~Jon
> 
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots