-
Notifications
You must be signed in to change notification settings - Fork 3
/
draft-ietf-ipsecme-diet-esp.xml
1630 lines (1432 loc) · 98 KB
/
draft-ietf-ipsecme-diet-esp.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.0.2) -->
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC4303 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml">
<!ENTITY RFC4301 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC8724 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8724.xml">
<!ENTITY RFC8376 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml">
<!ENTITY RFC7296 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY I-D.mglt-ipsecme-ikev2-diet-esp-extension SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-ipsecme-ikev2-diet-esp-extension.xml">
<!ENTITY RFC5996 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY I-D.mglt-ipsecme-dscp-np SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.mglt-ipsecme-dscp-np.xml">
<!ENTITY RFC8750 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8750.xml">
<!ENTITY RFC6437 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6437.xml">
<!ENTITY RFC6864 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6864.xml">
<!ENTITY RFC9333 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9333.xml">
<!ENTITY RFC4309 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4309.xml">
]>
<rfc ipr="trust200902" docName="draft-ietf-ipsecme-diet-esp-02" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="EHCP">ESP Header Compression Profile</title>
<author initials="D." surname="Migault" fullname="Daniel Migault">
<organization>Ericsson</organization>
<address>
<email>daniel.migault@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Hatami" fullname="Maryam Hatami">
<organization>Concordia University</organization>
<address>
<email>maryam.hatami@mail.concordia.ca</email>
</address>
</author>
<author initials="S." surname="Céspedes" fullname="Sandra Cespedes">
<organization>Concordia University</organization>
<address>
<email>sandra.cespedes@concordia.ca</email>
</address>
</author>
<author initials="W." surname="Atwood" fullname="J. William Atwood">
<organization>Concordia University</organization>
<address>
<email>william.atwood@concordia.ca</email>
</address>
</author>
<author initials="T." surname="Guggemos" fullname="Tobias Guggemos">
<organization>LMU</organization>
<address>
<email>guggemos@nm.ifi.lmu.de</email>
</address>
</author>
<author initials="C." surname="Bormann" fullname="Carsten Bormann">
<organization>Universitaet Bremen TZI</organization>
<address>
<email>cabo@tzi.org</email>
</address>
</author>
<author initials="D." surname="Schinazi" fullname="David Schinazi">
<organization>Google LLC</organization>
<address>
<email>dschinazi.ietf@gmail.com</email>
</address>
</author>
<date year="2024" month="July" day="29"/>
<area>Security</area>
<workgroup>IPsecme</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 55?>
<t>This document defines how to compress/decompress communications protected with IPsec/ESP using Static Context Header Compression and fragmentation (SCHC). SCHC uses static information from IPv6 headers to reduce redundancy and size of packets on the wire. This specification provides guidelines on the application of SCHC to compress/decompress at different levels of the ESP/IPv6 protected packets, leveraging the information already shared by the peers.</t>
</abstract>
</front>
<middle>
<?line 59?>
<section anchor="requirements-notation"><name>Requirements notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
<?line -6?></t>
</section>
<section anchor="introduction"><name>Introduction</name>
<t>The Encapsulating Security Payload (ESP) <xref target="RFC4303"/> protocol can provide confidentiality, data origin authentication, integrity, anti-replay, and traffic flow confidentiality. The set of services ESP provides depends on the Security Association (SA) parameters negotiated between devices.</t>
<t>ESP has two modes: Tunnel and Transport. Tunnel mode is commonly used for VPNs, with the ESP header placed after the outer IP header and before the inner IP packet headers. In Transport mode, the ESP Payload Data consists of the IP Payload, with the ESP header placed after the inner IP packet header and any IP extensions headers.</t>
<t>This document defines the ESP Header Compression profile (EHCP) for compression/decompression (C/D) of IPsec/ESP <xref target="RFC4301"/> / <xref target="RFC4303"/> packets, represented by the structure shown in <xref target="fig-esp"/>, using Static Context Header Compression and fragmentation (SCHC) <xref target="RFC8724"/>. Compression with SCHC is based on using a set of Rules, which constitutes the Context of SCHC C/D, to compress or decompress headers. The motivation is to avoid sending information that has already been shared by the peers, thus reducing the ESP packet size on the wire. To better understand ESP, the reader might be interested in reading Minimal ESP <xref target="RFC9333"/>, a simplified version of ESP.</t>
<figure title="Top-Level Format of an ESP Packet" anchor="fig-esp"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>This document provides the ESP Header Compression profile (EHCP) architecture with the integration of SCHC into various levels of the IPsec stack. The three levels of compression are defined below:</t>
<t><list style="numbers">
<t>Inner IP Compression (IIPC): This level happens directly on the inner IP packet. For example, in the case of a UDP packet with ports determined by the SA, fields such as UDP ports and checksums are typically compressed. If no compression of the inner packet is possible, the resulting SCHC packet contains the uncompressed IP packet, as per <xref section="7.2" sectionFormat="comma" target="RFC8724"/>.</t>
<t>Clear Text ESP Compression (CTEC): This level compresses fields of the ESP payload right before being encrypted.</t>
<t>Encrypted ESP Compression (EEC): This level compresses ESP fields that remain after encryption, that is, the ESP header.</t>
</list></t>
<t>Note that the descriptions of the three levels of compression provided in this document meet the general purpose of ESP. It is possible that in some specific deployments, SCHC contexts from different levels can be merged. Typically, a specific implementation may merge IIPC and CTEC.</t>
<t>For each compressor/decompressor level, it defines the ESP fields to be considered in the rules of its corresponding SCHC context. In addition, it defines how the SCHC contexts are initialized from the SA and provides the corresponding SCHC rules (RuleID, SCHC MAX_PACKET_SIZE, new SCHC Compression/Decompression Actions (CDA), and fragmentation). The appendix provides illustrative examples of applications of EHC using an implementation in openschc.</t>
</section>
<section anchor="terminology"><name>Terminology</name>
<dl>
<dt>ESP Header Compression Profile (EHCP):</dt>
<dd>
<t>A method to reduce the size of ESP headers using predefined compression rules and contexts to improve efficiency.</t>
</dd>
<dt>Inner IP C/D (IIPC):</dt>
<dd>
<t>Expressed via the SCHC framework, IIPC compresses/decompresses the inner IP packet headers.</t>
</dd>
<dt>Clear Text ESP C/D (CTEC):</dt>
<dd>
<t>Expressed via the SCHC framework, CTEC compresses/decompresses all fields that will later be encrypted by ESP.</t>
</dd>
<dt>Encrypted ESP C/D (EEC):</dt>
<dd>
<t>Expressed via the SCHC framework, EEC compresses/decompresses ESP fields that will not be encrypted by ESP.</t>
</dd>
<dt>Security Parameters Index (SPI):</dt>
<dd>
<t>As defined in <xref section="4.1" sectionFormat="comma" target="RFC4301"/>.</t>
</dd>
<dt>Sequence Number (SN):</dt>
<dd>
<t>As defined in <xref section="2.2" sectionFormat="comma" target="RFC4303"/>.</t>
</dd>
<dt>Static Context Header Compression (SCHC):</dt>
<dd>
<t>A framework for header compression designed for LPWANs, as defined in <xref target="RFC8724"/>.</t>
</dd>
<dt>Static Context Header Compression Rules (SCHC Rules):</dt>
<dd>
<t>As defined in <xref target="RFC8724"/>, Section 5.</t>
</dd>
<dt>RuleID:</dt>
<dd>
<t>A unique identifier for each SCHC rule, as defined in <xref target="RFC8724"/>, Section 5.1.</t>
</dd>
<dt>SCHC Context:</dt>
<dd>
<t>The set of parameters and rules shared between communicating entities, as defined in <xref target="RFC8724"/>, Section 5.3.</t>
</dd>
</dl>
<t>It is assumed that the reader is familiar with other SCHC terminology defined in <xref target="RFC8376"/> and <xref target="RFC8724"/>.</t>
</section>
<section anchor="schc-integration-into-the-ipsec-stack"><name>SCHC Integration into the IPsec Stack</name>
<t>The main principle of the ESP Header Compression Profile (EHCP) is to avoid sending information that has already been shared by the peers. Different profiles and technologies, such as those defined by <xref target="RFC4301"/> and <xref target="RFC4303"/>, ensure that ESP can be tailored to various network requirements and security policies. However, ESP is not optimized for bandwidth efficiency because it has been designed as a general-purpose protocol. EHCP aims to address this by leveraging a profile, expressed via the SCHC framework, to optimize the ESP header sizes for better efficiency in constrained environments.</t>
<t>Profiles for compression are derived from parameters associated with the Security Association (SA) and agreed upon via IKEv2 <xref target="RFC7296"/>, as well as specific compression parameters defined in IKEv2 <xref target="I-D.mglt-ipsecme-ikev2-diet-esp-extension"/>. As depicted in <xref target="fig-arch"/>, this document defines three levels of compression, as previously described: IIPC, CTEC, and EEC. The terminology of "levels" is used consistently throughout the document for clarity.</t>
<t>The <xref target="fig-arch"/> illustrates the integration of SCHC into the IPsec stack, detailing the different levels and components involved in the compression and decompression processes. The diagram is divided into two entities, each representing an endpoint of a communication link.</t>
<t>While the scope of this compression profile currently does not extend beyond the transport layer (i.e., UDP), there will eventually be a need to compress the application layer as well.</t>
<t>The decompression of the inbound packet follows a reverse process. First, the Encrypted ESP C/D (EEC) decompresses the encrypted ESP header fields. After the ESP packet is decrypted, the Clear Text ESP C/D (CTEC) decompresses the Clear Text fields of the ESP packet.</t>
<t>Note that implementations MAY differ from the architectural description but it is assumed the outputs will be the same.</t>
<figure title="SCHC Integration into the IPsec Stack. Packets are described for the tunnel mode and C designates the Compressed header for the fields inside. IIP designates the Inner IP packet, EH and ET respectively the ESP Header and the ESP Trailer" anchor="fig-arch"><artwork align="center"><![CDATA[
+--------------------------------+
| ESP Header Compression Context |
| - Security Association |
| - Additional Parameters |
+--------------------------------+
|
Endpoint | Endpoint
|
+----------------+ | +----------------+
| Inner IP packet| | | Inner IP packet|
+----------------+ | +----------------+
| SCHC |+---------IIPC level--------------+| SCHC |
+----------------+ C {IIP} +----------------+
| ESP | | | ESP |
| (encapsulation)| | | (unwrapping) |
+----------------+ v +----------------+
| SCHC |+---------CTEC level--------------+| SCHC |
+----------------+ EH, C {C {IIP}, ET} +----------------+
| ESP | | | ESP |
| (encryption) | | | (decryption) |
+----------------+ v +----------------+
| SCHC |+-----------EEC level-------------+| SCHC |
+----------------+ IP, C {EH, C {C {IIP}, ET}} +----------------+
| IPv6 + ESP | | IPv6 + ESP |
+----------------+ +----------------+
| L2 | | L2 |
+----------------+ +----------------+
]]></artwork></figure>
</section>
<section anchor="schc-parameters"><name>SCHC parameters</name>
<t>If ESP incorporates SCHC, it is essential that these scenarios use the SCHC header compression <xref target="RFC8724"/> capability to optimize data transmission.</t>
<t>In order to work properly, the different levels of C/D need to be configured similarly with the same SCHC Context Initialization. This involves defining variables such as SCHC MAX_PACKET_SIZE or Fragmentation that are invariants in our case, as well as SCHC Rules that are expected to be set on a per SA basis.</t>
<t>The EHCP Context provides the necessary information to generate the SCHC Rules.
Most pieces of information are already available from the negotiated SA <xref target="RFC4301"/>.
Other pieces of information need to be specifically configured or agreed via other mechanisms, such as <xref target="I-D.mglt-ipsecme-ikev2-diet-esp-extension"/>.</t>
<t>The reference column in <xref target="tab-ehc-ctx-esp"/> indicates how the information is defined. The C/D column specifies in which of the compression levels the parameter is being used.</t>
<t>Note that additional Compression might be performed especially on the inner IP packet - for example, including the TCP layer.
However, this profiles limits the scope of the compression to the inner IP header, and possibly UDP headers. We believe this is a reasonable scope for ESP to address both IoT UDP packets as well as large VPN traffic.
Further and more specific compression profiles may be defined in the future.</t>
<section anchor="schc-context-initialization"><name>SCHC Context Initialization</name>
<t>SCHC Context Initialization involves setting up the initial parameters and values that will be used for compressing and decompressing ESP headers. This includes defining the static context, which contains all the rules and parameters necessary for the SCHC operations. The context is shared between the sender and receiver to ensure consistent compression and decompression processes. Initialization ensures that both ends have a common understanding of the fields, their possible values, and how to handle them during communication.</t>
</section>
<section anchor="schc-rules"><name>SCHC Rules</name>
<t>SCHC Rules are predefined sets of instructions that specify how to compress and decompress the header fields of an ESP packet. Each rule is designed to handle specific patterns and variations in the header fields, allowing for efficient compression by eliminating redundancy and leveraging the static context. Rules are identified by RuleIDs and are crucial for mapping the fields correctly during the compression and decompression processes.</t>
<t>Similarly to SA, Rules are directional and the Direction Indicator (DI) is set to Up for outbound SA and Down for inbound SA. Each Rule also contains a Field Position parameter that is set to 1, unless specified otherwise.</t>
</section>
<section anchor="rule-id"><name>Rule ID</name>
<t>The RuleID is a unique identifier for each SCHC rule, included in packets to ensure the receiver applies the correct decompression rule, maintaining consistency in packet processing. Note that the Rule ID does not need to be explicitly agreed upon and can be defined independently by each party.</t>
</section>
<section anchor="schc-maxpacketsize"><name>SCHC MAX_PACKET_SIZE</name>
<t>This field defines the largest size of a compressed ESP packet that can be handled. It ensures packets fit within network limits, optimizing transmission and avoiding unnecessary fragmentation. Note that the SCHC MAX_PACKET_SIZE varies based on the packet because it is not specific to any particular lower-layer (LL) technology. This flexibility allows SCHC to be adapted to various network environments and constraints.</t>
</section>
<section anchor="fragmentation"><name>Fragmentation</name>
<t>The resulting IP/ESP packet size is variable. In some networks, the packet will require fragmentation before transmission over the wire. Fragmentation is out of the scope of this document since it is dependant on the layer 2 technology.</t>
</section>
<section anchor="schc-parameterization-for-esp"><name>SCHC parameterization for ESP</name>
<t>This section lists in Table <xref target="tab-ehc-ctx-esp"/> and describes the attributes of the EHCP Context. These attributes will be used to express the various compressions that operate at the IIPC, CTEC, and EEC level.<br />
The attributes can be derived from the agreed SA or being explicitly agreed or configured.</t>
<t>The compression of the Inner IP Packet is based on the attributes that are derived from the negotiated Traffic Selectors TSi/TSr. The resulting Traffic Selectors negotiated as described in <xref section="3.13" sectionFormat="comma" target="RFC7296"/> may result in a quite complex expression, and this specification restricted that complexity. In particular, we restrict the Traffic Selector to a single type of IP address (IPv4 or IPv6), a single protocol (such as UDP, TCP, not relevant), a single port range and multiple DSCP numbers. Such simplification corresponds to the expression of an individual Traffic Selector Payload <xref section="3.13.1" sectionFormat="comma" target="RFC7296"/>.<br />
The ability to derive the EHCP Context for the IIPC from the agreed Traffic Selectors is indicated by a variable iipc_profile.</t>
<figure title="EHCP related parameters" anchor="tab-ehc-ctx-esp"><artwork align="center"><![CDATA[
+===================+=============================+===========+=======+
| EHC Context | Possible Values | Reference | C / D |
+===================+=============================+===========+=======+
| iipc_profile | "diet-esp", "uncompress" | ThisRFC | N/A |
| dscp_cda | "uncompress", "lower", "sa" | ThisRFC | IIPC |
| ecn_cda | "uncompress", "lower" | ThisRFC | IIPC |
| flow_label_cda | "uncompress", "lower", | ThisRFC | IIPC |
| | "generated", "zero" | | |
| ts_ip_version | "IPv4-only", "IPv6-only" | ThisRFC | IIPC |
| ts_ip_src_start | IP4 or IPv6 address | ThisRFC | IIPC |
| ts_ip_src_end | IP4 or IPv6 address | ThisRFC | IIPC |
| ts_ip_dst_start | IPv4 or IPv6 address | ThisRFC | IIPC |
| ts_ip_dst_end | IPv4 or IPv6 address | ThisRFC | IIPC |
| ts_proto | TCP, UDP, UDP-Lite, SCTP, | ThisRFC | IIPC |
| | ANY, | | |
| ts_port_src_start | Port number | ThisRFC | IIPC |
| ts_port_src_end | Port number | ThisRFC | IIPC |
| ts_port_dst_start | Port number | ThisRFC | IIPC |
| ts_port_dst_end | Port number | ThisRFC | IIPC |
| dscp_list | list of DSCP numbers | RFCYYYY | IIPC |
+-------------------+-----------------------------+-----------+-------+
| alignment | "8 bit", "32 bit" | ThisRFC | CTEC |
| ipsec_mode | "Tunnel", "Transport" | RFC4301 | CTEC |
| tunnel_ip | IPv4, IPv6 address | RFC4301 | CTEC |
| esp_encr | ESP Encryption Algorithm | RFC4301 | CTEC |
+-------------------+-----------------------------+-----------+-------+
| esp_spi | ESP SPI | RFC4301 | EEC |
| esp_spi_lsb | 0, 1, 2, 3, 4* | ThisRFC | EEC |
| esp_sn | ESP Sequence Number | RFC4301 | EEC |
| esp_sn_lsb | 0, 1, 2, 3, 4* | ThisRFC | EEC |
+-------------------+-----------------------------+-----------+-------+
]]></artwork></figure>
<t>Any parameter starting with "ts_". These parameters are associated with the Traffic Selectors of the SA and are introduced by this specification.
This specification limits the expression of the Traffic Selector to be of the form (IP source range, IP destination range, Port source range, Port destination range, Protocol ID list, DSCP list).
This limits the original flexibility of the expression of TS, but we believe that it provides sufficient flexibility. Following shows detail information of these parameters.</t>
<dl>
<dt>iipc_profile:</dt>
<dd>
<t>designates the profile used by IIPC. When set to "uncompress" IIPC is not performed. This draft describes IIPC that corresponds to the "diet-esp" profile.</t>
</dd>
<dt>flow_label_cda:</dt>
<dd>
<t>indicates how the Flow Label field of the inner IPv6 packet or the Identification field of the inner IPv4 packet is compressed / decompressed - See <xref target="sec-cda"/> for more information. In a nutshell, "uncompress" indicates that Flow Label (resp. Identification) are not compressed. "lower" indicates the value is read from the outer IP header - eventually with some adaptations when inner IP packet and outer IP pakets have different versions. "generated" indicate s that the fields is generated by the receiving party. In that case, the decompressed value may take a different value its original value. "zero" indicates the field is set to zero.</t>
</dd>
<dt>dscp_cda:</dt>
<dd>
<t>indicates how the DSCP values of the inner IP packet are generated. (See flow_label_cda). "sa" indicates, compression is performed according to the DSCP values agreed by the SA (dscp_list).</t>
</dd>
<dt>ecn_cda:</dt>
<dd>
<t>indicates how the ECN values of the inner IP packet are generated. (See flow_label_cda).</t>
</dd>
<dt>ts_ip_version:</dt>
<dd>
<t>designates the IP version of the Traffic Selectors and its value is set to "IPv4-only" when only IPv4 IP addresses are considered and to "IPv6-only" when only IPv6 addresses are considered.
Practically, when IKEv2 is used, it means that the agreed TSi or TSr results only in a mutually exclusive combination of TS_IPv4_ADDR_RANGE or TS_IPV6_ADDR_RANGE payloads.</t>
</dd>
<dt>ts_ip_src_start:</dt>
<dd>
<t>designates the starting value range of source IP addresses of the inner packet and has the same meaning as the Starting Address field of the Traffic Selector payload defined in <xref section="3.13" sectionFormat="comma" target="RFC7296"/>.
Note however that in this specification, ts_ip_src_start applies for all agreed Traffic Selector payloads.
When the IP addresses cannot be expressed as a range, that can be exactly expressed as [ ts_ip_src_start, ts_ip_src_end ], ts_ip_src_start is undefined.</t>
</dd>
<dt>ts_ip_src_end:</dt>
<dd>
<t>designates the high end value range of source IP addresses of the inner packet and has the same meaning as the Ending Address field of the Traffic Selector payload defined in <xref section="3.13" sectionFormat="comma" target="RFC7296"/>.
Similarly to ts_ip_src_end, when the IP addresses cannot be expressed as a range, ts_ip_src_end is undefined.</t>
</dd>
<dt>ts_port_src_start:</dt>
<dd>
<t>designates the starting value of the port range of the inner packet and has the same meaning as the Start Port field of the Traffic Selector payload defined in <xref section="3.13" sectionFormat="comma" target="RFC7296"/>.</t>
</dd>
<dt>ts_port_src_end:</dt>
<dd>
<t>designates the starting value of the port range of the inner packet and has the same meaning as the End Port field of the Traffic Selector payload defined in <xref section="3.13" sectionFormat="comma" target="RFC7296"/>.</t>
</dd>
</dl>
<t>IP addresses and ports are defined as a range and compressed using the LSB.
For a range defined by start and end values, msb( start, end ) is defined as the function that returns the MSB that remains unchanged while the value evolves between start and end.
Similarly, lsb( start, end ) is defined as the function that returns the LSB that changes while the value evolves between start and end.
Finally, len( x ) is defined as the function that returns the number of bits of the bit array x.</t>
<dl>
<dt>ts_proto:</dt>
<dd>
<t>designates the list of Protocol ID field, whose meaning is defined in <xref section="3.13" sectionFormat="comma" target="RFC7296"/>. This profile considers the specific protocols values "TCP", "UDP", "UDP-Lite", "SCTP", "OTHER" and "ANY". "OTHER" designates any protocol values that are not in :"TCP", "UDP", "UDP-Lite", "SCTP. "ANY" as defined in <xref section="3.13" sectionFormat="comma" target="RFC5996"/> and designates any possible values.</t>
</dd>
<dt>dscp_list:</dt>
<dd>
<t>designates the list of DSCP values with the same meaning as the List of DSCP Values defined in <xref target="I-D.mglt-ipsecme-dscp-np"/>. These are not Traffic Selector, but the compression mandates the packets takes one of these listed DSCP value.</t>
</dd>
<dt>alignment:</dt>
<dd>
<t>indicates the byte alignement supported by the OS for the ESP extension. By default, the alignement is 32 bit for IPv6, but some systems may also support an 8 bit alignement. Note that when a block cipher such as AES-CCM is used, an 8 bit alignment is overwritten by the block size.</t>
</dd>
<dt>ipsec_mode:</dt>
<dd>
<t>designates the IPsec mode defined in <xref target="RFC4301"/>. In this document, the possible values are "tunnel" for the Tunnel mode and "transport" for the Transport mode.</t>
</dd>
<dt>tunnel_ip:</dt>
<dd>
<t>designates the IP address of the tunnel defined in <xref target="RFC4301"/>.
This field is only applicable when the Tunnel mode is used.
That IP address can be an IPv4 or IPv6 address.</t>
</dd>
<dt>esp_encr:</dt>
<dd>
<t>designates the encryption algorithm used. For the purpose of compression it is RECOMMENDED to use <xref target="RFC8750"/>.</t>
</dd>
<dt>esp_spi:</dt>
<dd>
<t>designates the Security Policy Index defined in <xref target="RFC4301"/>.</t>
</dd>
<dt>esp_spi_lsb:</dt>
<dd>
<t>designates the LSB to be considered for the compressed SPI. This parameter is defined by this specification and can take the following values 0, 1, 2, 4 respectively meaning that the compressed SPI will consist of the esp_spi_lsb LSB bytes of the original SPI.
A value of 4 for esp_spi_lsb will leave the SPI unchanged.</t>
</dd>
<dt>esp_sn:</dt>
<dd>
<t>designates the Sequence Number (SN) field defined in <xref target="RFC4301"/>.</t>
</dd>
<dt>esp_sn_lsb:</dt>
<dd>
<t>designates the LSB to be considered for the compressed SN and is defined by this specification. It works similarly to esp_spi_lsb.</t>
</dd>
</dl>
</section>
<section anchor="sec-cda"><name>New SCHC CDA</name>
<t>In addition to the Compression / Decompression Actions defined in <xref section="7.4" sectionFormat="comma" target="RFC8724"/>, this specification uses the CDA as presented in <xref target="tab-cda"/>.
These CDA are either a refinement of the compute- * CDA or the result of combined CDA.</t>
<figure title="EHCP ESP related parameter" anchor="tab-cda"><artwork align="center"><![CDATA[
+========================+=============+======================+
| Action | Compression | Decompression |
+========================+=============+======================+
| lower | elided | Get from lower layer |
| generated (Flow Label) | elided | Compute flow label |
| checksum | elided | Compute checksum |
| padding | elided | Compute padding |
+------------------------+-------------+----------------------+
]]></artwork></figure>
<dl>
<dt>lower:</dt>
<dd>
<t>is only used in a Tunnel mode and indicates that the fields of the inner IP packet header are generated from the corresponding fields of the Tunnel IP header fields. This CDA can be used for the DSCP, ECN, and IPv6 Flow Label (resp. IPv4 Identification) field. When the outer IP header is an IPv6 Header and the inner IP header is in IPv4 header the 16 LSB are copied. When the outer IP header is an IPv4 Header and the inner IP Header is an IPv6 Header, the 4 MSB bits are set to 0.</t>
</dd>
<dt>generated:</dt>
<dd>
<t>indicates that a brand new Flow Label/Identification field is generated following <xref target="RFC6437"/>, <xref target="RFC6864"/>.</t>
</dd>
<dt>checksum:</dt>
<dd>
<t>indicates that a checksum is computed accordingly. Typically, the checksum CDA has a different implementation for IPv4, UDP, TCP,...</t>
</dd>
<dt>padding:</dt>
<dd>
<t>indicates that padding bytes are generated accordingly.</t>
</dd>
</dl>
</section>
</section>
<section anchor="inner-ip-compression-iipc"><name>Inner IP Compression (IIPC)</name>
<t>When iipc_profile is set to "uncompress", the packet is uncompressed.
When iipc_profile is set to "diet-esp", IIPC proceeds to the compression of the inner IP Packet composed of an IP Header and an IP Payload.
The compression of the inner IP Payload is described in <xref target="sec-payload"/>.<br />
The IP Header is compressed when ipsec_mode is set to "Tunnel" and left uncompressed otherwise. ts_ip_version determines how the IPv6 Header (resp. the IPv4 Header) is compressed - see <xref target="sec-inner-ip6"/> (resp. <xref target="sec-inner-ip4"/>).</t>
<section anchor="sec-payload"><name>Inner IP Payload Compression</name>
<t>The compression only affects UDP, UDP-Lite, TCP or SCTP packets and the type of packet is determined by the IP header.</t>
<t>For UDP, UDP-Lite, TCP and SCTP packets, source ports destination ports and checksums are compressed.
For source port (resp. destination port) only the least significant bits are sent. FL is set to 16 bits, TV is set to msb( ts_port_src_start, ts_port_src_end ) ( resp. ts_port_dst_start, ts_port_dst_end ) ), MO is set to "MSB" and CDA to "LSB".
The checksum is elided, FL is set to 16 bits, TV is not set, MO is set to "ignore" and CDA is set to "checksum".
This may result in decompressing a zero-checksum UDP packet with a valid checksum, but this has no impact as a valid checksum is universally accepted.</t>
<t>For UDP or UDP-Lite the length field is elided. FL is set to 16, TV is not set, MO is set to "ignore".</t>
</section>
<section anchor="sec-inner-ip6"><name>Inner IPv6 Header Compression</name>
<t>The version field is elided, FL is set to 3, TV is set to ts_ipversion, MO is set to"equal" and CDA is set to "not-sent".</t>
<t>Traffic Class is composed of the 6 bit DSCP and 2 bit ECN and only the DSCP bits are subject to compression.
The compression of DSCP and ECN are defined independently.</t>
<t>DSCP values are compressed according to the dscp_cda value:
* If dscp_cda is set to "uncompress", the DSCP values are included in the inner IP header. FL is set to 6 bits, TV is not set, MO is set to "ignore", CDA is set to "sent-value".
* If dscp_cda is set to "lower", the DSCP field is elided and its value is copied from the Tunnel IP header. FL is set to 6 bits, TV is not set, MO is set to "ignore", CDA is set to "lower".
* If dscp_cda is set to "sa", DSCP is compressed according to the DSCP values of the SA. If dscp_list contains a single element, the DSCP is elided, FL is set to 6 bits, TV is set to dscp_list[0], MO is set to "equal" and CDA is set to "not-sent". If dscp_list contains more than one DSCP value, FL is set to 6 bits, TV is set to dscp_list, MO is set to "match-mapping" and the CDA is set to "mapping-sent".
For ECN, FL is set to 2 bits, TV is not set, MO is set to ignore and CDA is set to "value-sent".</t>
<t>ECN values are compressed according to the ecn_cda value:
* If ecn_cda is set to "uncompress", the ECN field included in the inner IP header. FL is set to 2 bits, TV is not set, MO is set to "ignore", CDA is set to "sent-value".
* If ecn_cda is set to "lower", the ECN value is elided and the ECN value is copied in the outer IP header. FL is set to 2 bits, TV is not set, MO is set to "ignore", CDA is set to "lower".</t>
<t>Flow label is compressed according to the flow_label_cda value:
* If flow_label_cda is set to "uncompress", the Flow label is included in the IPv6 Header. FL is set to 20 bits, TV is not set MO is set to "ignore" and CDA is set to "sent-value".
* If flow_label_cda is set to "lower", the Flow Label is elided and read from the outer IP Header (See <xref target="sec-cda"/>). FL is set to 20 bits, TV is not set, MO is set to "ignore" and CDA is set to "lower". If the outer IP header is an IPv4 Header, only the 16 LSB of the Flow Label are inserted into the IPv4 Header. At the decompression, the 4 MSB of the Flow Label are set to 0.
* If flow_label_cda is set to "generated", the Flow Label elided and the Flow Label is then re-generated at the decompression (See <xref target="sec-cda"/>). The resulting Flow Label is expected result in a different value. FL is set to 20, TV is not set, MO is set to "ignore" and CDA is set to "generated".
* If flow_label_cda is set to "zero", the Flow Label is elided and set to 0 at decompression. A 0 value indicates no flow label is present. Fl is set to 20 bits, TV is set to 0, MO is set to "equal" and CDA is set to "not-sent".</t>
<t>Payload Length is elided and determined from the Tunnel IP Header Payload Length as well as the decompressed Payload. FL is set to 16 bits, TV is not set, MO is set to "ignore", CDA is set to "lower".</t>
<t>NOTE TO COAUTHORS: I DO NOT THINK WE CAN COMPRESS THE LAST NEXT HEADER AS WE ONLY KNOW IT IS THE LAST ONCE WE HAVE READ IT. TO DETERMINE THAT THIS IS THE LAST WE NEED TO MAKE SOME ASSUMPTIONS THAT THERE ARE NO IPV6 EXTENSION HEADER. I AM NOT SURE WE CAN MAKE SUCH ASSUMPTION AS THIS IS NOT SOMETHING AGREED BETWEEN THE TWO PEERS. IF THAT IS CORRECT, THE SECTION BELOW NEEDS TO BE REMOVED.
The last Next Header determine the transport being used and for convenience we refer it as the Transport Next Header.
* If the ts_proto contains a single non-zero value specified by the SA, ts_proto, is elided and decompressed according to the SA. FL is set to 8, TV is set to that value, MO is set to "equal," and CDA is set to "not-sent."
* If ts_proto is a list of non zero values, values are ordered in increasing order to form proto_list. Next Header is then replaced by the corresponding index of the list. FL is set to 8 bits, TV is set to the proto_list, MO is set to "match-mapping," and CDA is set to "mapping-sent".
* If ts_proto is the single value 0, Next Header is not compressed. FL is set to 8 bits, TV is not set, MO is set to "ignore", CDA is set to "sent-value".
* If ts_proto is a list non zero values are ordered in increasing number, 0 ("OTHER") is appended. Next Header is then replaced by the corresponding index except for the "OTHER" in which case, the complete Next Header is sent.</t>
<t>NOTE TO COAUTHORS: I AM NOT SURE WE CAN USE STANDARD RULES TO IMPLEMENT THE LIST WITH 0. wE HAVE TWO ALTERNATIVES. EITHER WE ASSUME THAT THERE IS NO COMPRESSION WHEN A ZERO IS THERE OR WE CREATE A NEW CDA.</t>
<t>This profiles considers a list of values "TCP", "UDP", "UDP-Lite", "SCTP", "OTHER".</t>
<t>The IPv6 Hop Limit is read from the Tunnel IP Header Hop Limit. FL is set to 8 bits, TV is not set, MO is set to "ignore" and CDA is set to "lower."</t>
<t>NOTE TO COAUTHORS: WE MAY NEED TO DEFINE A hop_limit_cda FOR CONSISTENCY.</t>
<t>The source and destination IPv6 addresses are compressed using MSB.
In both cases, FL is set to 128, TV is respectively set to msb(ts_ip_src_start, ts_ip_src_ed) or msb(ts_ip_dst_start, ts_ip_dst_end)), the MO is set to "MSB," and the CDA is set to "LSB."</t>
</section>
<section anchor="sec-inner-ip4"><name>Inner IPv4 Compression</name>
<t>The fields Version, DSCP, ECN, Source Address and Destination Address are compressed as described for IPv6 in <xref target="sec-inner-ip6"/>.
The field Total Length (16 bits) is compressed similarly to the IPv6 field Payload Length. The field Identification (16 bits) is compressed similarly to the IPv6 field Flow Label. If the IP Header is an IPv6 Header, the Identification are placed as the LSB of the IPv6 Header and the 4 remaining MSB are set to 0. The field Time to Live is compressed similarly to the IPv6 Hop Limit field. The Protocol field is compressed similarly to the last IPv6 Next Header field.</t>
<t>IHL is uncompressed, FL is set to 4 bits, TV is not set, MO is set to ignore and CDA is set to "value-sent".</t>
<t>The IPv4 Header checksum is elided.
FL is set to 16, TV is omitted, MO is set to "ignore," and CDA is set to "checksum."</t>
</section>
</section>
<section anchor="clear-text-esp-compression-ctec"><name>Clear Text ESP Compression (CTEC)</name>
<t>The Clear Text ESP Compression is performed on the ESP fields not yet encrypted, that is the ESP Payload Data, the ESP padding field, the Pad Length field as well as the Next Header field, which indicates the type of the inner packet.</t>
<t>NOTE TO COAUTHORS: THE TWO FOLLOWING PARAGRAPHS NEED TO BE REMOVED, UNLESS WE CAN COMPRESS THE NEXT HEADER TRANSPORT.</t>
<t>When ipsec_mode is set to "Transport" and the ts_ip_version is set to 4, the Next Header in the ESP necessarily contains the Protocol ID and the Next Header can be compressed as described in sec-nh.</t>
<t>When ipsec_mode is set to "Transport" and the ts_ip_version is set to 6, the Next Header does not necessarily designates the Protocol ID, but instead it may contain an IPv6 Header extension. As result, the Next Header cannot be compressed.</t>
<t>When ipsec_mode is set to "Tunnel", the Next Header Field indicates whether the inner packet is an IPv6 or IPv4 packet.</t>
<t>END OF REMOVED PARAGRAPH</t>
<t>NOTE TO COAUTHORS: AS WE ASSUMES THAT WE HAVE A SINGLE TYPE IP ADDRESS WE CAN REMOVE THE FOLLOWING PARAGRAPH.</t>
<t>If ts_ip_version is set 0, the Next Header uses a map and FL is set to 8 bits, TV is set to the list [ "IPv4", "IPv6"], MO is set to "match-mapping" and CDA is set to "mapping-sent".
If ts_ip_version is set to IPv4 or IPv6, the Next Header is elided, FL is set to 8 bits, TV is set to ts_ip_version, MO is set to "equal" and CDA is set to "not-sent".</t>
<t>END OF PARAGRAPH TO BE REMOVED.</t>
<t>NOTE TO COAUTHORS: IN THE TUNNEL MODE, WE ONLY CONSIDER ip PACKETS SO THE INNER DATA END SUP IN:</t>
<t>BITS( PAYLOAD DATA ) + BITS(PADDING FOR ALIGNMENT)</t>
<t>IN SCHC, WE USUALLY DETERMINE PAYLOAD DATA AND IGNORE THE REMAINDER. I AM NOT SURE THIS IS SOMETHING WE CAN DO HERE AS WE HAVE NO WAYS TO DETERMINE THE END OF THE PAYLOAD DATA FROM READING THE PAYLOAD DATA (LENGTH HAVE BEEN REMOVED). I AM UNDER THE IMPRESSION THAT WE MUST IMPLEMENT A BIT_PADDING AT THE END THAT IS COMPOSED OF PADDING_BITS AND A PAD_LEN FIELD. WHEN ALIGNMENT IS 8 BITS, PAD_LEN FOLLOWS THE FOLLOWING RULES:</t>
<t>ALIGNMENT PAD_LEN<br />
8 BITS 3 BITS
16 BITS 4 BITS
32 BITS 5 BITS
64 BITS 6 BITS</t>
<t>If the esp_encr does not require a specific block size, Padding and Pad Length are elided.
FL is defined by the type that is to (Pad Length + 1 ) * 8 bits, TV is unset, MO is set to "ignore" and CDA is set to padding.</t>
<t>Encryption may require require the clear text to respect a given size block.
In addition, IP networking may also require a special alignment which is 32 bits by default for IPv6 Extensions, but may also be overwritten by the EHC Context.
The Padding is defined by pad_value and pad_size appended to the clear text payload - similarly to what ESP does with Padding and Pad Len.
An 8 (resp. 16, 32 or 64) bit alignment is interpreted by SCHC as a Word of 8 (resp. 16, 32 or 64) bits.
The padding size pad_size is defined by the alignment and set to 3 bits for an 8 bit alignment (23) and 5 bits for 32 bit alignment (2**5).
If pad designates the number of bits to be padded, the pad value is set to pad_value = ( pad + len( pad_size ) % Word.
This results in an additional pad_value + pad_size bits.</t>
</section>
<section anchor="encrypted-esp-compression-eec"><name>Encrypted ESP Compression (EEC)</name>
<t>SPI is compressed to its LSB.
FL is set to 32 bits, TV is not set, MO is set to "MSB( 4 - esp_spi_lsb)" and CDA is set to "LSB".</t>
<t>If the esp_encr considers implicit IV <xref target="RFC8750"/>, Sequence Numbers are not compressed. Otherwise, SN are compressed to their LSB similarly to the SPI.
FL is set to 32 bits, TV is not set, MO is set to "MSB( 4 - esp_spi_lsb)" and CDA is set to "LSB".</t>
<t>Note that the use of implicit IV always result in a better compression as a 64 bit IV to be sent while compression of the SN alone results at best in a reduction of 32 bits.</t>
<t>The IPv6 Next Header field or the IPv4 Protocol that contains the "ESP" value is changed to "SCHC".</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>We request the IANA to create a new registry for the IIPC Profile</t>
<figure><artwork><![CDATA[
| IIPC Profile value | Reference |
+--------------------+-----------+
| "uncompress" | ThisRFC |
| "diet-esp" | ThisRFC |
]]></artwork></figure>
<t>We request IANA to create the following registried for the "diet-esp" IIPC Profile.</t>
<figure><artwork><![CDATA[
| Flow Label CDA Value | Reference |
+----------------------+-----------+
| "uncompress" | ThisRFC |
| "generated" | ThisRFC |
]]></artwork></figure>
<figure><artwork><![CDATA[
| DSCP CDA Value | Reference |
+----------------------+-----------+
| "uncompress" | ThisRFC |
| "lower" | ThisRFC |
]]></artwork></figure>
<figure><artwork><![CDATA[
| DSCP CDA Value | Reference |
+----------------------+-----------+
| "uncompress" | ThisRFC |
| "lower" | ThisRFC |
]]></artwork></figure>
<figure><artwork><![CDATA[
| TS IP Version Value | Reference |
+----------------------+-----------+
| "IPv4-only" | ThisRFC |
| "IPv6-only" | ThisRFC |
]]></artwork></figure>
<figure><artwork><![CDATA[
| Alignment | Reference |
+----------------------+-----------+
| "8 bit" | ThisRFC |
| "16 bit" | ThisRFC |
| "32 bit" | ThisRFC |
| "64 bit" | ThisRFC |
]]></artwork></figure>
<figure><artwork><![CDATA[
| IPsec mode Value | Reference |
+----------------------+-----------+
| "Tunnel" | ThisRFC |
| "Transport" | ThisRFC |
]]></artwork></figure>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>There is no specific considerations associated with the profile other than the security considerations of ESP <xref target="RFC4303"/> and those of SCHC <xref target="RFC8724"/>.</t>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>We would like to thank Laurent Toutain for its guidance on SCHC. Robert Moskowitz for inspiring the name "Diet-ESP" from Diet-HIP.</t>
</section>
</middle>
<back>
<references title='Normative References' anchor="sec-normative-references">
&RFC2119;
&RFC8174;
&RFC4303;
&RFC4301;
&RFC8724;
&RFC8376;
&RFC7296;
&I-D.mglt-ipsecme-ikev2-diet-esp-extension;
&RFC5996;
&I-D.mglt-ipsecme-dscp-np;
&RFC8750;
&RFC6437;
&RFC6864;
</references>
<references title='Informative References' anchor="sec-informative-references">
&RFC9333;
&RFC4309;
</references>
<?line 587?>
<section anchor="illustrative-example"><name>Illustrative Example</name>
<section anchor="sec-iot-udp"><name>Single UDP Session IoT VPN</name>
<t>This section considers a IoT IPv6 probe hosting a UDP application.
The probe is dedicated to a single application and establishes a single UDP session with a server, and sets a VPN to connect its secure domain - like a home gateway.
The home gateway will be responsible to decompress the compress packet and provides interoperability with standard application server.</t>
<t>The EHC Context is defined as mentioned below:</t>
<t><list style="symbols">
<t>alignment is set to 8 bits</t>
<t>ipsec_mode is set to "Tunnel"</t>
<t>tunnel_ip_srct is set to the IPv6_m, the IPv6 address of the mote.</t>
<t>tunnel_ip_dst is set to IPv6_gw, the IPv6 of the security gateway.</t>
<t>esp_spi is agreed by the IKEv2.</t>
<t>esp_spi_lsb is set to 0 as IPv6_m provides sufficient context to associate the right SA.</t>
<t>esp_sn results from the standard IPsec, and not impacted.</t>
<t>esp_sn_lsb is set to 2 even though we are considering AES-CCM_8_IIV <xref target="RFC8750"/> which uses the ESP Sequence Number to generated the IV.
This results in a 8 bytes reduction compared to the AES-CCM_8 <xref target="RFC4309"/>.</t>
<t>esp_encr is configured with AES-CCM_8_IIV <xref target="RFC8750"/>. This cipher suite does not require a block size and so no padding is required and does not support SN compression.</t>
<t>flow_label As the inner traffic and the encrypted traffic are very correlated, it makes sense to re-use the flow label and flow_label is set to True.</t>
<t>ts_ip_version is set to IPv6.</t>
<t>ts_ip_src_start is set to IPv6_m. In this example, the SA is associated to messages sent by the mote to the application server (IPv6_server)</t>
<t>ts_ip_src_end is set to IPv6_m</t>
<t>ts_ip_dst_end the IPv6 address of the application server (IPv6_server).</t>
<t>ts_ip_dst_end IPv6_server</t>
<t>ts_proto [ UDP ], in the case of a very constraint mote, only UDP messages are considered.</t>
<t>ts_port_src_start port_m. The mote and the application server are using dedicated ports.</t>
<t>ts_port_src_end port_m. The mote and the application server are using dedicated ports. The use of a specific single port enables their elision.</t>
<t>ts_port_dst_end port_server</t>
<t>ts_port_dst_end port_server</t>
<t>ts_dsp_list [ 0 ] the default standard value, we MAY assume that value has been negotiated via IKEv2 or that it as been set as the default value left to the lower layers.</t>
</list></t>
<t><xref target="fig-std-udp-tunnel"/> illustrates an UDP packet being protected by ESP in the tunnel mode using AES-CCM_8_IIV.
This packet is compressed as depicted in <xref target="fig-comp-udp-tunnel"/>.<br />
EHC reduces the packet size by 53 bytes.</t>
<figure title="Standard ESP packet for IoT UDP in Tunnel mode more with AES-CCM_8_IIV" anchor="fig-std-udp-tunnel"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
U| source port | dest port |d t
D+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| length | checksum || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
-| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |v v
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<figure title="EHC ESP packet for IoT UDP in Tunnel mode more with AES-CCM_8_IIV" anchor="fig-comp-udp-tunnel"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--
| Sequence Number | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | aut
| | hen
~ APPLICATION DATA ~ tic
| (encrypted) | ate
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | V
+-+-+-+-+-+-+-+-+ |--
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</section>
<section anchor="single-tcp-session-iot-vpn"><name>Single TCP session IoT VPN</name>
<t>This section is very similar to <xref target="sec-iot-udp"/> except that a TCP session is used instead.</t>
<t>The compression on the TCP payload is very limited, and in a case where the TCP end point is the same as the ESP end point additionnal compression could be performed.
Additional fields such as TCP options, urgent pointers, the SN and ACK Number could be compressed by a specific profile agreed at the TCP level as opposed to the ESP level.</t>
<t>The ESP encapsulated TCP packet described in <xref target="fig-std-tcp-tunnel"/> is compressed by EHCP using th esam eEHCP context as in <xref target="sec-iot-udp"/> and EHCP reduces that packet by 55 bytes, as depicted in <xref target="fig-comp-udp-tunnel"/>.</t>
<figure title="Standard ESP packet for IoT TCP in Tunnel mode more with AES-CCM_8_IIV" anchor="fig-std-tcp-tunnel"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
T| source port | dest port |d t
C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| Sequence Number (SN) || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| ACK Sequence Number || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
|Off. | Rserv | Flags | Window Size || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| Checksum | Urgent Pointer || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |V V
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<figure title="EHC ESP packet for IoT TCP in Tunnel mode more with AES-CCM_8_IIV" anchor="fig-comp-tcp-tunnel"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| Sequence Number (SN) (ESP) | Sequence Number ~ ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
~ (SN) (TCP) | ACK ~^ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| a
~ Sequence Number |Off. | Rserv | Flags || u
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e t
| Window Size | Urgent Pointer |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c |
| Urgent Pointer | |r |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |y |
| ~p |
~ APPLICATION DATA |t |
| || |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| | |v v
+-+-+-+-+-+-+-+-+ |---
| Integrity Check Value-ICV (variable) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</section>
<section anchor="traditional-vpn"><name>Traditional VPN</name>
<t>This section illustrates the case of an company VPN that allows web browsing.
The VPN is typically set by a remote host that forwards all its traffic to the
security gateway.<br />
In this case, the SA does not specify the protocol (TCP and UDP packet can be sent), nor the ports.
Regarding ports it could be possible to restrict the user to only use high range ports (0 - 2 ** 10) - especially if the VPN is only supporting web browsing - but we did not consider this in this example.
The destination IP address is also expect to take any value, while the IPv6 source in the case of a road warrior scenarios us expected to take a single value.
We consider the VPN client is using an IPv4 or an IPv6 address.
Regarding ESP, we considered the VPN client is using AES-GCM_16, though AES-GCM_IIV would be the RECOMMENDED transform.
The VPN client is also expected to have a reasonably low throughput which enables the SN to be coded over 16 bits as opposed to 32 bits.
Similarly, the number of connection is expected to remain sufficiently low so that a 16 bit SPI remains sufficient.</t>
<t>The EHC Context is defined as mentioned below:</t>
<t><list style="symbols">
<t>alignment is set to 8 bits</t>
<t>ipsec_mode is set to "Tunnel"</t>
<t>tunnel_ip_src is set to the IPv6_user, the IPv6 address of the mote.</t>
<t>tunnel_ip_dst is set to IPv6_gw, the IPv6 of the security gateway.</t>
<t>esp_spi: is agreed by the IKEv2.</t>
<t>esp_spi_lsb: is set to 2 bytes.</t>
<t>esp_sn: results from the standard IPsec, and not impacted.</t>
<t>esp_sn_lsb: is set to 16 bits. Note that such compression is possible since AES-GCM_16 is used instead of AES-GCM_16_IIV.
While this results in better performances for EHC, it is not an optimal choice as IIV transforms results always in better comprehensions.</t>
<t>esp_encr: is configured with AES-GCM_16 <xref target="RFC8750"/>.</t>
<t>flow_label: is set to True, note as the outer IP address is IPv6, the compression is lossless.</t>
<t>ts_ip_version: is set not set as the VPN user can use either an IPv4 or an IPv6 address.</t>
<t>ts_ip_src_start: is set to IPv6_user or IPv4_user. Note that the version can be inferred by the Next Header, and the version can deterministically determine the IP in use.</t>
<t>ts_ip_src_end: is set to IPv6_user or IPv4_user</t>
<t>ts_ip_dst_end: IP destination is set to take any value, so the range is unspecified and the start/ end addresses are undefined.</t>
<t>ts_ip_dst_end: undefined.</t>
<t>ts_proto: undefined</t>
<t>ts_port_src_start: undefined.</t>
<t>ts_port_src_end: undefined.</t>
<t>ts_port_dst_end: undefined</t>
<t>ts_port_dst_end: undefined</t>
<t>ts_dsp_list: [ 0 ] the default standard value, we MAY assume that value has been negotiated via IKEv2 or that it as been set as the default value left to the lower layers.</t>
</list></t>
</section>
<section anchor="ipv6-in-ipv6"><name>IPv6 in IPv6</name>
<t><xref target="fig-std-vpn-tunnel-66"/> represents the original ESP TCP packet with IPv6 inner IP addresses and <xref target="fig-comp-vpn-tunnel-66"/> represents the corresponding packet compressed with EHC.</t>
<t>The compression with Diet-ESP results in a reduction of 32 bytes.</t>
<figure title="Standard ESP packet for VPN traffic mode with AES-GCM_16" anchor="fig-std-vpn-tunnel-66"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
E| Security Parameters Index (SPI) | ^
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
P| Sequence Number (SN) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| IV | |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
I|version| traffic class | flow label |^ |
P+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
v| payload length | next header | hop limit || |
6+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || a
| inner source IP || u
| |e t
| |n h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+c e
| |r n
| inner destination IP |y t
| |p i
| |t c
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+e a
T| source port | dest port |d t
C+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| e
P| Sequence Number (SN) || d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| ACK Sequence Number || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
|Off. | Rserv | Flags | Window Size || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| Checksum | Urgent Pointer || |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
| || |
~ APPLICATION DATA ~| |
| || |
-| +-+-+-+-+-+-+-+-+| |
E| | Padding || |
S+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |
P| Padding (continue) | Pad Length | Next Header |V V
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| |
| Integrity Check Value-ICV (variable) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<figure title="Compressed IPv6 in IPv6 ESP packet for VPN traffic mode with AES-GCM_16" anchor="fig-comp-vpn-tunnel-66"><artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| SPI | SN | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
| IV | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--|
| Next Header | |^ |
+-+-+-+-+-+-+-+-+ || |
| || |
| inner destination IP || |
| || |a
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |u
| | source port | destination ~|e|t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|n|h
~ port | TCP Sequence Number (SN) ~|c|e