Re: [Tsv-art] [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10

[Spencer Dawkins at IETF <[e-mail]>]

Peter,

On Wed, May 18, 2022 at 2:06 AM Peter van der Stok <[e-mail]>
wrote:

> HI Esko, Spencer,
>
> I will add a sentence in at the end of section 5.3.
>
> It is recommended to use the block option [RFC7959] and make sure that the
> block size allows the addition of the JPY header without violating MTU
> sizes.
>
> thanks for the reminder,
>

Oh, thank you!

Best,

Spencer


> Peter
>
> Spencer Dawkins at IETF schreef op 2022-05-17 17:31:
>
> Hi, Esko,
>
> On Tue, May 17, 2022 at 4:37 AM Esko Dijk <[e-mail]>
> wrote:
>
> Hi Peter, Spencer,
>
>
>
> For some more detail on Peter's 'No' answer:
>
>
> I was expecting that answer. 😉
>
> Thanks for the additional details!
>
>
>
>
> Since the Pledge communicates (link-local) with the Join Proxy using
> DTLS-over-UDP on a network that is likely 6LoWPAN (1280 byte MTU limit)
> mesh, it could happen in theory that the Pledge sends out a DTLS handshake
> UDP packet with a length that brings the carrying IPv6 packet length at
> 1280.
>
> In this case the DTLS record size is also something close to 1280. (We
> never did the exact calculations.)
>
>
>
> This may pose a problem for the stateless Join Proxy that appends a few
> bytes to the DTLS record (to relay it further to the Registrar) so the
> total length of the IPv6 packet sent to Registrar could exceed 1280. (And
> the Join Proxy is still on the mesh network with 1280 byte MTU).
>
> But in any case in the constrained-voucher draft we have written about
> this:
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-6.7
>
>
>
> So even though we don't know for sure it is a problem, as we haven't done
> the calculations in detail, it's preemptively solved by recommending the
> Pledge to break up the handshake into smaller parts. Then,  the Join Proxy
> doesn't need to do anything special anymore and it always works.
>
> That also helps with performance on the mesh network due to reduction of
> 6LoWPAN fragmentation.
>
>
> @Spencer do you think the Constrained Join Proxy draft should mention the
> potential issue also?  E.g. a reference to above section 6.7 is easy to
> make.
>
>
> The reference you described is exactly what I was thinking of (I was more
> familiar with COAP before blockwise transfer was specified in
> https://datatracker.ietf.org/doc/rfc7959/, but I knew it had been
> standardized).
>
> If you can preemptively avoid a potential problem by adding a reference to
> the document and section you provided, without slowing this document down,
> that would be great.
>
> And thanks again for a quick response to a really late directorate review.
>
> (I know we're not talking about
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher,
> but I didn't see RFC 7959 listed as a reference there, and it seems like
> that should be normative. But do the right thing, of course!
>
> Best,
>
> Spencer
>
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Anima <[e-mail]> *On Behalf Of * Peter van der Stok
> *Sent:* Tuesday, May 17, 2022 10:22
> *To:* Spencer Dawkins <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *Subject:* Re: [Anima] Tsvart last call review of
> draft-ietf-anima-constrained-join-proxy-10
>
>
>
> Hi Spencer,
>
> thanks for your kind words.
>
> Indeed the answer is no. (at least for the coming 20 years).
>
> Greetings and thanks,
>
> Peter
>
> Spencer Dawkins via Datatracker schreef op 2022-05-17 01:09:
>
> Reviewer: Spencer Dawkins
> Review result: Ready
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [e-mail] if you reply to or forward this review.
>
> This is a well-written specification. My only question - and I expect the
> answer will be "no" - is whether there is any concern that sizes of the
> resources that are being passed around might exceed the MTU between the
> pledge
> and the registrar, and whether there should be a mention of this
> possibility in
> the specification.
>
> Best,
>
> Spencer
>
>