Re: [core] draft-ietf-core-new-block: Congestion Control

[Jon Shallow <[e-mail]>]

Hi Michael,

It is good to have these thought provoking questions.

See inline.

Regards

Jon

> -----Original Message-----
> From: Michael Richardson [mailto:[e-mail]]
> Sent: 24 October 2020 21:47
> To: Jon Shallow
> Cc: [e-mail]
> Subject: Re: [core] draft-ietf-core-new-block: Congestion Control
> 
> 
> Jon Shallow <[e-mail]> wrote:
>     > The original concept of Quick-Block2 was to get all of the data over in
>     > an efficient manner (subject to congestion control) and reduce the
>     > number of requests needed as a part of that process.  An Observe
>     > trigger just needed to send over all of the data within the body.
> 
>     > "Selective" access to resource data was not required but is provided by
>     > Block2 (but missing blocks can be re-requested using Quick-Block2).
>     > When asked yesterday, I knew that there were likely to be issues in
>     > this area and my answer was not well thought through - hence what you
>     > picked up.
> 
> I'm asking if a return reachability check is needed before the multiple
> packet reply.

There is none at present.  This is only an issue if using NoSec security mode as any other mode implies reachability is there.

> 
> That is, is there an amplication attack possible here is one can forge the
> source address.

Yes.  This is covered in part by https://tools.ietf.org/html/rfc7252#section-11.3 .  If a security mode other than NoSec, then this should not be an issue as it becomes very difficult to spoof a source address.

In the case of the DOTS protocol which triggered this draft,, Security is a requirement https://tools.ietf.org/html/rfc8782#section-10 .  That said, it is worth adding something to https://datatracker.ietf.org/doc/html/draft-ietf-core-new-block-01#section-11 to recommend a security mode other than NoSec as picked up from https://tools.ietf.org/html/rfc7252#section-11.4 .

> 
> It might be that nobody will never use *-Block[12] (I also like Robust)
> without an OSCORE context, in which case there is probably enough security
> to prevent abuse by forged source address.

Agreed.

> 
>     > It is possible to ask for a specific offset and the blocks following as
>     > the Quick-Block2 option can be used multiple times in a single GET
>     > request - they would be the base offset (as indicated by block.num and
>     > block.szx) and the remaining options used for block.num+1,
> block.num+2
>     > etc.  If more than MAX_PAYLOAD options were defined, the first
>     > MAX_PAYLOAD would come back, then an ACK_TIMEOUT pause and then
> the
>     > next blocks etc.
> 
> So, given a Christmas-Tree-Packet (largest packet, every possible option
> space used, every extension turned on...) how much data can I get back? :-)

If the server is unable to use the smallest block size (16) (lack of PDU space) and there is 16 or more bytes, then no data will get transferred back.  This issue is the same as for the regular Block2. 

I believe that this should generate a 4.13 (Request Entity Too Large), but am open to other suggestions.

> 
> If it is legit to include multiple copies of the options, can I ask for the same
> offset to be sent to me multiple times?

Good catch. No as there is no point in supporting this. The text will get updated to indicate this is invalid and will get rejected.
 
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>