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

[Spencer Dawkins at IETF <[e-mail]>]

To a smaller audience,

I got this bounce message from AMS - perhaps Jiang's email address should
be updated?

<[e-mail]> (expanded from
    <[e-mail]>):
    host mx5.huawei.com[124.71.93.234] said: 551 5.1.1 <
[e-mail]>:
    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 <
[e-mail]> wrote:

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