Subject: [Dots] draft-ietf-dots-telemetry: URI-Query

From: <[email-masked]>
Date: Sun, 5 Apr 2020 07:57:52 +0000

Hi Jon, 

For /tm, a client that is interested to receive notifications for a particular target (@, port, protocol, etc.) can maintain only a tmid with that target using a PUT request. What is the benefit if the dots client sends a PUT /tm for an IP prefix, but then sends a GET to target the notifications bound to a specific protocol?

Cheers,
Med

> -----Message d'origine-----
> De : Jon Shallow [mailto:[email-masked]]
> Envoyé : vendredi 3 avril 2020 16:17
> À : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : RE: [Dots] /mitigate RE: New Version Notification for draft-
> ietf-dots-telemetry-05.txt
> 
> 
> Jon> What about the use of Uri-Queries to filter on what is returned
> for a GET?
> >

---

From: "Jon Shallow" <[email-masked]>
Date: Sun, 5 Apr 2020 15:32:55 +0100

Hi Med,

I initially thought of using Queries for the /mitigate case - as a DOTS client my IP is getting hammered so I put in a PUT /mitigate with just a target-prefix for my IP.  Then I can focus in on detail by doing a GET /mitigation with Queries to filter down the potential abundance of data flowing back with the telemetry extensions.  Likewise, if I did a PUT /mitigate with both target-prefix and target-port but am also interested with what is happening on other ports I could do a GET /mitigate with Queries which supersede what the PUT /mitigate specified.

Yes, this can all be done with a PUT /tm and a vanilla GET /tm - but then I would need to be sending both a PUT and GET - increasing traffic - if I wanted to look at different scenarios and then add in a DELETE to the mix to keep down the number of tmids.  A big burst of analysis could consume many tmids, and then we need to consider what happens when there is a wraparound of the tmid counter.  Here, a simple PUT to initiate telemetry recording followed by GETs with different Queries may give flexibility needed.

>From the DOTS server perspective, at the CoAP level, each different tmid for a cuid is a different resource which is potentially observable (and so needs to be unique).  Rapidly changing resources adds in unnecessary overhead.

Regards

Jon

> -----Original Message-----
> From: Dots [mailto: [email-masked]] On Behalf Of [email-masked]
> Sent: 05 April 2020 08:58
> To: Jon Shallow; [email-masked]
> Subject: [Dots] draft-ietf-dots-telemetry: URI-Query
> 
> Hi Jon,
> 
> For /tm, a client that is interested to receive notifications for a particular target
> (@, port, protocol, etc.) can maintain only a tmid with that target using a PUT
> request. What is the benefit if the dots client sends a PUT /tm for an IP prefix,
> but then sends a GET to target the notifications bound to a specific protocol?
> 
> Cheers,
> Med
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Mon, 6 Apr 2020 09:50:29 +0000

Hi Jon,

We do already use Uri-Query options to filter the GET data for /mitigate. We can enhance that feature to further filter out data for reasons that are specific to a DOTS client (e.g., focus on a specific alias). We might consider requests such as this one:

     Header: GET (Code=0.01)
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "mitigate"
     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
     Uri-Path: "mid=12332"
     Uri-Query: "target-alias=https1"
     Observe: 0

Nevertheless, I don't think it makes sense to send a GET with targets that supersede the one of a /mid. 

If an agent is interested to receive asynchronous notifications for targets not covered by a mitigation, this should be done with /tm (that can be filtered using the Uri-queries as an attack progresses).

Cheers,
Med

> Envoyé : dimanche 5 avril 2020 16:33
> Objet : RE: [Dots] draft-ietf-dots-telemetry: URI-Query
> 
> Hi Med,
> 
> I initially thought of using Queries for the /mitigate case - as a
> DOTS client my IP is getting hammered so I put in a PUT /mitigate with
> just a target-prefix for my IP.  Then I can focus in on detail by
> doing a GET /mitigation with Queries to filter down the potential
> abundance of data flowing back with the telemetry extensions.
> Likewise, if I did a PUT /mitigate with both target-prefix and target-
> port but am also interested with what is happening on other ports I
> could do a GET /mitigate with Queries which supersede what the PUT
> /mitigate specified.
> 
> Yes, this can all be done with a PUT /tm and a vanilla GET /tm - but
> then I would need to be sending both a PUT and GET - increasing
> traffic - if I wanted to look at different scenarios and then add in a
> DELETE to the mix to keep down the number of tmids.  A big burst of
> analysis could consume many tmids, and then we need to consider what
> happens when there is a wraparound of the tmid counter.  Here, a
> simple PUT to initiate telemetry recording followed by GETs with
> different Queries may give flexibility needed.
> 
> From the DOTS server perspective, at the CoAP level, each different
> tmid for a cuid is a different resource which is potentially
> observable (and so needs to be unique).  Rapidly changing resources
> adds in unnecessary overhead.
> 
> Regards
> 
> Jon
>

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Apr 2020 11:33:16 +0100

