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

> -----Message d'origine-----
> De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
> Envoyé : dimanche 5 avril 2020 16:33
> À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
> 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
> 
> > -----Original Message-----
> > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of
> mohamed.boucadair@orange.com
> > Sent: 05 April 2020 08:58
> > To: Jon Shallow; dots@ietf.org
> > 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
> >
> > > -----Message d'origine-----
> > > De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
> > > Envoyé : vendredi 3 avril 2020 16:17
> > > À : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
> > > 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?
> > > >
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots