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
|
<html><head><title>Opportunistic Encryption using The Internet Key Exchange (IKE)</title>
<STYLE type='text/css'>
.title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif }
.filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
font-family: helvetica, arial, sans-serif }
p.copyright { color: #000000; font-size: 10px;
font-family: verdana, charcoal, helvetica, arial, sans-serif }
p { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
ol { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
pre { margin-left: 3em; color: #333333 }
ul.toc { color: #000000; line-height: 16px;
font-family: verdana, charcoal, helvetica, arial, sans-serif }
H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
TD.author-text { color: #000000; font-size: 10px;
font-family: verdana, charcoal, helvetica, arial, sans-serif }
TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
A:link { color: #990000; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
A:visited { color: #333333; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
A:name { color: #333333; font-weight: bold;
font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
.link2 { color:#ffffff; font-weight: bold; text-decoration: none;
font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
font-size: 9px }
.RFC { color:#666666; font-weight: bold; text-decoration: none;
font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
font-size: 9px }
.hotText { color:#ffffff; font-weight: normal; text-decoration: none;
font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
font-size: 9px }
</style>
</head>
<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000">
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Independent submission</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: November 19, 2003</td><td width="33%" bgcolor="#666666" class="header">D. Redelmeier</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">Mimosa</td></tr>
<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">May 21, 2003</td></tr>
</table></td></tr></table>
<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">Opportunistic Encryption using The Internet Key Exchange (IKE)</span></b></font></div>
<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-richardson-ipsec-opportunistic-11.txt</span></b></font></div>
<font face="verdana, helvetica, arial, sans-serif" size="2">
<h3>Status of this Memo</h3>
<p>
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.
Note that other groups may also distribute working documents as
Internet-Drafts.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."</p>
<p>
The list of current Internet-Drafts can be accessed at
<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p>
<p>
The list of Internet-Draft Shadow Directories can be accessed at
<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p>
<p>
This Internet-Draft will expire on November 19, 2003.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
<h3>Abstract</h3>
<p>
This document describes opportunistic encryption (OE) using the Internet Key
Exchange (IKE) and IPsec.
Each system administrator adds new
resource records to his or her Domain Name System (DNS) to support
opportunistic encryption. The objective is to allow encryption for secure communication without
any pre-arrangement specific to the pair of systems involved.
</p>
<p>
DNS is used to distribute the public keys of each
system involved. This is resistant to passive attacks. The use of DNS
Security (DNSSEC) secures this system against active attackers as well.
</p>
<p>
As a result, the administrative overhead is reduced
from the square of the number of systems to a linear dependence, and it becomes
possible to make secure communication the default even
when the partner is not known in advance.
</p>
<p>
This document is offered up as an Informational RFC.
</p><a name="toc"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Table of Contents</h3>
<ul compact class="toc">
<b><a href="#anchor1">1.</a>
Introduction<br></b>
<b><a href="#anchor6">2.</a>
Overview<br></b>
<b><a href="#anchor13">3.</a>
Specification<br></b>
<b><a href="#anchor31">4.</a>
Impacts on IKE<br></b>
<b><a href="#anchor38">5.</a>
DNS issues<br></b>
<b><a href="#anchor42">6.</a>
Network address translation interaction<br></b>
<b><a href="#anchor46">7.</a>
Host implementations<br></b>
<b><a href="#anchor47">8.</a>
Multi-homing<br></b>
<b><a href="#anchor48">9.</a>
Failure modes<br></b>
<b><a href="#anchor52">10.</a>
Unresolved issues<br></b>
<b><a href="#anchor54">11.</a>
Examples<br></b>
<b><a href="#securityconsiderations">12.</a>
Security considerations<br></b>
<b><a href="#anchor79">13.</a>
IANA Considerations<br></b>
<b><a href="#anchor80">14.</a>
Acknowledgments<br></b>
<b><a href="#rfc.references1">§</a>
Normative references<br></b>
<b><a href="#rfc.authors">§</a>
Authors' Addresses<br></b>
<b><a href="#rfc.copyright">§</a>
Full Copyright Statement<br></b>
</ul>
<br clear="all">
<a name="anchor1"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.1"></a><h3>1. Introduction</h3>
<a name="rfc.section.1.1"></a><h4><a name="anchor2">1.1</a> Motivation</h4>
<p>
The objective of opportunistic encryption is to allow encryption without
any pre-arrangement specific to the pair of systems involved. Each
system administrator adds
public key information to DNS records to support opportunistic
encryption and then enables this feature in the nodes' IPsec stack.
Once this is done, any two such nodes can communicate securely.
</p>
<p>
This document describes opportunistic encryption as designed and
mostly implemented by the Linux FreeS/WAN project.
For project information, see http://www.freeswan.org.
</p>
<p>
The Internet Architecture Board (IAB) and Internet Engineering
Steering Group (IESG) have taken a strong stand that the Internet
should use powerful encryption to provide security and
privacy <a href="#RFC1984">[4]</a>.
The Linux FreeS/WAN project attempts to provide a practical means to implement this policy.
</p>
<p>
The project uses the IPsec, ISAKMP/IKE, DNS and DNSSEC
protocols because they are
standardized, widely available and can often be deployed very easily
without changing hardware or software or retraining users.
</p>
<p>
The extensions to support opportunistic encryption are simple. No
changes to any on-the-wire formats are needed. The only changes are to
the policy decision making system. This means that opportunistic
encryption can be implemented with very minimal changes to an existing
IPsec implementation.
</p>
<p>
Opportunistic encryption creates a "fax effect". The proliferation
of the fax machine was possible because it did not require that everyone
buy one overnight. Instead, as each person installed one, the value
of having one increased - as there were more people that could receive faxes.
Once opportunistic encryption is installed it
automatically recognizes
other boxes using opportunistic encryption, without any further configuration
by the network
administrator. So, as opportunistic encryption software is installed on more
boxes, its value
as a tool increases.
</p>
<p>
This document describes the infrastructure to permit deployment of
Opportunistic Encryption.
</p>
<p>
The term S/WAN is a trademark of RSA Data Systems, and is used with permission
by this project.
</p>
<a name="rfc.section.1.2"></a><h4><a name="anchor3">1.2</a> Types of network traffic</h4>
<p>
To aid in understanding the relationship between security processing and IPsec
we divide network traffic into four categories:
<blockquote class="text"><dl>
<dt>* Deny:</dt>
<dd> networks to which traffic is always forbidden.
</dd>
<dt>* Permit:</dt>
<dd> networks to which traffic in the clear is permitted.
</dd>
<dt>* Opportunistic tunnel:</dt>
<dd> networks to which traffic is encrypted if possible, but otherwise is in the clear
or fails depending on the default policy in place.
</dd>
<dt>* Configured tunnel:</dt>
<dd> networks to which traffic must be encrypted, and traffic in the clear is never permitted.
</dd>
</dl></blockquote><p>
</p>
<p>
Traditional firewall devices handle the first two categories. No authentication is required.
The permit policy is currently the default on the Internet.
</p>
<p>
This document describes the third category - opportunistic tunnel, which is
proposed as the new default for the Internet.
</p>
<p>
Category four, encrypt traffic or drop it, requires authentication of the
end points. As the number of end points is typically bounded and is typically
under a single authority, arranging for distribution of
authentication material, while difficult, does not require any new
technology. The mechanism described here provides an additional way to
distribute the authentication materials, that of a public key method that does not
require deployment of an X.509 based infrastructure.
</p>
<p>
Current Virtual Private Networks can often be replaced by an "OE paranoid"
policy as described herein.
</p>
<a name="rfc.section.1.3"></a><h4><a name="anchor4">1.3</a> Peer authentication in opportunistic encryption</h4>
<p>
Opportunistic encryption creates tunnels between nodes that
are essentially strangers. This is done without any prior bilateral
arrangement.
There is, therefore, the difficult question of how one knows to whom one is
talking.
</p>
<p>
One possible answer is that since no useful
authentication can be done, none should be tried. This mode of operation is
named "anonymous encryption". An active man-in-the-middle attack can be
used to thwart the privacy of this type of communication.
Without peer authentication, there is no way to prevent this kind of attack.
</p>
<p>
Although a useful mode, anonymous encryption is not the goal of this
project. Simpler methods are available that can achieve anonymous
encryption only, but authentication of the peer is a desireable goal.
The latter is achieved through key distribution in DNS, leveraging upon
the authentication of the DNS in DNSSEC.
</p>
<p>
Peers are, therefore, authenticated with DNSSEC when available. Local policy
determines how much trust to extend when DNSSEC is not available.
</p>
<p>
However, an essential premise of building private connections with
strangers is that datagrams received through opportunistic tunnels
are no more special than datagrams that arrive in the clear.
Unlike in a VPN, these datagrams should not be given any special
exceptions when it comes to auditing, further authentication or
firewalling.
</p>
<p>
When initiating outbound opportunistic encryption, local
configuration determines what happens if tunnel setup fails. It may be that
the packet goes out in the clear, or it may be dropped.
</p>
<a name="rfc.section.1.4"></a><h4><a name="anchor5">1.4</a> Use of RFC2119 terms</h4>
<p>
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 <a href="#RFC2119">[5]</a>
</p>
<a name="anchor6"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.2"></a><h3>2. Overview</h3>
<a name="rfc.section.2.1"></a><h4><a name="anchor7">2.1</a> Reference diagram</h4>
<br><hr size="1" shade="0">
<a name="networkdiagram"></a>
<p>The following network diagram is used in the rest of
this document as the canonical diagram:
</p></font><pre>
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Reference Network Diagram </b></font><br></td></tr></table><hr size="1" shade="0">
<p>
In this diagram, there are four end-nodes: A, B, C and D.
There are three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part
of the same administrative authority, AS1. SG-A and SG-D are on two different exit
paths from organization 1. SG-B/B is an independent organization, AS2.
Nodes Q and R are nodes on the Internet. PI is the Public
Internet ("The Wild").
</p>
<a name="rfc.section.2.2"></a><h4><a name="anchor8">2.2</a> Terminology</h4>
<p>
The following terminology is used in this document:
</p>
<blockquote class="text"><dl>
<dt>Security gateway:</dt>
<dd> a system that performs IPsec tunnel
mode encapsulation/decapsulation. [SG-x] in the diagram.
</dd>
<dt>Alice:</dt>
<dd> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.
</dd>
<dt>Bob:</dt>
<dd> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.
</dd>
<dt>Carol:</dt>
<dd> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.
</dd>
<dt>Dave:</dt>
<dd> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68.
</dd>
<dt>SG-A:</dt>
<dd> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.
</dd>
<dt>SG-B:</dt>
<dd> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.
</dd>
<dt>SG-D:</dt>
<dd> Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.
</dd>
<dt>-</dt>
<dd> A single dash represents clear-text datagrams.
</dd>
<dt>=</dt>
<dd> An equals sign represents phase 2 (IPsec) cipher-text
datagrams.
</dd>
<dt>~</dt>
<dd> A single tilde represents clear-text phase 1 datagrams.
</dd>
<dt>#</dt>
<dd> A hash sign represents phase 1 (IKE) cipher-text
datagrams.
</dd>
<dt>.</dt>
<dd> A period represents an untrusted network of unknown
type.
</dd>
<dt>Configured tunnel:</dt>
<dd> a tunnel that
is directly and deliberately hand configured on participating gateways.
Configured tunnels are typically given a higher level of
trust than opportunistic tunnels.
</dd>
<dt>Road warrior tunnel:</dt>
<dd> a configured tunnel connecting one
node with a fixed IP address and one node with a variable IP address.
A road warrior (RW) connection must be initiated by the
variable node, since the fixed node cannot know the
current address for the road warrior.
</dd>
<dt>Anonymous encryption:</dt>
<dd>
the process of encrypting a session without any knowledge of who the
other parties are. No authentication of identities is done.
</dd>
<dt>Opportunistic encryption:</dt>
<dd>
the process of encrypting a session with authenticated knowledge of
who the other parties are.
</dd>
<dt>Lifetime:</dt>
<dd>
the period in seconds (bytes or datagrams) for which a security
association will remain alive before needing to be re-keyed.
</dd>
<dt>Lifespan:</dt>
<dd>
the effective time for which a security association remains useful. A
security association with a lifespan shorter than its lifetime would
be removed when no longer needed. A security association with a
lifespan longer than its lifetime would need to be re-keyed one or
more times.
</dd>
<dt>Phase 1 SA:</dt>
<dd> an ISAKMP/IKE security association sometimes
referred to as a keying channel.
</dd>
<dt>Phase 2 SA:</dt>
<dd> an IPsec security association.
</dd>
<dt>Tunnel:</dt>
<dd> another term for a set of phase 2 SA (one in each direction).
</dd>
<dt>NAT:</dt>
<dd> Network Address Translation
(see <a href="#RFC2663">[20]</a>).
</dd>
<dt>NAPT:</dt>
<dd> Network Address and Port Translation
(see <a href="#RFC2663">[20]</a>).
</dd>
<dt>AS:</dt>
<dd> an autonomous system (AS) is a group of systems (a network) that
are under the administrative control of a single organization.
</dd>
<dt>Default-free zone:</dt>
<dd>
a set of routers that maintain a complete set of routes to
all currently reachable destinations. Having such a list, these routers
never make use of a default route. A datagram with a destination address
not matching any route will be dropped by such a router.
</dd>
</dl></blockquote><p>
<a name="rfc.section.2.3"></a><h4><a name="anchor9">2.3</a> Model of operation</h4>
<p>
The opportunistic encryption security gateway (OE gateway) is a regular
gateway node as described in <a href="#RFC0791">[2]</a> section 2.4 and
<a href="#RFC1009">[3]</a> with the additional capabilities described here and
in <a href="#RFC2401">[7]</a>.
The algorithm described here provides a way to determine, for each datagram,
whether or not to encrypt and tunnel the datagram. Two important things
that must be determined are whether or not to encrypt and tunnel and, if
so, the destination address or name of the tunnel end point which should be used.
</p>
<a name="rfc.section.2.3.1"></a><h4><a name="anchor10">2.3.1</a> Tunnel authorization</h4>
<p>
The OE gateway determines whether or not to create a tunnel based on
the destination address of each packet. Upon receiving a packet with a destination
address not recently seen, the OE gateway performs a lookup in DNS for an
authorization resource record (see <a href="#TXT">Use of TXT delegation record</a>). The record is located using
the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa
(IPv6) maps. If an authorization record is found, the OE gateway
interprets this as a request for a tunnel to be formed.
</p>
<a name="rfc.section.2.3.2"></a><h4><a name="anchor11">2.3.2</a> Tunnel end-point discovery</h4>
<p>
The authorization resource record also provides the address or name of the tunnel
end point which should be used.
</p>
<p>
The record may also provide the public RSA key of the tunnel end point
itself. This is provided for efficiency only. If the public RSA key is not
present, the OE gateway performs a second lookup to find a KEY
resource record for the end point address or name.
</p>
<p>
Origin and integrity protection of the resource records is provided by
DNSSEC (<a href="#RFC2535">[16]</a>). <a href="#nodnssec">Restriction on unauthenticated TXT delegation records</a>
documents an optional restriction on the tunnel end point if DNSSEC signatures
are not available for the relevant records.
</p>
<a name="rfc.section.2.3.3"></a><h4><a name="anchor12">2.3.3</a> Caching of authorization results</h4>
<p>
The OE gateway maintains a cache, in the forwarding plane, of
source/destination pairs for which opportunistic encryption has been
attempted. This cache maintains a record of whether or not OE was
successful so that subsequent datagrams can be forwarded properly
without additional delay.
</p>
<p>
Successful negotiation of OE instantiates a new security association.
Failure to negotiate OE results in creation of a
forwarding policy entry either to drop or transmit in the clear future
datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking
up the same information.
</p>
<p>
The cache is timed out periodically, as described in <a href="#teardown">Renewal and teardown</a>.
This removes entries that are no longer
being used and permits the discovery of changes in authorization policy.
</p>
<a name="anchor13"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.3"></a><h3>3. Specification</h3>
<p>
The OE gateway is modeled to have a forwarding plane and a control
plane. A control channel, such as PF_KEY, connects the two planes.
(See <a href="#RFC2367">[6]</a>.)
The forwarding plane performs per datagram operations. The control plane
contains a keying
daemon, such as ISAKMP/IKE, and performs all authorization, peer authentication and
key derivation functions.
</p>
<a name="rfc.section.3.1"></a><h4><a name="anchor14">3.1</a> Datagram state machine</h4>
<p>
Let the OE gateway maintain a collection of objects -- a superset of the
security policy database (SPD) specified in <a href="#RFC2401">[7]</a>. For
each combination of source and destination address, an SPD
object exists in one of five following states.
Prior to forwarding each datagram, the
responder uses the source and destination addresses to pick an entry from the SPD.
The SPD then determines if and how the packet is forwarded.
</p>
<a name="rfc.section.3.1.1"></a><h4><a name="anchor15">3.1.1</a> Non-existent policy</h4>
<p>
If the responder does not find an entry, then this policy applies.
The responder creates an entry with an initial state of "hold policy" and requests
keying material from the keying daemon. The responder does not forward the datagram,
rather it attaches the datagram to the SPD entry as the "first" datagram and retains it
for eventual transmission in a new state.
</p>
<a name="rfc.section.3.1.2"></a><h4><a name="anchor16">3.1.2</a> Hold policy</h4>
<p>
The responder requests keying material. If the interface to the keying
system is lossy (PF_KEY, for instance, can be), the implementation
SHOULD include a mechanism to retransmit the
keying request at a rate limited to less than 1 request per second.
The responder does not forward the datagram. It attaches the
datagram to the SPD entry as the "last" datagram where it is retained
for eventual transmission. If there is
a datagram already so stored, then that already stored datagram is discarded.
</p>
<p>
Because the "first" datagram is probably a TCP SYN packet, the
responder retains the "first" datagram in an attempt to avoid waiting for a
TCP retransmit. The responder retains the "last"
datagram in deference to streaming protocols that find it useful to know
how much data has been lost. These are recommendations to
decrease latency. There are no operational requirements for this.
</p>
<a name="rfc.section.3.1.3"></a><h4><a name="anchor17">3.1.3</a> Pass-through policy</h4>
<p>
The responder forwards the datagram using the normal forwarding table.
The responder enters this state only by command from the keying daemon,
and upon entering this state, also forwards the "first" and "last" datagrams.
</p>
<a name="rfc.section.3.1.4"></a><h4><a name="anchor18">3.1.4</a> Deny policy</h4>
<p>
The responder discards the datagram. The responder enters this state only by
command
from the keying daemon, and upon entering this state, discards the "first"
and "last" datagrams.
Local administration decides if further datagrams cause ICMP messages
to be generated (i.e. ICMP Destination Unreachable, Communication
Administratively Prohibited. type=3, code=13).
</p>
<a name="rfc.section.3.1.5"></a><h4><a name="anchor19">3.1.5</a> Encrypt policy</h4>
<p>
The responder encrypts the datagram using the indicated security association database
(SAD) entry. The responder enters this state only by command from the keying daemon, and upon entering
this state, releases and forwards the "first" and "last" datagrams using the
new encrypt policy.
</p>
<p>
If the associated SAD entry expires because of byte, packet or time limits, then
the entry returns to the Hold policy, and an expire message is sent to the keying daemon.
</p>
<p>
All states may be created directly by the keying daemon while acting as a
responder.
</p>
<a name="rfc.section.3.2"></a><h4><a name="initclasses">3.2</a> Keying state machine - initiator</h4>
<p>
Let the keying daemon maintain a collection of objects. Let them be
called "connections" or "conn"s. There are two categories of
connection objects: classes and instances. A class represents an
abstract policy - what could be. An instance represents an actual connection -
what is implemented at the time.
</p>
<p>
Let there be two further subtypes of connections: keying channels (Phase
1 SAs) and data channels (Phase 2 SAs). Each data channel object may have
a corresponding SPD and SAD entry maintained by the datagram state machine.
</p>
<p>
For the purposes of opportunistic encryption, there MUST, at least, be
connection classes known as "deny", "always-clear-text", "OE-permissive", and
"OE-paranoid".
The latter two connection classes define a set of source and/or destination
addresses for which opportunistic encryption will be attempted. The administrator MAY set policy
options in a number of additional places. An implementation MAY create additional connection classes to further refine
these policies.
</p>
<p>
The simplest system may need only the "OE-permissive" connection, and would
list its own (single) IP address as the source address of this policy and
the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the
simplest policy is to try opportunistic encryption with all destinations.
</p>
<p>
The distinction between permissive and paranoid OE use will become clear
in the state transition differences. In general a permissive OE will, on
failure, install a pass-through policy, while a paranoid OE will, on failure,
install a drop policy.
</p>
<p>
In this description of the keying machine's state transitions, the states
associated with the keying system itself are omitted because they are best documented in the keying system
(<a href="#RFC2407">[8]</a>,
<a href="#RFC2408">[9]</a> and <a href="#RFC2409">[10]</a> for ISAKMP/IKE),
and the details are keying system specific. Opportunistic encryption is not
dependent upon any specific keying protocol, but this document does provide
requirements for those using ISAKMP/IKE to assure that implementations inter-operate.
</p>
<p>
The state transitions that may be involved in communicating with the
forwarding plane are omitted. PF_KEY and similar protocols have their own
set of states required for message sends and completion notifications.
</p>
<p>
Finally, the retransmits and recursive lookups that are normal for DNS are
not included in this description of the state machine.
</p>
<a name="rfc.section.3.2.1"></a><h4><a name="anchor20">3.2.1</a> Nonexistent connection</h4>
<p>
There is no connection instance for a given source/destination address pair.
Upon receipt of a request for keying material for this
source/destination pair, the initiator searches through the connection classes to
determine the most appropriate policy. Upon determining an appropriate
connection class, an instance object is created of that type.
Both of the OE types result in a potential OE connection.
</p>
<p>Failure to find an appropriate connection class results in an
administrator defined default.
</p>
<p>
In each case, when the initiator finds an appropriate class for the new flow,
an instance connection is made of the class which matched.
</p>
<a name="rfc.section.3.2.2"></a><h4><a name="anchor21">3.2.2</a> Clear-text connection</h4>
<p>
The non-existent connection makes a transition to this state when an
always-clear-text class is instantiated, or when an OE-permissive
connection fails. During the transition, the initiator creates a pass-through
policy object in the forwarding plane for the appropriate flow.
</p>
<p>
Timing out is the only way to leave this state
(see <a href="#expiring">Expiring connection</a>).
</p>
<a name="rfc.section.3.2.3"></a><h4><a name="anchor22">3.2.3</a> Deny connection</h4>
<p>
The empty connection makes a transition to this state when a
deny class is instantiated, or when an OE-paranoid connection fails.
During the transition, the initiator creates a deny policy object in the forwarding plane
for the appropriate flow.
</p>
<p>
Timing out is the only way to leave this state
(see <a href="#expiring">Expiring connection</a>).
</p>
<a name="rfc.section.3.2.4"></a><h4><a name="anchor23">3.2.4</a> Potential OE connection</h4>
<p>
The empty connection makes a transition to this state when one of either OE class is instantiated.
During the transition to this state, the initiator creates a hold policy object in the
forwarding plane for the appropriate flow.
</p>
<p>
In addition, when making a transition into this state, DNS lookup is done in
the reverse-map for a TXT delegation resource record (see <a href="#TXT">Use of TXT delegation record</a>).
The lookup key is the destination address of the flow.
</p>
<p>
There are three ways to exit this state:
<ol class="text">
<li>DNS lookup finds a TXT delegation resource record.
</li>
<li>DNS lookup does not find a TXT delegation resource record.
</li>
<li>DNS lookup times out.
</li>
</ol><p>
</p>
<p>
Based upon the results of the DNS lookup, the potential OE connection makes a
transition to the pending OE connection state. The conditions for a
successful DNS look are:
<ol class="text">
<li>DNS finds an appropriate resource record
</li>
<li>It is properly formatted according to <a href="#TXT">Use of TXT delegation record</a>
</li>
<li> if DNSSEC is enabled, then the signature has been vouched for.
</li>
</ol><p>
Note that if the initiator does not find the public key
present in the TXT delegation record, then the public key must
be looked up as a sub-state. Only successful completion of all the
DNS lookups is considered a success.
</p>
<p>
If DNS lookup does not find a resource record or DNS times out, then the
initiator considers the receiver not OE capable. If this is an OE-paranoid instance,
then the potential OE connection makes a transition to the deny connection state.
If this is an OE-permissive instance, then the potential OE connection makes a transition to the
clear-text connection state.
</p>
<p>
If the initiator finds a resource record but it is not properly formatted, or
if DNSSEC is
enabled and reports a failure to authenticate, then the potential OE
connection should make a
transition to the deny connection state. This action SHOULD be logged. If the
administrator wishes to override this transition between states, then an
always-clear class can be installed for this flow. An implementation MAY make
this situation a new class.
</p>
<a name="rfc.section.3.2.4.1"></a><h4><a name="nodnssec">3.2.4.1</a> Restriction on unauthenticated TXT delegation records</h4>
<p>
An implementation SHOULD also provide an additional administrative control
on delegation records and DNSSEC. This control would apply to delegation
records (the TXT records in the reverse-map) that are not protected by
DNSSEC.
Records of this type are only permitted to delegate to their own address as
a gateway. When this option is enabled, an active attack on DNS will be
unable to redirect packets to other than the original destination.
</p>
<a name="rfc.section.3.2.5"></a><h4><a name="anchor24">3.2.5</a> Pending OE connection</h4>
<p>
The potential OE connection makes a transition to this state when
the initiator determines that all the information required from the DNS lookup is present.
Upon entering this state, the initiator attempts to initiate keying to the gateway
provided.
</p>
<p>
Exit from this state occurs either with a successfully created IPsec SA, or
with a failure of some kind. Successful SA creation results in a transition
to the key connection state.
</p>
<p>
Three failures have caused significant problems. They are clearly not the
only possible failures from keying.
</p>
<p>
Note that if there are multiple gateways available in the TXT delegation
records, then a failure can only be declared after all have been
tried. Further, creation of a phase 1 SA does not constitute success. A set
of phase 2 SAs (a tunnel) is considered success.
</p>
<p>
The first failure occurs when an ICMP port unreachable is consistently received
without any other communication, or when there is silence from the remote
end. This usually means that either the gateway is not alive, or the
keying daemon is not functional. For an OE-permissive connection, the initiator makes a transition
to the clear-text connection but with a low lifespan. For an OE-pessimistic connection,
the initiator makes a transition to the deny connection again with a low lifespan. The lifespan in both
cases is kept low because the remote gateway may
be in the process of rebooting or be otherwise temporarily unavailable.
</p>
<p>
The length of time to wait for the remote keying daemon to wake up is
a matter of some debate. If there is a routing failure, 5 minutes is usually long enough for the network to
re-converge. Many systems can reboot in that amount of
time as well. However, 5 minutes is far too long for most users to wait to
hear that they can not connect using OE. Implementations SHOULD make this a
tunable parameter.
</p>
<p>
The second failure occurs after a phase 1 SA has been created, but there is
either no response to the phase 2 proposal, or the initiator receives a
negative notify (the notify must be
authenticated). The remote gateway is not prepared to do OE at this time.
As before, the initiator makes a transition to the clear-text or the deny
connection based upon connection class, but this
time with a normal lifespan.
</p>
<p>
The third failure occurs when there is signature failure while authenticating
the remote gateway. This can occur when there has been a
key roll-over, but DNS has not caught up. In this case again, the initiator makes a
transition to the clear-text or the deny connection based
upon the connection class. However, the lifespan depends upon the remaining
time to live in the DNS. (Note that DNSSEC signed resource records have a different
expiry time than non-signed records.)
</p>
<a name="rfc.section.3.2.6"></a><h4><a name="keyed">3.2.6</a> Keyed connection</h4>
<p>
The pending OE connection makes a transition to this state when
session keying material (the phase 2 SAs) is derived. The initiator creates an encrypt
policy in the forwarding plane for this flow.
</p>
<p>
There are three ways to exit this state. The first is by receipt of an
authenticated delete message (via the keying channel) from the peer. This is
normal teardown and results in a transition to the expired connection state.
</p>
<p>
The second exit is by expiry of the forwarding plane keying material. This
starts a re-key operation with a transition back to pending OE
connection. In general, the soft expiry occurs with sufficient time left
to continue to use the keys. A re-key can fail, which may
result in the connection failing to clear-text or deny as
appropriate. In the event of a failure, the forwarding plane
policy does not change until the phase 2 SA (IPsec SA) reaches its
hard expiry.
</p>
<p>
The third exit is in response to a negotiation from a remote
gateway. If the forwarding plane signals the control plane that it has received an
unknown SPI from the remote gateway, or an ICMP is received from the remote gateway
indicating an unknown SPI, the initiator should consider that
the remote gateway has rebooted or restarted. Since these
indications are easily forged, the implementation must
exercise care. The initiator should make a cautious
(rate-limited) attempt to re-key the connection.
</p>
<a name="rfc.section.3.2.7"></a><h4><a name="expiring">3.2.7</a> Expiring connection</h4>
<p>
The initiator will periodically place each of the deny, clear-text, and keyed
connections into this
sub-state. See <a href="#teardown">Renewal and teardown</a> for more details of how often this
occurs.
The initiator queries the forwarding plane for last use time of the
appropriate
policy. If the last use time is relatively recent, then the connection
returns to the
previous deny, clear-text or keyed connection state. If not, then the
connection enters
the expired connection state.
</p>
<p>
The DNS query and answer that lead to the expiring connection state are also
examined. The DNS query may become stale. (A negative, i.e. no such record, answer
is valid for the period of time given by the MINIMUM field in an attached SOA
record. See <a href="#RFC1034">[12]</a> section 4.3.4.)
If the DNS query is stale, then a new query is made. If the results change, then the connection
makes a transition to a new state as described in potential OE connection state.
</p>
<p>
Note that when considering how stale a connection is, both outgoing SPD and
incoming SAD must be queried as some flows may be unidirectional for some time.
</p>
<p>
Also note that the policy at the forwarding plane is not updated unless there
is a conclusion that there should be a change.
</p>
<a name="rfc.section.3.2.8"></a><h4><a name="anchor25">3.2.8</a> Expired connection</h4>
<p>
Entry to this state occurs when no datagrams have been forwarded recently via the
appropriate SPD and SAD objects. The objects in the forwarding plane are
removed (logging any final byte and packet counts if appropriate) and the
connection instance in the keying plane is deleted.
</p>
<p>
The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in
<a href="#teardown">Renewal and teardown</a>.
</p>
<p>
Whether or not to delete the phase 1 SAs
at this time is left as a local implementation issue. Implementations
that do delete the phase 1 SAs MUST send authenticated delete messages to
indicate that they are doing so. There is an advantage to keeping
the phase 1 SAs until they expire - they may prove useful again in the
near future.
</p>
<a name="rfc.section.3.3"></a><h4><a name="anchor26">3.3</a> Keying state machine - responder</h4>
<p>
The responder has a set of objects identical to those of the initiator.
</p>
<p>
The responder receives an invitation to create a keying channel from an initiator.
</p>
<a name="rfc.section.3.3.1"></a><h4><a name="anchor27">3.3.1</a> Unauthenticated OE peer</h4>
<p>
Upon entering this state, the responder starts a DNS lookup for a KEY record for the
initiator.
The responder looks in the reverse-map for a KEY record for the initiator if the
initiator has offered an ID_IPV4_ADDR, and in the forward map if the
initiator has offered an ID_FQDN type. (See <a href="#RFC2407">[8]</a> section
4.6.2.1.)
</p>
<p>
The responder exits this state upon successful receipt of a KEY from DNS, and use of the key
to verify the signature of the initiator.
</p>
<p>
Successful authentication of the peer results in a transition to the
authenticated OE Peer state.
</p>
<p>
Note that the unauthenticated OE peer state generally occurs in the middle of the key negotiation
protocol. It is really a form of pseudo-state.
</p>
<a name="rfc.section.3.3.2"></a><h4><a name="anchor28">3.3.2</a> Authenticated OE Peer</h4>
<p>
The peer will eventually propose one or more phase 2 SAs. The responder uses the source and
destination address in the proposal to
finish instantiating the connection state
using the connection class table.
The responder MUST search for an identical connection object at this point.
</p>
<p>
If an identical connection is found, then the responder deletes the old instance,
and the new object makes a transition to the pending OE connection state. This means
that new ISAKMP connections with a given peer will always use the latest
instance, which is the correct one if the peer has rebooted in the interim.
</p>
<p>
If an identical connection is not found, then the responder makes the transition according to the
rules given for the initiator.
</p>
<p>
Note that if the initiator is in OE-paranoid mode and the responder is in
either always-clear-text or deny, then no communication is possible according
to policy. An implementation is permitted to create new types of policies
such as "accept OE but do not initiate it". This is a local matter.
</p>
<a name="rfc.section.3.4"></a><h4><a name="teardown">3.4</a> Renewal and teardown</h4>
<a name="rfc.section.3.4.1"></a><h4><a name="anchor29">3.4.1</a> Aging</h4>
<p>
A potentially unlimited number of tunnels may exist. In practice, only a few
tunnels are used during a period of time. Unused tunnels MUST, therefore, be
torn down. Detecting when tunnels are no longer in use is the subject of this section.
</p>
<p>
There are two methods for removing tunnels: explicit deletion or expiry.
</p>
<p>
Explicit deletion requires an IKE delete message. As the deletes
MUST be authenticated, both ends of the tunnel must maintain the
key channel (phase 1 ISAKMP SA). An implementation which refuses to either maintain or
recreate the keying channel SA will be unable to use this method.
</p>
<p>
The tunnel expiry method, simply allows the IKE daemon to
expire normally without attempting to re-key it.
</p>
<p>
Regardless of which method is used to remove tunnels, the implementation requires
a method to determine if the tunnel is still in use. The specifics are a
local matter, but the FreeS/WAN project uses the following criteria. These
criteria are currently implemented in the key management daemon, but could
also be implemented at the SPD layer using an idle timer.
</p>
<p>
Set a short initial (soft) lifespan of 1 minute since many net flows last
only a few seconds.
</p>
<p>
At the end of the lifespan, check to see if the tunnel was used by
traffic in either direction during the last 30 seconds. If so, assign a
longer tentative lifespan of 20 minutes after which, look again. If the
tunnel is not in use, then close the tunnel.
</p>
<p>
The expiring state in the key management
system (see <a href="#expiring">Expiring connection</a>) implements these timeouts.
The timer above may be in the forwarding plane,
but then it must be re-settable.
</p>
<p>
The tentative lifespan is independent of re-keying; it is just the time when
the tunnel's future is next considered.
(The term lifespan is used here rather than lifetime for this reason.)
Unlike re-keying, this tunnel use check is not costly and should happen
reasonably frequently.
</p>
<p>
A multi-step back-off algorithm is not considered worth the effort here.
</p>
<p>
If the security gateway and the client host are the
same and not a Bump-in-the-Stack or Bump-in-the-Wire implementation, tunnel
teardown decisions MAY pay attention to TCP connection status as reported
by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is
expected. Closing of the only TCP connection through a tunnel is a
strong hint that no more traffic is expected.
</p>
<a name="rfc.section.3.4.2"></a><h4><a name="anchor30">3.4.2</a> Teardown and cleanup</h4>
<p>
Teardown should always be coordinated between the two ends of the tunnel by
interpreting and sending delete notifications. There is a
detailed sub-state in the expired connection state of the key manager that
relates to retransmits of the delete notifications, but this is considered to
be a keying system detail.
</p>
<p>
On receiving a delete for the outbound SAs of a tunnel (or some subset of
them), tear down the inbound ones also and notify the remote end with a
delete. If the local system receives a delete for a tunnel which is no longer in
existence, then two delete messages have crossed paths. Ignore the delete.
The operation has already been completed. Do not generate any messages in this
situation.
</p>
<p>
Tunnels are to be considered as bidirectional entities, even though the
low-level protocols don't treat them this way.
</p>
<p>
When the deletion is initiated locally, rather than as a
response to a received delete, send a delete for (all) the
inbound SAs of a tunnel. If the local system does not receive a responding delete
for the outbound SAs, try re-sending the original
delete. Three tries spaced 10 seconds apart seems a reasonable
level of effort. A failure of the other end to respond after 3 attempts,
indicates that the possibility of further communication is unlikely. Remove the outgoing SAs.
(The remote system may be a mobile node that is no longer present or powered on.)
</p>
<p>
After re-keying, transmission should switch to using the new
outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover
outgoing SAs should be cleared out promptly (delete should be sent
for the outgoing SAs) rather than waiting for them to expire. This
reduces clutter and minimizes confusion for the operator doing diagnostics.
</p>
<a name="anchor31"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.4"></a><h3>4. Impacts on IKE</h3>
<a name="rfc.section.4.1"></a><h4><a name="anchor32">4.1</a> ISAKMP/IKE protocol</h4>
<p>
The IKE wire protocol needs no modifications. The major changes are
implementation issues relating to how the proposals are interpreted, and from
whom they may come.
</p>
<p>
As opportunistic encryption is designed to be useful between peers without
prior operator configuration, an IKE daemon must be prepared to negotiate
phase 1 SAs with any node. This may require a large amount of resources to
maintain cookie state, as well as large amounts of entropy for nonces,
cookies and so on.
</p>
<p>
The major changes to support opportunistic encryption are at the IKE daemon
level. These changes relate to handling of key acquisition requests, lookup
of public keys and TXT records, and interactions with firewalls and other
security facilities that may be co-resident on the same gateway.
</p>
<a name="rfc.section.4.2"></a><h4><a name="anchor33">4.2</a> Gateway discovery process</h4>
<p>
In a typical configured tunnel, the address of SG-B is provided
via configuration. Furthermore, the mapping of an SPD entry to a gateway is
typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then
the mapping to a gateway is determined by the reverse DNS records.
</p>
<p>
The need to do a DNS lookup and wait for a reply will typically introduce a
new state and a new event source (DNS replies) to IKE. Although a
synchronous DNS request can be implemented for proof of concept, experience
is that it can cause very high latencies when a queue of queries must
all timeout in series.
</p>
<p>
Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with
some of the protocol steps.
</p>
<a name="rfc.section.4.3"></a><h4><a name="anchor34">4.3</a> Self identification</h4>
<p>
SG-A will have to establish its identity. Use an
IPv4 ID in phase 1.
</p>
<p> There are many situations where the administrator of SG-A may not be
able to control the reverse DNS records for SG-A's public IP address.
Typical situations include dialup connections and most residential-type broadband Internet access
(ADSL, cable-modem) connections. In these situations, a fully qualified domain
name that is under the control of SG-A's administrator may be used
when acting as an initiator only.
The FQDN ID should be used in phase 1. See <a href="#fqdn">Use of FQDN IDs</a>
for more details and restrictions.
</p>
<a name="rfc.section.4.4"></a><h4><a name="anchor35">4.4</a> Public key retrieval process</h4>
<p>
Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID or
an FQDN ID, an IKE daemon needs to examine local caches and
configuration files to determine if this is part of a configured tunnel.
If no configured tunnels are found, then the implementation should attempt to retrieve
a KEY record from the reverse DNS in the case of an IPv4/IPv6 ID, or
from the forward DNS in the case of FQDN ID.
</p>
<p>
It is reasonable that if other non-local sources of policy are used
(COPS, LDAP), they be consulted concurrently but some
clear ordering of policy be provided. Note that due to variances in
latency, implementations must wait for positive or negative replies from all sources
of policy before making any decisions.
</p>
<a name="rfc.section.4.5"></a><h4><a name="anchor36">4.5</a> Interactions with DNSSEC</h4>
<p>
The implementation described (1.98) neither uses DNSSEC directly to
explicitly verify the authenticity of zone information, nor uses the NXT
records to provide authentication of the absence of a TXT or KEY
record. Rather, this implementation uses a trusted path to a DNSSEC
capable caching resolver.
</p>
<p>
To distinguish between an authenticated and an unauthenticated DNS
resource record, a stub resolver capable of returning DNSSEC
information MUST be used.
</p>
<a name="rfc.section.4.6"></a><h4><a name="anchor37">4.6</a> Required proposal types</h4>
<a name="rfc.section.4.6.1"></a><h4><a name="phase1id">4.6.1</a> Phase 1 parameters</h4>
<p>
Main mode MUST be used.
</p>
<p>
The initiator MUST offer at least one proposal using some combination
of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be
proposed first.
<a href="#RFC3526">[11]</a>
</p>
<p>
The initiator MAY offer additional proposals, but the cipher MUST not
be weaker than 3DES. The initiator SHOULD limit the number of proposals
such that the IKE datagrams do not need to be fragmented.
</p>
<p>
The responder MUST accept one of the proposals. If any configuration
of the responder is required then the responder is not acting in an
opportunistic way.
</p>
<p>
SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external
interface of SG-A for phase 1. (There is an exception, see <a href="#fqdn">Use of FQDN IDs</a>.) The authentication method MUST be RSA public key signatures.
The RSA key for SG-A SHOULD be placed into a DNS KEY record in
the reverse space of SG-A (i.e. using in-addr.arpa).
</p>
<a name="rfc.section.4.6.2"></a><h4><a name="phase2id">4.6.2</a> Phase 2 parameters</h4>
<p>
SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
</p>
<p>
Tunnel mode MUST be used.
</p>
<p>
Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
</p>
<p>
Authorization for SG-A to act on Alice's behalf is determined by
looking for a TXT record in the reverse-map at Alice's address.
</p>
<p>
Compression SHOULD NOT be mandatory. It may be offered as an option.
</p>
<a name="anchor38"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.5"></a><h3>5. DNS issues</h3>
<a name="rfc.section.5.1"></a><h4><a name="KEY">5.1</a> Use of KEY record</h4>
<p>
In order to establish their own identities, SG-A and SG-B SHOULD publish
their public keys in their reverse DNS via
DNSSEC's KEY record.
See section 3 of <a href="#RFC2535">RFC 2535</a>[16].
</p>
<p>
<p>For example:
</p></font><pre>
KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<blockquote class="text"><dl>
<dt>0x4200:</dt>
<dd> The flag bits, indicating that this key is prohibited
for confidentiality use (it authenticates the peer only, a separate
Diffie-Hellman exchange is used for
confidentiality), and that this key is associated with the non-zone entity
whose name is the RR owner name. No other flags are set.
</dd>
<dt>4:</dt>
<dd>This indicates that this key is for use by IPsec.
</dd>
<dt>1:</dt>
<dd>An RSA key is present.
</dd>
<dt>AQNJjkKlIk9...nYyUkKK8:</dt>
<dd>The public key of the host as described in <a href="#RFC3110">[17]</a>.
</dd>
</dl></blockquote><p>
</p>
<p>Use of several KEY records allows for key rollover. The SIG Payload in
IKE phase 1 SHOULD be accepted if the public key given by any KEY RR
validates it.
</p>
<a name="rfc.section.5.2"></a><h4><a name="TXT">5.2</a> Use of TXT delegation record</h4>
<p>
Alice publishes a TXT record to provide authorization for SG-A to act on
Alice's behalf.
Bob publishes a TXT record to provide authorization for SG-B to act on Bob's
behalf.
These records are located in the reverse DNS (in-addr.arpa) for their
respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC, when
it is deployed. DNSSEC is required to defend against active attacks.
</p>
<p>
If Alice's address is P.Q.R.S, then she can authorize another node to
act on her behalf by publishing records at:
</p>
</font><pre>
S.R.Q.P.in-addr.arpa
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
</p>
<p>
The contents of the resource record are expected to be a string that
uses the following syntax, as suggested in <a href="#RFC1464">[15]</a>.
(Note that the reply to query may include other TXT resource
records used by other applications.)
<br><hr size="1" shade="0">
<a name="txtformat"></a>
</p>
</font><pre>
X-IPsec-Server(P)=A.B.C.D KEY
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Format of reverse delegation record </b></font><br></td></tr></table><hr size="1" shade="0">
</p>
<blockquote class="text"><dl>
<dt>P:</dt>
<dd> Specifies a precedence for this record. This is
similar to MX record preferences. Lower numbers have stronger
preference.
</dd>
<dt>A.B.C.D:</dt>
<dd> Specifies the IP address of the Security Gateway
for this client machine.
</dd>
<dt>KEY:</dt>
<dd> Is the encoded RSA Public key of the Security
Gateway. The key is provided here to avoid a second DNS lookup. If this
field is absent, then a KEY resource record should be looked up in the
reverse-map of A.B.C.D. The key is transmitted in base64 format.
</dd>
</dl></blockquote><p>
<p>
The pieces of the record are separated by any whitespace
(space, tab, newline, carriage return). An ASCII space SHOULD
be used.
</p>
<p>
In the case where Alice is located at a public address behind a
security gateway that has no fixed address (or no control over its
reverse-map), then Alice may delegate to a public key by domain name.
<br><hr size="1" shade="0">
<a name="txtfqdnformat"></a>
</p>
</font><pre>
X-IPsec-Server(P)=@FQDN KEY
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Format of reverse delegation record (FQDN version) </b></font><br></td></tr></table><hr size="1" shade="0">
</p>
<blockquote class="text"><dl>
<dt>P:</dt>
<dd> Is as above.
</dd>
<dt>FQDN:</dt>
<dd> Specifies the FQDN that the Security Gateway
will identify itself with.
</dd>
<dt>KEY:</dt>
<dd> Is the encoded RSA Public key of the Security
Gateway.
</dd>
</dl></blockquote><p>
<p>
If there is more than one such TXT record with strongest (lowest
numbered) precedence, one Security Gateway is picked arbitrarily from
those specified in the strongest-preference records.
</p>
<a name="rfc.section.5.2.1"></a><h4><a name="anchor39">5.2.1</a> Long TXT records</h4>
<p>
When packed into transport format, TXT records which are longer than 255
characters are divided into smaller <character-strings>.
(See <a href="#RFC1035">[13]</a> section 3.3 and 3.3.14.) These MUST
be reassembled into a single string for processing.
Whitespace characters in the base64 encoding are to be ignored.
</p>
<a name="rfc.section.5.2.2"></a><h4><a name="anchor40">5.2.2</a> Choice of TXT record</h4>
<p>
It has been suggested to use the KEY, OPT, CERT, or KX records
instead of a TXT record. None is satisfactory.
</p>
<p> The KEY RR has a protocol field which could be used to indicate a new protocol,
and an algorithm field which could be used to
indicate different contents in the key data. However, the KEY record
is clearly not intended for storing what are really authorizations,
it is just for identities. Other uses have been discouraged.
</p>
<p> OPT resource records, as defined in <a href="#RFC2671">[14]</a> are not
intended to be used for storage of information. They are not to be loaded,
cached or forwarded. They are, therefore, inappropriate for use here.
</p>
<p>
CERT records <a href="#RFC2538">[18]</a> can encode almost any set of
information. A custom type code could be used permitting any suitable
encoding to be stored, not just X.509. According to
the RFC, the certificate RRs are to be signed internally which may add undesirable
and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers.
</p>
<p>
At the time of protocol design, the CERT RR was not widely deployed and
could not be counted upon. Use of CERT records will be investigated,
and may be proposed in a future revision of this document.
</p>
<p>
KX records are ideally suited for use instead of TXT records, but had not been deployed at
the time of implementation.
</p>
<a name="rfc.section.5.3"></a><h4><a name="fqdn">5.3</a> Use of FQDN IDs</h4>
<p>
Unfortunately, not every administrator has control over the contents
of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, the
authorization record present in the reverse-map of Alice may refer to a
FQDN instead of an IP address.
</p>
<p>
In this case, the client's TXT record gives the fully qualified domain
name (FQDN) in place of its security gateway's IP address.
The initiator should use the ID_FQDN ID-payload in phase 1.
A forward lookup for a KEY record on the FQDN must yield the
initiator's public key.
</p>
<p>
This method can also be used when the external address of SG-A is
dynamic.
</p>
<p>
If SG-A is acting on behalf of Alice, then Alice must still delegate
authority for SG-A to do so in her reverse-map. When Alice and SG-A
are one and the same (i.e. Alice is acting as an end-node) then there
is no need for this when initiating only.
</p>
<p>However, Alice must still delegate to herself if she wishes others to
initiate OE to her. See <a href="#txtfqdnformat">Format of reverse delegation record (FQDN version)</a>.
</p>
<a name="rfc.section.5.4"></a><h4><a name="anchor41">5.4</a> Key roll-over</h4>
<p>
Good cryptographic hygiene says that one should replace public/private key pairs
periodically. Some administrators may wish to do this as often as daily. Typical DNS
propagation delays are determined by the SOA Resource Record MINIMUM
parameter, which controls how long DNS replies may be cached. For reasonable
operation of DNS servers, administrators usually want this value to be at least several
hours, sometimes as a long as a day. This presents a problem - a new key MUST
not be used prior to it propagating through DNS.
</p>
<p>
This problem is dealt with by having the Security Gateway generate a new
public/private key pair at least MINIMUM seconds in advance of using it. It
then adds this key to the DNS (both as a second KEY record and in additional TXT
delegation records) at key generation time. Note: only one key is allowed in
each TXT record.
</p>
<p>
When authenticating, all gateways MUST have available all public keys
that are found in DNS for this entity. This permits the authenticating end
to check both the key for "today" and the key for "tomorrow". Note that it is
the end which is creating the signature (possesses the private key) that
determines which key is to be used.
</p>
<a name="anchor42"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.6"></a><h3>6. Network address translation interaction</h3>
<p>
There are no fundamentally new issues for implementing opportunistic encryption
in the presence of network address translation. Rather there are
only the regular IPsec issues with NAT traversal.
</p>
<p>
There are several situations to consider for NAT.
</p>
<a name="rfc.section.6.1"></a><h4><a name="anchor43">6.1</a> Co-located NAT/NAPT</h4>
<p>
If SG-A is also performing network address translation on
behalf of Alice, then the packet should be translated prior to
being subjected to opportunistic encryption. This is in contrast to
typically configured tunnels which often exist to bridge islands of
private network address space. SG-A will use the translated source
address for phase 2, and so SG-B will look up that address to
confirm SG-A's authorization.
</p>
<p> In the case of NAT (1:1), the address space into which the
translation is done MUST be globally unique, and control over the
reverse-map is assumed.
Placing of TXT records is possible.
</p>
<p> In the case of NAPT (m:1), the address will be SG-A. The ability to get
KEY and TXT records in place will again depend upon whether or not
there is administrative control over the reverse-map. This is
identical to situations involving a single host acting on behalf of
itself.
FQDN style can be used to get around a lack of a reverse-map for
initiators only.
</p>
<a name="rfc.section.6.2"></a><h4><a name="anchor44">6.2</a> SG-A behind NAT/NAPT</h4>
<p>
If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
NAT traversal rules apply. In addition to the transport problem
which may be solved by other mechanisms, there
is the issue of what phase 1 and phase 2 IDs to use. While FQDN could
be used during phase 1 for SG-A, there is no appropriate ID for phase 2
that permits SG-B to determine that SG-A is in fact authorized to speak for Alice.
</p>
<a name="rfc.section.6.3"></a><h4><a name="anchor45">6.3</a> Bob is behind a NAT/NAPT</h4>
<p>
If Bob is behind a NAT (perhaps SG-B), then there is, in fact, no way for
Alice to address a packet to Bob. Not only is opportunistic encryption
impossible, but it is also impossible for Alice to initiate any
communication to Bob. It may be possible for Bob to initiate in such
a situation. This creates an asymmetry, but this is common for
NAPT.
</p>
<a name="anchor46"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.7"></a><h3>7. Host implementations</h3>
<p>
When Alice and SG-A are components of the same system, they are
considered to be a host implementation. The packet sequence scenario remains unchanged.
</p>
<p>
Components marked Alice are the upper layers (TCP, UDP, the
application), and SG-A is the IP layer.
</p>
<p>
Note that tunnel mode is still required.
</p>
<p>
As Alice and SG-A are acting on behalf of themselves, no TXT based delegation
record is necessary for Alice to initiate. She can rely on FQDN in a
forward map. This is particularly attractive to mobile nodes such as
notebook computers at conferences.
To respond, Alice/SG-A will still need an entry in Alice's reverse-map.
</p>
<a name="anchor47"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.8"></a><h3>8. Multi-homing</h3>
<p>
If there are multiple paths between Alice and Bob (as illustrated in
the diagram with SG-D), then additional DNS records are required to establish
authorization.
</p>
<p>
In <a href="#networkdiagram">Reference Network Diagram</a>, Alice has two ways to
exit her network: SG-A and SG-D. Previously SG-D has been ignored. Postulate
that there are routers between Alice and her set of security gateways
(denoted by the + signs and the marking of an autonomous system number for
Alice's network). Datagrams may, therefore, travel to either SG-A or SG-D en
route to Bob.
</p>
<p>
As long as all network connections are in good order, it does not matter how
datagrams exit Alice's network. When they reach either security gateway, the
security gateway will find the TXT delegation record in Bob's reverse-map,
and establish an SA with SG-B.
</p>
<p>
SG-B has no problem establishing that either of SG-A or SG-D may speak for
Alice, because Alice has published two equally weighted TXT delegation records:
<br><hr size="1" shade="0">
<a name="txtmultiexample"></a>
</p>
</font><pre>
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Multiple gateway delegation example for Alice </b></font><br></td></tr></table><hr size="1" shade="0">
</p>
<p>
Alice's routers can now do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through
their tunnel to SG-B.
</p>
<p>
Alice's use of non-equal weight delegation records to show preference of one gateway over another, has relevance only when SG-B
is initiating to Alice.
</p>
<p>
If the precedences are the same, then SG-B has a more difficult time. It
must decide which of the two tunnels to use. SG-B has no information about
which link is less loaded, nor which security gateway has more cryptographic
resources available. SG-B, in fact, has no knowledge of whether both gateways
are even reachable.
</p>
<p>
The Public Internet's default-free zone may well know a good route to Alice,
but the datagrams that SG-B creates must be addressed to either SG-A or SG-D;
they can not be addressed to Alice directly.
</p>
<p>
SG-B may make a number of choices:
<ol class="text">
<li>It can ignore the problem and round robin among the tunnels. This
causes losses during times when one or the other security gateway is
unreachable. If this worries Alice, she can change the weights in her
TXT delegation records.
</li>
<li>It can send to the gateway from which it most recently received datagrams.
This assumes that routing and reachability are symmetrical.
</li>
<li>It can listen to BGP information from the Internet to decide which
system is currently up. This is clearly much more complicated, but if SG-B is already participating
in the BGP peering system to announce Bob, the results data may already
be available to it.
</li>
<li>It can refuse to negotiate the second tunnel. (It is unclear whether or
not this is even an option.)
</li>
<li>It can silently replace the outgoing portion of the first tunnel with the
second one while still retaining the incoming portions of both. SG-B can,
thus, accept datagrams from either SG-A or SG-D, but
send only to the gateway that most recently re-keyed with it.
</li>
</ol><p>
</p>
<p>
Local policy determines which choice SG-B makes. Note that even if SG-B has perfect
knowledge about the reachability of SG-A and SG-D, Alice may not be reachable
from either of these security gateways because of internal reachability
issues.
</p>
<p>
FreeS/WAN implements option 5. Implementing a different option is
being considered. The multi-homing aspects of OE are not well developed and may
be the subject of a future document.
</p>
<a name="anchor48"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.9"></a><h3>9. Failure modes</h3>
<a name="rfc.section.9.1"></a><h4><a name="anchor49">9.1</a> DNS failures</h4>
<p>
If a DNS server fails to respond, local policy decides
whether or not to permit communication in the clear as embodied in
the connection classes in <a href="#initclasses">Keying state machine - initiator</a>.
It is easy to mount a denial of service attack on the DNS server
responsible for a particular network's reverse-map.
Such an attack may cause all communication with that network to go in
the clear if the policy is permissive, or fail completely
if the policy is paranoid. Please note that this is an active attack.
</p>
<p>
There are still many networks
that do not have properly configured reverse-maps. Further, if the policy is not to communicate,
the above denial of service attack isolates the target network. Therefore, the decision of whether
or not to permit communication in the clear MUST be a matter of local policy.
</p>
<a name="rfc.section.9.2"></a><h4><a name="anchor50">9.2</a> DNS configured, IKE failures</h4>
<p>
DNS records claim that opportunistic encryption should
occur, but the target gateway either does not respond on port 500, or
refuses the proposal. This may be because of a crash or reboot, a
faulty configuration, or a firewall filtering port 500.
</p>
<p>
The receipt of ICMP port, host or network unreachable
messages indicates a potential problem, but MUST NOT cause communication
to fail
immediately. ICMP messages are easily forged by attackers. If such a
forgery caused immediate failure, then an active attacker could easily
prevent any
encryption from ever occurring, possibly preventing all communication.
</p>
<p>
In these situations a clear log should be produced
and local policy should dictate if communication is then
permitted in the clear.
</p>
<a name="rfc.section.9.3"></a><h4><a name="anchor51">9.3</a> System reboots</h4>
<p>
Tunnels sometimes go down because the remote end crashes,
disconnects, or has a network link break. In general there is no
notification of this. Even in the event of a crash and successful reboot,
other SGs don't hear about it unless the rebooted SG has specific
reason to talk to them immediately. Over-quick response to temporary
network outages is undesirable. Note that a tunnel can be torn
down and then re-established without any effect visible to the user
except a pause in traffic. On the other hand, if one end reboots,
the other end can't get datagrams to it at all (except via
IKE) until the situation is noticed. So a bias toward quick
response is appropriate even at the cost of occasional
false alarms.
</p>
<p>
A mechanism for recovery after reboot is a topic of current research and is not specified in this
document.
</p>
<p>
A deliberate shutdown should include an attempt, using deletes, to notify all other SGs
currently connected by phase 1 SAs that communication is
about to fail. Again, a remote SG will assume this is a teardown. Attempts by the
remote SGs to negotiate new tunnels as replacements should be ignored. When possible,
SGs should attempt to preserve information about currently-connected SGs in non-volatile storage, so
that after a crash, an Initial-Contact can be sent to previous partners to
indicate loss of all previously established connections.
</p>
<a name="anchor52"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.10"></a><h3>10. Unresolved issues</h3>
<a name="rfc.section.10.1"></a><h4><a name="anchor53">10.1</a> Control of reverse DNS</h4>
<p>
The method of obtaining information by reverse DNS lookup causes
problems for people who cannot control their reverse DNS
bindings. This is an unresolved problem in this version, and is out
of scope.
</p>
<a name="anchor54"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.11"></a><h3>11. Examples</h3>
<a name="rfc.section.11.1"></a><h4><a name="anchor55">11.1</a> Clear-text usage (permit policy)</h4>
<p>
Two example scenarios follow. In the first example GW-A
(Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second example they have an OE
policy.
</p><br><hr size="1" shade="0">
<a name="regulartiming"></a>
</font><pre>
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->
----------(6)------>
------(7)----->
<------(8)------
<----------(9)------
<----(10)-----
(11)----------->
----------(12)----->
-------------->
<---------------
<-------------------
<-------------
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Timing of regular transaction </b></font><br></td></tr></table><hr size="1" shade="0">
<p>
Alice wants to communicate with Bob. Perhaps she wants to retrieve a
web page from Bob's web server. In the absence of opportunistic
encryptors, the following events occur:
<blockquote class="text"><dl>
<dt>(1)</dt>
<dd>Human or application 'clicks' with a name.
</dd>
<dt>(2)</dt>
<dd>Application looks up name in DNS to get IP address.
</dd>
<dt>(3)</dt>
<dd>Resolver returns A record to application.
</dd>
<dt>(4)</dt>
<dd>Application starts a TCP session or UDP session and OS sends datagram.
</dd>
<dt>(5)</dt>
<dd>Datagram is seen at first gateway from Alice (SG-A). (SG-A
makes a transition through Empty connection to always-clear connection and
instantiates a pass-through policy at the forwarding plane.)
</dd>
<dt>(6)</dt>
<dd>Datagram is seen at last gateway before Bob (SG-B).
</dd>
<dt>(7)</dt>
<dd>First datagram from Alice is seen by Bob.
</dd>
<dt>(8)</dt>
<dd>First return datagram is sent by Bob.
</dd>
<dt>(9)</dt>
<dd>Datagram is seen at Bob's gateway. (SG-B makes a transition through
Empty connection to always-clear connection and instantiates a pass-through
policy at the forwarding plane.)
</dd>
<dt>(10)</dt>
<dd>Datagram is seen at Alice's gateway.
</dd>
<dt>(11)</dt>
<dd>OS hands datagram to application. Alice sends another datagram.
</dd>
<dt>(12)</dt>
<dd>A second datagram traverses the Internet.
</dd>
</dl></blockquote><p>
</p>
<a name="rfc.section.11.2"></a><h4><a name="anchor56">11.2</a> Opportunistic encryption</h4>
<p>
In the presence of properly configured opportunistic encryptors, the
event list is extended.
<br><hr size="1" shade="0">
<a name="opportunistictiming"></a>
</p>
</font><pre>
Alice SG-A DNS SG-B Bob
(1)
------(2)-------------->
<-----(3)---------------
(4)----(5)----->+
----(5B)->
<---(5C)--
~~~~~~~~~~~~~(5D)~~~>
<~~~~~~~~~~~~(5E1)~~~
~~~~~~~~~~~~~(5E2)~~>
<~~~~~~~~~~~~(5E3)~~~
#############(5E4)##>
<############(5E5)###
<----(5F1)--
-----(5F2)->
#############(5G1)##>
<----(5H1)--
-----(5H2)->
<############(5G2)###
#############(5G3)##>
============(6)====>
------(7)----->
<------(8)------
<==========(9)======
<-----(10)----
(11)----------->
==========(12)=====>
-------------->
<---------------
<===================
<-------------
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Timing of opportunistic encryption transaction </b></font><br></td></tr></table><hr size="1" shade="0">
<blockquote class="text"><dl>
<dt>(1)</dt>
<dd>Human or application clicks with a name.
</dd>
<dt>(2)</dt>
<dd>Application initiates DNS mapping.
</dd>
<dt>(3)</dt>
<dd>Resolver returns A record to application.
</dd>
<dt>(4)</dt>
<dd>Application starts a TCP session or UDP.
</dd>
<dt>(5)</dt>
<dd>SG-A (host or SG) sees datagram to target, and buffers it.
</dd>
<dt>(5B)</dt>
<dd>SG-A asks DNS for TXT record.
</dd>
<dt>(5C)</dt>
<dd>DNS returns TXT record(s).
</dd>
<dt>(5D)</dt>
<dd>Initial IKE Main Mode Packet goes out.
</dd>
<dt>(5E)</dt>
<dd>IKE ISAKMP phase 1 succeeds.
</dd>
<dt>(5F)</dt>
<dd>SG-B asks DNS for TXT record to prove SG-A is an agent for Alice.
</dd>
<dt>(5G)</dt>
<dd>IKE phase 2 negotiation.
</dd>
<dt>(5H)</dt>
<dd>DNS lookup by responder (SG-B).
</dd>
<dt>(6)</dt>
<dd>Buffered datagram is sent by SG-A.
</dd>
<dt>(7)</dt>
<dd>Datagram is received by SG-B, decrypted, and sent to Bob.
</dd>
<dt>(8)</dt>
<dd>Bob replies, and datagram is seen by SG-B.
</dd>
<dt>(9)</dt>
<dd>SG-B already has tunnel up with SG-A, and uses it.
</dd>
<dt>(10)</dt>
<dd>SG-A decrypts datagram and gives it to Alice.
</dd>
<dt>(11)</dt>
<dd>Alice receives datagram. Sends new packet to Bob.
</dd>
<dt>(12)</dt>
<dd>SG-A gets second datagram, sees that tunnel is up, and uses it.
</dd>
</dl></blockquote><p>
</p>
<p>
For the purposes of this section, we will describe only the changes that
occur between <a href="#regulartiming">Timing of regular transaction</a> and
<a href="#opportunistictiming">Timing of opportunistic encryption transaction</a>. This corresponds to time points 5, 6, 7, 9 and 10 on the list above.
</p>
<a name="rfc.section.11.2.1"></a><h4><a name="anchor57">11.2.1</a> (5) IPsec datagram interception</h4>
<p>
At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy
(the non-existent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon.
</p>
<a name="rfc.section.11.2.2"></a><h4><a name="anchor58">11.2.2</a> (5B) DNS lookup for TXT record</h4>
<p>
SG-A's IKE daemon, having looked up the source/destination pair in the connection
class list, creates a new Potential OE connection instance. SG-A starts DNS
queries.
</p>
<a name="rfc.section.11.2.3"></a><h4><a name="anchor59">11.2.3</a> (5C) DNS returns TXT record(s)</h4>
<p>
DNS returns properly formed TXT delegation records, and SG-A's IKE daemon
causes this instance to make a transition from Potential OE connection to Pending OE
connection.
</p>
<p>
Using the example above, the returned record might contain:
<br><hr size="1" shade="0">
<a name="txtexample"></a>
</p>
</font><pre>
X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
<p>
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Example of reverse delegation record for Bob </b></font><br></td></tr></table><hr size="1" shade="0">
with SG-B's IP address and public key listed.
</p>
<a name="rfc.section.11.2.4"></a><h4><a name="anchor60">11.2.4</a> (5D) Initial IKE main mode packet goes out</h4>
<p>Upon entering Pending OE connection, SG-A sends the initial ISAKMP
message with proposals. See <a href="#phase1id">Phase 1 parameters</a>.
</p>
<a name="rfc.section.11.2.5"></a><h4><a name="anchor61">11.2.5</a> (5E1) Message 2 of phase 1 exchange</h4>
<p>
SG-B receives the message. A new connection instance is created in the
unauthenticated OE peer state.
</p>
<a name="rfc.section.11.2.6"></a><h4><a name="anchor62">11.2.6</a> (5E2) Message 3 of phase 1 exchange</h4>
<p>
SG-A sends a Diffie-Hellman exponent. This is an internal state of the
keying daemon.
</p>
<a name="rfc.section.11.2.7"></a><h4><a name="anchor63">11.2.7</a> (5E3) Message 4 of phase 1 exchange</h4>
<p>
SG-B responds with a Diffie-Hellman exponent. This is an internal state of the
keying protocol.
</p>
<a name="rfc.section.11.2.8"></a><h4><a name="anchor64">11.2.8</a> (5E4) Message 5 of phase 1 exchange</h4>
<p>
SG-A uses the phase 1 SA to send its identity under encryption.
The choice of identity is discussed in <a href="#phase1id">Phase 1 parameters</a>.
This is an internal state of the keying protocol.
</p>
<a name="rfc.section.11.2.9"></a><h4><a name="anchor65">11.2.9</a> (5F1) Responder lookup of initiator key</h4>
<p>
SG-B asks DNS for the public key of the initiator.
DNS looks for a KEY record by IP address in the reverse-map.
That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa
(recall that SG-A's external address is 192.1.1.4).
SG-B uses the resulting public key to authenticate the initiator. See <a href="#KEY">Use of KEY record</a> for further details.
</p>
<a name="rfc.section.11.2.10"></a><h4><a name="anchor66">11.2.10</a> (5F2) DNS replies with public key of initiator</h4>
<p>
Upon successfully authenticating the peer, the connection instance makes a
transition to authenticated OE peer on SG-B.
</p>
<p>
The format of the TXT record returned is described in
<a href="#TXT">Use of TXT delegation record</a>.
</p>
<a name="rfc.section.11.2.11"></a><h4><a name="anchor67">11.2.11</a> (5E5) Responder replies with ID and authentication</h4>
<p>
SG-B sends its ID along with authentication material. This is an internal
state for the keying protocol.
</p>
<a name="rfc.section.11.2.12"></a><h4><a name="anchor68">11.2.12</a> (5G) IKE phase 2</h4>
<a name="rfc.section.11.2.12.1"></a><h4><a name="anchor69">11.2.12.1</a> (5G1) Initiator proposes tunnel</h4>
<p>
Having established mutually agreeable authentications (via KEY) and
authorizations (via TXT), SG-A proposes to create an IPsec tunnel for
datagrams transiting from Alice to Bob. This tunnel is established only for
the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B.
</p>
<a name="rfc.section.11.2.12.2"></a><h4><a name="anchor70">11.2.12.2</a> (5H1) Responder determines initiator's authority</h4>
<p>
While the identity of SG-A has been established, its authority to
speak for Alice has not yet been confirmed. SG-B does a reverse
lookup on Alice's address for a TXT record.
</p>
<p>Upon receiving this specific proposal, SG-B's connection instance
makes a transition into the potential OE connection state. SG-B may already have an
instance, and the check is made as described above.
</p>
<a name="rfc.section.11.2.12.3"></a><h4><a name="anchor71">11.2.12.3</a> (5H2) DNS replies with TXT record(s)</h4>
<p>
The returned key and IP address should match that of SG-A.
</p>
<a name="rfc.section.11.2.12.4"></a><h4><a name="anchor72">11.2.12.4</a> (5G2) Responder agrees to proposal</h4>
<p>
Should additional communication occur between, for instance, Dave and Bob using
SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA
may be reusable.
</p>
<p>SG-A, having successfully keyed the tunnel, now makes a transition from
Pending OE connection to Keyed OE connection.
</p>
<p>The responder MUST setup the inbound IPsec SAs before sending its reply.
</p>
<a name="rfc.section.11.2.12.5"></a><h4><a name="anchor73">11.2.12.5</a> (5G3) Final acknowledgment from initiator</h4>
<p>
The initiator agrees with the responder's choice and sets up the tunnel.
The initiator sets up the inbound and outbound IPsec SAs.
</p>
<p>
The proper authorization returned with keys prompts SG-B to make a transition
to the keyed OE connection state.
</p>
<p>Upon receipt of this message, the responder may now setup the outbound
IPsec SAs.
</p>
<a name="rfc.section.11.2.13"></a><h4><a name="anchor74">11.2.13</a> (6) IPsec succeeds, and sets up tunnel for communication between Alice and Bob</h4>
<p>
SG-A sends the datagram saved at step (5) through the newly created
tunnel to SG-B, where it gets decrypted and forwarded.
Bob receives it at (7) and replies at (8).
</p>
<a name="rfc.section.11.2.14"></a><h4><a name="anchor75">11.2.14</a> (9) SG-B already has tunnel up with G1 and uses it</h4>
<p>
At (9), SG-B has already established an SPD entry mapping Bob->Alice via a
tunnel, so this tunnel is simply applied. The datagram is encrypted to SG-A,
decrypted by SG-A and passed to Alice at (10).
</p>
<a name="securityconsiderations"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.12"></a><h3>12. Security considerations</h3>
<a name="rfc.section.12.1"></a><h4><a name="anchor76">12.1</a> Configured vs opportunistic tunnels</h4>
<p>
Configured tunnels are those which are setup using bilateral mechanisms: exchanging
public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that
are in known places (distinguished name from LDAP, DNS). These keys are then used to
configure a specific tunnel.
</p>
<p>
A pre-configured tunnel may be on all the time, or may be keyed only when needed.
The end points of the tunnel are not necessarily static: many mobile
applications (road warrior) are considered to be configured tunnels.
</p>
<p>
The primary characteristic is that configured tunnels are assigned specific
security properties. They may be trusted in different ways relating to exceptions to
firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions.
</p>
<p>
Opportunistic tunnels are not inherently trusted in any strong way. They are
created without prior arrangement. As the two parties are strangers, there
MUST be no confusion of datagrams that arrive from opportunistic peers and
those that arrive from configured tunnels. A security gateway MUST take care
that an opportunistic peer can not impersonate a configured peer.
</p>
<p>
Ingress filtering MUST be used to make sure that only datagrams authorized by
negotiation (and the concomitant authentication and authorization) are
accepted from a tunnel. This is to prevent one peer from impersonating another.
</p>
<p>
An implementation suggestion is to treat opportunistic tunnel
datagrams as if they arrive on a logical interface distinct from other
configured tunnels. As the number of opportunistic tunnels that may be
created automatically on a system is potentially very high, careful attention
to scaling should be taken into account.
</p>
<p>
As with any IKE negotiation, opportunistic encryption cannot be secure
without authentication. Opportunistic encryption relies on DNS for its
authentication information and, therefore, cannot be fully secure without
a secure DNS. Without secure DNS, opportunistic encryption can protect against passive
eavesdropping but not against active man-in-the-middle attacks.
</p>
<a name="rfc.section.12.2"></a><h4><a name="anchor77">12.2</a> Firewalls versus Opportunistic Tunnels</h4>
<p>
Typical usage of per datagram access control lists is to implement various
kinds of security gateways. These are typically called "firewalls".
</p>
<p>
Typical usage of a virtual private network (VPN) within a firewall is to
bypass all or part of the access controls between two networks. Additional
trust (as outlined in the previous section) is given to datagrams that arrive
in the VPN.
</p>
<p>
Datagrams that arrive via opportunistically configured tunnels MUST not be
trusted. Any security policy that would apply to a datagram arriving in the
clear SHOULD also be applied to datagrams arriving opportunistically.
</p>
<a name="rfc.section.12.3"></a><h4><a name="anchor78">12.3</a> Denial of service</h4>
<p>
There are several different forms of denial of service that an implementor
should concern themselves with. Most of these problems are shared with
security gateways that have large numbers of mobile peers (road warriors).
</p>
<p>
The design of ISAKMP/IKE, and its use of cookies, defend against many kinds
of denial of service. Opportunism changes the assumption that if the phase 1 (ISAKMP)
SA is authenticated, that it was worthwhile creating. Because the gateway will communicate with any machine, it is
possible to form phase 1 SAs with any machine on the Internet.
</p>
<a name="anchor79"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.13"></a><h3>13. IANA Considerations</h3>
<p>
There are no known numbers which IANA will need to manage.
</p>
<a name="anchor80"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<a name="rfc.section.14"></a><h3>14. Acknowledgments</h3>
<p>
Substantive portions of this document are based upon previous work by
Henry Spencer.
</p>
<p>
Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz,
Jakob Schlyter, Bill Sommerfeld, John Gilmore and John Denker for their
comments and constructive criticism.
</p>
<p>
Sandra Hoffman and Bill Dickie did the detailed proof reading and editing.
</p>
<a name="rfc.references1"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Normative references</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><b><a name="OEspec">[1]</a></b></td>
<td class="author-text"><a href="mailto:hugh@mimosa.com">Redelmeier, D.</a> and <a href="mailto:henry@spsystems.net">H. Spencer</a>, "Opportunistic Encryption", paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec, May 2001.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC0791">[2]</a></b></td>
<td class="author-text">Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office and University of Southern California (USC)/Information Sciences Institute, "<a href="ftp://ftp.isi.edu/in-notes/rfc791.txt">Internet Protocol</a>", STD 5, RFC 791, September 1981.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC1009">[3]</a></b></td>
<td class="author-text"><a href="mailto:">Braden, R.</a> and <a href="mailto:">J. Postel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1009.txt">Requirements for Internet gateways</a>", RFC 1009, June 1987.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC1984">[4]</a></b></td>
<td class="author-text">IAB, IESG, <a href="mailto:brian@dxcoms.cern.ch">Carpenter, B.</a> and <a href="mailto:fred@cisco.com">F. Baker</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">IAB and IESG Statement on Cryptographic Technology and the Internet</a>", RFC 1984, August 1996.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2119">[5]</a></b></td>
<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2367">[6]</a></b></td>
<td class="author-text"><a href="mailto:danmcd@eng.sun.com">McDonald, D.</a>, <a href="mailto:cmetz@inner.net">Metz, C.</a> and <a href="mailto:phan@itd.nrl.navy.mil">B. Phan</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2367.txt">PF_KEY Key Management API, Version 2</a>", RFC 2367, July 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2401">[7]</a></b></td>
<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>", RFC 2401, November 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2407">[8]</a></b></td>
<td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2408">[9]</a></b></td>
<td class="author-text"><a href="mailto:wdm@tycho.ncsc.mil">Maughan, D.</a>, <a href="mailto:mss@tycho.ncsc.mil">Schneider, M.</a> and <a href="er@raba.com">M. Schertler</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2408.txt">Internet Security Association and Key Management Protocol (ISAKMP)</a>", RFC 2408, November 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2409">[10]</a></b></td>
<td class="author-text"><a href="mailto:dharkins@cisco.com">Harkins, D.</a> and <a href="mailto:carrel@ipsec.org">D. Carrel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2409.txt">The Internet Key Exchange (IKE)</a>", RFC 2409, November 1998.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC3526">[11]</a></b></td>
<td class="author-text"><a href="mailto:kivinen@ssh.fi">Kivinen, T.</a> and <a href="mailto:mrskojo@cc.helsinki.fi">M. Kojo</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc3526.txt">More MODP Diffie-Hellman groups for IKE</a>", RFC 3526, March 2003.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC1034">[12]</a></b></td>
<td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC1035">[13]</a></b></td>
<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2671">[14]</a></b></td>
<td class="author-text"><a href="mailto:vixie@isc.org">Vixie, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2671.txt">Extension Mechanisms for DNS (EDNS0)</a>", RFC 2671, August 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC1464">[15]</a></b></td>
<td class="author-text"><a href="mailto:rosenbaum@lkg.dec.com">Rosenbaum, R.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1464.txt">Using the Domain Name System To Store Arbitrary String Attributes</a>", RFC 1464, May 1993.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2535">[16]</a></b></td>
<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC3110">[17]</a></b></td>
<td class="author-text">Eastlake, D., "<a href="ftp://ftp.isi.edu/in-notes/rfc3110.txt">RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</a>", RFC 3110, May 2001.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2538">[18]</a></b></td>
<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a> and <a href="mailto:ogud@tislabs.com">O. Gudmundsson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2538.txt">Storing Certificates in the Domain Name System (DNS)</a>", RFC 2538, March 1999.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2748">[19]</a></b></td>
<td class="author-text"><a href="mailto:David.Durham@intel.com">Durham, D.</a>, <a href="mailto:jboyle@Level3.net">Boyle, J.</a>, <a href="mailto:ronc@cisco.com">Cohen, R.</a>, <a href="mailto:herzog@iphighway.com">Herzog, S.</a>, <a href="mailto:rajan@research.att.com">Rajan, R.</a> and <a href="mailto:asastry@cisco.com">A. Sastry</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2748.txt">The COPS (Common Open Policy Service) Protocol</a>", RFC 2748, January 2000.</td></tr>
<tr><td class="author-text" valign="top"><b><a name="RFC2663">[20]</a></b></td>
<td class="author-text"><a href="mailto:srisuresh@lucent.com">Srisuresh, P.</a> and <a href="mailto:holdrege@lucent.com">M. Holdrege</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2663.txt">IP Network Address Translator (NAT) Terminology and Considerations</a>", RFC 2663, August 1999.</td></tr>
</table>
<a name="rfc.authors"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Michael C. Richardson</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Sandelman Software Works</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">470 Dawson Avenue</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Ottawa, ON K1Z 5V7</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">CA</td></tr>
<tr><td class="author" align="right">EMail: </td>
<td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr>
<tr cellpadding="3"><td> </td><td> </td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">D. Hugh Redelmeier</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Mimosa</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Toronto, ON</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">CA</td></tr>
<tr><td class="author" align="right">EMail: </td>
<td class="author-text"><a href="mailto:hugh@mimosa.com">hugh@mimosa.com</a></td></tr>
</table>
<a name="rfc.copyright"><br><hr size="1" shade="0"></a>
<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
<h3>Full Copyright Statement</h3>
<p class='copyright'>
Copyright (C) The Internet Society (2003). All Rights Reserved.</p>
<p class='copyright'>
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.</p>
<p class='copyright'>
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.</p>
<p class='copyright'>
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.</p>
<h3>Acknowledgement</h3>
<p class='copyright'>
Funding for the RFC Editor function is currently provided by the
Internet Society.</p>
</font></body></html>
|
