> PS one further addition to my review; a consideration that should be added > somewhere: > Suppose that the Pledge creates a IPv6 UDP packet containing a DTLS record > of 1278 bytes; and the network is 6LoWPAN based (1280 byte MTU limit). > Then a stateless Join Proxy would have to create a JPY_message by adding a > few more bytes for the CBOR map, so the overall new packet to be sent to > the Registrar over the 6lowpan network would exceed 1280 bytes so it cannot > send it. > Consequence: the BRSKI protocol cannot proceed; failure.
I know that 6lowpan must guarantee at least 1280 byte, but I guess it doesn't have to support more than that, so you are right. > So a Pledge that is configured to use a Join Proxy MUST limit the size of > its DTLS records to some value < 1280 such that when added to the > worst-case-length CBOR map added by a stateless Join Proxy, the total does > not exceed 1280 bytes; in case the Pledge is using 6lowpan network > interface. In general, also for other link types, the Pledge should be > some bytes under its current link MTU to the Join Proxy. should we include this analysis in constrained-voucher, and provide a value? > Because the Pledge doesn’t know in advance whether the Join Proxy operates > stateful or stateless. > DTLS has a built-in mechanism to fragment handshake messages (e.g. to 1024 > byte fragments) which can be used to stay below the limit. And for > CoAP-over-DTLS messages, blockwise transfer can be used to ensure this. do we want to insist that this is the way? It is good that we are figuring this out now. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
