aboutsummaryrefslogtreecommitdiffstats
path: root/doc/standards/rfc4301.txt
blob: 4a8eba9756bd2bbd5fd88bb4b8b8c7f1d4e3087d (plain)
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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659






Network Working Group                                            S. Kent
Request for Comments: 4301                                        K. Seo
Obsoletes: 2401                                         BBN Technologies
Category: Standards Track                                  December 2005


            Security Architecture for the Internet Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes an updated version of the "Security
   Architecture for IP", which is designed to provide security services
   for traffic at the IP layer.  This document obsoletes RFC 2401
   (November 1998).

Dedication

   This document is dedicated to the memory of Charlie Lynn, a long-time
   senior colleague at BBN, who made very significant contributions to
   the IPsec documents.



















Kent & Seo                  Standards Track                     [Page 1]

RFC 4301              Security Architecture for IP         December 2005


Table of Contents

   1. Introduction ....................................................4
      1.1. Summary of Contents of Document ............................4
      1.2. Audience ...................................................4
      1.3. Related Documents ..........................................5
   2. Design Objectives ...............................................5
      2.1. Goals/Objectives/Requirements/Problem Description ..........5
      2.2. Caveats and Assumptions ....................................6
   3. System Overview .................................................7
      3.1. What IPsec Does ............................................7
      3.2. How IPsec Works ............................................9
      3.3. Where IPsec Can Be Implemented ............................10
   4. Security Associations ..........................................11
      4.1. Definition and Scope ......................................12
      4.2. SA Functionality ..........................................16
      4.3. Combining SAs .............................................17
      4.4. Major IPsec Databases .....................................18
           4.4.1. The Security Policy Database (SPD) .................19
                  4.4.1.1. Selectors .................................26
                  4.4.1.2. Structure of an SPD Entry .................30
                  4.4.1.3. More Regarding Fields Associated
                           with Next Layer Protocols .................32
           4.4.2. Security Association Database (SAD) ................34
                  4.4.2.1. Data Items in the SAD .....................36
                  4.4.2.2. Relationship between SPD, PFP
                           flag, packet, and SAD .....................38
           4.4.3. Peer Authorization Database (PAD) ..................43
                  4.4.3.1. PAD Entry IDs and Matching Rules ..........44
                  4.4.3.2. IKE Peer Authentication Data ..............45
                  4.4.3.3. Child SA Authorization Data ...............46
                  4.4.3.4. How the PAD Is Used .......................46
      4.5. SA and Key Management .....................................47
           4.5.1. Manual Techniques ..................................48
           4.5.2. Automated SA and Key Management ....................48
           4.5.3. Locating a Security Gateway ........................49
      4.6. SAs and Multicast .........................................50
   5. IP Traffic Processing ..........................................50
      5.1. Outbound IP Traffic Processing
           (protected-to-unprotected) ................................52
           5.1.1. Handling an Outbound Packet That Must Be
                  Discarded ..........................................54
           5.1.2. Header Construction for Tunnel Mode ................55
                  5.1.2.1. IPv4: Header Construction for
                           Tunnel Mode ...............................57
                  5.1.2.2. IPv6: Header Construction for
                           Tunnel Mode ...............................59
      5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59



Kent & Seo                  Standards Track                     [Page 2]

RFC 4301              Security Architecture for IP         December 2005


   6. ICMP Processing ................................................63
      6.1. Processing ICMP Error Messages Directed to an
           IPsec Implementation ......................................63
           6.1.1. ICMP Error Messages Received on the
                  Unprotected Side of the Boundary ...................63
           6.1.2. ICMP Error Messages Received on the
                  Protected Side of the Boundary .....................64
      6.2. Processing Protected, Transit ICMP Error Messages .........64
   7. Handling Fragments (on the protected side of the IPsec
      boundary) ......................................................66
      7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
           Fragments .................................................67
      7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
      7.3. Stateful Fragment Checking ................................68
      7.4. BYPASS/DISCARD Traffic ....................................69
   8. Path MTU/DF Processing .........................................69
      8.1. DF Bit ....................................................69
      8.2. Path MTU (PMTU) Discovery .................................70
           8.2.1. Propagation of PMTU ................................70
           8.2.2. PMTU Aging .........................................71
   9. Auditing .......................................................71
   10. Conformance Requirements ......................................71
   11. Security Considerations .......................................72
   12. IANA Considerations ...........................................72
   13. Differences from RFC 2401 .....................................72
   14. Acknowledgements ..............................................75
   Appendix A: Glossary ..............................................76
   Appendix B: Decorrelation .........................................79
      B.1. Decorrelation Algorithm ...................................79
   Appendix C: ASN.1 for an SPD Entry ................................82
   Appendix D: Fragment Handling Rationale ...........................88
      D.1. Transport Mode and Fragments ..............................88
      D.2. Tunnel Mode and Fragments .................................89
      D.3. The Problem of Non-Initial Fragments ......................90
      D.4. BYPASS/DISCARD Traffic ....................................93
      D.5. Just say no to ports? .....................................94
      D.6. Other Suggested Solutions..................................94
      D.7. Consistency................................................95
      D.8. Conclusions................................................95
   Appendix E: Example of Supporting Nested SAs via SPD and
               Forwarding Table Entries...............................96
   References.........................................................98
      Normative References............................................98
      Informative References..........................................99







Kent & Seo                  Standards Track                     [Page 3]

RFC 4301              Security Architecture for IP         December 2005


1.  Introduction

1.1.  Summary of Contents of Document

   This document specifies the base architecture for IPsec-compliant
   systems.  It describes how to provide a set of security services for
   traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98]
   environments.  This document describes the requirements for systems
   that implement IPsec, the fundamental elements of such systems, and
   how the elements fit together and fit into the IP environment.  It
   also describes the security services offered by the IPsec protocols,
   and how these services can be employed in the IP environment.  This
   document does not address all aspects of the IPsec architecture.
   Other documents address additional architectural details in
   specialized environments, e.g., use of IPsec in Network Address
   Translation (NAT) environments and more comprehensive support for IP
   multicast.  The fundamental components of the IPsec security
   architecture are discussed in terms of their underlying, required
   functionality.  Additional RFCs (see Section 1.3 for pointers to
   other documents) define the protocols in (a), (c), and (d).

        a. Security Protocols -- Authentication Header (AH) and
           Encapsulating Security Payload (ESP)
        b. Security Associations -- what they are and how they work,
           how they are managed, associated processing
        c. Key Management -- manual and automated (The Internet Key
           Exchange (IKE))
        d. Cryptographic algorithms for authentication and encryption

   This document is not a Security Architecture for the Internet; it
   addresses security only at the IP layer, provided through the use of
   a combination of cryptographic and protocol security mechanisms.

   The spelling "IPsec" is preferred and used throughout this and all
   related IPsec standards.  All other capitalizations of IPsec (e.g.,
   IPSEC, IPSec, ipsec) are deprecated.  However, any capitalization of
   the sequence of letters "IPsec" should be understood to refer to the
   IPsec protocols.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [Bra97].

1.2.  Audience

   The target audience for this document is primarily individuals who
   implement this IP security technology or who architect systems that
   will use this technology.  Technically adept users of this technology



Kent & Seo                  Standards Track                     [Page 4]

RFC 4301              Security Architecture for IP         December 2005


   (end users or system administrators) also are part of the target
   audience.  A glossary is provided in Appendix A to help fill in gaps
   in background/vocabulary.  This document assumes that the reader is
   familiar with the Internet Protocol (IP), related networking
   technology, and general information system security terms and
   concepts.

1.3.  Related Documents

   As mentioned above, other documents provide detailed definitions of
   some of the components of IPsec and of their interrelationship.  They
   include RFCs on the following topics:

        a. security protocols -- RFCs describing the Authentication
           Header (AH) [Ken05b] and Encapsulating Security Payload
           (ESP) [Ken05a] protocols.
        b. cryptographic algorithms for integrity and encryption -- one
           RFC that defines the mandatory, default algorithms for use
           with AH and ESP [Eas05], a similar RFC that defines the
           mandatory algorithms for use with IKEv2 [Sch05] plus a
           separate RFC for each cryptographic algorithm.
        c. automatic key management -- RFCs on "The Internet Key
           Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic
           Algorithms for Use in the Internet Key Exchange Version 2
           (IKEv2)" [Sch05].

2.  Design Objectives

2.1.  Goals/Objectives/Requirements/Problem Description

   IPsec is designed to provide interoperable, high quality,
   cryptographically-based security for IPv4 and IPv6.  The set of
   security services offered includes access control, connectionless
   integrity, data origin authentication, detection and rejection of
   replays (a form of partial sequence integrity), confidentiality (via
   encryption), and limited traffic flow confidentiality.  These
   services are provided at the IP layer, offering protection in a
   standard fashion for all protocols that may be carried over IP
   (including IP itself).

   IPsec includes a specification for minimal firewall functionality,
   since that is an essential aspect of access control at the IP layer.
   Implementations are free to provide more sophisticated firewall
   mechanisms, and to implement the IPsec-mandated functionality using
   those more sophisticated mechanisms. (Note that interoperability may
   suffer if additional firewall constraints on traffic flows are
   imposed by an IPsec implementation but cannot be negotiated based on
   the traffic selector features defined in this document and negotiated



Kent & Seo                  Standards Track                     [Page 5]

RFC 4301              Security Architecture for IP         December 2005


   via IKEv2.)  The IPsec firewall function makes use of the
   cryptographically-enforced authentication and integrity provided for
   all IPsec traffic to offer better access control than could be
   obtained through use of a firewall (one not privy to IPsec internal
   parameters) plus separate cryptographic protection.

   Most of the security services are provided through use of two traffic
   security protocols, the Authentication Header (AH) and the
   Encapsulating Security Payload (ESP), and through the use of
   cryptographic key management procedures and protocols.  The set of
   IPsec protocols employed in a context, and the ways in which they are
   employed, will be determined by the users/administrators in that
   context.  It is the goal of the IPsec architecture to ensure that
   compliant implementations include the services and management
   interfaces needed to meet the security requirements of a broad user
   population.

   When IPsec is correctly implemented and deployed, it ought not
   adversely affect users, hosts, and other Internet components that do
   not employ IPsec for traffic protection.  IPsec security protocols
   (AH and ESP, and to a lesser extent, IKE) are designed to be
   cryptographic algorithm independent.  This modularity permits
   selection of different sets of cryptographic algorithms as
   appropriate, without affecting the other parts of the implementation.
   For example, different user communities may select different sets of
   cryptographic algorithms (creating cryptographically-enforced
   cliques) if required.

   To facilitate interoperability in the global Internet, a set of
   default cryptographic algorithms for use with AH and ESP is specified
   in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2
   is specified in [Sch05].  [Eas05] and [Sch05] will be periodically
   updated to keep pace with computational and cryptologic advances.  By
   specifying these algorithms in documents that are separate from the
   AH, ESP, and IKEv2 specifications, these algorithms can be updated or
   replaced without affecting the standardization progress of the rest
   of the IPsec document suite.  The use of these cryptographic
   algorithms, in conjunction with IPsec traffic protection and key
   management protocols, is intended to permit system and application
   developers to deploy high quality, Internet-layer, cryptographic
   security technology.

2.2.  Caveats and Assumptions

   The suite of IPsec protocols and associated default cryptographic
   algorithms are designed to provide high quality security for Internet
   traffic.  However, the security offered by use of these protocols
   ultimately depends on the quality of their implementation, which is



Kent & Seo                  Standards Track                     [Page 6]

RFC 4301              Security Architecture for IP         December 2005


   outside the scope of this set of standards.  Moreover, the security
   of a computer system or network is a function of many factors,
   including personnel, physical, procedural, compromising emanations,
   and computer security practices.  Thus, IPsec is only one part of an
   overall system security architecture.

   Finally, the security afforded by the use of IPsec is critically
   dependent on many aspects of the operating environment in which the
   IPsec implementation executes.  For example, defects in OS security,
   poor quality of random number sources, sloppy system management
   protocols and practices, etc., can all degrade the security provided
   by IPsec.  As above, none of these environmental attributes are
   within the scope of this or other IPsec standards.

3.  System Overview

   This section provides a high level description of how IPsec works,
   the components of the system, and how they fit together to provide
   the security services noted above.  The goal of this description is
   to enable the reader to "picture" the overall process/system, see how
   it fits into the IP environment, and to provide context for later
   sections of this document, which describe each of the components in
   more detail.

   An IPsec implementation operates in a host, as a security gateway
   (SG), or as an independent device, affording protection to IP
   traffic. (A security gateway is an intermediate system implementing
   IPsec, e.g., a firewall or router that has been IPsec-enabled.) More
   detail on these classes of implementations is provided later, in
   Section 3.3. The protection offered by IPsec is based on requirements
   defined by a Security Policy Database (SPD) established and
   maintained by a user or system administrator, or by an application
   operating within constraints established by either of the above.  In
   general, packets are selected for one of three processing actions
   based on IP and next layer header information ("Selectors", Section
   4.4.1.1) matched against entries in the SPD.  Each packet is either
   PROTECTed using IPsec security services, DISCARDed, or allowed to
   BYPASS IPsec protection, based on the applicable SPD policies
   identified by the Selectors.

3.1.  What IPsec Does

   IPsec creates a boundary between unprotected and protected
   interfaces, for a host or a network (see Figure 1 below).  Traffic
   traversing the boundary is subject to the access controls specified
   by the user or administrator responsible for the IPsec configuration.
   These controls indicate whether packets cross the boundary unimpeded,
   are afforded security services via AH or ESP, or are discarded.



Kent & Seo                  Standards Track                     [Page 7]

RFC 4301              Security Architecture for IP         December 2005


   IPsec security services are offered at the IP layer through selection
   of appropriate security protocols, cryptographic algorithms, and
   cryptographic keys.  IPsec can be used to protect one or more "paths"
   (a) between a pair of hosts, (b) between a pair of security gateways,
   or (c) between a security gateway and a host.  A compliant host
   implementation MUST support (a) and (c) and a compliant security
   gateway must support all three of these forms of connectivity, since
   under certain circumstances a security gateway acts as a host.

                        Unprotected
                         ^       ^
                         |       |
           +-------------|-------|-------+
           | +-------+   |       |       |
           | |Discard|<--|       V       |
           | +-------+   |B  +--------+  |
         ................|y..| AH/ESP |..... IPsec Boundary
           |   +---+     |p  +--------+  |
           |   |IKE|<----|a      ^       |
           |   +---+     |s      |       |
           | +-------+   |s      |       |
           | |Discard|<--|       |       |
           | +-------+   |       |       |
           +-------------|-------|-------+
                         |       |
                         V       V
                         Protected

            Figure 1.  Top Level IPsec Processing Model

   In this diagram, "unprotected" refers to an interface that might also
   be described as "black" or "ciphertext".  Here, "protected" refers to
   an interface that might also be described as "red" or "plaintext".
   The protected interface noted above may be internal, e.g., in a host
   implementation of IPsec, the protected interface may link to a socket
   layer interface presented by the OS.  In this document, the term
   "inbound" refers to traffic entering an IPsec implementation via the
   unprotected interface or emitted by the implementation on the
   unprotected side of the boundary and directed towards the protected
   interface.  The term "outbound" refers to traffic entering the
   implementation via the protected interface, or emitted by the
   implementation on the protected side of the boundary and directed
   toward the unprotected interface.  An IPsec implementation may
   support more than one interface on either or both sides of the
   boundary.






Kent & Seo                  Standards Track                     [Page 8]

RFC 4301              Security Architecture for IP         December 2005


   Note the facilities for discarding traffic on either side of the
   IPsec boundary, the BYPASS facility that allows traffic to transit
   the boundary without cryptographic protection, and the reference to
   IKE as a protected-side key and security management function.

   IPsec optionally supports negotiation of IP compression [SMPT01],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol
   layers.

3.2.  How IPsec Works

   IPsec uses two protocols to provide traffic security services --
   Authentication Header (AH) and Encapsulating Security Payload (ESP).
   Both protocols are described in detail in their respective RFCs
   [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
   support AH. (Support for AH has been downgraded to MAY because
   experience has shown that there are very few contexts in which ESP
   cannot provide the requisite security services.  Note that ESP can be
   used to provide only integrity, without confidentiality, making it
   comparable to AH in most contexts.)

    o The IP Authentication Header (AH) [Ken05b] offers integrity and
      data origin authentication, with optional (at the discretion of
      the receiver) anti-replay features.

    o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
      the same set of services, and also offers confidentiality.  Use of
      ESP to provide confidentiality without integrity is NOT
      RECOMMENDED.  When ESP is used with confidentiality enabled, there
      are provisions for limited traffic flow confidentiality, i.e.,
      provisions for concealing packet length, and for facilitating
      efficient generation and discard of dummy packets.  This
      capability is likely to be effective primarily in virtual private
      network (VPN) and overlay network contexts.

    o Both AH and ESP offer access control, enforced through the
      distribution of cryptographic keys and the management of traffic
      flows as dictated by the Security Policy Database (SPD, Section
      4.4.1).

   These protocols may be applied individually or in combination with
   each other to provide IPv4 and IPv6 security services.  However, most
   security requirements can be met through the use of ESP by itself.
   Each protocol supports two modes of use: transport mode and tunnel
   mode.  In transport mode, AH and ESP provide protection primarily for





Kent & Seo                  Standards Track                     [Page 9]

RFC 4301              Security Architecture for IP         December 2005


   next layer protocols; in tunnel mode, AH and ESP are applied to
   tunneled IP packets.  The differences between the two modes are
   discussed in Section 4.1.

   IPsec allows the user (or system administrator) to control the
   granularity at which a security service is offered.  For example, one
   can create a single encrypted tunnel to carry all the traffic between
   two security gateways, or a separate encrypted tunnel can be created
   for each TCP connection between each pair of hosts communicating
   across these gateways.  IPsec, through the SPD management paradigm,
   incorporates facilities for specifying:

    o which security protocol (AH or ESP) to employ, the mode (transport
      or tunnel), security service options, what cryptographic
      algorithms to use, and in what combinations to use the specified
      protocols and services, and

    o the granularity at which protection should be applied.

   Because most of the security services provided by IPsec require the
   use of cryptographic keys, IPsec relies on a separate set of
   mechanisms for putting these keys in place.  This document requires
   support for both manual and automated distribution of keys.  It
   specifies a specific public-key based approach (IKEv2 [Kau05]) for
   automated key management, but other automated key distribution
   techniques MAY be used.

   Note: This document mandates support for several features for which
   support is available in IKEv2 but not in IKEv1, e.g., negotiation of
   an SA representing ranges of local and remote ports or negotiation of
   multiple SAs with the same selectors.  Therefore, this document
   assumes use of IKEv2 or a key and security association management
   system with comparable features.

3.3.  Where IPsec Can Be Implemented

   There are many ways in which IPsec may be implemented in a host, or
   in conjunction with a router or firewall to create a security
   gateway, or as an independent security device.

   a. IPsec may be integrated into the native IP stack.  This requires
      access to the IP source code and is applicable to both hosts and
      security gateways, although native host implementations benefit
      the most from this strategy, as explained later (Section 4.4.1,
      paragraph 6; Section 4.4.1.1, last paragraph).






Kent & Seo                  Standards Track                    [Page 10]

RFC 4301              Security Architecture for IP         December 2005


   b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
      implemented "underneath" an existing implementation of an IP
      protocol stack, between the native IP and the local network
      drivers.  Source code access for the IP stack is not required in
      this context, making this implementation approach appropriate for
      use with legacy systems.  This approach, when it is adopted, is
      usually employed in hosts.

   c. The use of a dedicated, inline security protocol processor is a
      common design feature of systems used by the military, and of some
      commercial systems as well.  It is sometimes referred to as a
      "bump-in-the-wire" (BITW) implementation.  Such implementations
      may be designed to serve either a host or a gateway.  Usually, the
      BITW device is itself IP addressable.  When supporting a single
      host, it may be quite analogous to a BITS implementation, but in
      supporting a router or firewall, it must operate like a security
      gateway.

   This document often talks in terms of use of IPsec by a host or a
   security gateway, without regard to whether the implementation is
   native, BITS, or BITW.  When the distinctions among these
   implementation options are significant, the document makes reference
   to specific implementation approaches.

   A host implementation of IPsec may appear in devices that might not
   be viewed as "hosts".  For example, a router might employ IPsec to
   protect routing protocols (e.g., BGP) and management functions (e.g.,
   Telnet), without affecting subscriber traffic traversing the router.
   A security gateway might employ separate IPsec implementations to
   protect its management traffic and subscriber traffic.  The
   architecture described in this document is very flexible.  For
   example, a computer with a full-featured, compliant, native OS IPsec
   implementation should be capable of being configured to protect
   resident (host) applications and to provide security gateway
   protection for traffic traversing the computer.  Such configuration
   would make use of the forwarding tables and the SPD selection
   function described in Sections 5.1 and 5.2.

4.  Security Associations

   This section defines Security Association management requirements for
   all IPv6 implementations and for those IPv4 implementations that
   implement AH, ESP, or both AH and ESP.  The concept of a "Security
   Association" (SA) is fundamental to IPsec.  Both AH and ESP make use
   of SAs, and a major function of IKE is the establishment and
   maintenance of SAs.  All implementations of AH or ESP MUST support
   the concept of an SA as described below.  The remainder of this




Kent & Seo                  Standards Track                    [Page 11]

RFC 4301              Security Architecture for IP         December 2005


   section describes various aspects of SA management, defining required
   characteristics for SA policy management and SA management
   techniques.

4.1.  Definition and Scope

   An SA is a simplex "connection" that affords security services to the
   traffic carried by it.  Security services are afforded to an SA by
   the use of AH, or ESP, but not both.  If both AH and ESP protection
   are applied to a traffic stream, then two SAs must be created and
   coordinated to effect protection through iterated application of the
   security protocols.  To secure typical, bi-directional communication
   between two IPsec-enabled systems, a pair of SAs (one in each
   direction) is required.  IKE explicitly creates SA pairs in
   recognition of this common usage requirement.

   For an SA used to carry unicast traffic, the Security Parameters
   Index (SPI) by itself suffices to specify an SA.  (For information on
   the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
   Ken05a].)  However, as a local matter, an implementation may choose
   to use the SPI in conjunction with the IPsec protocol type (AH or
   ESP) for SA identification.  If an IPsec implementation supports
   multicast, then it MUST support multicast SAs using the algorithm
   below for mapping inbound IPsec datagrams to SAs.  Implementations
   that support only unicast traffic need not implement this de-
   multiplexing algorithm.

   In many secure multicast architectures, e.g., [RFC3740], a central
   Group Controller/Key Server unilaterally assigns the Group Security
   Association's (GSA's) SPI.  This SPI assignment is not negotiated or
   coordinated with the key management (e.g., IKE) subsystems that
   reside in the individual end systems that constitute the group.
   Consequently, it is possible that a GSA and a unicast SA can
   simultaneously use the same SPI.  A multicast-capable IPsec
   implementation MUST correctly de-multiplex inbound traffic even in
   the context of SPI collisions.

   Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
   whether the SA lookup makes use of the destination IP address, or the
   destination and source IP addresses, in addition to the SPI.  For
   multicast SAs, the protocol field is not employed for SA lookups.
   For each inbound, IPsec-protected packet, an implementation must
   conduct its search of the SAD such that it finds the entry that
   matches the "longest" SA identifier.  In this context, if two or more
   SAD entries match based on the SPI value, then the entry that also
   matches based on destination address, or destination and source
   address (as indicated in the SAD entry) is the "longest" match.  This
   implies a logical ordering of the SAD search as follows:



Kent & Seo                  Standards Track                    [Page 12]

