Hi, Esko, On Tue, May 17, 2022 at 4:37 AM Esko Dijk <[email protected]> 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 <[email protected]> *On Behalf Of * Peter van der Stok > *Sent:* Tuesday, May 17, 2022 10:22 > *To:* Spencer Dawkins <[email protected]> > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *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 > [email protected] 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 > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
