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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html">
<title>IPsec protocols</title>
<meta name="keywords"
content="Linux, IPsec, VPN, security, FreeSWAN, protocol, ESP, AH, IKE">
<!--
Written by Sandy Harris for the Linux FreeS/WAN project
Freely distributable under the GNU General Public License
More information at www.freeswan.org
Feedback to users@lists.freeswan.org
CVS information:
RCS ID: $Id: ipsec.html,v 1.1 2004/03/15 20:35:24 as Exp $
Last changed: $Date: 2004/03/15 20:35:24 $
Revision number: $Revision: 1.1 $
CVS revision numbers do not correspond to FreeS/WAN release numbers.
-->
</head>
<body>
<h1><a name="ipsec.detail">The IPsec protocols</a></h1>
<p>This section provides information on the IPsec protocols which FreeS/WAN
implements. For more detail, see the <a href="rfc.html">RFCs</a>.</p>
<p>The basic idea of IPsec is to provide security functions, <a
href="glossary.html#authentication">authentication</a> and <a
href="glossary.html#encryption">encryption</a>, at the IP (Internet Protocol)
level. This requires a higher-level protocol (IKE) to set things up for the
IP-level services (ESP and AH).</p>
<h2>Protocols and phases</h2>
<p>Three protocols are used in an IPsec implementation:</p>
<dl>
<dt>ESP, Encapsulating Security Payload</dt>
<dd>Encrypts and/or authenticates data</dd>
<dt>AH, Authentication Header</dt>
<dd>Provides a packet authentication service</dd>
<dt>IKE, Internet Key Exchange</dt>
<dd>Negotiates connection parameters, including keys, for the other
two</dd>
</dl>
<p>The term "IPsec" (also written as IPSEC) is slightly ambiguous. In some
contexts, it includes all three of the above but in other contexts it refers
only to AH and ESP.</p>
<p>There is more detail below, but a quick summary of how the whole thing
works is:</p>
<dl>
<dt>Phase one IKE (main mode exchange)</dt>
<dd>sets up a keying channel (ISAKMP SA) between the two gateways</dd>
<dt>Phase two IKE (quick mode exchange)</dt>
<dd>sets up data channels (IPsec SAs)</dd>
<dt>IPsec proper</dt>
<dd>exchanges data using AH or ESP</dd>
</dl>
<p>Both phases of IKE are repeated periodically to automate re-keying.</p>
<h2><a name="others">Applying IPsec</a></h2>
<p>Authentication and encryption functions for network data can, of course,
be provided at other levels. Many security protocols work at levels above
IP.</p>
<ul>
<li><a href="glossary.html#PGP">PGP</a> encrypts and authenticates mail
messages</li>
<li><a href="glossary.html#SSH">SSH</a> authenticates remote logins and
then encrypts the session</li>
<li><a href="glossary.html#SSL">SSL</a> or <a
href="glossary.html#TLS">TLS</a> provides security at the sockets layer,
e.g. for secure web browsing</li>
</ul>
<p>and so on. Other techniques work at levels below IP. For example, data on
a communications circuit or an entire network can be encrypted by specialised
hardware. This is common practice in high-security applications.</p>
<h3><a name="advantages">Advantages of IPsec</a></h3>
<p>There are, however, advantages to doing it at the IP level instead of, or
as well as, at other levels.</p>
<p>IPsec is the <strong>most general way to provide these services for the
Internet</strong>.</p>
<ul>
<li>Higher-level services protect a <em>single protocol</em>; for example
PGP protects mail.</li>
<li>Lower level services protect a <em>single medium</em>; for example a
pair of encryption boxes on the ends of a line make wiretaps on that line
useless unless the attacker is capable of breaking the encryption.</li>
</ul>
<p>IPsec, however, can protect <em>any protocol</em> running above IP and
<em>any medium</em> which IP runs over. More to the point, it can protect a
mixture of application protocols running over a complex combination of media.
This is the normal situation for Internet communication; IPsec is the only
general solution.</p>
<p>IPsec can also provide some security services "in the background", with
<strong>no visible impact on users</strong>. To use <a
href="glossary.html#PGP">PGP</a> encryption and signatures on mail, for
example, the user must at least:</p>
<ul>
<li>remember his or her passphrase,</li>
<li>keep it secure</li>
<li>follow procedures to validate correspondents' keys</li>
</ul>
<p>These systems can be designed so that the burden on users is not onerous,
but any system will place some requirements on users. No such system can hope
to be secure if users are sloppy about meeting those requirements. The author
has seen username and password stuck on terminals with post-it notes in an
allegedly secure environment, for example.</p>
<h3><a name="limitations">Limitations of IPsec</a></h3>
<p>IPsec is designed to secure IP links between machines. It does that well,
but it is important to remember that there are many things it does not do.
Some of the important limitations are:</p>
<dl>
<dt><a name="depends">IPsec cannot be secure if your system isn't</a></dt>
<dd>System security on IPsec gateway machines is an essential requirement
if IPsec is to function as designed. No system can be trusted if the
underlying machine has been subverted. See books on Unix security such
as <a href="biblio.html#practical">Garfinkel and Spafford</a> or our
web references for <a href="web.html#linsec">Linux security</a> or more
general <a href="web.html#compsec">computer security</a>.
<p>Of course, there is another side to this. IPsec can be a powerful
tool for improving system and network security. For example, requiring
packet authentication makes various spoofing attacks harder and IPsec
tunnels can be extremely useful for secure remote administration of
various things.</p>
</dd>
<dt><a name="not-end-to-end">IPsec is not end-to-end</a></dt>
<dd>IPsec cannot provide the same end-to-end security as systems working
at higher levels. IPsec encrypts an IP connection between two machines,
which is quite a different thing than encrypting messages between users
or between applications.
<p>For example, if you need mail encrypted from the sender's desktop to
the recipient's desktop and decryptable only by the recipient, use <a
href="glossary.html#PGP">PGP</a> or another such system. IPsec can
encrypt any or all of the links involved -- between the two mail
servers, or between either server and its clients. It could even be
used to secure a direct IP link from the sender's desktop machine to
the recipient's, cutting out any sort of network snoop. What it cannot
ensure is end-to-end user-to-user security. If only IPsec is used to
secure mail, then anyone with appropriate privileges on any machine
where that mail is stored (at either end or on any store-and-forward
servers in the path) can read it.</p>
<p>In another common setup, IPsec encrypts packets at a security
gateway machine as they leave the sender's site and decrypts them on
arrival at the gateway to the recipient's site. This does provide a
useful security service -- only encrypted data is passed over the
Internet -- but it does not even come close to providing an end-to-end
service. In particular, anyone with appropriate privileges on either
site's LAN can intercept the message in unencrypted form.</p>
</dd>
<dt><a name="notpanacea">IPsec cannot do everything</a></dt>
<dd>IPsec also cannot provide all the functions of systems working at
higher levels of the protocol stack. If you need a document
electronically signed by a particular person, then you need his or her
<a href="glossary.html#signature">digital signature</a> and a <a
href="glossary.html#public">public key cryptosystem</a> to verify it
with.
<p>Note, however, that IPsec authentication of the underlying
communication can make various attacks on higher-level protocols more
difficult. In particular, authentication prevents <a
href="glossary.html#middle">man-in-the-middle attacks</a>.</p>
</dd>
<dt><a name="no_user">IPsec authenticates machines, not users</a></dt>
<dd>IPsec uses strong authentication mechanisms to control which messages
go to which machines, but it does not have the concept of user ID,
which is vital to many other security mechansims and policies. This
means some care must be taken in fitting the various security
mechansims on a network together. For example, if you need to control
which users access your database server, you need some non-IPsec
mechansim for that. IPsec can control which machines connect to the
server, and can ensure that data transfer to those machines is done
securely, but that is all. Either the machines themselves must control
user access or there must be some form of user authentication to the
database, independent of IPsec.</dd>
<dt><a name="DoS">IPsec does not stop denial of service attacks</a></dt>
<dd><a href="glossary.html#DOS">Denial of service</a> attacks aim at
causing a system to crash, overload, or become confused so that
legitimate users cannot get whatever services the system is supposed to
provide. These are quite different from attacks in which the attacker
seeks either to use the service himself or to subvert the service into
delivering incorrect results.
<p>IPsec shifts the ground for DoS attacks; the attacks possible
against systems using IPsec are different than those that might be used
against other systems. It does not, however, eliminate the possibility
of such attacks.</p>
</dd>
<dt><a name="traffic">IPsec does not stop traffic analysis</a></dt>
<dd><a href="glossary.html#traffic">Traffic analysis</a> is the attempt
to derive intelligence from messages without regard for their contents.
In the case of IPsec, it would mean analysis based on things visible in
the unencrypted headers of encrypted packets -- source and destination
gateway addresses, packet size, et cetera. Given the resources to
acquire such data and some skill in analysing it (both of which any
national intelligence agency should have), this can be a very powerful
technique.
<p>IPsec is not designed to defend against this. Partial defenses are
certainly possible, and some are <a href="#traffic.resist">described
below</a>, but it is not clear that any complete defense can be
provided.</p>
</dd>
</dl>
<h3><a name="uses">IPsec is a general mechanism for securing IP</a></h3>
<p>While IPsec does not provide all functions of a mail encryption package,
it can encrypt your mail. In particular, it can ensure that all mail passing
between a pair or a group of sites is encrypted. An attacker looking only at
external traffic, without access to anything on or behind the IPsec gateway,
cannot read your mail. He or she is stymied by IPsec just as he or she would
be by <a href="glossary.html#PGP">PGP</a>.</p>
<p>The advantage is that IPsec can provide the same protection for <strong>
anything transmitted over IP</strong>. In a corporate network example, PGP
lets the branch offices exchange secure mail with head office. SSL and SSH
allow them to securely view web pages, connect as terminals to machines, and
so on. IPsec can support all those applications, plus database queries, file
sharing (NFS or Windows), other protocols encapsulated in IP (Netware,
Appletalk, ...), phone-over-IP, video-over-IP, ... anything-over-IP. The only
limitation is that IP Multicast is not yet supported, though there are
Internet Draft documents for that.</p>
<p>IPsec creates <strong>secure tunnels through untrusted networks</strong>.
Sites connected by these tunnels form VPNs, <a
href="glossary.html#VPN">Virtual Private Networks</a>.</p>
<p>IPsec gateways can be installed wherever they are required.</p>
<ul>
<li>One organisation might choose to install IPsec only on firewalls
between their LANs and the Internet. This would allow them to create a
VPN linking several offices. It would provide protection against anyone
outside their sites.</li>
<li>Another might install IPsec on departmental servers so everything on
the corporate backbone net was encrypted. This would protect messages on
that net from everyone except the sending and receiving department.</li>
<li>Another might be less concerned with information secrecy and more with
controlling access to certain resources. They might use IPsec packet
authentication as part of an access control mechanism, with or without
also using the IPsec encryption service.</li>
<li>It is even possible (assuming adequate processing power and an IPsec
implementation in each node) to make every machine its own IPsec gateway
so that everything on a LAN is encrypted. This protects information from
everyone outside the sending and receiving machine.</li>
<li>These techniques can be combined in various ways. One might, for
example, require authentication everywhere on a network while using
encryption only for a few links.</li>
</ul>
<p>Which of these, or of the many other possible variants, to use is up to
you. <strong>IPsec provides mechanisms; you provide the policy</strong>.</p>
<p><strong>No end user action is required</strong> for IPsec security to be
used; they don't even have to know about it. The site administrators, of
course, do have to know about it and to put some effort into making it work.
Poor administration can compromise IPsec as badly as the post-it notes
mentioned above. It seems reasonable, though, for organisations to hope their
system administrators are generally both more security-conscious than end
users and more able to follow computer security procedures. If not, at least
there are fewer of them to educate or replace.</p>
<p>IPsec can be, and often should be, used with along with security protocols
at other levels. If two sites communicate with each other via the Internet,
then IPsec is the obvious way to protect that communication. If two others
have a direct link between them, either link encryption or IPsec would make
sense. Choose one or use both. Whatever you use at and below the IP level,
use other things as required above that level. Whatever you use above the IP
level, consider what can be done with IPsec to make attacks on the higher
levels harder. For example, <a href="glossary.html#middle">man-in-the-middle
attacks</a> on various protocols become difficult if authentication at packet
level is in use on the potential victims' communication channel.</p>
<h3><a name="authonly">Using authentication without encryption</a></h3>
<p>Where appropriate, IPsec can provide authentication without encryption.
One might do this, for example:</p>
<ul>
<li>where the data is public but one wants to be sure of getting the right
data, for example on some web sites</li>
<li>where encryption is judged unnecessary, for example on some company or
department LANs</li>
<li>where strong encryption is provided at link level, below IP</li>
<li>where strong encryption is provided in other protocols, above IP<br>
Note that IPsec authentication may make some attacks on those protocols
harder.</li>
</ul>
<p>Authentication has lower overheads than encryption.</p>
<p>The protocols provide four ways to build such connections, using either an
AH-only connection or ESP using null encryption, and in either manually or
automatically keyed mode. FreeS/WAN supports only one of these, manually
keyed AH-only connections, and <strong>we do not recommend using
that</strong>. Our reasons are discussed under <a
href="#traffic.resist">Resisting traffic analysis</a> a few sections further
along.</p>
<h3><a name="encnoauth">Encryption without authentication is
dangerous</a></h3>
<p>Originally, the IPsec encryption protocol <a
href="glossary.html#ESP">ESP</a> didn't do integrity checking. It only did
encryption. Steve Bellovin found many ways to attack ESP used without
authentication. See his paper <a
href="http://www.research.att.com/~smb/papers/badesp.ps">Problem areas for
the IP Security Protocols</a>. To make a secure connection, you had to add an
<a href="glossary.html#AH">AH</a> Authentication Header as well as ESP.
Rather than incur the overhead of several layers (and rather than provide an
ESP layer that didn't actually protect the traffic), the IPsec working group
built integrity and replay checking directly into ESP.</p>
<p>Today, typical usage is one of:</p>
<ul>
<li>ESP for encryption and authentication</li>
<li>AH for authentication alone</li>
</ul>
<p>Other variants are allowed by the standard, but not much used:</p>
<dl>
<dt>ESP encryption without authentication</dt>
<dd><strong>Bellovin has demonstrated fatal flaws in this. Do not
use.</strong></dd>
<dt>ESP encryption with AH authentication</dt>
<dd>This has higher overheads than using the authentication in ESP, and
no obvious benefit in most cases. The exception might be a network
where AH authentication was widely or universally used. If you're going
to do AH to conform with network policy, why authenticate again in the
ESP layer?</dd>
<dt>Authenticate twice, with AH and with ESP</dt>
<dd>Why? Of course, some folk consider "belt and suspenders" the sensible
approach to security. If you're among them, you might use both
protocols here. You might also use both to satisfy different parts of a
security policy. For example, an organisation might require AH
authentication everywhere but two users within the organisation might
use ESP as well.</dd>
<dt>ESP authentication without encryption</dt>
<dd>The standard allows this, calling it "null encryption". FreeS/WAN
does not support it. We recommend that you use AH instead if
authentication is all you require. AH authenticates parts of the IP
header, which ESP-null does not do.</dd>
</dl>
<p>Some of these variants cannot be used with FreeS/WAN because we do not
support ESP-null and do not support automatic keying of AH-only
connections.</p>
<p>There are fairly frequent suggestions that AH be dropped entirely from the
IPsec specifications since ESP and null encryption can handle that situation.
It is not clear whether this will occur. My guess is that it is unlikely.</p>
<h3><a name="multilayer">Multiple layers of IPsec processing are
possible</a></h3>
<p>The above describes combinations possible on a single IPsec connection. In
a complex network you may have several layers of IPsec in play, with any of
the above combinations at each layer.</p>
<p>For example, a connection from a desktop machine to a database server
might require AH authentication. Working with other host, network and
database security measures, AH might be just the thing for access control.
You might decide not to use ESP encryption on such packets, since it uses
resources and might complicate network debugging. Within the site where the
server is, then, only AH would be used on those packets.</p>
<p>Users at another office, however, might have their whole connection (AH
headers and all) passing over an IPsec tunnel connecting their office to the
one with the database server. Such a tunnel should use ESP encryption and
authentication. You need authentication in this layer because without
authentication the encryption is vulnerable and the gateway cannot verify the
AH authentication. The AH is between client and database server; the gateways
aren't party to it.</p>
<p>In this situation, some packets would get multiple layers of IPsec applied
to them, AH on an end-to-end client-to-server basis and ESP from one office's
security gateway to the other.</p>
<h3><a name="traffic.resist">Resisting traffic analysis</a></h3>
<p><a href="glossary.html#traffic">Traffic analysis</a> is the attempt to
derive useful intelligence from encrypted traffic without breaking the
encryption.</p>
<p>Is your CEO exchanging email with a venture capital firm? With bankruptcy
trustees? With an executive recruiting agency? With the holder of some
important patents? If an eavesdropper learns about any of those, then he has
interesting intelligence on your company, whether or not he can read the
messages themselves.</p>
<p>Even just knowing that there is network traffic between two sites may tell
an analyst something useful, especially when combined with whatever other
information he or she may have. For example, if you know Company A is having
cashflow problems and Company B is looking for aquisitions, then knowing that
packets are passing between the two is interesting. It is more interesting if
you can tell it is email, and perhaps yet more if you know the sender and
recipient.</p>
<p>Except in the simplest cases, traffic analysis is hard to do well. It
requires both considerable resources and considerable analytic skill.
However, intelligence agencies of various nations have been doing it for
centuries and many of them are likely quite good at it by now. Various
commercial organisations, especially those working on "targeted marketing"
may also be quite good at analysing certain types of traffic.</p>
<p>In general, defending against traffic analysis is also difficult.
Inventing a really good defense could get you a PhD and some interesting job
offers.</p>
<p>IPsec is not designed to stop traffic analysis and we know of no plausible
method of extending it to do so. That said, there are ways to make traffic
analysis harder. This section describes them.</p>
<h4><a name="extra">Using "unnecessary" encryption</a></h4>
<p>One might choose to use encryption even where it appears unnecessary in
order to make analysis more difficult. Consider two offices which pass a
small volume of business data between them using IPsec and also transfer
large volumes of Usenet news. At first glance, it would seem silly to encrypt
the newsfeed, except possibly for any newsgroups that are internal to the
company. Why encrypt data that is all publicly available from many sites?</p>
<p>However, if we encrypt a lot of news and send it down the same connection
as our business data, we make <a href="glossary.html#traffic">traffic
analysis</a> much harder. A snoop cannot now make inferences based on
patterns in the volume, direction, sizes, sender, destination, or timing of
our business messages. Those messages are hidden in a mass of news messages
encapsulated in the same way.</p>
<p>If we're going to do this we need to ensure that keys change often enough
to remain secure even with high volumes and with the adversary able to get
plaintext of much of the data. We also need to look at other attacks this
might open up. For example, can the adversary use a chosen plaintext attack,
deliberately posting news articles which, when we receive and encrypt them,
will help break our encryption? Or can he block our business data
transmission by flooding us with silly news articles? Or ...</p>
<p>Also, note that this does not provide complete protection against traffic
analysis. A clever adversary might still deduce useful intelligence from
statistical analysis (perhaps comparing the input newsfeed to encrypted
output, or comparing the streams we send to different branch offices), or by
looking for small packets which might indicate establishment of TCP
connections, or ...</p>
<p>As a general rule, though, to improve resistance to traffic analysis, you
should <strong>encrypt as much traffic as possible, not just as much as seems
necessary.</strong></p>
<h4><a name="multi-encrypt">Using multiple encryption</a></h4>
<p>This also applies to using multiple layers of encryption. If you have an
IPsec tunnel between two branch offices, it might appear silly to send <a
href="glossary.html#PGP">PGP</a>-encrypted email through that tunnel.
However, if you suspect someone is snooping your traffic, then it does make
sense:</p>
<ul>
<li>it protects the mail headers; they cannot even see who is mailing
who</li>
<li>it protects against user bungles or software malfunctions that
accidentally send messages in the clear</li>
<li>it makes any attack on the mail encryption much harder; they have to
break IPsec or break into your network before they can start on the mail
encryption</li>
</ul>
<p>Similar arguments apply for <a href="glossary.html#SSL">SSL</a>-encrypted
web traffic or <a href="glossary.html#SSH">SSH</a>-encrypted remote login
sessions, even for end-to-end IPsec tunnels between systems in the two
offices.</p>
<h4><a name="fewer">Using fewer tunnels</a></h4>
<p>It may also help to use fewer tunnels. For example, if all you actually
need encrypted is connections between:</p>
<ul>
<li>mail servers at branch and head offices</li>
<li>a few branch office users and the head office database server</li>
</ul>
<p>You might build one tunnel per mail server and one per remote database
user, restricting traffic to those applications. This gives the traffic
analyst some information, however. He or she can distinguish the tunnels by
looking at information in the ESP header and, given that distinction and the
patterns of tunnel usage, might be able to figure out something useful.
Perhaps not, but why take the risk?</p>
<p>We suggest instead that you build one tunnel per branch office, encrypting
everything passing from head office to branches. This has a number of
advantages:</p>
<ul>
<li>it is easier to build and administer</li>
<li>it resists traffic analysis somewhat better</li>
<li>it provides security for whatever you forgot. For example, if some user
at a remote office browses proprietary company data on some head office
web page (that the security people may not even know about!), then that
data is encrypted before it reaches the Internet.</li>
</ul>
<p>Of course you might also want to add additional tunnels. For example, if
some of the database data is confidential and should not be exposed even
within the company, then you need protection from the user's desktop to the
database server. We suggest you do that in whatever way seems appropriate --
IPsec, SSH or SSL might fit -- but, whatever you choose, pass it between
locations via a gateway-to-gateway IPsec tunnel to provide some resistance to
traffic analysis.</p>
<h2><a name="primitives">Cryptographic components</a></h2>
<p>IPsec combines a number of cryptographic techniques, all of them
well-known and well-analyzed. The overall design approach was conservative;
no new or poorly-understood components were included.</p>
<p>This section gives a brief overview of each technique. It is intended only
as an introduction. There is more information, and links to related topics,
in our <a href="glossary.html">glossary</a>. See also our <a
href="biblio.html">bibliography</a> and cryptography <a
href="web.html#crypto.link">web links</a>.</p>
<h3><a name="block.cipher">Block ciphers</a></h3>
<p>The <a href="glossary.html#encryption">encryption</a> in the <a
href="glossary.html#ESP">ESP</a> encapsulation protocol is done with a <a
href="glossary.html#block">block cipher</a>.</p>
<p>We do not implement <a href="glossary.html#DES">single DES</a>. It is <a
href="politics.html#desnotsecure">insecure</a>. Our default, and currently
only, block cipher is <a href="glossary.html#3DES">triple DES</a>.</p>
<p>The <a href="glossary.html#rijndael">Rijndael</a> block cipher has won the
<a href="glossary.html#AES">AES</a> competition to choose a relacement for
DES. It will almost certainly be added to FreeS/WAN and to other IPsec
implementations. <a href="web.html#patch">Patches</a> are already
available.</p>
<h3><a name="hash.ipsec">Hash functions</a></h3>
<h4><a name="hmac.ipsec">The HMAC construct</a></h4>
<p>IPsec packet authentication is done with the <a
href="glossary.html#HMAC">HMAC</a> construct. This is not just a hash of the
packet data, but a more complex operation which uses both a hashing algorithm
and a key. It therefore does more than a simple hash would. A simple hash
would only tell you that the packet data was not changed in transit, or that
whoever changed it also regenerated the hash. An HMAC also tells you that the
sender knew the HMAC key.</p>
<p>For IPsec HMAC, the output of the hash algorithm is truncated to 96 bits.
This saves some space in the packets. More important, it prevents an attacker
from seeing all the hash output bits and perhaps creating some sort of attack
based on that knowledge.</p>
<h4>Choice of hash algorithm</h4>
<p>The IPsec RFCs require two hash algorithms -- <a
href="glossary.html#MD5">MD5</a> and <a href="glossary.html#SHA">SHA-1</a> --
both of which FreeS/WAN implements.</p>
<p>Various other algorithms -- such as RIPEMD and Tiger -- are listed in the
RFCs as optional. None of these are in the FreeS/WAN distribution, or are
likely to be added, although user <a href="web.html#patch">patches</a> exist
for several of them.</p>
<p>Additional hash algorithms -- <a href="glossary.html#SHA-256">SHA-256,
SHA-384 and SHA-512</a> -- may be required to give hash strength matching the
strength of <a href="glossary.html#AES">AES</a>. These are likely to be added
to FreeS/WAN along with AES.</p>
<h3><a name="DH.keying">Diffie-Hellman key agreement</a></h3>
<p>The <a href="glossary.html#DH">Diffie-Hellman</a> key agreement protocol
allows two parties (A and B or <a href="glossary.html#alicebob">Alice and
Bob</a>) to agree on a key in such a way that an eavesdropper who intercepts
the entire conversation cannot learn the key.</p>
<p>The protocol is based on the <a href="glossary.html#dlog">discrete
logarithm</a> problem and is therefore thought to be secure. Mathematicians
have been working on that problem for years and seem no closer to a solution,
though there is no proof that an efficient solution is impossible.</p>
<h3><a name="RSA.auth">RSA authentication</a></h3>
<p>The <a href="glossary.html#RSA">RSA</a> algorithm (named for its inventors
-- Rivest, Shamir and Adleman) is a very widely used <a
href="glossary.html#">public key</a> cryptographic technique. It is used in
IPsec as one method of authenticating gateways for Diffie-Hellman key
negotiation.</p>
<h2><a name="structure">Structure of IPsec</a></h2>
<p>There are three protocols used in an IPsec implementation:</p>
<dl>
<dt>ESP, Encapsulating Security Payload</dt>
<dd>Encrypts and/or authenticates data</dd>
<dt>AH, Authentication Header</dt>
<dd>Provides a packet authentication service</dd>
<dt>IKE, Internet Key Exchange</dt>
<dd>Negotiates connection parameters, including keys, for the other
two</dd>
</dl>
<p>The term "IPsec" is slightly ambiguous. In some contexts, it includes all
three of the above but in other contexts it refers only to AH and ESP.</p>
<h3><a name="IKE.ipsec">IKE (Internet Key Exchange)</a></h3>
<p>The IKE protocol sets up IPsec (ESP or AH) connections after negotiating
appropriate parameters (algorithms to be used, keys, connection lifetimes)
for them. This is done by exchanging packets on UDP port 500 between the two
gateways.</p>
<p>IKE (RFC 2409) was the outcome of a long, complex process in which quite a
number of protocols were proposed and debated. Oversimplifying mildly, IKE
combines:</p>
<dl>
<dt>ISAKMP (RFC 2408)</dt>
<dd>The <strong>I</strong>nternet <strong>S</strong>ecurity
<strong>A</strong>ssociation and <strong>K</strong>ey
<strong>M</strong>anagement <strong>P</strong>rotocol manages
negotiation of connections and defines <a
href="glossary.html#SA">SA</a>s (Security Associations) as a means of
describing connection properties.</dd>
<dt>IPsec DOI for ISAKMP (RFC 2407)</dt>
<dd>A <strong>D</strong>omain <strong>O</strong>f
<strong>I</strong>nterpretation fills in the details necessary to turn
the rather abstract ISAKMP protocol into a more tightly specified
protocol, so it becomes applicable in a particular domain.</dd>
<dt>Oakley key determination protocol (RFC 2412)</dt>
<dd>Oakley creates keys using the <a
href="glossary.html#DH">Diffie-Hellman</a> key agreement protocol.</dd>
</dl>
<p>For all the details, you would need to read the four <a
href="rfc.html">RFCs</a> just mentioned (over 200 pages) and a number of
others. We give a summary below, but it is far from complete.</p>
<h4><a name="phases">Phases of IKE</a></h4>
<p>IKE negotiations have two phases.</p>
<dl>
<dt>Phase one</dt>
<dd>The two gateways negotiate and set up a two-way ISAKMP SA which they
can then use to handle phase two negotiations. One such SA between a
pair of gateways can handle negotiations for multiple tunnels.</dd>
<dt>Phase two</dt>
<dd>Using the ISAKMP SA, the gateways negotiate IPsec (ESP and/or AH) SAs
as required. IPsec SAs are unidirectional (a different key is used in
each direction) and are always negotiated in pairs to handle two-way
traffic. There may be more than one pair defined between two
gateways.</dd>
</dl>
<p>Both of these phases use the UDP protocol and port 500 for their
negotiations.</p>
<p>After both IKE phases are complete, you have IPsec SAs to carry your
encrypted data. These use the ESP or AH protocols. These protocols do not
have ports. Ports apply only to UDP or TCP.</p>
<p>The IKE protocol is designed to be extremely flexible. Among the things
that can be negotiated (separately for each SA) are:</p>
<ul>
<li>SA lifetime before rekeying</li>
<li>encryption algorithm used. We currently support only <a
href="glossary.html#3DES">triple DES</a>. Single DES is <a
href="politics.html#desnotsecure">insecure</a>. The RFCs say you MUST do
DES, SHOULD do 3DES and MAY do various others. We do not do any of the
others.</li>
<li>authentication algorithms. We support <a
href="glossary.html#MD5">MD5</a> and <a href="glossary.html#SHA">SHA</a>.
These are the two the RFCs require.</li>
<li>choice of group for <a href="glossary.html#DH">Diffie-Hellman</a> key
agreement. We currently support Groups 2 and 5 (which are defined modulo
primes of various lengths) and do not support Group 1 (defined modulo a
shorter prime, and therefore cryptographically weak) or groups 3 and 4
(defined using elliptic curves). The RFCs require only Group 1.</li>
</ul>
<p>The protocol also allows implementations to add their own encryption
algorithms, authentication algorithms or Diffie-Hellman groups. We do not
support any such extensions, but there are some <a
href="web.html#patch">patches</a> that do.</p>
<p>There are a number of complications:</p>
<ul>
<li>The gateways must be able to authenticate each other's identities
before they can create a secure connection. This host authentication is
part of phase one negotiations, and is a required prerequisite for packet
authentication used later. Host authentication can be done in a variety
of ways. Those supported by FreeS/WAN are discussed in our <a
href="adv_config.html#auto-auth">advanced configuration</a> document.</li>
<li>Phase one can be done in two ways.
<ul>
<li>Main Mode is required by the RFCs and supported in FreeS/WAN. It
uses a 6-packet exzchange.</li>
<li>Aggressive Mode is somewhat faster (only 3 packets) but reveals
more to an eavesdropper. This is optional in the RFCs, not currently
supported by FreeS/WAN, and not likely to be.</li>
</ul>
</li>
<li>A new group exchange may take place after phase one but before phase
two, defining an additional group for use in the <a
href="glossary.html#DH">Diffie-Hellman</a> key agreement part of phase
two. FreeS/WAN does not currently support this.</li>
<li>Phase two always uses Quick Mode, but there are two variants of that:
<ul>
<li>One variant provides <a href="glossary.html#PFS">Perfect Forward
Secrecy (PFS)</a>. An attacker that obtains your long-term host
authentication key does not immediately get any of your short-term
packet encryption of packet authentication keys. He must conduct
another successful attack each time you rekey to get the short-term
keys. Having some short-term keys does not help him learn others. In
particular, breaking your system today does not let him read messages
he archived yestarday, assuming you've changed short-term keys in the
meanwhile. We enable PFS as the default.</li>
<li>The other variant disables PFS and is therefore slightly faster. We
do not recommend this since it is less secure, but FreeS/WAN does
support it. You can enable it with a <var>pfs=no</var> statement in
<a href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a>.</li>
<li>The protocol provides no way to negotiate which variant will be
used. If one gateway is set for PFS and the other is not, the
negotiation fails. This has proved a fairly common source of
interoperation problems.</li>
</ul>
</li>
<li>Several types of notification message may be sent by either side during
either phase, or later. FreeS/WAN does not currently support these, but
they are a likely addition in future releases.</li>
<li>There is a commit flag which may optionally be set on some messages.
The <a href="http://www.lounge.org/ike_doi_errata.html">errata</a> page
for the RFCs includes two changes related to this, one to clarify the
description of its use and one to block a <a
href="glossary.html#DOS">denial of service</a> attack which uses it. We
currently do not implement this feature.</li>
</ul>
<p>These complications can of course lead to problems, particularly when two
different implementations attempt to interoperate. For example, we have seen
problems such as:</p>
<ul>
<li>Some implementations (often products crippled by <a
href="politics.html#exlaw">export laws</a>) have the insecure DES
algorithm as their only supported encryption method. Other parts of our
documentation discuss the <a
href="politics.html#desnotsecure">reasons we do not implement single
DES</a>, and <a href="interop.html#noDES">how to cope with crippled
products</a>.</li>
<li>Windows 2000 IPsec tries to negotiate using Aggressive Mode, which we
don't support. Later on, it uses the commit bit, which we also don't
support.</li>
<li>Various implementations disable PFS by default, and therefore will not
talk to FreeS/WAN until you either turn on PFS on their end or turn it
off in FreeS/WAN with a <var>pfs=no</var> entry in the connection
description.</li>
<li>FreeS/WAN's interaction with PGPnet is complicated by their use of
notification messages we do not yet support.</li>
</ul>
<p>Despite this, we do interoperate successfully with many implementations,
including both Windows 2000 and PGPnet. Details are in our <a
href="interop.html">interoperability</a> document.</p>
<h4><a name="sequence">Sequence of messages in IKE</a></h4>
<p>Each phase (see <a href="#phases">previous section</a>)of IKE involves a
series of messages. In Pluto error messages, these are abbreviated using:</p>
<dl>
<dt>M</dt>
<dd><strong>M</strong>ain mode, settting up the keying channel (ISAKMP
SA)</dd>
<dt>Q</dt>
<dd><strong>Q</strong>uick mode, setting up the data channel (IPsec
SA)</dd>
<dt>I</dt>
<dd><strong>I</strong>nitiator, the machine that starts the
negotiation</dd>
<dt>R</dt>
<dd><strong>R</strong>esponder</dd>
</dl>
<p>For example, the six messages of a main mode negotiation, in sequence, are
labelled:</p>
<pre> MI1 ---------->
<---------- MR1
MI2 ---------->
<---------- MR2
MI3 ---------->
<---------- MR3</pre>
<h4><a name="struct.exchange">Structure of IKE messages</a></h4>
<p>Here is our Pluto developer explaining some of this on the mailing
list:</p>
<pre>When one IKE system (for example, Pluto) is negotiating with another
to create an SA, the Initiator proposes a bunch of choices and the
Responder replies with one that it has selected.
The structure of the choices is fairly complicated. An SA payload
contains a list of lists of "Proposals". The outer list is a set of
choices: the selection must be from one element of this list.
Each of these elements is a list of Proposals. A selection must be
made from each of the elements of the inner list. In other words,
*all* of them apply (that is how, for example, both AH and ESP can
apply at once).
Within each of these Proposals is a list of Transforms. For each
Proposal selected, one Transform must be selected (in other words,
each Proposal provides a choice of Transforms).
Each Transform is made up of a list of Attributes describing, well,
attributes. Such as lifetime of the SA. Such as algorithm to be
used. All the Attributes apply to a Transform.
You will have noticed a pattern here: layers alternate between being
disjunctions ("or") and conjunctions ("and").
For Phase 1 / Main Mode (negotiating an ISAKMP SA), this structure is
cut back. There must be exactly one Proposal. So this degenerates to
a list of Transforms, one of which must be chosen.</pre>
<h3><a name="services">IPsec Services, AH and ESP</a></h3>
<p>IPsec offers two services, <a
href="glossary.html#authentication">authentication</a> and <a
href="glossary.html#encryption">encryption</a>. These can be used separately
but are often used together.</p>
<dl>
<dt>Authentication</dt>
<dd>Packet-level authentication allows you to be confident that a packet
came from a particular machine and that its contents were not altered
en route to you. No attempt is made to conceal or protect the contents,
only to assure their integrity. Packet authentication can be provided
separately using an <a href="glossary.html#AH">Authentication
Header</a>, described just below, or it can be included as part of the
<a href="glossary.html#ESP">ESP</a> (Encapsulated Security Payload)
service, described in the following section. That service offers
encryption as well as authentication. In either case, the <a
href="glossary.html#HMAC">HMAC</a> construct is used as the
authentication mechanism.
<p>There is a separate authentication operation at the IKE level, in
which each gateway authenticates the other. This can be done in a
variety of ways.</p>
</dd>
<dt>Encryption</dt>
<dd>Encryption allows you to conceal the contents of a message from
eavesdroppers.
<p>In IPsec this is done using a <a href="glossary.html#block">block
cipher</a> (normally <a href="glossary.html#3DES">Triple DES</a> for
Linux). In the most used setup, keys are automatically negotiated, and
periodically re-negotiated, using the <a
href="glossary.html#IKE">IKE</a> (Internet Key Exchange) protocol. In
Linux FreeS/WAN this is handled by the Pluto Daemon.</p>
<p>The IPsec protocol offering encryption is <a
href="glossary.html#ESP">ESP</a>, Encapsulated Security Payload. It can
also include a packet authentication service.</p>
</dd>
</dl>
<p>Note that <strong>encryption should always be used with some packet
authentication service</strong>. Unauthenticated encryption is vulnerable to
<a href="glossary.html#middle">man-in-the-middle attacks</a>. Also note that
encryption does not prevent <a href="glossary.html#traffic">traffic
analysis</a>.</p>
<h3><a name="AH.ipsec">The Authentication Header (AH)</a></h3>
<p>Packet authentication can be provided separately from encryption by adding
an authentication header (AH) after the IP header but before the other
headers on the packet. This is the subject of this section. Details are in
RFC 2402.</p>
<p>Each of the several headers on a packet header contains a "next protocol"
field telling the system what header to look for next. IP headers generally
have either TCP or UDP in this field. When IPsec authentication is used, the
packet IP header has AH in this field, saying that an Authentication Header
comes next. The AH header then has the next header type -- usually TCP, UDP
or encapsulated IP.</p>
<p>IPsec packet authentication can be added in transport mode, as a
modification of standard IP transport. This is shown in this diagram from the
RFC:</p>
<pre> BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
||
except for mutable fields</pre>
<p>Athentication can also be used in tunnel mode, encapsulating the
underlying IP packet beneath AH and an additional IP header.</p>
<pre> ||
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
||
| in the new IP hdr |</pre>
<p>This would normally be used in a gateway-to-gateway tunnel. The receiving
gateway then strips the outer IP header and the AH header and forwards the
inner IP packet.</p>
<p>The mutable fields referred to are things like the time-to-live field in
the IP header. These cannot be included in authentication calculations
because they change as the packet travels.</p>
<h4><a name="keyed">Keyed MD5 and Keyed SHA</a></h4>
<p>The actual authentication data in the header is typically 96 bits and
depends both on a secret shared between sender and receiver and on every byte
of the data being authenticated. The technique used is <a
href="glossary.html#HMAC">HMAC</a>, defined in RFC 2104.</p>
<p>The algorithms involved are the <a href="glossary.html#MD5">MD5</a>
Message Digest Algorithm or <a href="glossary.html#SHA">SHA</a>, the Secure
Hash Algorithm. For details on their use in this application, see RFCs 2403
and 2404 respectively.</p>
<p>For descriptions of the algorithms themselves, see RFC 1321 for MD5 and <a
href="glossary.html#FIPS">FIPS</a> (Federal Information Processing Standard)
number 186 from <a href="glossary.html#NIST">NIST</a>, the US National
Institute of Standards and Technology for SHA. <a
href="biblio.html#schneier"><cite>Applied Cryptography</cite></a> covers both
in some detail, MD5 starting on page 436 and SHA on 442.</p>
<p>These algorithms are intended to make it nearly impossible for anyone to
alter the authenticated data in transit. The sender calculates a digest or
hash value from that data and includes the result in the authentication
header. The recipient does the same calculation and compares results. For
unchanged data, the results will be identical. The hash algorithms are
designed to make it extremely difficult to change the data in any way and
still get the correct hash.</p>
<p>Since the shared secret key is also used in both calculations, an
interceptor cannot simply alter the authenticated data and change the hash
value to match. Without the key, he or she (or even the dreaded They) cannot
produce a usable hash.</p>
<h4><a name="sequence">Sequence numbers</a></h4>
<p>The authentication header includes a sequence number field which the
sender is required to increment for each packet. The receiver can ignore it
or use it to check that packets are indeed arriving in the expected
sequence.</p>
<p>This provides partial protection against <a
href="glossary.html#replay">replay attacks</a> in which an attacker resends
intercepted packets in an effort to confuse or subvert the receiver. Complete
protection is not possible since it is necessary to handle legitmate packets
which are lost, duplicated, or delivered out of order, but use of sequence
numbers makes the attack much more difficult.</p>
<p>The RFCs require that sequence numbers never cycle, that a new key always
be negotiated before the sequence number reaches 2^32-1. This protects both
against replays attacks using packets from a previous cyclce and against <a
href="glossary.html#birthday">birthday attacks</a> on the the packet
authentication algorithm.</p>
<p>In Linux FreeS/WAN, the sequence number is ignored for manually keyed
connections and checked for automatically keyed ones. In manual mode, there
is no way to negotiate a new key, or to recover from a sequence number
problem, so we don't use sequence numbers.</p>
<h3><a name="ESP.ipsec">Encapsulated Security Payload (ESP)</a></h3>
<p>The ESP protocol is defined in RFC 2406. It provides one or both of
encryption and packet authentication. It may be used with or without AH
packet authentication.</p>
<p>Note that <strong>some form of packet authentication should
<em>always</em> be used whenever data is encrypted</strong>. Without
authentication, the encryption is vulnerable to active attacks which may
allow an enemy to break the encryption. ESP should <strong>always</strong>
either include its own authentication or be used with AH authentication.</p>
<p>The RFCs require support for only two mandatory encryption algorithms --
<a href="glossary.html#DES">DES</a>, and null encryption -- and for two
authentication methods -- keyed MD5 and keyed SHA. Implementers may choose to
support additional algorithms in either category.</p>
<p>The authentication algorithms are the same ones used in the IPsec <a
href="#AH">authentication header</a>.</p>
<p>We do not implement single DES since <a
href="politics.html#desnotsecure">DES is insecure</a>. Instead we provide <a
href="glossary.html#3DES">triple DES or 3DES</a>. This is currently the only
encryption algorithm supported.</p>
<p>We do not implement null encryption since it is obviously insecure.</p>
<h2><a name="modes">IPsec modes</a></h2>
<p>IPsec can connect in two modes. Transport mode is a host-to-host
connection involving only two machines. In tunnel mode, the IPsec machines
act as gateways and trafiic for any number of client machines may be
carried.</p>
<h3><a name="tunnel.ipsec">Tunnel mode</a></h3>
<p>Security gateways are required to support tunnel mode connections. In this
mode the gateways provide tunnels for use by client machines behind the
gateways. The client machines need not do any IPsec processing; all they have
to do is route things to gateways.</p>
<h3><a name="transport.ipsec">Transport mode</a></h3>
<p>Host machines (as opposed to security gateways) with IPsec implementations
must also support transport mode. In this mode, the host does its own IPsec
processing and routes some packets via IPsec.</p>
<h2><a name="parts">FreeS/WAN parts</a></h2>
<h3><a name="KLIPS.ipsec">KLIPS: Kernel IPsec Support</a></h3>
<p>KLIPS is <strong>K</strong>erne<strong>L</strong> <strong>IP</strong>SEC
<strong>S</strong>upport, the modifications necessary to support IPsec within
the Linux kernel. KILPS does all the actual IPsec packet-handling,
including</p>
<ul>
<li>encryption</li>
<li>packet authentication calculations</li>
<li>creation of ESP and AH headers for outgoing packets</li>
<li>interpretation of those headers on incoming packets</li>
</ul>
<p>KLIPS also checks all non-IPsec packets to ensure they are not bypassing
IPsec security policies.</p>
<h3><a name="Pluto.ipsec">The Pluto daemon</a></h3>
<p><a href="manpage.d/ipsec_pluto.8.html">Pluto(8)</a> is a daemon which
implements the IKE protocol. It</p>
<ul>
<li>handles all the Phase one ISAKMP SAs</li>
<li>performs host authentication and negotiates with other gateways</li>
<li>creates IPsec SAs and passes the data required to run them to KLIPS</li>
<li>adjust routing and firewall setup to meet IPsec requirements. See our
<a href="firewall.html">IPsec and firewalling</a> document for
details.</li>
</ul>
<p>Pluto is controlled mainly by the <a
href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> configuration file.</p>
<h3><a name="command">The ipsec(8) command</a></h3>
<p>The <a href="manpage.d/ipsec.8.html">ipsec(8)</a> command is a front end
shellscript that allows control over IPsec activity.</p>
<h3><a name="ipsec.conf">Linux FreeS/WAN configuration file</a></h3>
<p>The configuration file for Linux FreeS/WAN is</p>
<pre> /etc/ipsec.conf</pre>
<p>For details see the <a
href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</a> manual page .</p>
<h2><a name="key">Key management</a></h2>
<p>There are several ways IPsec can manage keys. Not all are implemented in
Linux FreeS/WAN.</p>
<h3><a name="current">Currently Implemented Methods</a></h3>
<h4><a name="manual">Manual keying</a></h4>
<p>IPsec allows keys to be manually set. In Linux FreeS/WAN, such keys are
stored with the connection definitions in /etc/ipsec.conf.</p>
<p><a href="glossary.html#manual">Manual keying</a> is useful for debugging
since it allows you to test the <a href="glossary.html#KLIPS">KLIPS</a>
kernel IPsec code without the <a href="glossary.html#Pluto">Pluto</a> daemon
doing key negotiation.</p>
<p>In general, however, automatic keying is preferred because it is more
secure.</p>
<h4><a name="auto">Automatic keying</a></h4>
<p>In automatic keying, the <a href="glossary.html#Pluto">Pluto</a> daemon
negotiates keys using the <a href="glossary.html#IKE">IKE</a> Internet Key
Exchange protocol. Connections are automatically re-keyed periodically.</p>
<p>This is considerably more secure than manual keying. In either case an
attacker who acquires a key can read every message encrypted with that key,
but automatic keys can be changed every few hours or even every few minutes
without breaking the connection or requiring intervention by the system
administrators. Manual keys can only be changed manually; you need to shut
down the connection and have the two admins make changes. Moreover, they have
to communicate the new keys securely, perhaps with <a
href="glossary.html#PGP">PGP</a> or <a href="glossary.html#SSH">SSH</a>. This
may be possible in some cases, but as a general solution it is expensive,
bothersome and unreliable. Far better to let <a
href="glossary.html#Pluto">Pluto</a> handle these chores; no doubt the
administrators have enough to do.</p>
<p>Also, automatic keying is inherently more secure against an attacker who
manages to subvert your gateway system. If manual keying is in use and an
adversary acquires root privilege on your gateway, he reads your keys from
/etc/ipsec.conf and then reads all messages encrypted with those keys.</p>
<p>If automatic keying is used, an adversary with the same privileges can
read /etc/ipsec.secrets, but this does not contain any keys, only the secrets
used to authenticate key exchanges. Having an adversary able to authenticate
your key exchanges need not worry you overmuch. Just having the secrets does
not give him any keys. You are still secure against <a
href="glossary.html#passive">passive</a> attacks. This property of automatic
keying is called <a href="glossary.html#PFS">perfect forward secrecy</a>,
abbreviated PFS.</p>
<p>Unfortunately, having the secrets does allow an <a
href="glossary.html#active">active attack</a>, specifically a <a
href="glossary.html#middle">man-in-the-middle</a> attack. Losing these
secrets to an attacker may not be quite as disastrous as losing the actual
keys, but it is <em>still a serious security breach</em>. These secrets
should be guarded as carefully as keys.</p>
<h3><a name="notyet">Methods not yet implemented</a></h3>
<h4><a name="noauth">Unauthenticated key exchange</a></h4>
<p>It would be possible to exchange keys without authenticating the players.
This would support <a href="glossary.html#carpediem">opportunistic
encryption</a> -- allowing any two systems to encrypt their communications
without requiring a shared PKI or a previously negotiated secret -- and would
be secure against <a href="glossary.html#passive">passive attacks</a>. It
would, however, be highly vulnerable to active <a
href="glossary.html#middle">man-in-the-middle</a> attacks. RFC 2408 therefore
specifies that all <a href="glossary.html#ISAKMP">ISAKMP</a> key management
interactions <em>must</em> be authenticated.</p>
<p>There is room for debate here. Should we provide immediate security
against <a href="glossary.html#passive">passive attacks</a> and encourage
widespread use of encryption, at the expense of risking the more difficult <a
href="glossary.html#active">active attacks</a>? Or should we wait until we
can implement a solution that can both be widespread and offer security
against active attacks?</p>
<p>So far, we have chosen the second course, complying with the RFCs and
waiting for secure DNS (see <a href="glossary.html#DNS">below</a>) so that we
can do <a href="glossary.html#carpediem">opportunistic encryption</a>
right.</p>
<h4><a name="DNS">Key exchange using DNS</a></h4>
<p>The IPsec RFCs allow key exchange based on authentication services
provided by <a href="glossary.html#SDNS">Secure DNS</a>. Once Secure DNS
service becomes widely available, we expect to make this the <em>primary key
management method for Linux FreeS/WAN</em>. It is the best way we know of to
support <a href="glossary.html#carpediem">opportunistic encryption</a>,
allowing two systems without a common PKI or previous negotiation to secure
their communication.</p>
<p>We currently have code to acquire RSA keys from DNS but do not yet have
code to validate Secure DNS signatures.</p>
<h4><a name="PKI">Key exchange using a PKI</a></h4>
<p>The IPsec RFCs allow key exchange based on authentication services
provided by a <a href="glossary.html#PKI">PKI</a> or Public Key
Infrastructure. With many vendors selling such products and many large
organisations building these infrastructures, this will clearly be an
important application of IPsec and one Linux FreeS/WAN will eventually
support.</p>
<p>On the other hand, this is not as high a priority for Linux FreeS/WAN as
solutions based on <a href="glossary.html#SDNS">secure DNS</a>. We do not
expect any PKI to become as universal as DNS.</p>
<p>Some <a href="web.html#patch">patches</a> to handle authentication with
X.509 certificates, which most PKIs use, are available.</p>
<h4><a name="photuris">Photuris</a></h4>
<p><a href="glossary.html#photuris">Photuris</a> is another key management
protocol, an alternative to IKE and ISAKMP, described in RFCs 2522 and 2523
which are labelled "experimental". Adding Photuris support to Linux FreeS/WAN
might be a good project for a volunteer. The likely starting point would be
the OpenBSD photurisd code.</p>
<h4><a name="skip">SKIP</a></h4>
<p><a href="glossary.html#SKIP">SKIP</a> is yet another key management
protocol, developed by Sun. At one point it was fairly widely used, but it
now seems moribund, displaced by IKE. Sun now (as of Solaris 8.0) ship an
IPsec implementation using IKE. We have no plans to implement SKIP. If a user
were to implement it, we would almost certainly not want to add the code to
our distribution.</p>
</body>
</html>
|