RFC 4301              Security Architecture for IP         December 2005


      1. Search the SAD for a match on the combination of SPI,
         destination address, and source address.  If an SAD entry
         matches, then process the inbound packet with that
         matching SAD entry.  Otherwise, proceed to step 2.

      2. Search the SAD for a match on both SPI and destination address.
         If the SAD entry matches, then process the inbound packet
         with that matching SAD entry.  Otherwise, proceed to step 3.

      3. Search the SAD for a match on only SPI if the receiver has
         chosen to maintain a single SPI space for AH and ESP, and on
         both SPI and protocol, otherwise.  If an SAD entry matches,
         then process the inbound packet with that matching SAD entry.
         Otherwise, discard the packet and log an auditable event.

   In practice, an implementation may choose any method (or none at all)
   to accelerate this search, although its externally visible behavior
   MUST be functionally equivalent to having searched the SAD in the
   above order.  For example, a software-based implementation could
   index into a hash table by the SPI.  The SAD entries in each hash
   table bucket's linked list could be kept sorted to have those SAD
   entries with the longest SA identifiers first in that linked list.
   Those SAD entries having the shortest SA identifiers could be sorted
   so that they are the last entries in the linked list.  A
   hardware-based implementation may be able to effect the longest match
   search intrinsically, using commonly available Ternary
   Content-Addressable Memory (TCAM) features.

   The indication of whether source and destination address matching is
   required to map inbound IPsec traffic to SAs MUST be set either as a
   side effect of manual SA configuration or via negotiation using an SA
   management protocol, e.g., IKE or Group Domain of Interpretation
   (GDOI) [RFC3547].  Typically, Source-Specific Multicast (SSM) [HC03]
   groups use a 3-tuple SA identifier composed of an SPI, a destination
   multicast address, and source address.  An Any-Source Multicast group
   SA requires only an SPI and a destination multicast address as an
   identifier.

   If different classes of traffic (distinguished by Differentiated
   Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
   the same SA, and if the receiver is employing the optional
   anti-replay feature available in both AH and ESP, this could result
   in inappropriate discarding of lower priority packets due to the
   windowing mechanism used by this feature.  Therefore, a sender SHOULD
   put traffic of different classes, but with the same selector values,
   on different SAs to support Quality of Service (QoS) appropriately.
   To permit this, the IPsec implementation MUST permit establishment
   and maintenance of multiple SAs between a given sender and receiver,



Kent & Seo                  Standards Track                    [Page 13]

RFC 4301              Security Architecture for IP         December 2005


   with the same selectors.  Distribution of traffic among these
   parallel SAs to support QoS is locally determined by the sender and
   is not negotiated by IKE.  The receiver MUST process the packets from
   the different SAs without prejudice.  These requirements apply to
   both transport and tunnel mode SAs.  In the case of tunnel mode SAs,
   the DSCP values in question appear in the inner IP header.  In
   transport mode, the DSCP value might change en route, but this should
   not cause problems with respect to IPsec processing since the value
   is not employed for SA selection and MUST NOT be checked as part of
   SA/packet validation.  However, if significant re-ordering of packets
   occurs in an SA, e.g., as a result of changes to DSCP values en
   route, this may trigger packet discarding by a receiver due to
   application of the anti-replay mechanism.

   DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
   Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
   as that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "classifier".

   As noted above, two types of SAs are defined: transport mode and
   tunnel mode.  IKE creates pairs of SAs, so for simplicity, we choose
   to require that both SAs in a pair be of the same mode, transport or
   tunnel.

   A transport mode SA is an SA typically employed between a pair of
   hosts to provide end-to-end security services.  When security is
   desired between two intermediate systems along a path (vs. end-to-end
   use of IPsec), transport mode MAY be used between security gateways
   or between a security gateway and a host.  In the case where
   transport mode is used between security gateways or between a
   security gateway and a host, transport mode may be used to support
   in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing
   Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing
   [ToEgWa04]) over transport mode SAs.  To clarify, the use of
   transport mode by an intermediate system (e.g., a security gateway)
   is permitted only when applied to packets whose source address (for
   outbound packets) or destination address (for inbound packets) is an
   address belonging to the intermediate system itself.  The access
   control functions that are an important part of IPsec are
   significantly limited in this context, as they cannot be applied to
   the end-to-end headers of the packets that traverse a transport mode
   SA used in this fashion.  Thus, this way of using transport mode
   should be evaluated carefully before being employed in a specific
   context.






Kent & Seo                  Standards Track                    [Page 14]

RFC 4301              Security Architecture for IP         December 2005


   In IPv4, a transport mode security protocol header appears
   immediately after the IP header and any options, and before any next
   layer protocols (e.g., TCP or UDP).  In IPv6, the security protocol
   header appears after the base IP header and selected extension
   headers, but may appear before or after destination options; it MUST
   appear before next layer protocols (e.g., TCP, UDP, Stream Control
   Transmission Protocol (SCTP)).  In the case of ESP, a transport mode
   SA provides security services only for these next layer protocols,
   not for the IP header or any extension headers preceding the ESP
   header.  In the case of AH, the protection is also extended to
   selected portions of the IP header preceding it, selected portions of
   extension headers, and selected options (contained in the IPv4
   header, IPv6 Hop-by-Hop extension header, or IPv6 Destination
   extension headers).  For more details on the coverage afforded by AH,
   see the AH specification [Ken05b].

   A tunnel mode SA is essentially an SA applied to an IP tunnel, with
   the access controls applied to the headers of the traffic inside the
   tunnel.  Two hosts MAY establish a tunnel mode SA between themselves.
   Aside from the two exceptions below, whenever either end of a
   security association is a security gateway, the SA MUST be tunnel
   mode.  Thus, an SA between two security gateways is typically a
   tunnel mode SA, as is an SA between a host and a security gateway.
   The two exceptions are as follows.

    o Where traffic is destined for a security gateway, e.g., Simple
      Network Management Protocol (SNMP) commands, the security gateway
      is acting as a host and transport mode is allowed.  In this case,
      the SA terminates at a host (management) function within a
      security gateway and thus merits different treatment.

    o As noted above, security gateways MAY support a transport mode SA
      to provide security for IP traffic between two intermediate
      systems along a path, e.g., between a host and a security gateway
      or between two security gateways.

   Several concerns motivate the use of tunnel mode for an SA involving
   a security gateway.  For example, if there are multiple paths (e.g.,
   via different security gateways) to the same destination behind a
   security gateway, it is important that an IPsec packet be sent to the
   security gateway with which the SA was negotiated.  Similarly, a
   packet that might be fragmented en route must have all the fragments
   delivered to the same IPsec instance for reassembly prior to
   cryptographic processing.  Also, when a fragment is processed by
   IPsec and transmitted, then fragmented en route, it is critical that
   there be inner and outer headers to retain the fragmentation state
   data for the pre- and post-IPsec packet formats.  Hence there are
   several reasons for employing tunnel mode when either end of an SA is



Kent & Seo                  Standards Track                    [Page 15]

RFC 4301              Security Architecture for IP         December 2005


   a security gateway. (Use of an IP-in-IP tunnel in conjunction with
   transport mode can also address these fragmentation issues.  However,
   this configuration limits the ability of IPsec to enforce access
   control policies on traffic.)

   Note: AH and ESP cannot be applied using transport mode to IPv4
   packets that are fragments.  Only tunnel mode can be employed in such
   cases.  For IPv6, it would be feasible to carry a plaintext fragment
   on a transport mode SA; however, for simplicity, this restriction
   also applies to IPv6 packets.  See Section 7 for more details on
   handling plaintext fragments on the protected side of the IPsec
   barrier.

   For a tunnel mode SA, there is an "outer" IP header that specifies
   the IPsec processing source and destination, plus an "inner" IP
   header that specifies the (apparently) ultimate source and
   destination for the packet.  The security protocol header appears
   after the outer IP header, and before the inner IP header.  If AH is
   employed in tunnel mode, portions of the outer IP header are afforded
   protection (as above), as well as all of the tunneled IP packet
   (i.e., all of the inner IP header is protected, as well as next layer
   protocols).  If ESP is employed, the protection is afforded only to
   the tunneled packet, not to the outer header.

   In summary,

   a) A host implementation of IPsec MUST support both transport and
      tunnel mode.  This is true for native, BITS, and BITW
      implementations for hosts.

   b) A security gateway MUST support tunnel mode and MAY support
      transport mode.  If it supports transport mode, that should be
      used only when the security gateway is acting as a host, e.g., for
      network management, or to provide security between two
      intermediate systems along a path.

4.2.  SA Functionality

   The set of security services offered by an SA depends on the security
   protocol selected, the SA mode, the endpoints of the SA, and the
   election of optional services within the protocol.

   For example, both AH and ESP offer integrity and authentication
   services, but the coverage differs for each protocol and differs for
   transport vs. tunnel mode.  If the integrity of an IPv4 option or
   IPv6 extension header must be protected en route between sender and
   receiver, AH can provide this service, except for IP or extension
   headers that may change in a fashion not predictable by the sender.



Kent & Seo                  Standards Track                    [Page 16]

RFC 4301              Security Architecture for IP         December 2005


   However, the same security may be achieved in some contexts by
   applying ESP to a tunnel carrying a packet.

   The granularity of access control provided is determined by the
   choice of the selectors that define each SA.  Moreover, the
   authentication means employed by IPsec peers, e.g., during creation
   of an IKE (vs. child) SA also affects the granularity of the access
   control afforded.

   If confidentiality is selected, then an ESP (tunnel mode) SA between
   two security gateways can offer partial traffic flow confidentiality.
   The use of tunnel mode allows the inner IP headers to be encrypted,
   concealing the identities of the (ultimate) traffic source and
   destination.  Moreover, ESP payload padding also can be invoked to
   hide the size of the packets, further concealing the external
   characteristics of the traffic.  Similar traffic flow confidentiality
   services may be offered when a mobile user is assigned a dynamic IP
   address in a dialup context, and establishes a (tunnel mode) ESP SA
   to a corporate firewall (acting as a security gateway).  Note that
   fine-granularity SAs generally are more vulnerable to traffic
   analysis than coarse-granularity ones that are carrying traffic from
   many subscribers.

   Note: A compliant implementation MUST NOT allow instantiation of an
   ESP SA that employs both NULL encryption and no integrity algorithm.
   An attempt to negotiate such an SA is an auditable event by both
   initiator and responder.  The audit log entry for this event SHOULD
   include the current date/time, local IKE IP address, and remote IKE
   IP address.  The initiator SHOULD record the relevant SPD entry.

4.3.  Combining SAs

   This document does not require support for nested security
   associations or for what RFC 2401 [RFC2401] called "SA bundles".
   These features still can be effected by appropriate configuration of
   both the SPD and the local forwarding functions (for inbound and
   outbound traffic), but this capability is outside of the IPsec module
   and thus the scope of this specification.  As a result, management of
   nested/bundled SAs is potentially more complex and less assured than
   under the model implied by RFC 2401 [RFC2401].  An implementation
   that provides support for nested SAs SHOULD provide a management
   interface that enables a user or administrator to express the nesting
   requirement, and then create the appropriate SPD entries and
   forwarding table entries to effect the requisite processing. (See
   Appendix E for an example of how to configure nested SAs.)






Kent & Seo                  Standards Track                    [Page 17]

RFC 4301              Security Architecture for IP         December 2005


4.4.  Major IPsec Databases

   Many of the details associated with processing IP traffic in an IPsec
   implementation are largely a local matter, not subject to
   standardization.  However, some external aspects of the processing
   must be standardized to ensure interoperability and to provide a
   minimum management capability that is essential for productive use of
   IPsec.  This section describes a general model for processing IP
   traffic relative to IPsec functionality, in support of these
   interoperability and functionality goals.  The model described below
   is nominal; implementations need not match details of this model as
   presented, but the external behavior of implementations MUST
   correspond to the externally observable characteristics of this model
   in order to be compliant.

   There are three nominal databases in this model: the Security Policy
   Database (SPD), the Security Association Database (SAD), and the Peer
   Authorization Database (PAD).  The first specifies the policies that
   determine the disposition of all IP traffic inbound or outbound from
   a host or security gateway (Section 4.4.1).  The second database
   contains parameters that are associated with each established (keyed)
   SA (Section 4.4.2).  The third database, the PAD, provides a link
   between an SA management protocol (such as IKE) and the SPD (Section
   4.4.3).

   Multiple Separate IPsec Contexts

      If an IPsec implementation acts as a security gateway for multiple
      subscribers, it MAY implement multiple separate IPsec contexts.
      Each context MAY have and MAY use completely independent
      identities, policies, key management SAs, and/or IPsec SAs.  This
      is for the most part a local implementation matter.  However, a
      means for associating inbound (SA) proposals with local contexts
      is required.  To this end, if supported by the key management
      protocol in use, context identifiers MAY be conveyed from
      initiator to responder in the signaling messages, with the result
      that IPsec SAs are created with a binding to a particular context.
      For example, a security gateway that provides VPN service to
      multiple customers will be able to associate each customer's
      traffic with the correct VPN.

   Forwarding vs Security Decisions

      The IPsec model described here embodies a clear separation between
      forwarding (routing) and security decisions, to accommodate a wide
      range of contexts where IPsec may be employed.  Forwarding may be
      trivial, in the case where there are only two interfaces, or it
      may be complex, e.g., if the context in which IPsec is implemented



Kent & Seo                  Standards Track                    [Page 18]

RFC 4301              Security Architecture for IP         December 2005


      employs a sophisticated forwarding function.  IPsec assumes only
      that outbound and inbound traffic that has passed through IPsec
      processing is forwarded in a fashion consistent with the context
      in which IPsec is implemented.  Support for nested SAs is
      optional; if required, it requires coordination between forwarding
      tables and SPD entries to cause a packet to traverse the IPsec
      boundary more than once.

   "Local" vs "Remote"

      In this document, with respect to IP addresses and ports, the
      terms "Local" and "Remote" are used for policy rules.  "Local"
      refers to the entity being protected by an IPsec implementation,
      i.e., the "source" address/port of outbound packets or the
      "destination" address/port of inbound packets. "Remote" refers to
      a peer entity or peer entities.  The terms "source" and
      "destination" are used for packet header fields.

   "Non-initial" vs "Initial" Fragments

      Throughout this document, the phrase "non-initial fragments" is
      used to mean fragments that do not contain all of the selector
      values that may be needed for access control (e.g., they might not
      contain Next Layer Protocol, source and destination ports, ICMP
      message type/code, Mobility Header type).  And the phrase "initial
      fragment" is used to mean a fragment that contains all the
      selector values needed for access control.  However, it should be
      noted that for IPv6, which fragment contains the Next Layer
      Protocol and ports (or ICMP message type/code or Mobility Header
      type [Mobip]) will depend on the kind and number of extension
      headers present.  The "initial fragment" might not be the first
      fragment, in this context.

4.4.1.  The Security Policy Database (SPD)

   An SA is a management construct used to enforce security policy for
   traffic crossing the IPsec boundary.  Thus, an essential element of
   SA processing is an underlying Security Policy Database (SPD) that
   specifies what services are to be offered to IP datagrams and in what
   fashion.  The form of the database and its interface are outside the
   scope of this specification.  However, this section specifies minimum
   management functionality that must be provided, to allow a user or
   system administrator to control whether and how IPsec is applied to
   traffic transmitted or received by a host or transiting a security
   gateway.  The SPD, or relevant caches, must be consulted during the
   processing of all traffic (inbound and outbound), including traffic
   not protected by IPsec, that traverses the IPsec boundary.  This
   includes IPsec management traffic such as IKE.  An IPsec



Kent & Seo                  Standards Track                    [Page 19]

RFC 4301              Security Architecture for IP         December 2005


   implementation MUST have at least one SPD, and it MAY support
   multiple SPDs, if appropriate for the context in which the IPsec
   implementation operates.  There is no requirement to maintain SPDs on
   a per-interface basis, as was specified in RFC 2401 [RFC2401].
   However, if an implementation supports multiple SPDs, then it MUST
   include an explicit SPD selection function that is invoked to select
   the appropriate SPD for outbound traffic processing.  The inputs to
   this function are the outbound packet and any local metadata (e.g.,
   the interface via which the packet arrived) required to effect the
   SPD selection function.  The output of the function is an SPD
   identifier (SPD-ID).

   The SPD is an ordered database, consistent with the use of Access
   Control Lists (ACLs) or packet filters in firewalls, routers, etc.
   The ordering requirement arises because entries often will overlap
   due to the presence of (non-trivial) ranges as values for selectors.
   Thus, a user or administrator MUST be able to order the entries to
   express a desired access control policy.  There is no way to impose a
   general, canonical order on SPD entries, because of the allowed use
   of wildcards for selector values and because the different types of
   selectors are not hierarchically related.

   Processing Choices:  DISCARD, BYPASS, PROTECT

      An SPD must discriminate among traffic that is afforded IPsec
      protection and traffic that is allowed to bypass IPsec.  This
      applies to the IPsec protection to be applied by a sender and to
      the IPsec protection that must be present at the receiver.  For
      any outbound or inbound datagram, three processing choices are
      possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec.  The
      first choice refers to traffic that is not allowed to traverse the
      IPsec boundary (in the specified direction).  The second choice
      refers to traffic that is allowed to cross the IPsec boundary
      without IPsec protection.  The third choice refers to traffic that
      is afforded IPsec protection, and for such traffic the SPD must
      specify the security protocols to be employed, their mode,
      security service options, and the cryptographic algorithms to be
      used.

   SPD-S, SPD-I, SPD-O

      An SPD is logically divided into three pieces.  The SPD-S (secure
      traffic) contains entries for all traffic subject to IPsec
      protection.  SPD-O (outbound) contains entries for all outbound
      traffic that is to be bypassed or discarded.  SPD-I (inbound) is
      applied to inbound traffic that will be bypassed or discarded.
      All three of these can be decorrelated (with the exception noted
      above for native host implementations) to facilitate caching.  If



Kent & Seo                  Standards Track                    [Page 20]

RFC 4301              Security Architecture for IP         December 2005


      an IPsec implementation supports only one SPD, then the SPD
      consists of all three parts.  If multiple SPDs are supported, some
      of them may be partial, e.g., some SPDs might contain only SPD-I
      entries, to control inbound bypassed traffic on a per-interface
      basis.  The split allows SPD-I to be consulted without having to
      consult SPD-S, for such traffic.  Since the SPD-I is just a part
      of the SPD, if a packet that is looked up in the SPD-I cannot be
      matched to an entry there, then the packet MUST be discarded.
      Note that for outbound traffic, if a match is not found in SPD-S,
      then SPD-O must be checked to see if the traffic should be
      bypassed.  Similarly, if SPD-O is checked first and no match is
      found, then SPD-S must be checked.  In an ordered,
      non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O
      are interleaved.  So there is one lookup in the SPD.

   SPD Entries

      Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
      PROTECT.  The entry is keyed by a list of one or more selectors.
      The SPD contains an ordered list of these entries.  The required
      selector types are defined in Section 4.4.1.1. These selectors are
      used to define the granularity of the SAs that are created in
      response to an outbound packet or in response to a proposal from a
      peer.  The detailed structure of an SPD entry is described in
      Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
      matches anything that is otherwise unmatched, and discards it.

      The SPD MUST permit a user or administrator to specify policy
      entries as follows:

       - SPD-I: For inbound traffic that is to be bypassed or discarded,
         the entry consists of the values of the selectors that apply to
         the traffic to be bypassed or discarded.

       - SPD-O: For outbound traffic that is to be bypassed or
         discarded, the entry consists of the values of the selectors
         that apply to the traffic to be bypassed or discarded.

       - SPD-S: For traffic that is to be protected using IPsec, the
         entry consists of the values of the selectors that apply to the
         traffic to be protected via AH or ESP, controls on how to
         create SAs based on these selectors, and the parameters needed
         to effect this protection (e.g., algorithms, modes, etc.). Note
         that an SPD-S entry also contains information such as "populate
         from packet" (PFP) flag (see paragraphs below on "How To Derive
         the Values for an SAD entry") and bits indicating whether the





Kent & Seo                  Standards Track                    [Page 21]

RFC 4301              Security Architecture for IP         December 2005


         SA lookup makes use of the local and remote IP addresses in
         addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
         specifications).

   Representing Directionality in an SPD Entry

      For traffic protected by IPsec, the Local and Remote address and
      ports in an SPD entry are swapped to represent directionality,
      consistent with IKE conventions.  In general, the protocols that
      IPsec deals with have the property of requiring symmetric SAs with
      flipped Local/Remote IP addresses.  However, for ICMP, there is
      often no such bi-directional authorization requirement.
      Nonetheless, for the sake of uniformity and simplicity, SPD
      entries for ICMP are specified in the same way as for other
      protocols.  Note also that for ICMP, Mobility Header, and
      non-initial fragments, there are no port fields in these packets.
      ICMP has message type and code and Mobility Header has mobility
      header type.  Thus, SPD entries have provisions for expressing
      access controls appropriate for these protocols, in lieu of the
      normal port field controls.  For bypassed or discarded traffic,
      separate inbound and outbound entries are supported, e.g., to
      permit unidirectional flows if required.

   OPAQUE and ANY

      For each selector in an SPD entry, in addition to the literal
      values that define a match, there are two special values: ANY and
      OPAQUE.  ANY is a wildcard that matches any value in the
      corresponding field of the packet, or that matches packets where
      that field is not present or is obscured.  OPAQUE indicates that
      the corresponding selector field is not available for examination
      because it may not be present in a fragment, it does not exist for
      the given Next Layer Protocol, or prior application of IPsec may
      have encrypted the value.  The ANY value encompasses the OPAQUE
      value.  Thus, OPAQUE need be used only when it is necessary to
      distinguish between the case of any allowed value for a field, vs.
      the absence or unavailability (e.g., due to encryption) of the
      field.

   How to Derive the Values for an SAD Entry

      For each selector in an SPD entry, the entry specifies how to
      derive the corresponding values for a new SA Database (SAD, see
      Section 4.4.2) entry from those in the SPD and the packet.  The
      goal is to allow an SAD entry and an SPD cache entry to be created
      based on specific selector values from the packet, or from the
      matching SPD entry.  For outbound traffic, there are SPD-S cache
      entries and SPD-O cache entries.  For inbound traffic not



Kent & Seo                  Standards Track                    [Page 22]

RFC 4301              Security Architecture for IP         December 2005


      protected by IPsec, there are SPD-I cache entries and there is the
      SAD, which represents the cache for inbound IPsec-protected
      traffic (see Section 4.4.2).  If IPsec processing is specified for
      an entry, a "populate from packet" (PFP) flag may be asserted for
      one or more of the selectors in the SPD entry (Local IP address;
      Remote IP address; Next Layer Protocol; and, depending on Next
      Layer Protocol, Local port and Remote port, or ICMP type/code, or
      Mobility Header type).  If asserted for a given selector X, the
      flag indicates that the SA to be created should take its value for
      X from the value in the packet.  Otherwise, the SA should take its
      value(s) for X from the value(s) in the SPD entry.  Note: In the
      non-PFP case, the selector values negotiated by the SA management
      protocol (e.g., IKEv2) may be a subset of those in the SPD entry,
      depending on the SPD policy of the peer.  Also, whether a single
      flag is used for, e.g., source port, ICMP type/code, and Mobility
      Header (MH) type, or a separate flag is used for each, is a local
      matter.

      The following example illustrates the use of the PFP flag in the
      context of a security gateway or a BITS/BITW implementation.
      Consider an SPD entry where the allowed value for Remote address
      is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10.  Suppose an
      outbound packet arrives with a destination address of 192.0.2.3,
      and there is no extant SA to carry this packet.  The value used
      for the SA created to transmit this packet could be either of the
      two values shown below, depending on what the SPD entry for this
      selector says is the source of the selector value:

          PFP flag value  example of new
          for the Remote  SAD dest. address
          addr. selector  selector value
          --------------- ------------
          a. PFP TRUE     192.0.2.3 (one host)
          b. PFP FALSE    192.0.2.1 to 192.0.2.10 (range of hosts)

      Note that if the SPD entry above had a value of ANY for the Remote
      address, then the SAD selector value would have to be ANY for case
      (b), but would still be as illustrated for case (a).  Thus, the
      PFP flag can be used to prohibit sharing of an SA, even among
      packets that match the same SPD entry.

   Management Interface

      For every IPsec implementation, there MUST be a management
      interface that allows a user or system administrator to manage the
      SPD.  The interface must allow the user (or administrator) to
      specify the security processing to be applied to every packet that
      traverses the IPsec boundary. (In a native host IPsec



Kent & Seo                  Standards Track                    [Page 23]

RFC 4301              Security Architecture for IP         December 2005


      implementation making use of a socket interface, the SPD may not
      need to be consulted on a per-packet basis, as noted at the end of
      Section 4.4.1.1 and in Section 5.)  The management interface for
      the SPD MUST allow creation of entries consistent with the
      selectors defined in Section 4.4.1.1, and MUST support (total)
      ordering of these entries, as seen via this interface.  The SPD
      entries' selectors are analogous to the ACL or packet filters
      commonly found in a stateless firewall or packet filtering router
      and which are currently managed this way.

      In host systems, applications MAY be allowed to create SPD
      entries.  (The means of signaling such requests to the IPsec
      implementation are outside the scope of this standard.)  However,
      the system administrator MUST be able to specify whether or not a
      user or application can override (default) system policies.  The
      form of the management interface is not specified by this document
      and may differ for hosts vs. security gateways, and within hosts
      the interface may differ for socket-based vs. BITS
      implementations.  However, this document does specify a standard
      set of SPD elements that all IPsec implementations MUST support.

   Decorrelation

      The processing model described in this document assumes the
      ability to decorrelate overlapping SPD entries to permit caching,
      which enables more efficient processing of outbound traffic in
      security gateways and BITS/BITW implementations.  Decorrelation
      [CoSa04] is only a means of improving performance and simplifying
      the processing description.  This RFC does not require a compliant
      implementation to make use of decorrelation.  For example, native
      host implementations typically make use of caching implicitly
      because they bind SAs to socket interfaces, and thus there is no
      requirement to be able to decorrelate SPD entries in these
      implementations.

      Note:  Unless otherwise qualified, the use of "SPD" refers to the
      body of policy information in both ordered or decorrelated
      (unordered) state.  Appendix B provides an algorithm that can be
      used to decorrelate SPD entries, but any algorithm that produces
      equivalent output may be used.  Note that when an SPD entry is
      decorrelated all the resulting entries MUST be linked together, so
      that all members of the group derived from an individual, SPD
      entry (prior to decorrelation) can all be placed into caches and
      into the SAD at the same time.  For example, suppose one starts
      with an entry A (from an ordered SPD) that when decorrelated,
      yields entries A1, A2, and A3.  When a packet comes along that
      matches, say A2, and triggers the creation of an SA, the SA
      management protocol (e.g., IKEv2) negotiates A.  And all 3



