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,
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 <esko.dijk@xxxxxxxxxxxxxxxxx> 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 <anima-bounces@xxxxxxxx> On Behalf Of Peter van der Stok
Sent: Tuesday, May 17, 2022 10:22
To: Spencer Dawkins <spencerdawkins.ietf@xxxxxxxxx>
Cc: tsv-art@xxxxxxxx; anima@xxxxxxxx; draft-ietf-anima-constrained-join-proxy.all@xxxxxxxx; last-call@xxxxxxxx
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,
PeterSpencer 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
tsv-art@xxxxxxxx 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