Hi Med et all,

See inline Jon>

Regards

Jon

> Sent: 06 April 2020 10:50
> Subject: Re: [Dots] draft-ietf-dots-telemetry: URI-Query
> 
> Hi Jon,
> 
> We do already use Uri-Query options to filter the GET data for /mitigate. We can
> enhance that feature to further filter out data for reasons that are specific to a
> DOTS client (e.g., focus on a specific alias). We might consider requests such as
> this one:
> 
>      Header: GET (Code=0.01)
>      Uri-Path: ".well-known"
>      Uri-Path: "dots"
>      Uri-Path: "mitigate"

Jon> This works for me.  Additionally, multiple queries for filtering are valid - e.g.

...
     Uri-Path: "mid=12332"
    Uri-Query: "target-alias=https1"
    Uri-Query: "target-alias=https2"
    Uri-Query: "target-port=443"
    Observe: 0

> supersede the one of a /mid.

Jon> I am inclined to agree with you
> 
> If an agent is interested to receive asynchronous notifications for targets not
> covered by a mitigation, this should be done with /tm (that can be filtered using
> the Uri-queries as an attack progresses).

Jon> Yes, a PUT /tm with a target-prefix is all that is needed and then GET /tm with Queries is all that is needed for a tmid=
~Jon

---

From: <[email-masked]>
Date: Mon, 6 Apr 2020 10:40:13 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : lundi 6 avril 2020 12:33

[Med] Agree. This is what I have in my local copy:

   DOTS clients can filter out the asynchronous notifications from the
   DOTS server by indicating one or more Uri-Query options in its GET
   request.  A Uri-Query option can include the following parameters:
   target-prefix, lower-port, upper-port, target-protocol, target-fqdn,
   target-uri, alias-name.  An example of request to subscribe to
   asynchronous notifications bound to the "http1" alias is shown in
   Figure 40.

   If the target query does not match the target of the enclosed 'mid'
   as maintained by the DOTS server, the latter MUST respond with a 4.04
   (Not Found) error response code.  The DOTS server MUST NOT add a new
   observe entry if this query overlaps with an existing one.

> 
> >
> > Nevertheless, I don't think it makes sense to send a GET with
> targets that
> > supersede the one of a /mid.
> 
[Med] Thanks. 

> Jon> Yes, a PUT /tm with a target-prefix is all that is needed and
> then GET /tm with Queries is all that is needed for a tmid=

[Med] Deal.  

> > > > For /tm, a client that is interested to receive notifications
> for a
> > > particular target
> > > > (@, port, protocol, etc.) can maintain only a tmid with that
> target
> > > using a PUT
> > > > request. What is the benefit if the dots client sends a PUT /tm
> for
> > > an IP prefix,
> > > > but then sends a GET to target the notifications bound to a
> specific
> > > protocol?
> > > >
> > > > Cheers,
> > > > Med
> > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Apr 2020 11:54:32 +0100

Hi Med,

Do we need to say that Queries can be applied to GET /tm and GET /mitigate (signal extension)?
- it may be that you already have this text in elsewhere.

Regards

Jon

> Sent: 06 April 2020 11:40

---

From: <[email-masked]>
Date: Mon, 6 Apr 2020 10:58:34 +0000

Re-,

Yes, this will be mentioned in Section 7.3.

Cheers,
Med 

> Envoyé : lundi 6 avril 2020 12:55
> > > > enhance that feature to further filter out data for reasons that
> are
> > > specific to a
> > > Jon> This works for me.  Additionally, multiple queries for
> filtering
> > > are valid - e.g.
> > >
> > > ...
> > >      Uri-Path: "mid=12332"
> > > > If an agent is interested to receive asynchronous notifications
> for
> > > targets not
> > > > covered by a mitigation, this should be done with /tm (that can
> be
> > > filtered using
> > > > > DOTS client my IP is getting hammered so I put in a PUT
> /mitigate
> > > with
> > > > > port but am also interested with what is happening on other
> ports
> > > I
> > > > > Yes, this can all be done with a PUT /tm and a vanilla GET /tm
> -
> > > but
> > > > > traffic - if I wanted to look at different scenarios and then
> add
> > > in a
> > > > > DELETE to the mix to keep down the number of tmids.  A big
> burst
> > > of
> > > > > analysis could consume many tmids, and then we need to
> consider
> > > what
> > > > > > > Objet : RE: [Dots] /mitigate RE: New Version Notification
> for
> > > > > draft-
> > > > > > > Jon> What about the use of Uri-Queries to filter on what
> is
> > > > > returned
> > > > > > > for a GET?
> > > > > > > >
> > > > > >

---

From: "Jon Shallow" <[email-masked]>
Date: Mon, 6 Apr 2020 12:00:05 +0100

Thanks Med,

Then I am good with the Queries changes.

Regards

Jon

> Sent: 06 April 2020 11:59