Kent & Seo                  Standards Track                    [Page 24]

RFC 4301              Security Architecture for IP         December 2005


      decorrelated entries, A1, A2, and A3, are placed in the
      appropriate SPD-S cache and linked to the SA.  The intent is that
      use of a decorrelated SPD ought not to create more SAs than would
      have resulted from use of a not-decorrelated SPD.

      If a decorrelated SPD is employed, there are three options for
      what an initiator sends to a peer via an SA management protocol
      (e.g., IKE).  By sending the complete set of linked, decorrelated
      entries that were selected from the SPD, a peer is given the best
      possible information to enable selection of the appropriate SPD
      entry at its end, especially if the peer has also decorrelated its
      SPD.  However, if a large number of decorrelated entries are
      linked, this may create large packets for SA negotiation, and
      hence fragmentation problems for the SA management protocol.

      Alternatively, the original entry from the (correlated) SPD may be
      retained and passed to the SA management protocol.  Passing the
      correlated SPD entry keeps the use of a decorrelated SPD a local
      matter, not visible to peers, and avoids possible fragmentation
      concerns, although it provides less precise information to a
      responder for matching against the responder's SPD.

      An intermediate approach is to send a subset of the complete set
      of linked, decorrelated SPD entries.  This approach can avoid the
      fragmentation problems cited above yet provide better information
      than the original, correlated entry.  The major shortcoming of
      this approach is that it may cause additional SAs to be created
      later, since only a subset of the linked, decorrelated entries are
      sent to a peer.  Implementers are free to employ any of the
      approaches cited above.

      A responder uses the traffic selector proposals it receives via an
      SA management protocol to select an appropriate entry in its SPD.
      The intent of the matching is to select an SPD entry and create an
      SA that most closely matches the intent of the initiator, so that
      traffic traversing the resulting SA will be accepted at both ends.
      If the responder employs a decorrelated SPD, it SHOULD use the
      decorrelated SPD entries for matching, as this will generally
      result in creation of SAs that are more likely to match the intent
      of both peers.  If the responder has a correlated SPD, then it
      SHOULD match the proposals against the correlated entries.  For
      IKEv2, use of a decorrelated SPD offers the best opportunity for a
      responder to generate a "narrowed" response.

      In all cases, when a decorrelated SPD is available, the
      decorrelated entries are used to populate the SPD-S cache.  If the
      SPD is not decorrelated, caching is not allowed and an ordered




Kent & Seo                  Standards Track                    [Page 25]

RFC 4301              Security Architecture for IP         December 2005


      search of SPD MUST be performed to verify that inbound traffic
      arriving on an SA is consistent with the access control policy
      expressed in the SPD.

   Handling Changes to the SPD While the System Is Running

      If a change is made to the SPD while the system is running, a
      check SHOULD be made of the effect of this change on extant SAs.
      An implementation SHOULD check the impact of an SPD change on
      extant SAs and SHOULD provide a user/administrator with a
      mechanism for configuring what actions to take, e.g., delete an
      affected SA, allow an affected SA to continue unchanged, etc.

4.4.1.1.   Selectors

   An SA may be fine-grained or coarse-grained, depending on the
   selectors used to define the set of traffic for the SA.  For example,
   all traffic between two hosts may be carried via a single SA, and
   afforded a uniform set of security services.  Alternatively, traffic
   between a pair of hosts might be spread over multiple SAs, depending
   on the applications being used (as defined by the Next Layer Protocol
   and related fields, e.g., ports), with different security services
   offered by different SAs.  Similarly, all traffic between a pair of
   security gateways could be carried on a single SA, or one SA could be
   assigned for each communicating host pair.  The following selector
   parameters MUST be supported by all IPsec implementations to
   facilitate control of SA granularity.  Note that both Local and
   Remote addresses should either be IPv4 or IPv6, but not a mix of
   address types.  Also, note that the Local/Remote port selectors (and
   ICMP message type and code, and Mobility Header type) may be labeled
   as OPAQUE to accommodate situations where these fields are
   inaccessible due to packet fragmentation.

      - Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges
        of IP addresses (unicast, broadcast (IPv4 only)).  This
        structure allows expression of a single IP address (via a
        trivial range), or a list of addresses (each a trivial range),
        or a range of addresses (low and high values, inclusive), as
        well as the most generic form of a list of ranges.  Address
        ranges are used to support more than one remote system sharing
        the same SA, e.g., behind a security gateway.

      - Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of
        IP addresses (unicast, broadcast (IPv4 only)).  This structure
        allows expression of a single IP address (via a trivial range),
        or a list of addresses (each a trivial range), or a range of
        addresses (low and high values, inclusive), as well as the most
        generic form of a list of ranges.  Address ranges are used to



Kent & Seo                  Standards Track                    [Page 26]

RFC 4301              Security Architecture for IP         December 2005


        support more than one source system sharing the same SA, e.g.,
        behind a security gateway.  Local refers to the address(es)
        being protected by this implementation (or policy entry).

        Note: The SPD does not include support for multicast address
        entries.  To support multicast SAs, an implementation should
        make use of a Group SPD (GSPD) as defined in [RFC3740].  GSPD
        entries require a different structure, i.e., one cannot use the
        symmetric relationship associated with local and remote address
        values for unicast SAs in a multicast context.  Specifically,
        outbound traffic directed to a multicast address on an SA would
        not be received on a companion, inbound SA with the multicast
        address as the source.

      - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
        IPv6 "Next Header" fields.  This is an individual protocol
        number, ANY, or for IPv6 only, OPAQUE.  The Next Layer Protocol
        is whatever comes after any IP extension headers that are
        present.  To simplify locating the Next Layer Protocol, there
        SHOULD be a mechanism for configuring which IPv6 extension
        headers to skip.  The default configuration for which protocols
        to skip SHOULD include the following protocols: 0 (Hop-by-hop
        options), 43 (Routing Header), 44 (Fragmentation Header), and 60
        (Destination Options).  Note: The default list does NOT include
        51 (AH) or 50 (ESP).  From a selector lookup point of view,
        IPsec treats AH and ESP as Next Layer Protocols.

        Several additional selectors depend on the Next Layer Protocol
        value:

         * If the Next Layer Protocol uses two ports (as do TCP, UDP,
           SCTP, and others), then there are selectors for Local and
           Remote Ports.  Each of these selectors has a list of ranges
           of values.  Note that the Local and Remote ports may not be
           available in the case of receipt of a fragmented packet or if
           the port fields have been protected by IPsec (encrypted);
           thus, a value of OPAQUE also MUST be supported.  Note: In a
           non-initial fragment, port values will not be available.  If
           a port selector specifies a value other than ANY or OPAQUE,
           it cannot match packets that are non-initial fragments.  If
           the SA requires a port value other than ANY or OPAQUE, an
           arriving fragment without ports MUST be discarded. (See
           Section 7, "Handling Fragments".)

         * If the Next Layer Protocol is a Mobility Header, then there
           is a selector for IPv6 Mobility Header message type (MH type)
           [Mobip].  This is an 8-bit value that identifies a particular
           mobility message.  Note that the MH type may not be available



Kent & Seo                  Standards Track                    [Page 27]

RFC 4301              Security Architecture for IP         December 2005


           in the case of receipt of a fragmented packet. (See Section
           7, "Handling Fragments".) For IKE, the IPv6 Mobility Header
           message type (MH type) is placed in the most significant
           eight bits of the 16-bit local "port" selector.

         * If the Next Layer Protocol value is ICMP, then there is a
           16-bit selector for the ICMP message type and code.  The
           message type is a single 8-bit value, which defines the type
           of an ICMP message, or ANY.  The ICMP code is a single 8-bit
           value that defines a specific subtype for an ICMP message.
           For IKE, the message type is placed in the most significant 8
           bits of the 16-bit selector and the code is placed in the
           least significant 8 bits.  This 16-bit selector can contain a
           single type and a range of codes, a single type and ANY code,
           and ANY type and ANY code.  Given a policy entry with a range
           of Types (T-start to T-end) and a range of Codes (C-start to
           C-end), and an ICMP packet with Type t and Code c, an
           implementation MUST test for a match using

               (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
               C-end

           Note that the ICMP message type and code may not be available
           in the case of receipt of a fragmented packet. (See Section
           7, "Handling Fragments".)

      - Name:  This is not a selector like the others above.  It is not
        acquired from a packet.  A name may be used as a symbolic
        identifier for an IPsec Local or Remote address.  Named SPD
        entries are used in two ways:

         1. A named SPD entry is used by a responder (not an initiator)
            in support of access control when an IP address would not be
            appropriate for the Remote IP address selector, e.g., for
            "road warriors".  The name used to match this field is
            communicated during the IKE negotiation in the ID payload.
            In this context, the initiator's Source IP address (inner IP
            header in tunnel mode) is bound to the Remote IP address in
            the SAD entry created by the IKE negotiation.  This address
            overrides the Remote IP address value in the SPD, when the
            SPD entry is selected in this fashion.  All IPsec
            implementations MUST support this use of names.

         2. A named SPD entry may be used by an initiator to identify a
            user for whom an IPsec SA will be created (or for whom
            traffic may be bypassed).  The initiator's IP source address
            (from inner IP header in tunnel mode) is used to replace the
            following if and when they are created:



Kent & Seo                  Standards Track                    [Page 28]

RFC 4301              Security Architecture for IP         December 2005


                    - local address in the SPD cache entry
                    - local address in the outbound SAD entry
                    - remote address in the inbound SAD entry

            Support for this use is optional for multi-user, native host
            implementations and not applicable to other implementations.
            Note that this name is used only locally; it is not
            communicated by the key management protocol.  Also, name
            forms other than those used for case 1 above (responder) are
            applicable in the initiator context (see below).

         An SPD entry can contain both a name (or a list of names) and
         also values for the Local or Remote IP address.

         For case 1, responder, the identifiers employed in named SPD
         entries are one of the following four types:

                 a. a fully qualified user name string (email), e.g.,
                    mozart@foo.example.com
                    (this corresponds to ID_RFC822_ADDR in IKEv2)

                 b. a fully qualified DNS name, e.g.,
                    foo.example.com
                    (this corresponds to ID_FQDN in IKEv2)

                 c. X.500 distinguished name, e.g., [WaKiHo97],
                    CN = Stephen T. Kent, O = BBN Technologies,
                    SP = MA, C = US
                    (this corresponds to ID_DER_ASN1_DN in IKEv2, after
                    decoding)

                 d. a byte string
                    (this corresponds to Key_ID in IKEv2)

         For case 2, initiator, the identifiers employed in named SPD
         entries are of type byte string.  They are likely to be Unix
         UIDs, Windows security IDs, or something similar, but could
         also be a user name or account name.  In all cases, this
         identifier is only of local concern and is not transmitted.

   The IPsec implementation context determines how selectors are used.
   For example, a native host implementation typically makes use of a
   socket interface.  When a new connection is established, the SPD can
   be consulted and an SA bound to the socket.  Thus, traffic sent via
   that socket need not result in additional lookups to the SPD (SPD-O
   and SPD-S) cache.  In contrast, a BITS, BITW, or security gateway
   implementation needs to look at each packet and perform an
   SPD-O/SPD-S cache lookup based on the selectors.



Kent & Seo                  Standards Track                    [Page 29]

RFC 4301              Security Architecture for IP         December 2005


4.4.1.2.  Structure of an SPD Entry

   This section contains a prose description of an SPD entry.  Also,
   Appendix C provides an example of an ASN.1 definition of an SPD
   entry.

   This text describes the SPD in a fashion that is intended to map
   directly into IKE payloads to ensure that the policy required by SPD
   entries can be negotiated through IKE.  Unfortunately, the semantics
   of the version of IKEv2 published concurrently with this document
   [Kau05] do not align precisely with those defined for the SPD.
   Specifically, IKEv2 does not enable negotiation of a single SA that
   binds multiple pairs of local and remote addresses and ports to a
   single SA.  Instead, when multiple local and remote addresses and
   ports are negotiated for an SA, IKEv2 treats these not as pairs, but
   as (unordered) sets of local and remote values that can be
   arbitrarily paired.  Until IKE provides a facility that conveys the
   semantics that are expressed in the SPD via selector sets (as
   described below), users MUST NOT include multiple selector sets in a
   single SPD entry unless the access control intent aligns with the IKE
   "mix and match" semantics.  An implementation MAY warn users, to
   alert them to this problem if users create SPD entries with multiple
   selector sets, the syntax of which indicates possible conflicts with
   current IKE semantics.

   The management GUI can offer the user other forms of data entry and
   display, e.g., the option of using address prefixes as well as
   ranges, and symbolic names for protocols, ports, etc. (Do not confuse
   the use of symbolic names in a management interface with the SPD
   selector "Name".) Note that Remote/Local apply only to IP addresses
   and ports, not to ICMP message type/code or Mobility Header type.
   Also, if the reserved, symbolic selector value OPAQUE or ANY is
   employed for a given selector type, only that value may appear in the
   list for that selector, and it must appear only once in the list for
   that selector.  Note that ANY and OPAQUE are local syntax conventions
   -- IKEv2 negotiates these values via the ranges indicated below:

          ANY:     start = 0        end = <max>
          OPAQUE:  start = <max>    end = 0

   An SPD is an ordered list of entries each of which contains the
   following fields.

           o Name -- a list of IDs.  This quasi-selector is optional.
             The forms that MUST be supported are described above in
             Section 4.4.1.1 under "Name".





Kent & Seo                  Standards Track                    [Page 30]

RFC 4301              Security Architecture for IP         December 2005


           o PFP flags -- one per traffic selector.  A given flag, e.g.,
             for Next Layer Protocol, applies to the relevant selector
             across all "selector sets" (see below) contained in an SPD
             entry.  When creating an SA, each flag specifies for the
             corresponding traffic selector whether to instantiate the
             selector from the corresponding field in the packet that
             triggered the creation of the SA or from the value(s) in
             the corresponding SPD entry (see Section 4.4.1, "How to
             Derive the Values for an SAD Entry").  Whether a single
             flag is used for, e.g., source port, ICMP type/code, and
             MH type, or a separate flag is used for each, is a local
             matter.  There are PFP flags for:
                - Local Address
                - Remote Address
                - Next Layer Protocol
                - Local Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)
                - Remote Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)

           o One to N selector sets that correspond to the "condition"
             for applying a particular IPsec action.  Each selector set
             contains:
                - Local Address
                - Remote Address
                - Next Layer Protocol
                - Local Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)
                - Remote Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)

             Note: The "next protocol" selector is an individual value
             (unlike the local and remote IP addresses) in a selector
             set entry.  This is consistent with how IKEv2 negotiates
             the Traffic Selector (TS) values for an SA.  It also makes
             sense because one may need to associate different port
             fields with different protocols.  It is possible to
             associate multiple protocols (and ports) with a single SA
             by specifying multiple selector sets for that SA.

           o Processing info -- which action is required -- PROTECT,
             BYPASS, or DISCARD.  There is just one action that goes
             with all the selector sets, not a separate action for each
             set.  If the required processing is PROTECT, the entry
             contains the following information.
                - IPsec mode -- tunnel or transport





Kent & Seo                  Standards Track                    [Page 31]

RFC 4301              Security Architecture for IP         December 2005


                - (if tunnel mode) local tunnel address -- For a
                  non-mobile host, if there is just one interface, this
                  is straightforward; if there are multiple
                  interfaces, this must be statically configured.  For a
                  mobile host, the specification of the local address
                  is handled externally to IPsec.
                - (if tunnel mode) remote tunnel address -- There is no
                  standard way to determine this.  See 4.5.3, "Locating
                  a Security Gateway".
                - Extended Sequence Number -- Is this SA using extended
                  sequence numbers?
                - stateful fragment checking -- Is this SA using
                  stateful fragment checking?  (See Section 7 for more
                  details.)
                - Bypass DF bit (T/F) -- applicable to tunnel mode SAs
                - Bypass DSCP (T/F) or map to unprotected DSCP values
                  (array) if needed to restrict bypass of DSCP values --
                  applicable to tunnel mode SAs
                - IPsec protocol -- AH or ESP
                - algorithms -- which ones to use for AH, which ones to
                  use for ESP, which ones to use for combined mode,
                  ordered by decreasing priority

   It is a local matter as to what information is kept with regard to
   handling extant SAs when the SPD is changed.

4.4.1.3.  More Regarding Fields Associated with Next Layer Protocols

   Additional selectors are often associated with fields in the Next
   Layer Protocol header.  A particular Next Layer Protocol can have
   zero, one, or two selectors.  There may be situations where there
   aren't both local and remote selectors for the fields that are
   dependent on the Next Layer Protocol.  The IPv6 Mobility Header has
   only a Mobility Header message type.  AH and ESP have no further
   selector fields.  A system may be willing to send an ICMP message
   type and code that it does not want to receive.  In the descriptions
   below, "port" is used to mean a field that is dependent on the Next
   Layer Protocol.

        A. If a Next Layer Protocol has no "port" selectors, then
           the Local and Remote "port" selectors are set to OPAQUE in
           the relevant SPD entry, e.g.,

           Local's
             next layer protocol = AH
             "port" selector     = OPAQUE





Kent & Seo                  Standards Track                    [Page 32]

RFC 4301              Security Architecture for IP         December 2005


           Remote's
             next layer protocol = AH
             "port" selector     = OPAQUE

        B. Even if a Next Layer Protocol has only one selector, e.g.,
           Mobility Header type, then the Local and Remote "port"
           selectors are used to indicate whether a system is
           willing to send and/or receive traffic with the specified
          "port" values. For example, if Mobility Headers of a
           specified type are allowed to be sent and received via an
           SA, then the relevant SPD entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           If Mobility Headers of a specified type are allowed to be
           sent but NOT received via an SA, then the relevant SPD
           entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = OPAQUE

           If Mobility Headers of a specified type are allowed to be
           received but NOT sent via an SA, then the relevant SPD
           entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = OPAQUE

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

        C. If a system is willing to send traffic with a particular
           "port" value but NOT receive traffic with that kind of
           port value, the system's traffic selectors are set as
           follows in the relevant SPD entry:



Kent & Seo                  Standards Track                    [Page 33]

RFC 4301              Security Architecture for IP         December 2005


           Local's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type & code>

           Remote's
             next layer protocol = ICMP
             "port" selector     = OPAQUE

        D. To indicate that a system is willing to receive traffic
           with a particular "port" value but NOT send that kind of
           traffic, the system's traffic selectors are set as follows
           in the relevant SPD entry:

           Local's
             next layer protocol = ICMP
             "port" selector     = OPAQUE

           Remote's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type & code>

           For example, if a security gateway is willing to allow
           systems behind it to send ICMP traceroutes, but is not
           willing to let outside systems run ICMP traceroutes to
           systems behind it, then the security gateway's traffic
           selectors are set as follows in the relevant SPD entry:

           Local's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = 30 (traceroute)

           Remote's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = OPAQUE

4.4.2.  Security Association Database (SAD)

   In each IPsec implementation, there is a nominal Security Association
   Database (SAD), in which each entry defines the parameters associated
   with one SA.  Each SA has an entry in the SAD.  For outbound
   processing, each SAD entry is pointed to by entries in the SPD-S part
   of the SPD cache.  For inbound processing, for unicast SAs, the SPI
   is used either alone to look up an SA or in conjunction with the
   IPsec protocol type.  If an IPsec implementation supports multicast,
   the SPI plus destination address, or SPI plus destination and source
   addresses are used to look up the SA. (See Section 4.1 for details on
   the algorithm that MUST be used for mapping inbound IPsec datagrams
   to SAs.) The following parameters are associated with each entry in



Kent & Seo                  Standards Track                    [Page 34]

RFC 4301              Security Architecture for IP         December 2005


   the SAD.  They should all be present except where otherwise noted,
   e.g., AH Authentication algorithm.  This description does not purport
   to be a MIB, only a specification of the minimal data items required
   to support an SA in an IPsec implementation.

   For each of the selectors defined in Section 4.4.1.1, the entry for
   an inbound SA in the SAD MUST be initially populated with the value
   or values negotiated at the time the SA was created. (See the
   paragraph in Section 4.4.1 under "Handling Changes to the SPD while
   the System is Running" for guidance on the effect of SPD changes on
   extant SAs.) For a receiver, these values are used to check that the
   header fields of an inbound packet (after IPsec processing) match the
   selector values negotiated for the SA.  Thus, the SAD acts as a cache
   for checking the selectors of inbound traffic arriving on SAs.  For
   the receiver, this is part of verifying that a packet arriving on an
   SA is consistent with the policy for the SA. (See Section 6 for rules
   for ICMP messages.)  These fields can have the form of specific
   values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1,
   "Selectors".  Note also that there are a couple of situations in
   which the SAD can have entries for SAs that do not have corresponding
   entries in the SPD.  Since this document does not mandate that the
   SAD be selectively cleared when the SPD is changed, SAD entries can
   remain when the SPD entries that created them are changed or deleted.
   Also, if a manually keyed SA is created, there could be an SAD entry
   for this SA that does not correspond to any SPD entry.

   Note: The SAD can support multicast SAs, if manually configured.  An
   outbound multicast SA has the same structure as a unicast SA.  The
   source address is that of the sender, and the destination address is
   the multicast group address.  An inbound, multicast SA must be
   configured with the source addresses of each peer authorized to
   transmit to the multicast SA in question.  The SPI value for a
   multicast SA is provided by a multicast group controller, not by the
   receiver, as for a unicast SA.  Because an SAD entry may be required
   to accommodate multiple, individual IP source addresses that were
   part of an SPD entry (for unicast SAs), the required facility for
   inbound, multicast SAs is a feature already present in an IPsec
   implementation.  However, because the SPD has no provisions for
   accommodating multicast entries, this document does not specify an
   automated way to create an SAD entry for a multicast, inbound SA.
   Only manually configured SAD entries can be created to accommodate
   inbound, multicast traffic.

   Implementation Guidance: This document does not specify how an SPD-S
   entry refers to the corresponding SAD entry, as this is an
   implementation-specific detail.  However, some implementations (based
   on experience from RFC 2401) are known to have problems in this
   regard.  In particular, simply storing the (remote tunnel header IP



Kent & Seo                  Standards Track                    [Page 35]

RFC 4301              Security Architecture for IP         December 2005


   address, remote SPI) pair in the SPD cache is not sufficient, since
   the pair does not always uniquely identify a single SAD entry.  For
   instance, two hosts behind the same NAT could choose the same SPI
   value.  The situation also may arise if a host is assigned an IP
   address (e.g., via DHCP) previously used by some other host, and the
   SAs associated with the old host have not yet been deleted via dead
   peer detection mechanisms.  This may lead to packets being sent over
   the wrong SA or, if key management ensures the pair is unique,
   denying the creation of otherwise valid SAs.  Thus, implementors
   should implement links between the SPD cache and the SAD in a way
   that does not engender such problems.

4.4.2.1.  Data Items in the SAD

   The following data items MUST be in the SAD:

    o Security Parameter Index (SPI): a 32-bit value selected by the
      receiving end of an SA to uniquely identify the SA.  In an SAD
      entry for an outbound SA, the SPI is used to construct the
      packet's AH or ESP header.  In an SAD entry for an inbound SA, the
      SPI is used to map traffic to the appropriate SA (see text on
      unicast/multicast in Section 4.1).

    o Sequence Number Counter: a 64-bit counter used to generate the
      Sequence Number field in AH or ESP headers. 64-bit sequence
      numbers are the default, but 32-bit sequence numbers are also
      supported if negotiated.

    o Sequence Counter Overflow: a flag indicating whether overflow of
      the sequence number counter should generate an auditable event and
      prevent transmission of additional packets on the SA, or whether
      rollover is permitted.  The audit log entry for this event SHOULD
      include the SPI value, current date/time, Local Address, Remote
      Address, and the selectors from the relevant SAD entry.

    o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
      used to determine whether an inbound AH or ESP packet is a replay.

      Note: If anti-replay has been disabled by the receiver for an SA,
      e.g., in the case of a manually keyed SA, then the Anti-Replay
      Window is ignored for the SA in question. 64-bit sequence numbers
      are the default, but this counter size accommodates 32-bit
      sequence numbers as well.

    o AH Authentication algorithm, key, etc.  This is required only if
      AH is supported.





Kent & Seo                  Standards Track                    [Page 36]

