Re: [core] [Dots] Large asynchronous notifications under DDoS: New BLOCK Option?

[[e-mail]]

Hi Carsten,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:[e-mail]]
> Envoyé : jeudi 9 avril 2020 09:18
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Achim Kraus; Jon Shallow; [e-mail]; [e-mail]
> Objet : Re: [core] [Dots] Large asynchronous notifications under DDoS:
> New BLOCK Option?
> 
> I apologize in advance for chiming in before having digested the whole
> thread.
> 
> I think that the idea of using observe with a modified block-wise
> protocol (1 below) can work.
> 
> I also think that application-layer framing (3 below) is useful.
> 
> I don’t see a contradiction between the two; they might be used
> together.
> 
> I would like to know how to handle two sub-problems here:
> 
> (a) using non-confirmable responses without additional requests brings
> us into PROBING_RATE territory.  What is actually the rate at which
> this exchange is supposed to happen?  Do we have other ways to manage
> capacity of the response path (a.k.a. congestion control)?  I.e., how
> does the server know which rate (e.g., for pacing) it should use for
> sending further messages?

[Med] 

(1)

Probing rate is negotiated during idle time between the client and server:

      probing-rate:  The average data rate that must not be exceeded by
         a DOTS agent in sending to a peer DOTS agent that does not
         respond (referred to as PROBING_RATE parameter in CoAP).

(2)

The probing-rate used in idle time may not be the same as the one using during at attack time. We do a value for each of them.

(3) in addition, we negotiate this additional "guard":

   DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
   messages to the same peer more frequently than once every 'telemetry-
   notify-interval'

> 
> (b) the semantics of observe is that a notification is the whole new
> state of the resource.  Proxies will implement it that way.  Of course
> block2 modifies this semantics a bit, so nonblock2 might do that too.
> Still, I think we need to consider what proxies (or client caches)
> will make out of the mechanism we devise.

[Med] Agree for the generic CoAP case. 

For the particular case of DOTS, sessions are established hop-by-hp when a proxy (we called it, gateway) is involved. We have the full visibility on what happens.   

