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 <[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