RFC 4301              Security Architecture for IP         December 2005


    o ESP Encryption algorithm, key, mode, IV, etc.  If a combined mode
      algorithm is used, these fields will not be applicable.

    o ESP integrity algorithm, keys, etc.  If the integrity service is
      not selected, these fields will not be applicable.  If a combined
      mode algorithm is used, these fields will not be applicable.

    o ESP combined mode algorithms, key(s), etc.  This data is used when
      a combined mode (encryption and integrity) algorithm is used with
      ESP.  If a combined mode algorithm is not used, these fields are
      not applicable.

    o Lifetime of this SA: a time interval after which an SA must be
      replaced with a new SA (and new SPI) or terminated, plus an
      indication of which of these actions should occur.  This may be
      expressed as a time or byte count, or a simultaneous use of both
      with the first lifetime to expire taking precedence.  A compliant
      implementation MUST support both types of lifetimes, and MUST
      support a simultaneous use of both.  If time is employed, and if
      IKE employs X.509 certificates for SA establishment, the SA
      lifetime must be constrained by the validity intervals of the
      certificates, and the NextIssueDate of the Certificate Revocation
      Lists (CRLs) used in the IKE exchange for the SA.  Both initiator
      and responder are responsible for constraining the SA lifetime in
      this fashion.  Note: The details of how to handle the refreshing
      of keys when SAs expire is a local matter.  However, one
      reasonable approach is:

     (a) If byte count is used, then the implementation SHOULD count the
         number of bytes to which the IPsec cryptographic algorithm is
         applied.  For ESP, this is the encryption algorithm (including
         Null encryption) and for AH, this is the authentication
         algorithm.  This includes pad bytes, etc.  Note that
         implementations MUST be able to handle having the counters at
         the ends of an SA get out of synch, e.g., because of packet
         loss or because the implementations at each end of the SA
         aren't doing things the same way.

     (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
         warns the implementation to initiate action such as setting up
         a replacement SA, and a hard lifetime when the current SA ends
         and is destroyed.

     (c) If the entire packet does not get delivered during the SA's
         lifetime, the packet SHOULD be discarded.

    o IPsec protocol mode: tunnel or transport.  Indicates which mode of
      AH or ESP is applied to traffic on this SA.



Kent & Seo                  Standards Track                    [Page 37]

RFC 4301              Security Architecture for IP         December 2005


    o Stateful fragment checking flag.  Indicates whether or not
      stateful fragment checking applies to this SA.

    o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
      inner and outer headers are IPv4.

    o DSCP values -- the set of DSCP values allowed for packets carried
      over this SA.  If no values are specified, no DSCP-specific
      filtering is applied.  If one or more values are specified, these
      are used to select one SA among several that match the traffic
      selectors for an outbound packet.  Note that these values are NOT
      checked against inbound traffic arriving on the SA.

    o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
      needed to restrict bypass of DSCP values -- applicable to tunnel
      mode SAs.  This feature maps DSCP values from an inner header to
      values in an outer header, e.g., to address covert channel
      signaling concerns.

    o Path MTU: any observed path MTU and aging variables.

    o Tunnel header IP source and destination address -- both addresses
      must be either IPv4 or IPv6 addresses.  The version implies the
      type of IP header to be used.  Only used when the IPsec protocol
      mode is tunnel.

4.4.2.2.  Relationship between SPD, PFP flag, packet, and SAD

      For each selector, the following tables show the relationship
      between the value in the SPD, the PFP flag, the value in the
      triggering packet, and the resulting value in the SAD.  Note that
      the administrative interface for IPsec can use various syntactic
      options to make it easier for the administrator to enter rules.
      For example, although a list of ranges is what IKEv2 sends, it
      might be clearer and less error prone for the user to enter a
      single IP address or IP address prefix.















Kent & Seo                  Standards Track                    [Page 38]

RFC 4301              Security Architecture for IP         December 2005


                                        Value in
                                        Triggering   Resulting SAD
         Selector  SPD Entry        PFP Packet       Entry
         --------  ---------------- --- ------------ --------------
         loc addr  list of ranges    0  IP addr "S"  list of ranges
                   ANY               0  IP addr "S"  ANY
                   list of ranges    1  IP addr "S"  "S"
                   ANY               1  IP addr "S"  "S"

         rem addr  list of ranges    0  IP addr "D"  list of ranges
                   ANY               0  IP addr "D"  ANY
                   list of ranges    1  IP addr "D"  "D"
                   ANY               1  IP addr "D"  "D"

         protocol  list of prot's*   0  prot. "P"    list of prot's*
                   ANY**             0  prot. "P"    ANY
                   OPAQUE****        0  prot. "P"    OPAQUE

                   list of prot's*   0  not avail.   discard packet
                   ANY**             0  not avail.   ANY
                   OPAQUE****        0  not avail.   OPAQUE

                   list of prot's*   1  prot. "P"    "P"
                   ANY**             1  prot. "P"    "P"
                   OPAQUE****        1  prot. "P"    ***

                   list of prot's*   1  not avail.   discard packet
                   ANY**             1  not avail.   discard packet
                   OPAQUE****        1  not avail.   ***






















Kent & Seo                  Standards Track                    [Page 39]

RFC 4301              Security Architecture for IP         December 2005


      If the protocol is one that has two ports, then there will be
      selectors for both Local and Remote ports.

                                        Value in
                                        Triggering   Resulting SAD
         Selector  SPD Entry        PFP Packet       Entry
         --------  ---------------- --- ------------ --------------
         loc port  list of ranges    0  src port "s" list of ranges
                   ANY               0  src port "s" ANY
                   OPAQUE            0  src port "s" OPAQUE

                   list of ranges    0  not avail.   discard packet
                   ANY               0  not avail.   ANY
                   OPAQUE            0  not avail.   OPAQUE

                   list of ranges    1  src port "s" "s"
                   ANY               1  src port "s" "s"
                   OPAQUE            1  src port "s" ***

                   list of ranges    1  not avail.   discard packet
                   ANY               1  not avail.   discard packet
                   OPAQUE            1  not avail.   ***


         rem port  list of ranges    0  dst port "d" list of ranges
                   ANY               0  dst port "d" ANY
                   OPAQUE            0  dst port "d" OPAQUE

                   list of ranges    0  not avail.   discard packet
                   ANY               0  not avail.   ANY
                   OPAQUE            0  not avail.   OPAQUE

                   list of ranges    1  dst port "d" "d"
                   ANY               1  dst port "d" "d"
                   OPAQUE            1  dst port "d" ***

                   list of ranges    1  not avail.   discard packet
                   ANY               1  not avail.   discard packet
                   OPAQUE            1  not avail.   ***












Kent & Seo                  Standards Track                    [Page 40]

RFC 4301              Security Architecture for IP         December 2005


      If the protocol is mobility header, then there will be a selector
      for mh type.

                                        Value in
                                        Triggering   Resulting SAD
         Selector  SPD Entry        PFP Packet       Entry
         --------  ---------------- --- ------------ --------------
         mh type   list of ranges    0  mh type "T"  list of ranges
                   ANY               0  mh type "T"  ANY
                   OPAQUE            0  mh type "T"  OPAQUE

                   list of ranges    0  not avail.   discard packet
                   ANY               0  not avail.   ANY
                   OPAQUE            0  not avail.   OPAQUE

                   list of ranges    1  mh type "T"  "T"
                   ANY               1  mh type "T"  "T"
                   OPAQUE            1  mh type "T"  ***

                   list of ranges    1  not avail.   discard packet
                   ANY               1  not avail.   discard packet
                   OPAQUE            1  not avail.   ***





























Kent & Seo                  Standards Track                    [Page 41]

RFC 4301              Security Architecture for IP         December 2005


      If the protocol is ICMP, then there will be a 16-bit selector for
      ICMP type and ICMP code.  Note that the type and code are bound to
      each other, i.e., the codes apply to the particular type.  This
      16-bit selector can contain a single type and a range of codes, a
      single type and ANY code, and ANY type and ANY code.

                                         Value in
                                         Triggering   Resulting SAD
         Selector   SPD Entry        PFP Packet       Entry
         ---------  ---------------- --- ------------ --------------
         ICMP type  a single type &   0  type "t" &   single type &
         and code    range of codes        code "c"    range of codes
                    a single type &   0  type "t" &   single type &
                     ANY code              code "c"    ANY code
                    ANY type & ANY    0  type "t" &   ANY type &
                     code                  code "c"    ANY code
                    OPAQUE            0  type "t" &   OPAQUE
                                           code "c"

                    a single type &   0  not avail.   discard packet
                     range of codes
                    a single type &   0  not avail.   discard packet
                     ANY code
                    ANY type &        0  not avail.   ANY type &
                     ANY code                          ANY code
                    OPAQUE            0  not avail.   OPAQUE

                    a single type &   1  type "t" &   "t" and "c"
                     range of codes        code "c"
                    a single type &   1  type "t" &   "t" and "c"
                     ANY code              code "c"
                    ANY type &        1  type "t" &   "t" and "c"
                     ANY code              code "c"
                    OPAQUE            1  type "t" &   ***
                                           code "c"

                    a single type &   1  not avail.   discard packet
                     range of codes
                    a single type &   1  not avail.   discard packet
                     ANY code
                    ANY type &        1  not avail.   discard packet
                     ANY code
                    OPAQUE            1  not avail.   ***








Kent & Seo                  Standards Track                    [Page 42]

RFC 4301              Security Architecture for IP         December 2005


      If the name selector is used:

                                         Value in
                                         Triggering   Resulting SAD
         Selector   SPD Entry        PFP Packet       Entry
         ---------  ---------------- --- ------------ --------------
         name       list of user or  N/A     N/A           N/A
                    system names

            * "List of protocols" is the information, not the way
              that the SPD or SAD or IKEv2 have to represent this
              information.
           ** 0 (zero) is used by IKE to indicate ANY for
              protocol.
          *** Use of PFP=1 with an OPAQUE value is an error and
              SHOULD be prohibited by an IPsec implementation.
         **** The protocol field cannot be OPAQUE in IPv4.  This
              table entry applies only to IPv6.

4.4.3.  Peer Authorization Database (PAD)

   The Peer Authorization Database (PAD) provides the link between the
   SPD and a security association management protocol such as IKE.  It
   embodies several critical functions:

        o identifies the peers or groups of peers that are authorized
          to communicate with this IPsec entity
        o specifies the protocol and method used to authenticate each
          peer
        o provides the authentication data for each peer
        o constrains the types and values of IDs that can be asserted
          by a peer with regard to child SA creation, to ensure that the
          peer does not assert identities for lookup in the SPD that it
          is not authorized to represent, when child SAs are created
        o peer gateway location info, e.g., IP address(es) or DNS names,
          MAY be included for peers that are known to be "behind" a
          security gateway

   The PAD provides these functions for an IKE peer when the peer acts
   as either the initiator or the responder.

   To perform these functions, the PAD contains an entry for each peer
   or group of peers with which the IPsec entity will communicate.  An
   entry names an individual peer (a user, end system or security
   gateway) or specifies a group of peers (using ID matching rules
   defined below).  The entry specifies the authentication protocol
   (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-
   shared secrets) and the authentication data (e.g., the pre-shared



Kent & Seo                  Standards Track                    [Page 43]

RFC 4301              Security Architecture for IP         December 2005


   secret or the trust anchor relative to which the peer's certificate
   will be validated).  For certificate-based authentication, the entry
   also may provide information to assist in verifying the revocation
   status of the peer, e.g., a pointer to a CRL repository or the name
   of an Online Certificate Status Protocol (OCSP) server associated
   with the peer or with the trust anchor associated with the peer.

   Each entry also specifies whether the IKE ID payload will be used as
   a symbolic name for SPD lookup, or whether the remote IP address
   provided in traffic selector payloads will be used for SPD lookups
   when child SAs are created.

   Note that the PAD information MAY be used to support creation of more
   than one tunnel mode SA at a time between two peers, e.g., two
   tunnels to protect the same addresses/hosts, but with different
   tunnel endpoints.

4.4.3.1.  PAD Entry IDs and Matching Rules

   The PAD is an ordered database, where the order is defined by an
   administrator (or a user in the case of a single-user end system).
   Usually, the same administrator will be responsible for both the PAD
   and SPD, since the two databases must be coordinated.  The ordering
   requirement for the PAD arises for the same reason as for the SPD,
   i.e., because use of "star name" entries allows for overlaps in the
   set of IKE IDs that could match a specific entry.

   Six types of IDs are supported for entries in the PAD, consistent
   with the symbolic name types and IP addresses used to identify SPD
   entries.  The ID for each entry acts as the index for the PAD, i.e.,
   it is the value used to select an entry.  All of these ID types can
   be used to match IKE ID payload types.  The six types are:

           o DNS name (specific or partial)
           o Distinguished Name (complete or sub-tree constrained)
           o RFC 822 email address (complete or partially qualified)
           o IPv4 address (range)
           o IPv6 address (range)
           o Key ID (exact match only)

   The first three name types can accommodate sub-tree matching as well
   as exact matches.  A DNS name may be fully qualified and thus match
   exactly one name, e.g., foo.example.com.  Alternatively, the name may
   encompass a group of peers by being partially specified, e.g., the
   string ".example.com" could be used to match any DNS name ending in
   these two domain name components.





Kent & Seo                  Standards Track                    [Page 44]

RFC 4301              Security Architecture for IP         December 2005


   Similarly, a Distinguished Name may specify a complete Distinguished
   Name to match exactly one entry, e.g., CN = Stephen, O = BBN
   Technologies, SP = MA, C = US.  Alternatively, an entry may encompass
   a group of peers by specifying a sub-tree, e.g., an entry of the form
   "C = US, SP = MA" might be used to match all DNs that contain these
   two attributes as the top two Relative Distinguished Names (RDNs).

   For an RFC 822 e-mail addresses, the same options exist.  A complete
   address such as foo@example.com matches one entity, but a sub-tree
   name such as "@example.com" could be used to match all the entities
   with names ending in those two domain names to the right of the @.

   The specific syntax used by an implementation to accommodate sub-tree
   matching for distinguished names, domain names or RFC 822 e-mail
   addresses is a local matter.  But, at a minimum, sub-tree matching of
   the sort described above MUST be supported. (Substring matching
   within a DN, DNS name, or RFC 822 address MAY be supported, but is
   not required.)

   For IPv4 and IPv6 addresses, the same address range syntax used for
   SPD entries MUST be supported.  This allows specification of an
   individual address (via a trivial range), an address prefix (by
   choosing a range that adheres to Classless Inter-Domain Routing
   (CIDR)-style prefixes), or an arbitrary address range.

   The Key ID field is defined as an OCTET string in IKE.  For this name
   type, only exact-match syntax MUST be supported (since there is no
   explicit structure for this ID type).  Additional matching functions
   MAY be supported for this ID type.

4.4.3.2.  IKE Peer Authentication Data

   Once an entry is located based on an ordered search of the PAD based
   on ID field matching, it is necessary to verify the asserted
   identity, i.e., to authenticate the asserted ID.  For each PAD entry,
   there is an indication of the type of authentication to be performed.
   This document requires support for two required authentication data
   types:

        - X.509 certificate
        - pre-shared secret

   For authentication based on an X.509 certificate, the PAD entry
   contains a trust anchor via which the end entity (EE) certificate for
   the peer must be verifiable, either directly or via a certificate
   path.  See RFC 3280 for the definition of a trust anchor.  An entry
   used with certificate-based authentication MAY include additional
   data to facilitate certificate revocation status, e.g., a list of



Kent & Seo                  Standards Track                    [Page 45]

RFC 4301              Security Architecture for IP         December 2005


   appropriate OCSP responders or CRL repositories, and associated
   authentication data.  For authentication based on a pre-shared
   secret, the PAD contains the pre-shared secret to be used by IKE.

   This document does not require that the IKE ID asserted by a peer be
   syntactically related to a specific field in an end entity
   certificate that is employed to authenticate the identity of that
   peer.  However, it often will be appropriate to impose such a
   requirement, e.g., when a single entry represents a set of peers each
   of whom may have a distinct SPD entry.  Thus, implementations MUST
   provide a means for an administrator to require a match between an
   asserted IKE ID and the subject name or subject alt name in a
   certificate.  The former is applicable to IKE IDs expressed as
   distinguished names; the latter is appropriate for DNS names, RFC 822
   e-mail addresses, and IP addresses.  Since KEY ID is intended for
   identifying a peer authenticated via a pre-shared secret, there is no
   requirement to match this ID type to a certificate field.

   See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
   performs peer authentication using certificates or pre-shared
   secrets.

   This document does not mandate support for any other authentication
   methods, although such methods MAY be employed.

4.4.3.3.  Child SA Authorization Data

   Once an IKE peer is authenticated, child SAs may be created.  Each
   PAD entry contains data to constrain the set of IDs that can be
   asserted by an IKE peer, for matching against the SPD.  Each PAD
   entry indicates whether the IKE ID is to be used as a symbolic name
   for SPD matching, or whether an IP address asserted in a traffic
   selector payload is to be used.

   If the entry indicates that the IKE ID is to be used, then the PAD
   entry ID field defines the authorized set of IDs.  If the entry
   indicates that child SAs traffic selectors are to be used, then an
   additional data element is required, in the form of IPv4 and/or IPv6
   address ranges. (A peer may be authorized for both address types, so
   there MUST be provision for both a v4 and a v6 address range.)

4.4.3.4.  How the PAD Is Used

   During the initial IKE exchange, the initiator and responder each
   assert their identity via the IKE ID payload and send an AUTH payload
   to verify the asserted identity.  One or more CERT payloads may be
   transmitted to facilitate the verification of each asserted identity.




Kent & Seo                  Standards Track                    [Page 46]

RFC 4301              Security Architecture for IP         December 2005


   When an IKE entity receives an IKE ID payload, it uses the asserted
   ID to locate an entry in the PAD, using the matching rules described
   above.  The PAD entry specifies the authentication method to be
   employed for the identified peer.  This ensures that the right method
   is used for each peer and that different methods can be used for
   different peers.  The entry also specifies the authentication data
   that will be used to verify the asserted identity.  This data is
   employed in conjunction with the specified method to authenticate the
   peer, before any CHILD SAs are created.

   Child SAs are created based on the exchange of traffic selector
   payloads, either at the end of the initial IKE exchange or in
   subsequent CREATE_CHILD_SA exchanges.  The PAD entry for the (now
   authenticated) IKE peer is used to constrain creation of child SAs;
   specifically, the PAD entry specifies how the SPD is searched using a
   traffic selector proposal from a peer.  There are two choices: either
   the IKE ID asserted by the peer is used to find an SPD entry via its
   symbolic name, or peer IP addresses asserted in traffic selector
   payloads are used for SPD lookups based on the remote IP address
   field portion of an SPD entry.  It is necessary to impose these
   constraints on creation of child SAs to prevent an authenticated peer
   from spoofing IDs associated with other, legitimate peers.

   Note that because the PAD is checked before searching for an SPD
   entry, this safeguard protects an initiator against spoofing attacks.
   For example, assume that IKE A receives an outbound packet destined
   for IP address X, a host served by a security gateway.  RFC 2401
   [RFC2401] and this document do not specify how A determines the
   address of the IKE peer serving X.  However, any peer contacted by A
   as the presumed representative for X must be registered in the PAD in
   order to allow the IKE exchange to be authenticated.  Moreover, when
   the authenticated peer asserts that it represents X in its traffic
   selector exchange, the PAD will be consulted to determine if the peer
   in question is authorized to represent X.  Thus, the PAD provides a
   binding of address ranges (or name sub-spaces) to peers, to counter
   such attacks.

4.5.  SA and Key Management

   All IPsec implementations MUST support both manual and automated SA
   and cryptographic key management.  The IPsec protocols, AH and ESP,
   are largely independent of the associated SA management techniques,
   although the techniques involved do affect some of the security
   services offered by the protocols.  For example, the optional
   anti-replay service available for AH and ESP requires automated SA
   management.  Moreover, the granularity of key distribution employed
   with IPsec determines the granularity of authentication provided.  In
   general, data origin authentication in AH and ESP is limited by the



Kent & Seo                  Standards Track                    [Page 47]

RFC 4301              Security Architecture for IP         December 2005


   extent to which secrets used with the integrity algorithm (or with a
   key management protocol that creates such secrets) are shared among
   multiple possible sources.

   The following text describes the minimum requirements for both types
   of SA management.

4.5.1.  Manual Techniques

   The simplest form of management is manual management, in which a
   person manually configures each system with keying material and SA
   management data relevant to secure communication with other systems.
   Manual techniques are practical in small, static environments but
   they do not scale well.  For example, a company could create a
   virtual private network (VPN) using IPsec in security gateways at
   several sites.  If the number of sites is small, and since all the
   sites come under the purview of a single administrative domain, this
   might be a feasible context for manual management techniques.  In
   this case, the security gateway might selectively protect traffic to
   and from other sites within the organization using a manually
   configured key, while not protecting traffic for other destinations.
   It also might be appropriate when only selected communications need
   to be secured.  A similar argument might apply to use of IPsec
   entirely within an organization for a small number of hosts and/or
   gateways.  Manual management techniques often employ statically
   configured, symmetric keys, though other options also exist.

4.5.2.  Automated SA and Key Management

   Widespread deployment and use of IPsec requires an Internet-standard,
   scalable, automated, SA management protocol.  Such support is
   required to facilitate use of the anti-replay features of AH and ESP,
   and to accommodate on-demand creation of SAs, e.g., for user- and
   session-oriented keying.  (Note that the notion of "rekeying" an SA
   actually implies creation of a new SA with a new SPI, a process that
   generally implies use of an automated SA/key management protocol.)

   The default automated key management protocol selected for use with
   IPsec is IKEv2 [Kau05].  This document assumes the availability of
   certain functions from the key management protocol that are not
   supported by IKEv1.  Other automated SA management protocols MAY be
   employed.

   When an automated SA/key management protocol is employed, the output
   from this protocol is used to generate multiple keys for a single SA.
   This also occurs because distinct keys are used for each of the two





Kent & Seo                  Standards Track                    [Page 48]

RFC 4301              Security Architecture for IP         December 2005


   SAs created by IKE.  If both integrity and confidentiality are
   employed, then a minimum of four keys are required.  Additionally,
   some cryptographic algorithms may require multiple keys, e.g., 3DES.

   The Key Management System may provide a separate string of bits for
   each key or it may generate one string of bits from which all keys
   are extracted.  If a single string of bits is provided, care needs to
   be taken to ensure that the parts of the system that map the string
   of bits to the required keys do so in the same fashion at both ends
   of the SA.  To ensure that the IPsec implementations at each end of
   the SA use the same bits for the same keys, and irrespective of which
   part of the system divides the string of bits into individual keys,
   the encryption keys MUST be taken from the first (left-most,
   high-order) bits and the integrity keys MUST be taken from the
   remaining bits.  The number of bits for each key is defined in the
   relevant cryptographic algorithm specification RFC.  In the case of
   multiple encryption keys or multiple integrity keys, the
   specification for the cryptographic algorithm must specify the order
   in which they are to be selected from a single string of bits
   provided to the cryptographic algorithm.

4.5.3.  Locating a Security Gateway

   This section discusses issues relating to how a host learns about the
   existence of relevant security gateways and, once a host has
   contacted these security gateways, how it knows that these are the
   correct security gateways.  The details of where the required
   information is stored is a local matter, but the Peer Authorization
   Database (PAD) described in Section 4.4 is the most likely candidate.
   (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2
   below.)

   Consider a situation in which a remote host (SH1) is using the
   Internet to gain access to a server or other machine (H2) and there
   is a security gateway (SG2), e.g., a firewall, through which H1's
   traffic must pass.  An example of this situation would be a mobile
   host crossing the Internet to his home organization's firewall (SG2).
   This situation raises several issues:

   1. How does SH1 know/learn about the existence of the security
      gateway SG2?

   2. How does it authenticate SG2, and once it has authenticated SG2,
      how does it confirm that SG2 has been authorized to represent H2?

   3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
      contact H2?




Kent & Seo                  Standards Track                    [Page 49]

RFC 4301              Security Architecture for IP         December 2005


   4. How does SH1 know/learn about any additional gateways that provide
      alternate paths to H2?

   To address these problems, an IPsec-supporting host or security
   gateway MUST have an administrative interface that allows the
   user/administrator to configure the address of one or more security
   gateways for ranges of destination addresses that require its use.
   This includes the ability to configure information for locating and
   authenticating one or more security gateways and verifying the
   authorization of these gateways to represent the destination host.
   (The authorization function is implied in the PAD.) This document
   does not address the issue of how to automate the
   discovery/verification of security gateways.

4.6.  SAs and Multicast

   The receiver-orientation of the SA implies that, in the case of
   unicast traffic, the destination system will select the SPI value.
   By having the destination select the SPI value, there is no potential
   for manually configured SAs to conflict with automatically configured
   (e.g., via a key management protocol) SAs or for SAs from multiple
   sources to conflict with each other.  For multicast traffic, there
   are multiple destination systems associated with a single SA.  So
   some system or person will need to coordinate among all multicast
   groups to select an SPI or SPIs on behalf of each multicast group and
   then communicate the group's IPsec information to all of the
   legitimate members of that multicast group via mechanisms not defined
   here.

   Multiple senders to a multicast group SHOULD use a single Security
   Association (and hence SPI) for all traffic to that group when a
   symmetric key encryption or integrity algorithm is employed.  In such
   circumstances, the receiver knows only that the message came from a
   system possessing the key for that multicast group.  In such
   circumstances, a receiver generally will not be able to authenticate
   which system sent the multicast traffic.  Specifications for other,
   more general multicast approaches are deferred to the IETF Multicast
   Security Working Group.

5.  IP Traffic Processing

   As mentioned in Section 4.4.1, "The Security Policy Database (SPD)",
   the SPD (or associated caches) MUST be consulted during the
   processing of all traffic that crosses the IPsec protection boundary,
   including IPsec management traffic.  If no policy is found in the SPD
   that matches a packet (for either inbound or outbound traffic), the
   packet MUST be discarded.  To simplify processing, and to allow for
   very fast SA lookups (for SG/BITS/BITW), this document introduces the



Kent & Seo                  Standards Track                    [Page 50]

RFC 4301              Security Architecture for IP         December 2005


   notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
   and a cache for inbound, non-IPsec-protected traffic (SPD-I).  (As
   mentioned earlier, the SAD acts as a cache for checking the selectors
   of inbound IPsec-protected traffic arriving on SAs.) There is
   nominally one cache per SPD.  For the purposes of this specification,
   it is assumed that each cached entry will map to exactly one SA.
   Note, however, exceptions arise when one uses multiple SAs to carry
   traffic of different priorities (e.g., as indicated by distinct DSCP
   values) but the same selectors.  Note also, that there are a couple
   of situations in which the SAD can have entries for SAs that do not
   have corresponding entries in the SPD.  Since this document does not
   mandate that the SAD be selectively cleared when the SPD is changed,
   SAD entries can remain when the SPD entries that created them are
   changed or deleted.  Also, if a manually keyed SA is created, there
   could be an SAD entry for this SA that does not correspond to any SPD
   entry.

   Since SPD entries may overlap, one cannot safely cache these entries
   in general.  Simple caching might result in a match against a cache
   entry, whereas an ordered search of the SPD would have resulted in a
   match against a different entry.  But, if the SPD entries are first
   decorrelated, then the resulting entries can safely be cached.  Each
   cached entry will indicate that matching traffic should be bypassed
   or discarded, appropriately. (Note: The original SPD entry might
   result in multiple SAs, e.g., because of PFP.) Unless otherwise
   noted, all references below to the "SPD" or "SPD cache" or "cache"
   are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
   containing entries from the decorrelated SPD.

   Note: In a host IPsec implementation based on sockets, the SPD will
   be consulted whenever a new socket is created to determine what, if
   any, IPsec processing will be applied to the traffic that will flow
   on that socket.  This provides an implicit caching mechanism, and the
   portions of the preceding discussion that address caching can be
   ignored in such implementations.

   Note: It is assumed that one starts with a correlated SPD because
   that is how users and administrators are accustomed to managing these
   sorts of access control lists or firewall filter rules.  Then the
   decorrelation algorithm is applied to build a list of cache-able SPD
   entries.  The decorrelation is invisible at the management interface.

   For inbound IPsec traffic, the SAD entry selected by the SPI serves
   as the cache for the selectors to be matched against arriving IPsec
   packets, after AH or ESP processing has been performed.






Kent & Seo                  Standards Track                    [Page 51]

RFC 4301              Security Architecture for IP         December 2005


5.1.  Outbound IP Traffic Processing (protected-to-unprotected)

   First consider the path for traffic entering the implementation via a
   protected interface and exiting via an unprotected interface.

                          Unprotected Interface
                                   ^
                                   |
            (nested SAs)      +----------+
           -------------------|Forwarding|<-----+
           |                  +----------+      |
           |                        ^           |
           |                        | BYPASS    |
           V                     +-----+        |
       +-------+                 | SPD |     +--------+
    ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
       |  (*)  |                 | (*) |---->|(AH/ESP)|   boundary
       +-------+                 +-----+     +--------+
           |        +-------+     /  ^
           |        |DISCARD| <--/   |
           |        +-------+        |
           |                         |
           |                 +-------------+
           |---------------->|SPD Selection|
                             +-------------+
                                    ^
                                    |     +------+
                                    |  -->| ICMP |
                                    | /   +------+
                                    |/
                                    |
                                    |
                            Protected Interface


         Figure 2.  Processing Model for Outbound Traffic
                    (*) = The SPD caches are shown here.  If there
                          is a cache miss, then the SPD is checked.
                          There is no requirement that an
                          implementation buffer the packet if
                          there is a cache miss.










Kent & Seo                  Standards Track                    [Page 52]

RFC 4301              Security Architecture for IP         December 2005


   IPsec MUST perform the following steps when processing outbound
   packets:

   1.  When a packet arrives from the subscriber (protected) interface,
       invoke the SPD selection function to obtain the SPD-ID needed to
       choose the appropriate SPD. (If the implementation uses only one
       SPD, this step is a no-op.)

   2.  Match the packet headers against the cache for the SPD specified
       by the SPD-ID from step 1.  Note that this cache contains entries
       from SPD-O and SPD-S.

   3a. If there is a match, then process the packet as specified by the
       matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
       or ESP.  If IPsec processing is applied, there is a link from the
       SPD cache entry to the relevant SAD entry (specifying the mode,
       cryptographic algorithms, keys, SPI, PMTU, etc.).  IPsec
       processing is as previously defined, for tunnel or transport
       modes and for AH or ESP, as specified in their respective RFCs
       [Ken05b, Ken05a].  Note that the SA PMTU value, plus the value of
       the stateful fragment checking flag (and the DF bit in the IP
       header of the outbound packet) determine whether the packet can
       (must) be fragmented prior to or after IPsec processing, or if it
       must be discarded and an ICMP PMTU message is sent.

   3b. If no match is found in the cache, search the SPD (SPD-S and
       SPD-O parts) specified by SPD-ID.  If the SPD entry calls for
       BYPASS or DISCARD, create one or more new outbound SPD cache
       entries and if BYPASS, create one or more new inbound SPD cache
       entries. (More than one cache entry may be created since a
       decorrelated SPD entry may be linked to other such entries that
       were created as a side effect of the decorrelation process.) If
       the SPD entry calls for PROTECT, i.e., creation of an SA, the key
       management mechanism (e.g., IKEv2) is invoked to create the SA.
       If SA creation succeeds, a new outbound (SPD-S) cache entry is
       created, along with outbound and inbound SAD entries, otherwise
       the packet is discarded. (A packet that triggers an SPD lookup
       MAY be discarded by the implementation, or it MAY be processed
       against the newly created cache entry, if one is created.)  Since
       SAs are created in pairs, an SAD entry for the corresponding
       inbound SA also is created, and it contains the selector values
       derived from the SPD entry (and packet, if any PFP flags were
       "true") used to create the inbound SA, for use in checking
       inbound traffic delivered via the SA.

   4.  The packet is passed to the outbound forwarding function
       (operating outside of the IPsec implementation), to select the
       interface to which the packet will be directed.  This function



Kent & Seo                  Standards Track                    [Page 53]

RFC 4301              Security Architecture for IP         December 2005


       may cause the packet to be passed back across the IPsec boundary,
       for additional IPsec processing, e.g., in support of nested SAs.
       If so, there MUST be an entry in SPD-I database that permits
       inbound bypassing of the packet, otherwise the packet will be
       discarded.  If necessary, i.e., if there is more than one SPD-I,
       the traffic being looped back MAY be tagged as coming from this
       internal interface.  This would allow the use of a different
       SPD-I for "real" external traffic vs. looped traffic, if needed.

   Note: With the exception of IPv4 and IPv6 transport mode, an SG,
   BITS, or BITW implementation MAY fragment packets before applying
   IPsec. (This applies only to IPv4.  For IPv6 packets, only the
   originator is allowed to fragment them.) The device SHOULD have a
   configuration setting to disable this.  The resulting fragments are
   evaluated against the SPD in the normal manner.  Thus, fragments not
   containing port numbers (or ICMP message type and code, or Mobility
   Header type) will only match rules having port (or ICMP message type
   and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for
   more details.)

   Note: With regard to determining and enforcing the PMTU of an SA, the
   IPsec system MUST follow the steps described in Section 8.2.

5.1.1.  Handling an Outbound Packet That Must Be Discarded

   If an IPsec system receives an outbound packet that it finds it must
   discard, it SHOULD be capable of generating and sending an ICMP
   message to indicate to the sender of the outbound packet that the
   packet was discarded.  The type and code of the ICMP message will
   depend on the reason for discarding the packet, as specified below.
   The reason SHOULD be recorded in the audit log.  The audit log entry
   for this event SHOULD include the reason, current date/time, and the
   selector values from the packet.

   a.  The selectors of the packet matched an SPD entry requiring the
       packet to be discarded.

           IPv4 Type = 3 (destination unreachable) Code = 13
                (Communication Administratively Prohibited)

           IPv6 Type = 1 (destination unreachable) Code = 1
                (Communication with destination administratively
                prohibited)

   b1. The IPsec system successfully reached the remote peer but was
       unable to negotiate the SA required by the SPD entry matching the
       packet because, for example, the remote peer is administratively
       prohibited from communicating with the initiator, the initiating



Kent & Seo                  Standards Track                    [Page 54]

RFC 4301              Security Architecture for IP         December 2005


       peer was unable to authenticate itself to the remote peer, the
       remote peer was unable to authenticate itself to the initiating
       peer, or the SPD at the remote peer did not have a suitable
       entry.

           IPv4 Type = 3 (destination unreachable) Code = 13
                (Communication Administratively Prohibited)

           IPv6 Type = 1 (destination unreachable) Code = 1
                (Communication with destination administratively
                prohibited)

   b2. The IPsec system was unable to set up the SA required by the SPD
       entry matching the packet because the IPsec peer at the other end
       of the exchange could not be contacted.

           IPv4 Type = 3 (destination unreachable) Code = 1 (host
                unreachable)

           IPv6 Type = 1 (destination unreachable) Code = 3 (address
                unreachable)

   Note that an attacker behind a security gateway could send packets
   with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
   to send ICMP messages to W.X.Y.Z.  This creates an opportunity for a
   denial of service (DoS) attack among hosts behind a security gateway.
   To address this, a security gateway SHOULD include a management
   control to allow an administrator to configure an IPsec
   implementation to send or not send the ICMP messages under these
   circumstances, and if this facility is selected, to rate limit the
   transmission of such ICMP responses.

5.1.2.  Header Construction for Tunnel Mode

   This section describes the handling of the inner and outer IP
   headers, extension headers, and options for AH and ESP tunnels, with
   regard to outbound traffic processing.  This includes how to
   construct the encapsulating (outer) IP header, how to process fields
   in the inner IP header, and what other actions should be taken for
   outbound, tunnel mode traffic.  The general processing described here
   is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:

    o The outer IP header Source Address and Destination Address
      identify the "endpoints" of the tunnel (the encapsulator and
      decapsulator).  The inner IP header Source Address and Destination
      Addresses identify the original sender and recipient of the
      datagram (from the perspective of this tunnel), respectively.




Kent & Seo                  Standards Track                    [Page 55]

RFC 4301              Security Architecture for IP         December 2005


      (See footnote 3 after the table in 5.1.2.1 for more details on the
      encapsulating source IP address.)

    o The inner IP header is not changed except as noted below for TTL
      (or Hop Limit) and the DS/ECN Fields.  The inner IP header
      otherwise remains unchanged during its delivery to the tunnel exit
      point.

    o No change to IP options or extension headers in the inner header
      occurs during delivery of the encapsulated datagram through the
      tunnel.

   Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
   2003 [Per96]) in several ways:

    o IPsec offers certain controls to a security administrator to
      manage covert channels (which would not normally be a concern for
      tunneling) and to ensure that the receiver examines the right
      portions of the received packet with respect to application of
      access controls.  An IPsec implementation MAY be configurable with
      regard to how it processes the outer DS field for tunnel mode for
      transmitted packets.  For outbound traffic, one configuration
      setting for the outer DS field will operate as described in the
      following sections on IPv4 and IPv6 header processing for IPsec
      tunnels.  Another will allow the outer DS field to be mapped to a
      fixed value, which MAY be configured on a per-SA basis. (The value
      might really be fixed for all traffic outbound from a device, but
      per-SA granularity allows that as well.) This configuration option
      allows a local administrator to decide whether the covert channel
      provided by copying these bits outweighs the benefits of copying.

    o IPsec describes how to handle ECN or DS and provides the ability
      to control propagation of changes in these fields between
      unprotected and protected domains.  In general, propagation from a
      protected to an unprotected domain is a covert channel and thus
      controls are provided to manage the bandwidth of this channel.
      Propagation of ECN values in the other direction are controlled so
      that only legitimate ECN changes (indicating occurrence of
      congestion between the tunnel endpoints) are propagated.  By
      default, DS propagation from an unprotected domain to a protected
      domain is not permitted.  However, if the sender and receiver do
      not share the same DS code space, and the receiver has no way of
      learning how to map between the two spaces, then it may be
      appropriate to deviate from the default.  Specifically, an IPsec
      implementation MAY be configurable in terms of how it processes
      the outer DS field for tunnel mode for received packets.  It may
      be configured to either discard the outer DS value (the default)
      OR to overwrite the inner DS field with the outer DS field.  If



