On 4/19/22 23:15, Benjamin Kaduk wrote:
On Tue, Apr 19, 2022 at 11:09:26PM -0400, Robert Moskowitz wrote:
Has there been any discussion about Transport ESP and SCHC from lpwan?
https://datatracker.ietf.org/doc/draft-ietf-lpwan-architecture/
In Sec 5, the assumption is the security envelope is above UDP. e.g.
DTLS and QUIC. No consideration for ESP Transport.
RFC 8824 only deals with CoAP and not UDP.
SCHC does not have an IP Protocol Number, thus I can't use it in ESP
Next Header.
The first "SC" is for "static context", i.e., you're supposed to just know,
from an external (fixed/static) context, when the header compression
is/isn't to be used. Since you "just know" when to use it, no in-band
signaling such as IP protocol number is needed, at least in the original
envisioned use cases.
Yet in 8724, they define a in-band header:
|------- Compressed Header -------|
+---------------------------------+--------------------+
| RuleID | Compression Residue | Payload |
+---------------------------------+--------------------+
How do you include this? This is especially needed with CoAP, rfc 8824.
What is preconfigured is what does the RuleID instruct you to do with
that compression residue.
Do you think you can draw a boundary around your use case such that the
"static context" would indicate when to (not) use the compression
techniques?
I can, except for the CoAP part which I have not plowed into yet. Only
getting started on the actual transactions and thus what is needed from
CoAP, and CBOR.
I believe that the UDP header will compress to zero bytes, which is good...
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
