I have been doing more research on using SCHC with DTLS for general UDP
applications.
For this I am using MAVlink
https://mavlink.io/en/
As my UDP app example.
I see EKR's point on the small header design of DTLS 1.3 per RFC9147 fig
3. I will use:
2-byte CID
1-byte Seq# (same as MAVlink)
2-byte Length (max MAVlink after compression is 263 bytes)
The SCHC rules allow for compressing 16 bytes within MAVlink and
eliminating transport of the UDP header.
The challenge is without the UDP header, and assuming NextHeader is UDP,
how does the UDP layer handle this datagram? The UDP Destination Port
is the DTLS Seq and 1st byte of the length.
This seems to fraught with failure modes, and that the NextHeader really
MUST be SCHC as I have defined in draft-moskowitz-lpwan-ipnumber.
This is really the first question: Is there anyway to do this without
adding SCHC as an IP Number?
Next is does the RuleID need to be explicit in the packet or can it be
implicit? I think that would depend on the IP Source Addr. If this is
the ONLY SCHC RuleID from that addr, then, yes it can be implicit,
saving the byte.
Finally setting up SCHC. Is static configuration the only option? Well
for MAVlink use, this is not so much an issue, as there is a limited
pairing between UA/GCS. But should there be a DTLS SCHC negotiation as
link in draft-mglt-ipsecme-ikev2-diet-esp-extension?
I welcome your comments/observations.
Oh, why work hard to save 24 bytes over the 'wire'? For some wireless
links that might be all it takes to result in fragmentation and
potentially doubling the link usage.
Other UDP apps might have other savings. This might have general
aviation usage beyond what I have looked at todate.
Thanks.
Bob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