Kent & Seo                  Standards Track                    [Page 56]

RFC 4301              Security Architecture for IP         December 2005


      offered, the discard vs. overwrite behavior MAY be configured on a
      per-SA basis.  This configuration option allows a local
      administrator to decide whether the vulnerabilities created by
      copying these bits outweigh the benefits of copying.  See
      [RFC2983] for further information on when each of these behaviors
      may be useful, and also for the possible need for diffserv traffic
      conditioning prior or subsequent to IPsec processing (including
      tunnel decapsulation).

    o IPsec allows the IP version of the encapsulating header to be
      different from that of the inner header.

   The tables in the following sub-sections show the handling for the
   different header/option fields ("constructed" means that the value in
   the outer field is constructed independently of the value in the
   inner).

5.1.2.1.  IPv4: Header Construction for Tunnel Mode

                         <-- How Outer Hdr Relates to Inner Hdr -->
                         Outer Hdr at                 Inner Hdr at
    IPv4                 Encapsulator                 Decapsulator
      Header fields:     --------------------         ------------
        version          4 (1)                        no change
        header length    constructed                  no change
        DS Field         copied from inner hdr (5)    no change
        ECN Field        copied from inner hdr        constructed (6)
        total length     constructed                  no change
        ID               constructed                  no change
        flags (DF,MF)    constructed, DF (4)          no change
        fragment offset  constructed                  no change
        TTL              constructed (2)              decrement (2)
        protocol         AH, ESP                      no change
        checksum         constructed                  constructed (2)(6)
        src address      constructed (3)              no change
        dest address     constructed (3)              no change
      Options            never copied                 no change

    Notes:

      (1) The IP version in the encapsulating header can be different
          from the value in the inner header.

      (2) The TTL in the inner header is decremented by the encapsulator
          prior to forwarding and by the decapsulator if it forwards the
          packet.  (The IPv4 checksum changes when the TTL changes.)





Kent & Seo                  Standards Track                    [Page 57]

RFC 4301              Security Architecture for IP         December 2005


          Note: Decrementing the TTL value is a normal part of
          forwarding a packet.  Thus, a packet originating from the same
          node as the encapsulator does not have its TTL decremented,
          since the sending node is originating the packet rather than
          forwarding it.  This applies to BITS and native IPsec
          implementations in hosts and routers.  However, the IPsec
          processing model includes an external forwarding capability.
          TTL processing can be used to prevent looping of packets,
          e.g., due to configuration errors, within the context of this
          processing model.

      (3) Local and Remote addresses depend on the SA, which is used to
          determine the Remote address, which in turn determines which
          Local address (net interface) is used to forward the packet.

          Note: For multicast traffic, the destination address, or
          source and destination addresses, may be required for
          demuxing.  In that case, it is important to ensure consistency
          over the lifetime of the SA by ensuring that the source
          address that appears in the encapsulating tunnel header is the
          same as the one that was negotiated during the SA
          establishment process.  There is an exception to this general
          rule, i.e., a mobile IPsec implementation will update its
          source address as it moves.

      (4) Configuration determines whether to copy from the inner header
          (IPv4 only), clear, or set the DF.

      (5) If the packet will immediately enter a domain for which the
          DSCP value in the outer header is not appropriate, that value
          MUST be mapped to an appropriate value for the domain
          [NiBlBaBL98].  See RFC 2475 [BBCDWW98] for further
          information.

      (6) If the ECN field in the inner header is set to ECT(0) or
          ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
          ECN field in the outer header is set to Congestion Experienced
          (CE), then set the ECN field in the inner header to CE;
          otherwise, make no change to the ECN field in the inner
          header.  (The IPv4 checksum changes when the ECN changes.)

   Note: IPsec does not copy the options from the inner header into the
   outer header, nor does IPsec construct the options in the outer
   header.  However, post-IPsec code MAY insert/construct options for
   the outer header.






Kent & Seo                  Standards Track                    [Page 58]

RFC 4301              Security Architecture for IP         December 2005


5.1.2.2.  IPv6: Header Construction for Tunnel Mode

                         <-- How Outer Hdr  Relates Inner Hdr --->
                         Outer Hdr at                 Inner Hdr at
    IPv6                 Encapsulator                 Decapsulator
      Header fields:     --------------------         ------------
        version          6 (1)                        no change
        DS Field         copied from inner hdr (5)    no change (9)
        ECN Field        copied from inner hdr        constructed (6)
        flow label       copied or configured (8)     no change
        payload length   constructed                  no change
        next header      AH,ESP,routing hdr           no change
        hop limit        constructed (2)              decrement (2)
        src address      constructed (3)              no change
        dest address     constructed (3)              no change
      Extension headers  never copied (7)             no change

    Notes:

      (1) - (6) See Section 5.1.2.1.

      (7) IPsec does not copy the extension headers from the inner
          packet into outer headers, nor does IPsec construct extension
          headers in the outer header.  However, post-IPsec code MAY
          insert/construct extension headers for the outer header.

      (8) See [RaCoCaDe04].  Copying is acceptable only for end systems,
          not SGs.  If an SG copied flow labels from the inner header to
          the outer header, collisions might result.

      (9) An implementation MAY choose to provide a facility to pass the
          DS value from the outer header to the inner header, on a per-
          SA basis, for received tunnel mode packets.  The motivation
          for providing this feature is to accommodate situations in
          which the DS code space at the receiver is different from that
          of the sender and the receiver has no way of knowing how to
          translate from the sender's space.  There is a danger in
          copying this value from the outer header to the inner header,
          since it enables an attacker to modify the outer DSCP value in
          a fashion that may adversely affect other traffic at the
          receiver.  Hence the default behavior for IPsec
          implementations is NOT to permit such copying.

5.2.  Processing Inbound IP Traffic (unprotected-to-protected)

   Inbound processing is somewhat different from outbound processing,
   because of the use of SPIs to map IPsec-protected traffic to SAs.
   The inbound SPD cache (SPD-I) is applied only to bypassed or



Kent & Seo                  Standards Track                    [Page 59]

RFC 4301              Security Architecture for IP         December 2005


   discarded traffic.  If an arriving packet appears to be an IPsec
   fragment from an unprotected interface, reassembly is performed prior
   to IPsec processing.  The intent for any SPD cache is that a packet
   that fails to match any entry is then referred to the corresponding
   SPD.  Every SPD SHOULD have a nominal, final entry that catches
   anything that is otherwise unmatched, and discards it.  This ensures
   that non-IPsec-protected traffic that arrives and does not match any
   SPD-I entry will be discarded.

                      Unprotected Interface
                                |
                                V
                             +-----+   IPsec protected
         ------------------->|Demux|-------------------+
         |                   +-----+                   |
         |                      |                      |
         |            Not IPsec |                      |
         |                      |                      |
         |                      V                      |
         |     +-------+    +---------+                |
         |     |DISCARD|<---|SPD-I (*)|                |
         |     +-------+    +---------+                |
         |                   |                         |
         |                   |-----+                   |
         |                   |     |                   |
         |                   |     V                   |
         |                   |  +------+               |
         |                   |  | ICMP |               |
         |                   |  +------+               |
         |                   |                         V
      +---------+            |                   +-----------+
  ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
      +---------+            |                   | (AH/ESP)  | Boundary
         ^                   |                   +-----------+
         |                   |       +---+             |
         |            BYPASS |   +-->|IKE|             |
         |                   |   |   +---+             |
         |                   V   |                     V
         |               +----------+          +---------+   +----+
         |--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
           nested SAs    +----------+          | (***)   |   +----+
                               |               +---------+
                               V
                       Protected Interface

            Figure 3.  Processing Model for Inbound Traffic





Kent & Seo                  Standards Track                    [Page 60]

RFC 4301              Security Architecture for IP         December 2005


                       (*) = The caches are shown here.  If there is
                             a cache miss, then the SPD is checked.
                             There is no requirement that an
                             implementation buffer the packet if
                             there is a cache miss.
                      (**) = This processing includes using the
                             packet's SPI, etc., to look up the SA
                             in the SAD, which forms a cache of the
                             SPD for inbound packets (except for
                             cases noted in Sections 4.4.2 and 5).
                             See step 3a below.
                     (***) = This SAD check refers to step 4 below.

   Prior to performing AH or ESP processing, any IP fragments that
   arrive via the unprotected interface are reassembled (by IP).  Each
   inbound IP datagram to which IPsec processing will be applied is
   identified by the appearance of the AH or ESP values in the IP Next
   Protocol field (or of AH or ESP as a next layer protocol in the IPv6
   context).

   IPsec MUST perform the following steps:

   1.  When a packet arrives, it may be tagged with the ID of the
       interface (physical or virtual) via which it arrived, if
       necessary, to support multiple SPDs and associated SPD-I caches.
       (The interface ID is mapped to a corresponding SPD-ID.)

   2.  The packet is examined and demuxed into one of two categories:
       - If the packet appears to be IPsec protected and it is addressed
         to this device, an attempt is made to map it to an active SA
         via the SAD.  Note that the device may have multiple IP
         addresses that may be used in the SAD lookup, e.g., in the case
         of protocols such as SCTP.
       - Traffic not addressed to this device, or addressed to this
         device and not AH or ESP, is directed to SPD-I lookup. (This
         implies that IKE traffic MUST have an explicit BYPASS entry in
         the SPD.) If multiple SPDs are employed, the tag assigned to
         the packet in step 1 is used to select the appropriate SPD-I
         (and cache) to search.  SPD-I lookup determines whether the
         action is DISCARD or BYPASS.

   3a. If the packet is addressed to the IPsec device and AH or ESP is
       specified as the protocol, the packet is looked up in the SAD.
       For unicast traffic, use only the SPI (or SPI plus protocol).
       For multicast traffic, use the SPI plus the destination or SPI
       plus destination and source addresses, as specified in Section
       4.1. In either case (unicast or multicast), if there is no match,
       discard the traffic.  This is an auditable event.  The audit log



Kent & Seo                  Standards Track                    [Page 61]

RFC 4301              Security Architecture for IP         December 2005


       entry for this event SHOULD include the current date/time, SPI,
       source and destination of the packet, IPsec protocol, and any
       other selector values of the packet that are available.  If the
       packet is found in the SAD, process it accordingly (see step 4).

   3b. If the packet is not addressed to the device or is addressed to
       this device and is not AH or ESP, look up the packet header in
       the (appropriate) SPD-I cache.  If there is a match and the
       packet is to be discarded or bypassed, do so.  If there is no
       cache match, look up the packet in the corresponding SPD-I and
       create a cache entry as appropriate. (No SAs are created in
       response to receipt of a packet that requires IPsec protection;
       only BYPASS or DISCARD cache entries can be created this way.) If
       there is no match, discard the traffic.  This is an auditable
       event.  The audit log entry for this event SHOULD include the
       current date/time, SPI if available, IPsec protocol if available,
       source and destination of the packet, and any other selector
       values of the packet that are available.

   3c. Processing of ICMP messages is assumed to take place on the
       unprotected side of the IPsec boundary.  Unprotected ICMP
       messages are examined and local policy is applied to determine
       whether to accept or reject these messages and, if accepted, what
       action to take as a result.  For example, if an ICMP unreachable
       message is received, the implementation must decide whether to
       act on it, reject it, or act on it with constraints. (See Section
       6.)

   4.  Apply AH or ESP processing as specified, using the SAD entry
       selected in step 3a above.  Then match the packet against the
       inbound selectors identified by the SAD entry to verify that the
       received packet is appropriate for the SA via which it was
       received.

   5.  If an IPsec system receives an inbound packet on an SA and the
       packet's header fields are not consistent with the selectors for
       the SA, it MUST discard the packet.  This is an auditable event.
       The audit log entry for this event SHOULD include the current
       date/time, SPI, IPsec protocol(s), source and destination of the
       packet, any other selector values of the packet that are
       available, and the selector values from the relevant SAD entry.
       The system SHOULD also be capable of generating and sending an
       IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
       indicating that the received packet was discarded because of
       failure to pass selector checks.






Kent & Seo                  Standards Track                    [Page 62]

RFC 4301              Security Architecture for IP         December 2005


   To minimize the impact of a DoS attack, or a mis-configured peer, the
   IPsec system SHOULD include a management control to allow an
   administrator to configure the IPsec implementation to send or not
   send this IKE notification, and if this facility is selected, to rate
   limit the transmission of such notifications.

   After traffic is bypassed or processed through IPsec, it is handed to
   the inbound forwarding function for disposition.  This function may
   cause the packet to be sent (outbound) across the IPsec boundary for
   additional inbound IPsec processing, e.g., in support of nested SAs.
   If so, then as with ALL outbound traffic that is to be bypassed, the
   packet MUST be matched against an SPD-O entry.  Ultimately, the
   packet should be forwarded to the destination host or process for
   disposition.

