Re: [Last-Call] [Anima] Tsvart last call review of draft-ietf-anima-constrained-join-proxy-10

[Peter van der Stok <[e-mail]>]

  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 <[e-mail]> 
> 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 <[e-mail]> On Behalf Of Peter van der Stok
> Sent: Tuesday, May 17, 2022 10:22
> To: Spencer Dawkins <[e-mail]>
> Cc: [e-mail]; [e-mail]; 
> [e-mail]; 
> [e-mail]
> 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
> [e-mail] 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