Re: [IPsec] Transport ESP and SCHC

2022-04-20 Thread Robert Moskowitz



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


Re: [IPsec] Transport ESP and SCHC

2022-04-20 Thread Robert Moskowitz



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