6.  ICMP Processing

   This section describes IPsec handling of ICMP traffic.  There are two
   categories of ICMP traffic: error messages (e.g., type = destination
   unreachable) and non-error messages (e.g., type = echo).  This
   section applies exclusively to error messages.  Disposition of
   non-error, ICMP messages (that are not addressed to the IPsec
   implementation itself) MUST be explicitly accounted for using SPD
   entries.

   The discussion in this section applies to ICMPv6 as well as to
   ICMPv4.  Also, a mechanism SHOULD be provided to allow an
   administrator to cause ICMP error messages (selected, all, or none)
   to be logged as an aid to problem diagnosis.

6.1.  Processing ICMP Error Messages Directed to an IPsec Implementation

6.1.1.  ICMP Error Messages Received on the Unprotected Side of the
        Boundary

   Figure 3 in Section 5.2 shows a distinct ICMP processing module on
   the unprotected side of the IPsec boundary, for processing ICMP
   messages (error or otherwise) that are addressed to the IPsec device
   and that are not protected via AH or ESP.  An ICMP message of this
   sort is unauthenticated, and its processing may result in denial or
   degradation of service.  This suggests that, in general, it would be
   desirable to ignore such messages.  However, many ICMP messages will
   be received by hosts or security gateways from unauthenticated
   sources, e.g., routers in the public Internet.  Ignoring these ICMP
   messages can degrade service, e.g., because of a failure to process
   PMTU message and redirection messages.  Thus, there is also a
   motivation for accepting and acting upon unauthenticated ICMP
   messages.



Kent & Seo                  Standards Track                    [Page 63]

RFC 4301              Security Architecture for IP         December 2005


   To accommodate both ends of this spectrum, a compliant IPsec
   implementation MUST permit a local administrator to configure an
   IPsec implementation to accept or reject unauthenticated ICMP
   traffic.  This control MUST be at the granularity of ICMP type and
   MAY be at the granularity of ICMP type and code.  Additionally, an
   implementation SHOULD incorporate mechanisms and parameters for
   dealing with such traffic.  For example, there could be the ability
   to establish a minimum PMTU for traffic (on a per destination basis),
   to prevent receipt of an unauthenticated ICMP from setting the PMTU
   to a trivial size.

   If an ICMP PMTU message passes the checks above and the system is
   configured to accept it, then there are two possibilities.  If the
   implementation applies fragmentation on the ciphertext side of the
   boundary, then the accepted PMTU information is passed to the
   forwarding module (outside of the IPsec implementation), which uses
   it to manage outbound packet fragmentation.  If the implementation is
   configured to effect plaintext side fragmentation, then the PMTU
   information is passed to the plaintext side and processed as
   described in Section 8.2.

6.1.2.  ICMP Error Messages Received on the Protected Side of the
        Boundary

   These ICMP messages are not authenticated, but they do come from
   sources on the protected side of the IPsec boundary.  Thus, these
   messages generally are viewed as more "trustworthy" than their
   counterparts arriving from sources on the unprotected side of the
   boundary.  The major security concern here is that a compromised host
   or router might emit erroneous ICMP error messages that could degrade
   service for other devices "behind" the security gateway, or that
   could even result in violations of confidentiality.  For example, if
   a bogus ICMP redirect were consumed by a security gateway, it could
   cause the forwarding table on the protected side of the boundary to
   be modified so as to deliver traffic to an inappropriate destination
   "behind" the gateway.  Thus, implementers MUST provide controls to
   allow local administrators to constrain the processing of ICMP error
   messages received on the protected side of the boundary, and directed
   to the IPsec implementation.  These controls are of the same type as
   those employed on the unprotected side, described above in Section
   6.1.1.

6.2.  Processing Protected, Transit ICMP Error Messages

   When an ICMP error message is transmitted via an SA to a device
   "behind" an IPsec implementation, both the payload and the header of
   the ICMP message require checking from an access control perspective.
   If one of these messages is forwarded to a host behind a security



Kent & Seo                  Standards Track                    [Page 64]

RFC 4301              Security Architecture for IP         December 2005


   gateway, the receiving host IP implementation will make decisions
   based on the payload, i.e., the header of the packet that purportedly
   triggered the error response.  Thus, an IPsec implementation MUST be
   configurable to check that this payload header information is
   consistent with the SA via which it arrives. (This means that the
   payload header, with source and destination address and port fields
   reversed, matches the traffic selectors for the SA.) If this sort of
   check is not performed, then, for example, anyone with whom the
   receiving IPsec system (A) has an active SA could send an ICMP
   Destination Unreachable message that refers to any host/net with
   which A is currently communicating, and thus effect a highly
   efficient DoS attack regarding communication with other peers of A.
   Normal IPsec receiver processing of traffic is not sufficient to
   protect against such attacks.  However, not all contexts may require
   such checks, so it is also necessary to allow a local administrator
   to configure an implementation to NOT perform such checks.

   To accommodate both policies, the following convention is adopted.
   If an administrator wants to allow ICMP error messages to be carried
   by an SA without inspection of the payload, then configure an SPD
   entry that explicitly allows for carriage of such traffic.  If an
   administrator wants IPsec to check the payload of ICMP error messages
   for consistency, then do not create any SPD entries that accommodate
   carriage of such traffic based on the ICMP packet header.  This
   convention motivates the following processing description.

   IPsec senders and receivers MUST support the following processing for
   ICMP error messages that are sent and received via SAs.

   If an SA exists that accommodates an outbound ICMP error message,
   then the message is mapped to the SA and only the IP and ICMP headers
   are checked upon receipt, just as would be the case for other
   traffic.  If no SA exists that matches the traffic selectors
   associated with an ICMP error message, then the SPD is searched to
   determine if such an SA can be created.  If so, the SA is created and
   the ICMP error message is transmitted via that SA.  Upon receipt,
   this message is subject to the usual traffic selector checks at the
   receiver.  This processing is exactly what would happen for traffic
   in general, and thus does not represent any special processing for
   ICMP error messages.

   If no SA exists that would carry the outbound ICMP message in
   question, and if no SPD entry would allow carriage of this outbound
   ICMP error message, then an IPsec implementation MUST map the message
   to the SA that would carry the return traffic associated with the
   packet that triggered the ICMP error message.  This requires an IPsec
   implementation to detect outbound ICMP error messages that map to no
   extant SA or SPD entry, and treat them specially with regard to SA



Kent & Seo                  Standards Track                    [Page 65]

RFC 4301              Security Architecture for IP         December 2005


   creation and lookup.  The implementation extracts the header for the
   packet that triggered the error (from the ICMP message payload),
   reverses the source and destination IP address fields, extracts the
   protocol field, and reverses the port fields (if accessible).  It
   then uses this extracted information to locate an appropriate, active
   outbound SA, and transmits the error message via this SA.  If no such
   SA exists, no SA will be created, and this is an auditable event.

   If an IPsec implementation receives an inbound ICMP error message on
   an SA, and the IP and ICMP headers of the message do not match the
   traffic selectors for the SA, the receiver MUST process the received
   message in a special fashion.  Specifically, the receiver must
   extract the header of the triggering packet from the ICMP payload,
   and reverse fields as described above to determine if the packet is
   consistent with the selectors for the SA via which the ICMP error
   message was received.  If the packet fails this check, the IPsec
   implementation MUST NOT forwarded the ICMP message to the
   destination.  This is an auditable event.

7.  Handling Fragments (on the protected side of the IPsec boundary)

   Earlier sections of this document describe mechanisms for (a)
   fragmenting an outbound packet after IPsec processing has been
   applied and reassembling it at the receiver before IPsec processing
   and (b) handling inbound fragments received from the unprotected side
   of the IPsec boundary.  This section describes how an implementation
   should handle the processing of outbound plaintext fragments on the
   protected side of the IPsec boundary. (See Appendix D, "Fragment
   Handling Rationale".) In particular, it addresses:

        o mapping an outbound non-initial fragment to the right SA
          (or finding the right SPD entry)
        o verifying that a received non-initial fragment is
          authorized for the SA via which it was received
        o mapping outbound and inbound non-initial fragments to the
          right SPD-O/SPD-I entry or the relevant cache entry, for
          BYPASS/DISCARD traffic

   Note: In Section 4.1, transport mode SAs have been defined to not
   carry fragments (IPv4 or IPv6).  Note also that in Section 4.4.1, two
   special values, ANY and OPAQUE, were defined for selectors and that
   ANY includes OPAQUE.  The term "non-trivial" is used to mean that the
   selector has a value other than OPAQUE or ANY.

   Note: The term "non-initial fragment" is used here to indicate a
   fragment that does not contain all the selector values that may be
   needed for access control.  As observed in Section 4.4.1, depending
   on the Next Layer Protocol, in addition to Ports, the ICMP message



Kent & Seo                  Standards Track                    [Page 66]

RFC 4301              Security Architecture for IP         December 2005


   type/code or Mobility Header type could be missing from non-initial
   fragments.  Also, for IPv6, even the first fragment might NOT contain
   the Next Layer Protocol or Ports (or ICMP message type/code, or
   Mobility Header type) depending on the kind and number of extension
   headers present.  If a non-initial fragment contains the Port (or
   ICMP type and code or Mobility Header type) but not the Next Layer
   Protocol, then unless there is an SPD entry for the relevant
   Local/Remote addresses with ANY for Next Layer Protocol and Port (or
   ICMP type and code or Mobility Header type), the fragment would not
   contain all the selector information needed for access control.

   To address the above issues, three approaches have been defined:

       o Tunnel mode SAs that carry initial and non-initial fragments
         (See Section 7.1.)
       o Separate tunnel mode SAs for non-initial fragments (See
         Section 7.2.)
       o Stateful fragment checking (See Section 7.3.)

7.1.  Tunnel Mode SAs that Carry Initial and Non-Initial Fragments

   All implementations MUST support tunnel mode SAs that are configured
   to pass traffic without regard to port field (or ICMP type/code or
   Mobility Header type) values.  If the SA will carry traffic for
   specified protocols, the selector set for the SA MUST specify the
   port fields (or ICMP type/code or Mobility Header type) as ANY.  An
   SA defined in this fashion will carry all traffic including initial
   and non-initial fragments for the indicated Local/Remote addresses
   and specified Next Layer protocol(s).  If the SA will carry traffic
   without regard to a specific protocol value (i.e., ANY is specified
   as the (Next Layer) protocol selector value), then the port field
   values are undefined and MUST be set to ANY as well. (As noted in
   4.4.1, ANY includes OPAQUE as well as all specific values.)

7.2.  Separate Tunnel Mode SAs for Non-Initial Fragments

   An implementation MAY support tunnel mode SAs that will carry only
   non-initial fragments, separate from non-fragmented packets and
   initial fragments.  The OPAQUE value will be used to specify port (or
   ICMP type/code or Mobility Header type) field selectors for an SA to
   carry such fragments.  Receivers MUST perform a minimum offset check
   on IPv4 (non-initial) fragments to protect against overlapping
   fragment attacks when SAs of this type are employed.  Because such
   checks cannot be performed on IPv6 non-initial fragments, users and
   administrators are advised that carriage of such fragments may be
   dangerous, and implementers may choose to NOT support such SAs for
   IPv6 traffic.  Also, an SA of this sort will carry all non-initial
   fragments that match a specified Local/Remote address pair and



Kent & Seo                  Standards Track                    [Page 67]

RFC 4301              Security Architecture for IP         December 2005


   protocol value, i.e., the fragments carried on this SA belong to
   packets that if not fragmented, might have gone on separate SAs of
   differing security.  Therefore, users and administrators are advised
   to protect such traffic using ESP (with integrity) and the
   "strongest" integrity and encryption algorithms in use between both
   peers.  (Determination of the "strongest" algorithms requires
   imposing an ordering of the available algorithms, a local
   determination at the discretion of the initiator of the SA.)

   Specific port (or ICMP type/code or Mobility Header type) selector
   values will be used to define SAs to carry initial fragments and
   non-fragmented packets.  This approach can be used if a user or
   administrator wants to create one or more tunnel mode SAs between the
   same Local/Remote addresses that discriminate based on port (or ICMP
   type/code or Mobility Header type) fields.  These SAs MUST have
   non-trivial protocol selector values, otherwise approach #1 above
   MUST be used.

   Note: In general, for the approach described in this section, one
   needs only a single SA between two implementations to carry all
   non-initial fragments.  However, if one chooses to have multiple SAs
   between the two implementations for QoS differentiation, then one
   might also want multiple SAs to carry fragments-without-ports, one
   for each supported QoS class.  Since support for QoS via distinct SAs
   is a local matter, not mandated by this document, the choice to have
   multiple SAs to carry non-initial fragments should also be local.

7.3.  Stateful Fragment Checking

   An implementation MAY support some form of stateful fragment checking
   for a tunnel mode SA with non-trivial port (or ICMP type/code or MH
   type) field values (not ANY or OPAQUE).  Implementations that will
   transmit non-initial fragments on a tunnel mode SA that makes use of
   non-trivial port (or ICMP type/code or MH type) selectors MUST notify
   a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.

   The peer MUST reject this proposal if it will not accept non-initial
   fragments in this context.  If an implementation does not
   successfully negotiate transmission of non-initial fragments for such
   an SA, it MUST NOT send such fragments over the SA.  This standard
   does not specify how peers will deal with such fragments, e.g., via
   reassembly or other means, at either sender or receiver.  However, a
   receiver MUST discard non-initial fragments that arrive on an SA with
   non-trivial port (or ICMP type/code or MH type) selector values
   unless this feature has been negotiated.  Also, the receiver MUST
   discard non-initial fragments that do not comply with the security
   policy applied to the overall packet.  Discarding such packets is an
   auditable event.  Note that in network configurations where fragments



Kent & Seo                  Standards Track                    [Page 68]

RFC 4301              Security Architecture for IP         December 2005


   of a packet might be sent or received via different security gateways
   or BITW implementations, stateful strategies for tracking fragments
   may fail.

7.4.  BYPASS/DISCARD Traffic

   All implementations MUST support DISCARDing of fragments using the
   normal SPD packet classification mechanisms.  All implementations
   MUST support stateful fragment checking to accommodate BYPASS traffic
   for which a non-trivial port range is specified.  The concern is that
   BYPASS of a cleartext, non-initial fragment arriving at an IPsec
   implementation could undermine the security afforded IPsec-protected
   traffic directed to the same destination.  For example, consider an
   IPsec implementation configured with an SPD entry that calls for
   IPsec protection of traffic between a specific source/destination
   address pair, and for a specific protocol and destination port, e.g.,
   TCP traffic on port 23 (Telnet).  Assume that the implementation also
   allows BYPASS of traffic from the same source/destination address
   pair and protocol, but for a different destination port, e.g., port
   119 (NNTP).  An attacker could send a non-initial fragment (with a
   forged source address) that, if bypassed, could overlap with
   IPsec-protected traffic from the same source and thus violate the
   integrity of the IPsec-protected traffic.  Requiring stateful
   fragment checking for BYPASS entries with non-trivial port ranges
   prevents attacks of this sort.  As noted above, in network
   configurations where fragments of a packet might be sent or received
   via different security gateways or BITW implementations, stateful
   strategies for tracking fragments may fail.

8.  Path MTU/DF Processing

   The application of AH or ESP to an outbound packet increases the size
   of a packet and thus may cause a packet to exceed the PMTU for the SA
   via which the packet will travel.  An IPsec implementation also may
   receive an unprotected ICMP PMTU message and, if it chooses to act
   upon the message, the result will affect outbound traffic processing.
   This section describes the processing required of an IPsec
   implementation to deal with these two PMTU issues.

8.1.  DF Bit

   All IPsec implementations MUST support the option of copying the DF
   bit from an outbound packet to the tunnel mode header that it emits,
   when traffic is carried via a tunnel mode SA.  This means that it
   MUST be possible to configure the implementation's treatment of the
   DF bit (set, clear, copy from inner header) for each SA.  This
   applies to SAs where both inner and outer headers are IPv4.




Kent & Seo                  Standards Track                    [Page 69]

RFC 4301              Security Architecture for IP         December 2005


8.2.  Path MTU (PMTU) Discovery

   This section discusses IPsec handling for unprotected Path MTU
   Discovery messages.  ICMP PMTU is used here to refer to an ICMP
   message for:

           IPv4 (RFC 792 [Pos81b]):
                   - Type = 3 (Destination Unreachable)
                   - Code = 4 (Fragmentation needed and DF set)
                   - Next-Hop MTU in the low-order 16 bits of the
                     second word of the ICMP header (labeled "unused"
                     in RFC 792), with high-order 16 bits set to zero)

           IPv6 (RFC 2463 [CD98]):
                   - Type = 2 (Packet Too Big)
                   - Code = 0 (Fragmentation needed)
                   - Next-Hop MTU in the 32-bit MTU field of the ICMP6
                     message

8.2.1.  Propagation of PMTU

   When an IPsec implementation receives an unauthenticated PMTU
   message, and it is configured to process (vs. ignore) such messages,
   it maps the message to the SA to which it corresponds.  This mapping
   is effected by extracting the header information from the payload of
   the PMTU message and applying the procedure described in Section 5.2.
   The PMTU determined by this message is used to update the SAD PMTU
   field, taking into account the size of the AH or ESP header that will
   be applied, any crypto synchronization data, and the overhead imposed
   by an additional IP header, in the case of a tunnel mode SA.

   In a native host implementation, it is possible to maintain PMTU data
   at the same granularity as for unprotected communication, so there is
   no loss of functionality.  Signaling of the PMTU information is
   internal to the host.  For all other IPsec implementation options,
   the PMTU data must be propagated via a synthesized ICMP PMTU.  In
   these cases, the IPsec implementation SHOULD wait for outbound
   traffic to be mapped to the SAD entry.  When such traffic arrives, if
   the traffic would exceed the updated PMTU value the traffic MUST be
   handled as follows:

       Case 1: Original (cleartext) packet is IPv4 and has the DF
               bit set.  The implementation SHOULD discard the packet
               and send a PMTU ICMP message.







Kent & Seo                  Standards Track                    [Page 70]

RFC 4301              Security Architecture for IP         December 2005


       Case 2: Original (cleartext) packet is IPv4 and has the DF
               bit clear.  The implementation SHOULD fragment (before or
               after encryption per its configuration) and then forward
               the fragments.  It SHOULD NOT send a PMTU ICMP message.

       Case 3: Original (cleartext) packet is IPv6.  The implementation
               SHOULD discard the packet and send a PMTU ICMP message.

8.2.2.  PMTU Aging

   In all IPsec implementations, the PMTU associated with an SA MUST be
   "aged" and some mechanism is required to update the PMTU in a timely
   manner, especially for discovering if the PMTU is smaller than
   required by current network conditions.  A given PMTU has to remain
   in place long enough for a packet to get from the source of the SA to
   the peer, and to propagate an ICMP error message if the current PMTU
   is too big.

   Implementations SHOULD use the approach described in the Path MTU
   Discovery document (RFC 1191 [MD90], Section 6.3), which suggests
   periodically resetting the PMTU to the first-hop data-link MTU and
   then letting the normal PMTU Discovery processes update the PMTU as
   necessary.  The period SHOULD be configurable.

9.  Auditing

   IPsec implementations are not required to support auditing.  For the
   most part, the granularity of auditing is a local matter.  However,
   several auditable events are identified in this document, and for
   each of these events a minimum set of information that SHOULD be
   included in an audit log is defined.  Additional information also MAY
   be included in the audit log for each of these events, and additional
   events, not explicitly called out in this specification, also MAY
   result in audit log entries.  There is no requirement for the
   receiver to transmit any message to the purported transmitter in
   response to the detection of an auditable event, because of the
   potential to induce denial of service via such action.

10.  Conformance Requirements

   All IPv4 IPsec implementations MUST comply with all requirements of
   this document.  All IPv6 implementations MUST comply with all
   requirements of this document.








Kent & Seo                  Standards Track                    [Page 71]

RFC 4301              Security Architecture for IP         December 2005


11.  Security Considerations

   The focus of this document is security; hence security considerations
   permeate this specification.

   IPsec imposes stringent constraints on bypass of IP header data in
   both directions, across the IPsec barrier, especially when tunnel
   mode SAs are employed.  Some constraints are absolute, while others
   are subject to local administrative controls, often on a per-SA
   basis.  For outbound traffic, these constraints are designed to limit
   covert channel bandwidth.  For inbound traffic, the constraints are
   designed to prevent an adversary who has the ability to tamper with
   one data stream (on the unprotected side of the IPsec barrier) from
   adversely affecting other data streams (on the protected side of the
   barrier).  The discussion in Section 5 dealing with processing DSCP
   values for tunnel mode SAs illustrates this concern.

   If an IPsec implementation is configured to pass ICMP error messages
   over SAs based on the ICMP header values, without checking the header
   information from the ICMP message payload, serious vulnerabilities
   may arise.  Consider a scenario in which several sites (A, B, and C)
   are connected to one another via ESP-protected tunnels: A-B, A-C, and
   B-C.  Also assume that the traffic selectors for each tunnel specify
   ANY for protocol and port fields and IP source/destination address
   ranges that encompass the address range for the systems behind the
   security gateways serving each site.  This would allow a host at site
   B to send an ICMP Destination Unreachable message to any host at site
   A, that declares all hosts on the net at site C to be unreachable.
   This is a very efficient DoS attack that could have been prevented if
   the ICMP error messages were subjected to the checks that IPsec
   provides, if the SPD is suitably configured, as described in Section
   6.2.

12.  IANA Considerations

   The IANA has assigned the value (3) for the asn1-modules registry and
   has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
   module.  See Appendix C, "ASN.1 for an SPD Entry".

13.  Differences from RFC 2401

   This architecture document differs substantially from RFC 2401
   [RFC2401] in detail and in organization, but the fundamental notions
   are unchanged.

   o The processing model has been revised to address new IPsec
     scenarios, improve performance, and simplify implementation.  This
     includes a separation between forwarding (routing) and SPD



Kent & Seo                  Standards Track                    [Page 72]

RFC 4301              Security Architecture for IP         December 2005


     selection, several SPD changes, and the addition of an outbound SPD
     cache and an inbound SPD cache for bypassed or discarded traffic.
     There is also a new database, the Peer Authorization Database
     (PAD).  This provides a link between an SA management protocol
     (such as IKE) and the SPD.

   o There is no longer a requirement to support nested SAs or "SA
     bundles".  Instead this functionality can be achieved through SPD
     and forwarding table configuration.  An example of a configuration
     has been added in Appendix E.

   o SPD entries were redefined to provide more flexibility.  Each SPD
     entry now consists of 1 to N sets of selectors, where each selector
     set contains one protocol and a "list of ranges" can now be
     specified for the Local IP address, Remote IP address, and whatever
     fields (if any) are associated with the Next Layer Protocol (Local
     Port, Remote Port, ICMP message type and code, and Mobility Header
     type).  An individual value for a selector is represented via a
     trivial range and ANY is represented via a range than spans all
     values for the selector.  An example of an ASN.1 description is
     included in Appendix C.

   o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and
     ECN.  The tunnel section has been updated to explain how to handle
     DSCP and ECN bits.

   o For tunnel mode SAs, an SG, BITS, or BITW implementation is now
     allowed to fragment packets before applying IPsec.  This applies
     only to IPv4.  For IPv6 packets, only the originator is allowed to
     fragment them.

   o When security is desired between two intermediate systems along a
     path or between an intermediate system and an end system, transport
     mode may now be used between security gateways and between a
     security gateway and a host.

   o This document clarifies that for all traffic that crosses the IPsec
     boundary, including IPsec management traffic, the SPD or associated
     caches must be consulted.

   o This document defines how to handle the situation of a security
     gateway with multiple subscribers requiring separate IPsec
     contexts.

   o A definition of reserved SPIs has been added.






Kent & Seo                  Standards Track                    [Page 73]

RFC 4301              Security Architecture for IP         December 2005


   o Text has been added explaining why ALL IP packets must be checked
     -- IPsec includes minimal firewall functionality to support access
     control at the IP layer.

   o The tunnel section has been updated to clarify how to handle the IP
     options field and IPv6 extension headers when constructing the
     outer header.

   o SA mapping for inbound traffic has been updated to be consistent
     with the changes made in AH and ESP for support of unicast and
     multicast SAs.

   o Guidance has been added regarding how to handle the covert channel
     created in tunnel mode by copying the DSCP value to outer header.

   o Support for AH in both IPv4 and IPv6 is no longer required.

   o PMTU handling has been updated.  The appendix on
     PMTU/DF/Fragmentation has been deleted.

   o Three approaches have been added for handling plaintext fragments
     on the protected side of the IPsec boundary.  Appendix D documents
     the rationale behind them.

   o Added revised text describing how to derive selector values for SAs
     (from the SPD entry or from the packet, etc.)

   o Added a new table describing the relationship between selector
     values in an SPD entry, the PFP flag, and resulting selector values
     in the corresponding SAD entry.

   o Added Appendix B to describe decorrelation.

   o Added text describing how to handle an outbound packet that must be
     discarded.

   o Added text describing how to handle a DISCARDED inbound packet,
     i.e., one that does not match the SA upon which it arrived.

   o IPv6 mobility header has been added as a possible Next Layer
     Protocol.  IPv6 Mobility Header message type has been added as a
     selector.

   o ICMP message type and code have been added as selectors.

   o The selector "data sensitivity level" has been removed to simplify
     things.




