[TLS] DTLS support of SCHC

[Robert Moskowitz <[e-mail]>]

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