Hi Michael, So you're proposing to add these DTLS considerations into draft-constrained-voucher, since the (constrained) Pledge has to do something additional (i.e. use the MFL option in DTLS) with respect to a regular BRSKI TLS Pledge? That sounds good to me. This even seems relevant if there is no Join Proxy in the middle: for cases that an unaware Registrar would construct a >1280 byte UDP datagram for example. In this case, path MTU discovery could make the Registrar learn to not exceed 1280 bytes, but the explicit signaling of MFL by the client is more efficient and also solves the case of "Join Proxy in the middle".
Instead of a section 5.4, a subsection in Section 9 is also possible, but I don't have a preference. The Join-Proxy draft might then refer to that DTLS considerations section in draft-constrained-voucher. The "special case" that join-proxy presents (as Peter commented on) could be explained best in the Join Proxy document. Esko -----Original Message----- From: Michael Richardson <[email protected]> Sent: Thursday, August 19, 2021 22:50 To: Esko Dijk <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02 (part 2/2) Esko Dijk <[email protected]> wrote: > So my point was that the draft could mention this implementation > aspect; preferably a DTLS client on the Pledge should use this; see the > motivation in https://datatracker.ietf.org/doc/html/rfc7925#section-15 > . The extension/option itself is defined in > https://datatracker.ietf.org/doc/html/rfc6066#section-4 . A value 2^9 > or 2^10 is a good choice for 6lowpan networks. If the client signals > this, the Registrar knows the size of the fragments to use for the > constrained network, even if it is located itself on a non-constrained > network without those MTU constraints. So, I think you are saying that we need to say something about keeping the DTLS handshake fragmentation size small enough that we can add the join-proxy overhead. Would a section 5.4: DTLS Considerations make sense? 5. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 6 5.1. Discovery, URIs and Content Formats . . . . . . . . . . . 6 5.2. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8 5.3. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 9 5.3.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 9 5.3.2. Registrar Extensions . . . . . . . . . . . . . . . . 10 ** 5.4 DTLS Considerations Peter, we can't use Blockwise on the DTLS handshake, because that part is outside of the CoAP header. We can only blockwise on the CoAP Payload. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