Kent & Seo                  Standards Track                    [Page 74]

RFC 4301              Security Architecture for IP         December 2005


   o Updated text describing handling ICMP error messages.  The appendix
     on "Categorization of ICMP Messages" has been deleted.

   o The text for the selector name has been updated and clarified.

   o The "Next Layer Protocol" has been further explained and a default
     list of protocols to skip when looking for the Next Layer Protocol
     has been added.

   o The text has been amended to say that this document assumes use of
     IKEv2 or an SA management protocol with comparable features.

   o Text has been added clarifying the algorithm for mapping inbound
     IPsec datagrams to SAs in the presence of multicast SAs.

   o The appendix "Sequence Space Window Code Example" has been removed.

   o With respect to IP addresses and ports, the terms "Local" and
     "Remote" are used for policy rules (replacing source and
     destination).  "Local" refers to the entity being protected by an
     IPsec implementation, i.e., the "source" address/port of outbound
     packets or the "destination" address/port of inbound packets.
     "Remote" refers to a peer entity or peer entities.  The terms
     "source" and "destination" are still used for packet header fields.

14.  Acknowledgements

   The authors would like to acknowledge the contributions of Ran
   Atkinson, who played a critical role in initial IPsec activities, and
   who authored the first series of IPsec standards: RFCs 1825-1827; and
   Charlie Lynn, who made significant contributions to the second series
   of IPsec standards (RFCs 2401, 2402, and 2406) and to the current
   versions, especially with regard to IPv6 issues.  The authors also
   would like to thank the members of the IPsec and MSEC working groups
   who have contributed to the development of this protocol
   specification.















Kent & Seo                  Standards Track                    [Page 75]

RFC 4301              Security Architecture for IP         December 2005


Appendix A: Glossary

   This section provides definitions for several key terms that are
   employed in this document.  Other documents provide additional
   definitions and background information relevant to this technology,
   e.g., [Shi00], [VK83], and [HA94].  Included in this glossary are
   generic security service and security mechanism terms, plus
   IPsec-specific terms.

   Access Control
      A security service that prevents unauthorized use of a resource,
      including the prevention of use of a resource in an unauthorized
      manner.  In the IPsec context, the resource to which access is
      being controlled is often:

               o for a host, computing cycles or data
               o for a security gateway, a network behind the gateway
                 or bandwidth on that network.

   Anti-replay
      See "Integrity" below.

   Authentication
      Used informally to refer to the combination of two nominally
      distinct security services, data origin authentication and
      connectionless integrity.  See the definitions below for each of
      these services.

   Availability
      When viewed as a security service, addresses the security concerns
      engendered by attacks against networks that deny or degrade
      service.  For example, in the IPsec context, the use of
      anti-replay mechanisms in AH and ESP support availability.

   Confidentiality
      The security service that protects data from unauthorized
      disclosure.  The primary confidentiality concern in most instances
      is unauthorized disclosure of application-level data, but
      disclosure of the external characteristics of communication also
      can be a concern in some circumstances.  Traffic flow
      confidentiality is the service that addresses this latter concern
      by concealing source and destination addresses, message length, or
      frequency of communication.  In the IPsec context, using ESP in
      tunnel mode, especially at a security gateway, can provide some
      level of traffic flow confidentiality. (See also "Traffic
      Analysis" below.)





Kent & Seo                  Standards Track                    [Page 76]

RFC 4301              Security Architecture for IP         December 2005


   Data Origin Authentication
      A security service that verifies the identity of the claimed
      source of data.  This service is usually bundled with
      connectionless integrity service.

   Encryption
      A security mechanism used to transform data from an intelligible
      form (plaintext) into an unintelligible form (ciphertext), to
      provide confidentiality.  The inverse transformation process is
      designated "decryption".  Often the term "encryption" is used to
      generically refer to both processes.

   Integrity
      A security service that ensures that modifications to data are
      detectable.  Integrity comes in various flavors to match
      application requirements.  IPsec supports two forms of integrity:
      connectionless and a form of partial sequence integrity.
      Connectionless integrity is a service that detects modification of
      an individual IP datagram, without regard to the ordering of the
      datagram in a stream of traffic.  The form of partial sequence
      integrity offered in IPsec is referred to as anti-replay
      integrity, and it detects arrival of duplicate IP datagrams
      (within a constrained window).  This is in contrast to
      connection-oriented integrity, which imposes more stringent
      sequencing requirements on traffic, e.g., to be able to detect
      lost or re-ordered messages.  Although authentication and
      integrity services often are cited separately, in practice they
      are intimately connected and almost always offered in tandem.

   Protected vs. Unprotected
      "Protected" refers to the systems or interfaces that are inside
      the IPsec protection boundary, and "unprotected" refers to the
      systems or interfaces that are outside the IPsec protection
      boundary.  IPsec provides a boundary through which traffic passes.
      There is an asymmetry to this barrier, which is reflected in the
      processing model.  Outbound data, if not discarded or bypassed, is
      protected via the application of AH or ESP and the addition of the
      corresponding headers.  Inbound data, if not discarded or
      bypassed, is processed via the removal of AH or ESP headers.  In
      this document, inbound traffic enters an IPsec implementation from
      the "unprotected" interface.  Outbound traffic enters the
      implementation via the "protected" interface, or is internally
      generated by the implementation on the "protected" side of the
      boundary and directed toward the "unprotected" interface.  An
      IPsec implementation may support more than one interface on either
      or both sides of the boundary.  The protected interface may be





Kent & Seo                  Standards Track                    [Page 77]

RFC 4301              Security Architecture for IP         December 2005


      internal, e.g., in a host implementation of IPsec.  The protected
      interface may link to a socket layer interface presented by the
      OS.

   Security Association (SA)
      A simplex (uni-directional) logical connection, created for
      security purposes.  All traffic traversing an SA is provided the
      same security processing.  In IPsec, an SA is an Internet-layer
      abstraction implemented through the use of AH or ESP.  State data
      associated with an SA is represented in the SA Database (SAD).

   Security Gateway
      An intermediate system that acts as the communications interface
      between two networks.  The set of hosts (and networks) on the
      external side of the security gateway is termed unprotected (they
      are generally at least less protected than those "behind" the SG),
      while the networks and hosts on the internal side are viewed as
      protected.  The internal subnets and hosts served by a security
      gateway are presumed to be trusted by virtue of sharing a common,
      local, security administration.  In the IPsec context, a security
      gateway is a point at which AH and/or ESP is implemented in order
      to serve a set of internal hosts, providing security services for
      these hosts when they communicate with external hosts also
      employing IPsec (either directly or via another security gateway).

   Security Parameters Index (SPI)
      An arbitrary 32-bit value that is used by a receiver to identify
      the SA to which an incoming packet should be bound.  For a unicast
      SA, the SPI can be used by itself to specify an SA, or it may be
      used in conjunction with the IPsec protocol type.  Additional IP
      address information is used to identify multicast SAs.  The SPI is
      carried in AH and ESP protocols to enable the receiving system to
      select the SA under which a received packet will be processed.  An
      SPI has only local significance, as defined by the creator of the
      SA (usually the receiver of the packet carrying the SPI); thus an
      SPI is generally viewed as an opaque bit string.  However, the
      creator of an SA may choose to interpret the bits in an SPI to
      facilitate local processing.

   Traffic Analysis
      The analysis of network traffic flow for the purpose of deducing
      information that is useful to an adversary.  Examples of such
      information are frequency of transmission, the identities of the
      conversing parties, sizes of packets, and flow identifiers
      [Sch94].






Kent & Seo                  Standards Track                    [Page 78]

RFC 4301              Security Architecture for IP         December 2005


Appendix B: Decorrelation

   This appendix is based on work done for caching of policies in the IP
   Security Policy Working Group by Luis Sanchez, Matt Condell, and John
   Zao.

   Two SPD entries are correlated if there is a non-null intersection
   between the values of corresponding selectors in each entry.  Caching
   correlated SPD entries can lead to incorrect policy enforcement.  A
   solution to this problem, which still allows for caching, is to
   remove the ambiguities by decorrelating the entries.  That is, the
   SPD entries must be rewritten so that for every pair of entries there
   exists a selector for which there is a null intersection between the
   values in both of the entries.  Once the entries are decorrelated,
   there is no longer any ordering requirement on them, since only one
   entry will match any lookup.  The next section describes
   decorrelation in more detail and presents an algorithm that may be
   used to implement decorrelation.

B.1.  Decorrelation Algorithm

   The basic decorrelation algorithm takes each entry in a correlated
   SPD and divides it into a set of entries using a tree structure.
   The nodes of the tree are the selectors that may overlap between the
   policies.  At each node, the algorithm creates a branch for each of
   the values of the selector.  It also creates one branch for the
   complement of the union of all selector values.  Policies are then
   formed by traversing the tree from the root to each leaf.  The
   policies at the leaves are compared to the set of already
   decorrelated policy rules.  Each policy at a leaf is either
   completely overridden by a policy in the already decorrelated set and
   is discarded or is decorrelated with all the policies in the
   decorrelated set and is added to it.

   The basic algorithm does not guarantee an optimal set of decorrelated
   entries.  That is, the entries may be broken up into smaller sets
   than is necessary, though they will still provide all the necessary
   policy information.  Some extensions to the basic algorithm are
   described later to improve this and improve the performance of the
   algorithm.

           C   A set of ordered, correlated entries (a correlated SPD).
           Ci  The ith entry in C.
           U   The set of decorrelated entries being built from C.
           Ui  The ith entry in U.
           Sik The kth selection for policy Ci.
           Ai  The action for policy Ci.




Kent & Seo                  Standards Track                    [Page 79]

RFC 4301              Security Architecture for IP         December 2005


   A policy (SPD entry) P may be expressed as a sequence of selector
   values and an action (BYPASS, DISCARD, or PROTECT):

           Ci = Si1 x Si2 x ... x Sik -> Ai

   1) Put C1 in set U as U1

   For each policy Cj (j > 1) in C

   2) If Cj is decorrelated with every entry in U, then add it to U.

   3) If Cj is correlated with one or more entries in U, create a tree
   rooted at the policy Cj that partitions Cj into a set of decorrelated
   entries.  The algorithm starts with a root node where no selectors
   have yet been chosen.

     A) Choose a selector in Cj, Sjn, that has not yet been chosen when
        traversing the tree from the root to this node.  If there are no
        selectors not yet used, continue to the next unfinished branch
        until all branches have been completed.  When the tree is
        completed, go to step D.

        T is the set of entries in U that are correlated with the entry
        at this node.

        The entry at this node is the entry formed by the selector
        values of each of the branches between the root and this node.
        Any selector values that are not yet represented by branches
        assume the corresponding selector value in Cj, since the values
        in Cj represent the maximum value for each selector.

     B) Add a branch to the tree for each value of the selector Sjn that
        appears in any of the entries in T.  (If the value is a superset
        of the value of Sjn in Cj, then use the value in Cj, since that
        value represents the universal set.)  Also add a branch for the
        complement of the union of all the values of the selector Sjn
        in T.  When taking the complement, remember that the universal
        set is the value of Sjn in Cj.  A branch need not be created
        for the null set.

     C) Repeat A and B until the tree is completed.

     D) The entry to each leaf now represents an entry that is a subset
        of Cj.  The entries at the leaves completely partition Cj in
        such a way that each entry is either completely overridden by
        an entry in U, or is decorrelated with the entries in U.

        Add all the decorrelated entries at the leaves of the tree to U.



Kent & Seo                  Standards Track                    [Page 80]

RFC 4301              Security Architecture for IP         December 2005


   4) Get next Cj and go to 2.

   5) When all entries in C have been processed, then U will contain an
   decorrelated version of C.

   There are several optimizations that can be made to this algorithm.
   A few of them are presented here.

   It is possible to optimize, or at least improve, the amount of
   branching that occurs by carefully choosing the order of the
   selectors used for the next branch.  For example, if a selector Sjn
   can be chosen so that all the values for that selector in T are equal
   to or a superset of the value of Sjn in Cj, then only a single branch
   needs to be created (since the complement will be null).

   Branches of the tree do not have to proceed with the entire
   decorrelation algorithm.  For example, if a node represents an entry
   that is decorrelated with all the entries in U, then there is no
   reason to continue decorrelating that branch.  Also, if a branch is
   completely overridden by an entry in U, then there is no reason to
   continue decorrelating the branch.

   An additional optimization is to check to see if a branch is
   overridden by one of the CORRELATED entries in set C that has already
   been decorrelated.  That is, if the branch is part of decorrelating
   Cj, then check to see if it was overridden by an entry Cm, m < j.
   This is a valid check, since all the entries Cm are already expressed
   in U.

   Along with checking if an entry is already decorrelated in step 2,
   check if Cj is overridden by any entry in U.  If it is, skip it since
   it is not relevant.  An entry x is overridden by another entry y if
   every selector in x is equal to or a subset of the corresponding
   selector in entry y.

















Kent & Seo                  Standards Track                    [Page 81]

RFC 4301              Security Architecture for IP         December 2005


Appendix C: ASN.1 for an SPD Entry

   This appendix is included as an additional way to describe SPD
   entries, as defined in Section 4.4.1.  It uses ASN.1 syntax that has
   been successfully compiled.  This syntax is merely illustrative and
   need not be employed in an implementation to achieve compliance.  The
   SPD description in Section 4.4.1 is normative.

   SPDModule

    {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
     ipsec (8) asn1-modules (3) spd-module (1) }

       DEFINITIONS IMPLICIT TAGS ::=

       BEGIN

       IMPORTS
           RDNSequence FROM PKIX1Explicit88
             { iso(1) identified-organization(3)
               dod(6) internet(1) security(5) mechanisms(5) pkix(7)
               id-mod(0) id-pkix1-explicit(18) } ;

       -- An SPD is a list of policies in decreasing order of preference
       SPD ::= SEQUENCE OF SPDEntry

       SPDEntry ::= CHOICE {
           iPsecEntry       IPsecEntry,               -- PROTECT traffic
           bypassOrDiscard  [0] BypassOrDiscardEntry } -- DISCARD/BYPASS

       IPsecEntry ::= SEQUENCE {       -- Each entry consists of
           name        NameSets OPTIONAL,
           pFPs        PacketFlags,    -- Populate from packet flags
                              -- Applies to ALL of the corresponding
                              -- traffic selectors in the SelectorLists
           condition   SelectorLists,  -- Policy "condition"
           processing  Processing      -- Policy "action"
           }

       BypassOrDiscardEntry ::= SEQUENCE {
           bypass      BOOLEAN,        -- TRUE BYPASS, FALSE DISCARD
           condition   InOutBound }

       InOutBound ::= CHOICE {
           outbound    [0] SelectorLists,
           inbound     [1] SelectorLists,
           bothways    [2] BothWays }




Kent & Seo                  Standards Track                    [Page 82]

RFC 4301              Security Architecture for IP         December 2005


       BothWays ::= SEQUENCE {
           inbound     SelectorLists,
           outbound    SelectorLists }

       NameSets ::= SEQUENCE {
           passed      SET OF Names-R,  -- Matched to IKE ID by
                                        -- responder
           local       SET OF Names-I } -- Used internally by IKE
                                        -- initiator

       Names-R ::= CHOICE {                   -- IKEv2 IDs
           dName       RDNSequence,           -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

       Names-I ::= OCTET STRING       -- Used internally by IKE
                                      -- initiator

       FQDN ::= IA5String

       RFC822Name ::= IA5String

       PacketFlags ::= BIT STRING {
                   -- if set, take selector value from packet
                   -- establishing SA
                   -- else use value in SPD entry
           localAddr  (0),
           remoteAddr (1),
           protocol   (2),
           localPort  (3),
           remotePort (4)  }

       SelectorLists ::= SET OF SelectorList

       SelectorList ::= SEQUENCE {
           localAddr   AddrList,
           remoteAddr  AddrList,
           protocol    ProtocolChoice }

       Processing ::= SEQUENCE {
           extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
           seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
           fragCheck   BOOLEAN, -- TRUE stateful fragment checking,
                                -- FALSE no stateful fragment checking
           lifetime    SALifetime,
           spi         ManualSPI,
           algorithms  ProcessingAlgs,



Kent & Seo                  Standards Track                    [Page 83]

RFC 4301              Security Architecture for IP         December 2005


           tunnel      TunnelOptions OPTIONAL } -- if absent, use
                                                -- transport mode

       SALifetime ::= SEQUENCE {
           seconds   [0] INTEGER OPTIONAL,
           bytes     [1] INTEGER OPTIONAL }

       ManualSPI ::= SEQUENCE {
           spi     INTEGER,
           keys    KeyIDs }

       KeyIDs ::= SEQUENCE OF OCTET STRING

       ProcessingAlgs ::= CHOICE {
           ah          [0] IntegrityAlgs,  -- AH
           esp         [1] ESPAlgs}        -- ESP

       ESPAlgs ::= CHOICE {
           integrity       [0] IntegrityAlgs,       -- integrity only
           confidentiality [1] ConfidentialityAlgs, -- confidentiality
                                                    -- only
           both            [2] IntegrityConfidentialityAlgs,
           combined        [3] CombinedModeAlgs }

       IntegrityConfidentialityAlgs ::= SEQUENCE {
           integrity       IntegrityAlgs,
           confidentiality ConfidentialityAlgs }

       -- Integrity Algorithms, ordered by decreasing preference
       IntegrityAlgs ::= SEQUENCE OF IntegrityAlg

       -- Confidentiality Algorithms, ordered by decreasing preference
       ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg

       -- Integrity Algorithms
       IntegrityAlg ::= SEQUENCE {
           algorithm   IntegrityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       IntegrityAlgType ::= INTEGER {
           none              (0),
           auth-HMAC-MD5-96  (1),
           auth-HMAC-SHA1-96 (2),
           auth-DES-MAC      (3),
           auth-KPDK-MD5     (4),
           auth-AES-XCBC-96  (5)
       --  tbd (6..65535)
           }



Kent & Seo                  Standards Track                    [Page 84]

RFC 4301              Security Architecture for IP         December 2005


       -- Confidentiality Algorithms
       ConfidentialityAlg ::= SEQUENCE {
           algorithm   ConfidentialityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       ConfidentialityAlgType ::= INTEGER {
           encr-DES-IV64   (1),
           encr-DES        (2),
           encr-3DES       (3),
           encr-RC5        (4),
           encr-IDEA       (5),
           encr-CAST       (6),
           encr-BLOWFISH   (7),
           encr-3IDEA      (8),
           encr-DES-IV32   (9),
           encr-RC4       (10),
           encr-NULL      (11),
           encr-AES-CBC   (12),
           encr-AES-CTR   (13)
       --  tbd (14..65535)
           }

       CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg

       CombinedModeAlg ::= SEQUENCE {
           algorithm   CombinedModeType,
           parameters  ANY -- DEFINED BY algorithm} -- defined outside
                                    -- of this document for AES modes.

       CombinedModeType ::= INTEGER {
           comb-AES-CCM    (1),
           comb-AES-GCM    (2)
       --  tbd (3..65535)
           }

       TunnelOptions ::= SEQUENCE {
           dscp        DSCP,
           ecn         BOOLEAN,    -- TRUE Copy CE to inner header
           df          DF,
           addresses   TunnelAddresses }

       TunnelAddresses ::= CHOICE {
           ipv4        IPv4Pair,
           ipv6        [0] IPv6Pair }

       IPv4Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(4)),
           remote      OCTET STRING (SIZE(4)) }



Kent & Seo                  Standards Track                    [Page 85]

RFC 4301              Security Architecture for IP         December 2005


       IPv6Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(16)),
           remote      OCTET STRING (SIZE(16)) }

       DSCP ::= SEQUENCE {
           copy      BOOLEAN, -- TRUE copy from inner header
                              -- FALSE do not copy
           mapping   OCTET STRING OPTIONAL} -- points to table
                                            -- if no copy

       DF ::= INTEGER {
           clear   (0),
           set     (1),
           copy    (2) }

       ProtocolChoice::= CHOICE {
           anyProt  AnyProtocol,              -- for ANY protocol
           noNext   [0] NoNextLayerProtocol,  -- has no next layer
                                              -- items
           oneNext  [1] OneNextLayerProtocol, -- has one next layer
                                              -- item
           twoNext  [2] TwoNextLayerProtocol, -- has two next layer
                                              -- items
           fragment FragmentNoNext }          -- has no next layer
                                              -- info

       AnyProtocol ::= SEQUENCE {
           id          INTEGER (0),    -- ANY protocol
           nextLayer   AnyNextLayers }

       AnyNextLayers ::= SEQUENCE {      -- with either
           first       AnyNextLayer,     -- ANY next layer selector
           second      AnyNextLayer }    -- ANY next layer selector

       NoNextLayerProtocol ::= INTEGER (2..254)

       FragmentNoNext ::= INTEGER (44)   -- Fragment identifier

       OneNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (1..254),   -- ICMP, MH, ICMPv6
           nextLayer   NextLayerChoice }   -- ICMP Type*256+Code
                                           -- MH   Type*256

       TwoNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (2..254),   -- Protocol
           local       NextLayerChoice,    -- Local and
           remote      NextLayerChoice }   -- Remote ports




Kent & Seo                  Standards Track                    [Page 86]

RFC 4301              Security Architecture for IP         December 2005


       NextLayerChoice ::= CHOICE {
           any         AnyNextLayer,
           opaque      [0] OpaqueNextLayer,
           range       [1] NextLayerRange }

       -- Representation of ANY in next layer field
       AnyNextLayer ::= SEQUENCE {
           start       INTEGER (0),
           end         INTEGER (65535) }

       -- Representation of OPAQUE in next layer field.
       -- Matches IKE convention
       OpaqueNextLayer ::= SEQUENCE {
           start       INTEGER (65535),
           end         INTEGER (0) }

       -- Range for a next layer field
       NextLayerRange ::= SEQUENCE {
           start       INTEGER (0..65535),
           end         INTEGER (0..65535) }

       -- List of IP addresses
       AddrList ::= SEQUENCE {
           v4List      IPv4List OPTIONAL,
           v6List      [0] IPv6List OPTIONAL }

       -- IPv4 address representations
       IPv4List ::= SEQUENCE OF IPv4Range

       IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
           ipv4Start   OCTET STRING (SIZE (4)),
           ipv4End     OCTET STRING (SIZE (4)) }

       -- IPv6 address representations
       IPv6List ::= SEQUENCE OF IPv6Range

       IPv6Range ::= SEQUENCE {    -- close, but not quite right ...
           ipv6Start   OCTET STRING (SIZE (16)),
           ipv6End     OCTET STRING (SIZE (16)) }

       END










Kent & Seo                  Standards Track                    [Page 87]

RFC 4301              Security Architecture for IP         December 2005


Appendix D: Fragment Handling Rationale

   There are three issues that must be resolved regarding processing of
   (plaintext) fragments in IPsec:

        - mapping a non-initial, outbound fragment to the right SA
          (or finding the right SPD entry)
        - verifying that a received, non-initial fragment is authorized
          for the SA via which it is received
        - mapping outbound and inbound non-initial fragments to the
          right SPD/cache entry, for BYPASS/DISCARD traffic

   The first and third issues arise because we need a deterministic
   algorithm for mapping traffic to SAs (and SPD/cache entries).  All
   three issues are important because we want to make sure that
   non-initial fragments that cross the IPsec boundary do not cause the
   access control policies in place at the receiver (or transmitter) to
   be violated.