> 
> Grüße, Carsten
> 
> 
> > On 2020-04-09, at 09:01, <[e-mail]>
> <[e-mail]> wrote:
> >
> > Hi Achim,
> >
> > First, I was not looking to "make your example buggy". I was trying
> to understand how this would work without requiring changes to the
> base specs. Your feedback is highly appreciated and very useful. Thank
> you.
> >
> > So far we have three approaches:
> >
> > (1) The use of nonblock2 option with a "relax" of the behavior at
> the server to send the fragments with the same token and without
> waiting for GETs.
> >
> > (2) The use of a shim application as you suggested, which requires
> an update on the server side but also on how clients on how to fill
> the gaps (use of PUT/FETCH).
> >
> > (3) A DOTS specific approach to build its own chunks and signal
> blocks as part of the CBOR. These blocks are handled as atomic
> notifications. If a block is missing, the client can use GET+Query to
> retrieve the gap. We don't require any modification at the base CoAP
> specs. The issue with this one is to decide what data to put in the
> blocks to avoid that when a block is passed to other layers, the
> overheads won't lead to fragmentation.
> >
> > It seems to me that (2) is a little bit more complex vs (1).
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Achim Kraus [mailto:[e-mail]]
> >> Envoyé : jeudi 9 avril 2020 08:00
> >> À : BOUCADAIR Mohamed TGI/OLN; Carsten Bormann
> >> Cc : Jon Shallow; [e-mail]; [e-mail]
> >> Objet : Re: [core] [Dots] Large asynchronous notifications under
> DDoS:
> >> New BLOCK Option?
> >>
> >> Hi Med,
> >>
> >> maybe, we have a different understanding of the CoAP principles.
> >>
> >> RFC 7252:
> >> single request-responses are matched by their tokens, chosen by the
> >> client. The server must include that token in it's response and
> must
> >> not
> >> make assumptions about it.
> >>
> >> RFC 7641:
> >> single request - multiple responses are matched by their tokens,
> >> chosen
> >> by the client. The server must include that token in all responses
> and
> >> must not make assumptions about it.
> >>
> >> RFC 7959:
> >> multiple request - multiple responses are used to transmit a large
> >> resource using the principals of RFC 7252/7641.
> >> RFC 7252 each single block transfer matches the single block
> request
> >> with it's single block response by a token chosen by the client.
> The
> >> server can not assume, that the tokens of several block-requests
> are
> >> related.
> >> RFC 7641 "single request - multiple responses" applies only to the
> >> head.
> >> the download of the left blocks doesn't reuse the token, nor is the
> >> server allowed, to make assumptions about the token.
> >>
> >> => you can't send the follow up blocks, because the token to do so
> is
> >> not defined. It would have been defined by the (missing) client
> >> request.
> >> If the token of the observe is used, the server makes a assumption
> and
> >> relate request of RFC7959, which are not related by the token.
> >>
> >> Therefore I asked also about the usage of observer/notify. If a
> >> PUT/POST
> >> is used, then your transfer looks just pretty much as a blockwise
> with
> >> NSTART-X. The drawback there will be the missing "blocksize"
> >> negotiation
> >> at the head. If that is acceptable, it should have a chance
> comparable
> >> to the proposal.
> >>
> >> The NonBlock2 solution is not bad on it's own, but it disrupt the
> >> principals for the tokens on the server side, at least in my
> >> understanding.
> >>
> >> -------------------------------------------------------------------
> --
> >>
> >>> One clarification question:
> >>
> >>>>            +--------->|   GET /path/ctrl Token 0xf1 { NonBlock2
> >>>> 1/0/1024 NonBlock2 2/0/1024 }
> >>
> >>> Do existing CoAP implementations (libcoap, for example) support
> >> GETs
> >> with a payload?
> >>
> >>
> >> I know, it looks a little unfair to point on single items of other
> >> example and then make buggy examples on my own :-). But I already
> >> admit
> >> "That should be not considered as "precise description of the
> >> application layer framing"".
> >> In fact, there is no outer GET required. The outer request could
> also
> >> be
> >> POST.
> >>
> >>              +--------->|   POST /path/ctrl Token 0xf1 { GET /path
> >> Token cde NonBlock2 1/0/1024 NonBlock2 2/0/1024 }
> >>
> >>
> >> Just to mention, that this request triggers the notifies with the
> >> missing block is "application layer convention". You may use
> whatever
> >> definition you want to tell the server to (re-)send notifies with
> >> blocks, there is no need of that inner GET request.
> >>
> >> -------------------------------------------------------------------
> --
> >>
> >> best regards
> >> Achim
> >>
> >> Am 08.04.20 um 23:22 schrieb [e-mail]:
> >>> Re-,
> >>>
> >>> Thanks, Carsten.
> >>>
> >>> This would mean that legacy CoAP implems do not support the coap-
> in-
> >> coap proposal without modification (given that rfc8132 support will
> be
> >> required).
> >>>
> >>> Actually, I'm struggling to understand what problem is solved by
> >> defining the NonBlock2 option but use it only with an extra coap
> >> layering.
> >>>
> >>> Cheers,
> >>> Med
> >>>
> >>>> -----Message d'origine-----
> >>>> De : Carsten Bormann [mailto:[e-mail]]
> >>>> Envoyé : mercredi 8 avril 2020 23:08
> >>>> À : BOUCADAIR Mohamed TGI/OLN
> >>>> Cc : Achim Kraus; Jon Shallow; [e-mail]; [e-mail]
> >>>> Objet : Re: [core] [Dots] Large asynchronous notifications under
> >> DDoS:
> >>>> New BLOCK Option?
> >>>>
> >>>> On 2020-04-08, at 23:04, <[e-mail]>
> >>>> <[e-mail]> wrote:
> >>>>>
> >>>>> Do existing CoAP implementations (libcoap, for example) support
> >> GETs
> >>>> with a payload?
> >>>>
> >>>> That is what FETCH is for.
> >>>>
> >>>> Grüße, Carsten
> >>>
> >