EskoDijk
commented
2 years ago Thanks Peter,
That sounds good. A block size up to 1024 should always work. Ideally we do those detail in the constrained-voucher draft and then constrained-join-proxy can just refer to the section! But some repetition is also fine for me. Just to be clear the CoAP blockwise transfer doesn’t help for the handshake messages – for that we still need the measures as described in 6.7 in constrained-voucher.
Esko
From: peter van der stok @.> Sent: Wednesday, May 18, 2022 09:17 To: anima-wg/constrained-join-proxy @.> Cc: Subscribed @.***> Subject: [anima-wg/constrained-join-proxy] TSVART review (Issue #22)
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 @.**@.>> 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.
@spencerhttps://github.com/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 @.**@.>> On Behalf Of Peter van der Stok Sent: Tuesday, May 17, 2022 10:22 To: Spencer Dawkins @.**@.>> Cc: @.**@.>; @.**@.>; @.**@.>; @.**@.> 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 @.**@.> 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
— Reply to this email directly, view it on GitHubhttps://github.com/anima-wg/constrained-join-proxy/issues/22, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADXDAXUPDSLDFYH2IWXCEZDVKSKQNANCNFSM5WHN427A. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>
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@iotconsultancy.nl](mailto:esko.dijk@iotconsultancy.nl) 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@ietf.org](mailto:anima-bounces@ietf.org) On Behalf Of Peter van der Stok Sent: Tuesday, May 17, 2022 10:22 To: Spencer Dawkins [spencerdawkins.ietf@gmail.com](mailto:spencerdawkins.ietf@gmail.com) Cc: tsv-art@ietf.org; anima@ietf.org; draft-ietf-anima-constrained-join-proxy.all@ietf.org; last-call@ietf.org 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 tsv-art@ietf.org 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