On 4/20/22 05:42, Robert Moskowitz wrote:
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.
A bit more on this. When above Transport as in 8824, the port number
needs to know how to process the RuleID. When below IP as in 9011, the
MAC needs a type assigned for SCHC to know to use the RuleID for
IP/whatever expansion. MAC types are not the IETF's problem.
It takes something like ESP that sits below Transport, to change this.
Thus this COULD be an lpwan issue for introducing SCHC, or it could be
an ipsecme issue as as far as I can think, only ESP presents this issue.
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
