Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
Spencer Dawkins via Datatracker wrote: > 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. There were several answers already. There are two places where this matters: a) during the DTLS setup phase. DTLS has a fragmentation mechanism to deal with DTLS messages which are larger than a UDP packet. End points can be conservative and keep below 1280. b) during the data transfer phase, DTLS does not provide any fragmentation and assumes applications won't send things larger than a UDP message, or that UDP fragmentation is acceptable. For this, we use CoAP Block modes. This is also described in RFC9148. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
Peter, On Wed, May 18, 2022 at 2:06 AM Peter van der Stok 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 > 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 *On Behalf Of * Peter van der Stok > *Sent:* Tuesday, May 17, 2022 10:22 > *To:* Spencer Dawkins > *Cc:* tsv-...@ietf.org; anima@ietf.org; > draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@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-...@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 > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
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. @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: tsv-...@ietf.org; anima@ietf.org; draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@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-...@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___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
To a smaller audience, I got this bounce message from AMS - perhaps Jiang's email address should be updated? (expanded from ): host mx5.huawei.com[124.71.93.234] said: 551 5.1.1 < jiangsh...@huawei.com>: Recipient address rejected: Failed recipient validation check.: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 recipient verify from ldap failed (in reply to RCPT TO command) (in reply to RCPT TO command) Best, Spencer On Tue, May 17, 2022 at 10:31 AM Spencer Dawkins at IETF < spencerdawkins.i...@gmail.com> wrote: > 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. >> >> >> @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:* tsv-...@ietf.org; anima@ietf.org; >> draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@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-...@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 >> >> ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
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. > > > @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:* tsv-...@ietf.org; anima@ietf.org; > draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@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-...@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 > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
Hi Peter, Spencer, For some more detail on Peter’s ‘No’ answer: 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. Regards Esko From: Anima On Behalf Of Peter van der Stok Sent: Tuesday, May 17, 2022 10:22 To: Spencer Dawkins Cc: tsv-...@ietf.org; anima@ietf.org; draft-ietf-anima-constrained-join-proxy@ietf.org; last-c...@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-...@ietf.org<mailto:tsv-...@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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
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-...@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___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10
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-...@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 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