D.1.  Transport Mode and Fragments

   First, we note that transport mode SAs have been defined to not carry
   fragments.  This is a carryover from RFC 2401, where transport mode
   SAs always terminated at endpoints.  This is a fundamental
   requirement because, in the worst case, an IPv4 fragment to which
   IPsec was applied might then be fragmented (as a ciphertext packet),
   en route to the destination.  IP fragment reassembly procedures at
   the IPsec receiver would not be able to distinguish between pre-IPsec
   fragments and fragments created after IPsec processing.

   For IPv6, only the sender is allowed to fragment a packet.  As for
   IPv4, an IPsec implementation is allowed to fragment tunnel mode
   packets after IPsec processing, because it is the sender relative to
   the (outer) tunnel header.  However, unlike IPv4, it would be
   feasible to carry a plaintext fragment on a transport mode SA,
   because the fragment header in IPv6 would appear after the AH or ESP
   header, and thus would not cause confusion at the receiver with
   respect to reassembly.  Specifically, the receiver would not attempt
   reassembly for the fragment until after IPsec processing.  To keep
   things simple, this specification prohibits carriage of fragments on
   transport mode SAs for IPv6 traffic.

   When only end systems used transport mode SAs, the prohibition on
   carriage of fragments was not a problem, since we assumed that the
   end system could be configured to not offer a fragment to IPsec.  For
   a native host implementation, this seems reasonable, and, as someone
   already noted, RFC 2401 warned that a BITS implementation might have
   to reassemble fragments before performing an SA lookup.  (It would



Kent & Seo                  Standards Track                    [Page 88]

RFC 4301              Security Architecture for IP         December 2005


   then apply AH or ESP and could re-fragment the packet after IPsec
   processing.) Because a BITS implementation is assumed to be able to
   have access to all traffic emanating from its host, even if the host
   has multiple interfaces, this was deemed a reasonable mandate.

   In this specification, it is acceptable to use transport mode in
   cases where the IPsec implementation is not the ultimate destination,
   e.g., between two SGs.  In principle, this creates a new opportunity
   for outbound, plaintext fragments to be mapped to a transport mode SA
   for IPsec processing.  However, in these new contexts in which a
   transport mode SA is now approved for use, it seems likely that we
   can continue to prohibit transmission of fragments, as seen by IPsec,
   i.e., packets that have an "outer header" with a non-zero fragment
   offset field.  For example, in an IP overlay network, packets being
   sent over transport mode SAs are IP-in-IP tunneled and thus have the
   necessary inner header to accommodate fragmentation prior to IPsec
   processing.  When carried via a transport mode SA, IPsec would not
   examine the inner IP header for such traffic, and thus would not
   consider the packet to be a fragment.

D.2.  Tunnel Mode and Fragments

   For tunnel mode SAs, it has always been the case that outbound
   fragments might arrive for processing at an IPsec implementation.
   The need to accommodate fragmented outbound packets can pose a
   problem because a non-initial fragment generally will not contain the
   port fields associated with a next layer protocol such as TCP, UDP,
   or SCTP.  Thus, depending on the SPD configuration for a given IPsec
   implementation, plaintext fragments might or might not pose a
   problem.

   For example, if the SPD requires that all traffic between two address
   ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries
   apply to this address range), then it should be easy to carry
   non-initial fragments on the SA defined for this address range, since
   the SPD entry implies an intent to carry ALL traffic between the
   address ranges.  But, if there are multiple SPD entries that could
   match a fragment, and if these entries reference different subsets of
   port fields (vs. ANY), then it is not possible to map an outbound
   non-initial fragment to the right entry, unambiguously. (If we choose
   to allow carriage of fragments on transport mode SAs for IPv6, the
   problems arises in that context as well.)

   This problem largely, though not exclusively, motivated the
   definition of OPAQUE as a selector value for port fields in RFC 2401.
   The other motivation for OPAQUE is the observation that port fields
   might not be accessible due to the prior application of IPsec.  For
   example, if a host applied IPsec to its traffic and that traffic



Kent & Seo                  Standards Track                    [Page 89]

RFC 4301              Security Architecture for IP         December 2005


   arrived at an SG, these fields would be encrypted.  The algorithm
   specified for locating the "next layer protocol" described in RFC
   2401 also motivated use of OPAQUE to accommodate an encrypted next
   layer protocol field in such circumstances.  Nonetheless, the primary
   use of the OPAQUE value was to match traffic selector fields in
   packets that did not contain port fields (non-initial fragments), or
   packets in which the port fields were already encrypted (as a result
   of nested application of IPsec).  RFC 2401 was ambiguous in
   discussing the use of OPAQUE vs. ANY, suggesting in some places that
   ANY might be an alternative to OPAQUE.

   We gain additional access control capability by defining both ANY and
   OPAQUE values.  OPAQUE can be defined to match only fields that are
   not accessible.  We could define ANY as the complement of OPAQUE,
   i.e., it would match all values but only for accessible port fields.
   We have therefore simplified the procedure employed to locate the
   next layer protocol in this document, so that we treat ESP and AH as
   next layer protocols.  As a result, the notion of an encrypted next
   layer protocol field has vanished, and there is also no need to worry
   about encrypted port fields either.  And accordingly, OPAQUE will be
   applicable only to non-initial fragments.

   Since we have adopted the definitions above for ANY and OPAQUE, we
   need to clarify how these values work when the specified protocol
   does not have port fields, and when ANY is used for the protocol
   selector.  Accordingly, if a specific protocol value is used as a
   selector, and if that protocol has no port fields, then the port
   field selectors are to be ignored and ANY MUST be specified as the
   value for the port fields. (In this context, ICMP TYPE and CODE
   values are lumped together as a single port field (for IKEv2
   negotiation), as is the IPv6 Mobility Header TYPE value.) If the
   protocol selector is ANY, then this should be treated as equivalent
   to specifying a protocol for which no port fields are defined, and
   thus the port selectors should be ignored, and MUST be set to ANY.

D.3.  The Problem of Non-Initial Fragments

   For an SG implementation, it is obvious that fragments might arrive
   from end systems behind the SG.  A BITW implementation also may
   encounter fragments from a host or gateway behind it. (As noted
   earlier, native host implementations and BITS implementations
   probably can avoid the problems described below.) In the worst case,
   fragments from a packet might arrive at distinct BITW or SG
   instantiations and thus preclude reassembly as a solution option.
   Hence, in RFC 2401 we adopted a general requirement that fragments
   must be accommodated in tunnel mode for all implementations. However,





Kent & Seo                  Standards Track                    [Page 90]

RFC 4301              Security Architecture for IP         December 2005


   RFC 2401 did not provide a perfect solution.  The use of OPAQUE as a
   selector value for port fields (a SHOULD in RFC 2401) allowed an SA
   to carry non-initial fragments.

   Using the features defined in RFC 2401, if one defined an SA between
   two IPsec (SG or BITW) implementations using the OPAQUE value for
   both port fields, then all non-initial fragments matching the
   source/destination (S/D) address and protocol values for the SA would
   be mapped to that SA.  Initial fragments would NOT map to this SA, if
   we adopt a strict definition of OPAQUE.  However, RFC 2401 did not
   provide detailed guidance on this and thus it may not have been
   apparent that use of this feature would essentially create a
   "non-initial fragment only" SA.

   In the course of discussing the "fragment-only" SA approach, it was
   noted that some subtle problems, problems not considered in RFC 2401,
   would have to be avoided.  For example, an SA of this sort must be
   configured to offer the "highest quality" security services for any
   traffic between the indicated S/D addresses (for the specified
   protocol).  This is necessary to ensure that any traffic captured by
   the fragment-only SA is not offered degraded security relative to
   what it would have been offered if the packet were not fragmented.  A
   possible problem here is that we may not be able to identify the
   "highest quality" security services defined for use between two IPsec
   implementation, since the choice of security protocols, options, and
   algorithms is a lattice, not a totally ordered set. (We might safely
   say that BYPASS < AH < ESP w/integrity, but it gets complicated if we
   have multiple ESP encryption or integrity algorithm options.) So, one
   has to impose a total ordering on these security parameters to make
   this work, but this can be done locally.

   However, this conservative strategy has a possible performance
   downside.  If most traffic traversing an IPsec implementation for a
   given S/D address pair (and specified protocol) is bypassed, then a
   fragment-only SA for that address pair might cause a dramatic
   increase in the volume of traffic afforded crypto processing.  If the
   crypto implementation cannot support high traffic rates, this could
   cause problems. (An IPsec implementation that is capable of line rate
   or near line rate crypto performance would not be adversely affected
   by this SA configuration approach.  Nonetheless, the performance
   impact is a potential concern, specific to implementation
   capabilities.)

   Another concern is that non-initial fragments sent over a dedicated
   SA might be used to effect overlapping reassembly attacks, when
   combined with an apparently acceptable initial fragment. (This sort
   of attack assumes creation of bogus fragments and is not a side
   effect of normal fragmentation.) This concern is easily addressed in



Kent & Seo                  Standards Track                    [Page 91]

RFC 4301              Security Architecture for IP         December 2005


   IPv4, by checking the fragment offset value to ensure that no
   non-initial fragments have a small enough offset to overlap port
   fields that should be contained in the initial fragment.  Recall that
   the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60
   bytes, so any ports should be present in the initial fragment.  If we
   require all non-initial fragments to have an offset of, say, 128 or
   greater, just to be on the safe side, this should prevent successful
   attacks of this sort.  If the intent is only to protect against this
   sort of reassembly attack, this check need be implemented only by a
   receiver.

   IPv6 also has a fragment offset, carried in the fragmentation
   extension header.  However, IPv6 extension headers are variable in
   length and there is no analogous max header length value that we can
   use to check non-initial fragments, to reject ones that might be used
   for an attack of the sort noted above.  A receiver would need to
   maintain state analogous to reassembly state, to provide equivalent
   protection.  So, only for IPv4 is it feasible to impose a fragment
   offset check that would reject attacks designed to circumvent port
   field checks by IPsec (or firewalls) when passing non-initial
   fragments.

   Another possible concern is that in some topologies and SPD
   configurations this approach might result in an access control
   surprise.  The notion is that if we create an SA to carry ALL
   (non-initial) fragments, then that SA would carry some traffic that
   might otherwise arrive as plaintext via a separate path, e.g., a path
   monitored by a proxy firewall.  But, this concern arises only if the
   other path allows initial fragments to traverse it without requiring
   reassembly, presumably a bad idea for a proxy firewall.  Nonetheless,
   this does represent a potential problem in some topologies and under
   certain assumptions with respect to SPD and (other) firewall rule
   sets, and administrators need to be warned of this possibility.

   A less serious concern is that non-initial fragments sent over a
   non-initial fragment-only SA might represent a DoS opportunity, in
   that they could be sent when no valid, initial fragment will ever
   arrive.  This might be used to attack hosts behind an SG or BITW
   device.  However, the incremental risk posed by this sort of attack,
   which can be mounted only by hosts behind an SG or BITW device, seems
   small.

   If we interpret the ANY selector value as encompassing OPAQUE, then a
   single SA with ANY values for both port fields would be able to
   accommodate all traffic matching the S/D address and protocol traffic
   selectors, an alternative to using the OPAQUE value.  But, using ANY





Kent & Seo                  Standards Track                    [Page 92]

RFC 4301              Security Architecture for IP         December 2005


   here precludes multiple, distinct SAs between the same IPsec
   implementations for the same address pairs and protocol.  So, it is
   not an exactly equivalent alternative.

   Fundamentally, fragment handling problems arise only when more than
   one SA is defined with the same S/D address and protocol selector
   values, but with different port field selector values.

D.4.  BYPASS/DISCARD Traffic

   We also have to address the non-initial fragment processing issue for
   BYPASS/DISCARD entries, independent of SA processing.  This is
   largely a local matter for two reasons:

           1) We have no means for coordinating SPD entries for such
              traffic between IPsec implementations since IKE is not
              invoked.
           2) Many of these entries refer to traffic that is NOT
              directed to or received from a location that is using
              IPsec.  So there is no peer IPsec implementation with
              which to coordinate via any means.

   However, this document should provide guidance here, consistent with
   our goal of offering a well-defined, access control function for all
   traffic, relative to the IPsec boundary.  To that end, this document
   says that implementations MUST support fragment reassembly for
   BYPASS/DISCARD traffic when port fields are specified.  An
   implementation also MUST permit a user or administrator to accept
   such traffic or reject such traffic using the SPD conventions
   described in Section 4.4.1.  The concern is that BYPASS of a
   cleartext, non-initial fragment arriving at an IPsec implementation
   could undermine the security afforded IPsec-protected traffic
   directed to the same destination.  For example, consider an IPsec
   implementation configured with an SPD entry that calls for
   IPsec-protection of traffic between a specific source/destination
   address pair, and for a specific protocol and destination port, e.g.,
   TCP traffic on port 23 (Telnet).  Assume that the implementation also
   allows BYPASS of traffic from the same source/destination address
   pair and protocol, but for a different destination port, e.g., port
   119 (NNTP).  An attacker could send a non-initial fragment (with a
   forged source address) that, if bypassed, could overlap with
   IPsec-protected traffic from the same source and thus violate the
   integrity of the IPsec-protected traffic.  Requiring stateful
   fragment checking for BYPASS entries with non-trivial port ranges
   prevents attacks of this sort.






Kent & Seo                  Standards Track                    [Page 93]

RFC 4301              Security Architecture for IP         December 2005


D.5.  Just say no to ports?

   It has been suggested that we could avoid the problems described
   above by not allowing port field selectors to be used in tunnel mode.
   But the discussion above shows this to be an unnecessarily stringent
   approach, i.e., since no problems arise for the native OS and BITS
   implementations.  Moreover, some WG members have described scenarios
   where use of tunnel mode SAs with (non-trivial) port field selectors
   is appropriate.  So the challenge is defining a strategy that can
   deal with this problem in BITW and SG contexts.  Also note that
   BYPASS/DISCARD entries in the SPD that make use of ports pose the
   same problems, irrespective of tunnel vs. transport mode notions.

   Some folks have suggested that a firewall behind an SG or BITW should
   be left to enforce port-level access controls and the effects of
   fragmentation.  However, this seems to be an incongruous suggestion
   in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned
   about firewalls that always discard fragments.  If many firewalls
   don't pass fragments in general, why should we expect them to deal
   with fragments in this case? So, this analysis rejects the suggestion
   of disallowing use of port field selectors with tunnel mode SAs.

D.6.  Other Suggested Solutions

   One suggestion is to reassemble fragments at the sending IPsec
   implementation, and thus avoid the problem entirely.  This approach
   is invisible to a receiver and thus could be adopted as a purely
   local implementation option.

   A more sophisticated version of this suggestion calls for
   establishing and maintaining minimal state from each initial fragment
   encountered, to allow non-initial fragments to be matched to the
   right SAs or SPD/cache entries.  This implies an extension to the
   current processing model (and the old one).  The IPsec implementation
   would intercept all fragments; capture Source/Destination IP
   addresses, protocol, packet ID, and port fields from initial
   fragments; and then use this data to map non-initial fragments to SAs
   that require port fields.  If this approach is employed, the receiver
   needs to employ an equivalent scheme, as it too must verify that
   received fragments are consistent with SA selector values.  A
   non-initial fragment that arrives prior to an initial fragment could
   be cached or discarded, awaiting arrival of the corresponding initial
   fragment.

   A downside of both approaches noted above is that they will not
   always work.  When a BITW device or SG is configured in a topology
   that might allow some fragments for a packet to be processed at
   different SGs or BITW devices, then there is no guarantee that all



Kent & Seo                  Standards Track                    [Page 94]

RFC 4301              Security Architecture for IP         December 2005


   fragments will ever arrive at the same IPsec device.  This approach
   also raises possible processing problems.  If the sender caches
   non-initial fragments until the corresponding initial fragment
   arrives, buffering problems might arise, especially at high speeds.
   If the non-initial fragments are discarded rather than cached, there
   is no guarantee that traffic will ever pass, e.g., retransmission
   will result in different packet IDs that cannot be matched with prior
   transmissions.  In any case, housekeeping procedures will be needed
   to decide when to delete the fragment state data, adding some
   complexity to the system.  Nonetheless, this is a viable solution in
   some topologies, and these are likely to be common topologies.

   The Working Group rejected an earlier version of the convention of
   creating an SA to carry only non-initial fragments, something that
   was supported implicitly under the RFC 2401 model via use of OPAQUE
   port fields, but never clearly articulated in RFC 2401.  The
   (rejected) text called for each non-initial fragment to be treated as
   protocol 44 (the IPv6 fragment header protocol ID) by the sender and
   receiver.  This approach has the potential to make IPv4 and IPv6
   fragment handling more uniform, but it does not fundamentally change
   the problem, nor does it address the issue of fragment handling for
   BYPASS/DISCARD traffic.  Given the fragment overlap attack problem
   that IPv6 poses, it does not seem that it is worth the effort to
   adopt this strategy.

D.7.  Consistency

   Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform
   fragmentation prior to IPsec processing.  If this fragmentation is
   performed after SA lookup at the sender, there is no "mapping to the
   right SA" problem.  But, the receiver still needs to be able to
   verify that the non-initial fragments are consistent with the SA via
   which they are received.  Since the initial fragment might be lost en
   route, the receiver encounters all of the potential problems noted
   above.  Thus, if we are to be consistent in our decisions, we need to
   say how a receiver will deal with the non-initial fragments that
   arrive.

D.8.  Conclusions

   There is no simple, uniform way to handle fragments in all contexts.
   Different approaches work better in different contexts.  Thus, this
   document offers 3 choices -- one MUST and two MAYs.  At some point in
   the future, if the community gains experience with the two MAYs, they
   may become SHOULDs or MUSTs or other approaches may be proposed.






Kent & Seo                  Standards Track                    [Page 95]

RFC 4301              Security Architecture for IP         December 2005


Appendix E: Example of Supporting Nested SAs via SPD and Forwarding
            Table Entries

   This appendix provides an example of how to configure the SPD and
   forwarding tables to support a nested pair of SAs, consistent with
   the new processing model.  For simplicity, this example assumes just
   one SPD-I.

   The goal in this example is to support a transport mode SA from A to
   C, carried over a tunnel mode SA from A to B.  For example, A might
   be a laptop connected to the public Internet, B might be a firewall
   that protects a corporate network, and C might be a server on the
   corporate network that demands end-to-end authentication of A's
   traffic.

         +---+     +---+  +---+
         | A |=====| B |  | C |
         |   |------------|   |
         |   |=====|   |  |   |
         +---+     +---+  +---+

   A's SPD contains entries of the form:

                        Next Layer
      Rule Local Remote Protocol   Action
      ---- ----- ------ ---------- -----------------------
       1     C     A     ESP       BYPASS
       2     A     C     ICMP,ESP  PROTECT(ESP,tunnel,integr+conf)
       3     A     C     ANY       PROTECT(ESP,transport,integr-only)
       4     A     B     ICMP,IKE  BYPASS

   A's unprotected-side forwarding table is set so that outbound packets
   destined for C are looped back to the protected side.  A's
   protected-side forwarding table is set so that inbound ESP packets
   are looped back to the unprotected side.  A's forwarding tables
   contain entries of the form:

      Unprotected-side forwarding table

        Rule Local Remote Protocol Action
        ---- ----- ------ -------- ---------------------------
         1     A     C       ANY   loop back to protected side
         2     A     B       ANY   forward to B








Kent & Seo                  Standards Track                    [Page 96]

RFC 4301              Security Architecture for IP         December 2005


      Protected-side forwarding table

        Rule Local Remote Protocol Action
        ---- ----- ------ -------- -----------------------------
         1     A     C       ESP   loop back to unprotected side

   An outbound TCP packet from A to C would match SPD rule 3 and have
   transport mode ESP applied to it.  The unprotected-side forwarding
   table would then loop back the packet.  The packet is compared
   against SPD-I (see Figure 2), matches SPD rule 1, and so it is
   BYPASSed.  The packet is treated as an outbound packet and compared
   against the SPD for a third time.  This time it matches SPD rule 2,
   so ESP is applied in tunnel mode.  This time the forwarding table
   doesn't loop back the packet, because the outer destination address
   is B, so the packet goes out onto the wire.

   An inbound TCP packet from C to A is wrapped in two ESP headers; the
   outer header (ESP in tunnel mode) shows B as the source, whereas the
   inner header (ESP transport mode) shows C as the source.  Upon
   arrival at A, the packet would be mapped to an SA based on the SPI,
   have the outer header removed, and be decrypted and
   integrity-checked.  Then it would be matched against the SAD
   selectors for this SA, which would specify C as the source and A as
   the destination, derived from SPD rule 2.  The protected-side
   forwarding function would then send it back to the unprotected side
   based on the addresses and the next layer protocol (ESP), indicative
   of nesting.  It is compared against SPD-O (see Figure 3) and found to
   match SPD rule 1, so it is BYPASSed.  The packet is mapped to an SA
   based on the SPI, integrity-checked, and compared against the SAD
   selectors derived from SPD rule 3.  The forwarding function then
   passes it up to the next layer, because it isn't an ESP packet.




















Kent & Seo                  Standards Track                    [Page 97]

RFC 4301              Security Architecture for IP         December 2005


References

Normative References

   [BBCDWW98]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                  Z., and W. Weiss, "An Architecture for Differentiated
                  Service", RFC 2475, December 1998.

   [Bra97]        Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Level", BCP 14, RFC 2119, March 1997.

   [CD98]         Conta, A. and S. Deering, "Internet Control Message
                  Protocol (ICMPv6) for the Internet Protocol Version 6
                  (IPv6) Specification", RFC 2463, December 1998.

   [DH98]         Deering, S., and R. Hinden, "Internet Protocol,
                  Version 6 (IPv6) Specification", RFC 2460, December
                  1998.

   [Eas05]        3rd Eastlake, D., "Cryptographic Algorithm
                  Implementation Requirements For Encapsulating Security
                  Payload (ESP) and Authentication Header (AH)", RFC
                  4305, December 2005.

   [HarCar98]     Harkins, D. and D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC 2409, November 1998.

   [Kau05]        Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
                  Protocol", RFC 4306, December 2005.

   [Ken05a]       Kent, S., "IP Encapsulating Security Payload (ESP)",
                  RFC 4303, December 2005.

   [Ken05b]       Kent, S., "IP Authentication Header", RFC 4302,
                  December 2005.

   [MD90]         Mogul, J. and S. Deering, "Path MTU discovery", RFC
                  1191, November 1990.

   [Mobip]        Johnson, D., Perkins, C., and J. Arkko, "Mobility
                  Support in IPv6", RFC 3775, June 2004.

   [Pos81a]       Postel, J., "Internet Protocol", STD 5, RFC 791,
                  September 1981.

   [Pos81b]       Postel, J., "Internet Control Message Protocol", RFC
                  792, September 1981.




Kent & Seo                  Standards Track                    [Page 98]

RFC 4301              Security Architecture for IP         December 2005


   [Sch05]        Schiller, J., "Cryptographic Algorithms for use in the
                  Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
                  December 2005.

   [WaKiHo97]     Wahl, M., Kille, S., and T. Howes, "Lightweight
                  Directory Access Protocol (v3): UTF-8 String
                  Representation of Distinguished Names", RFC 2253,
                  December 1997.

Informative References

   [CoSa04]       Condell, M., and L. Sanchez, "On the Deterministic
                  Enforcement of Un-ordered Security Policies", BBN
                  Technical Memo 1346, March 2004.

   [FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                  Traina, "Generic Routing Encapsulation (GRE)", RFC
                  2784, March 2000.

   [Gro02]        Grossman, D., "New Terminology and Clarifications for
                  Diffserv", RFC 3260, April 2002.
   [HC03]         Holbrook, H. and B. Cain, "Source Specific Multicast
                  for IP", Work in Progress, November 3, 2002.

   [HA94]         Haller, N. and R. Atkinson, "On Internet
                  Authentication", RFC 1704, October 1994.

   [NiBlBaBL98]   Nichols, K., Blake, S., Baker, F., and D. Black,
                  "Definition of the Differentiated Services Field (DS
                  Field) in the IPv4 and IPv6 Headers", RFC 2474,
                  December 1998.

   [Per96]        Perkins, C., "IP Encapsulation within IP", RFC 2003,
                  October 1996.

   [RaFlBl01]     Ramakrishnan, K., Floyd, S., and D. Black, "The
                  Addition of Explicit Congestion Notification (ECN) to
                  IP", RFC 3168, September 2001.

   [RFC2401]      Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [RFC2983]      Black, D., "Differentiated Services and Tunnels", RFC
                  2983, October 2000.

   [RFC3547]      Baugher, M., Weis, B., Hardjono, T., and H. Harney,
                  "The Group Domain of Interpretation", RFC 3547, July
                  2003.



Kent & Seo                  Standards Track                    [Page 99]

RFC 4301              Security Architecture for IP         December 2005


   [RFC3740]      Hardjono, T. and B.  Weis, "The Multicast Group
                  Security Architecture", RFC 3740, March 2004.

   [RaCoCaDe04]   Rajahalme, J., Conta, A., Carpenter, B., and S.
                  Deering, "IPv6 Flow Label Specification", RFC 3697,
                  March 2004.

   [Sch94]        Schneier, B.,  Applied Cryptography, Section 8.6, John
                  Wiley & Sons, New York, NY, 1994.

   [Shi00]        Shirey, R., "Internet Security Glossary", RFC 2828,
                  May 2000.

   [SMPT01]       Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
                  "IP Payload Compression Protocol (IPComp)", RFC 3173,
                  September 2001.

   [ToEgWa04]     Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
                  Transport Mode for Dynamic Routing", RFC 3884,
                  September 2004.

   [VK83]         V.L. Voydock & S.T. Kent, "Security Mechanisms in
                  High-level Networks", ACM Computing Surveys, Vol. 15,
                  No. 2, June 1983.

Authors' Addresses

   Stephen Kent
   BBN Technologies
   10 Moulton Street
   Cambridge, MA  02138
   USA

   Phone: +1 (617) 873-3988
   EMail: kent@bbn.com


   Karen Seo
   BBN Technologies
   10 Moulton Street
   Cambridge, MA  02138
   USA

   Phone: +1 (617) 873-3152
   EMail: kseo@bbn.com






Kent & Seo                  Standards Track                   [Page 100]

RFC 4301              Security Architecture for IP         December 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Kent & Seo                  Standards Track                   [Page 101]