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
|
<pre>Network Working Group B. Patel
Request for Comments: 3456 Intel Corp
Category: Standards Track B. Aboba
Microsoft
S. Kelly
Airespace
V. Gupta
Sun Microsystems, Inc.
January 2003
<span class="h1">Dynamic Host Configuration Protocol (DHCPv4)</span>
<span class="h1">Configuration of IPsec Tunnel Mode</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo explores the requirements for host configuration in IPsec
tunnel mode, and describes how the Dynamic Host Configuration
Protocol (DHCPv4) may be leveraged for configuration. In many remote
access scenarios, a mechanism for making the remote host appear to be
present on the local corporate network is quite useful. This may be
accomplished by assigning the host a "virtual" address from the
corporate network, and then tunneling traffic via IPsec from the
host's ISP-assigned address to the corporate security gateway. In
IPv4, DHCP provides for such remote host configuration.
<span class="grey">Patel, et. al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Table of Contents
<a href="#section-1">1</a>. Introduction................................................... <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a> Terminology................................................. <a href="#page-2">2</a>
<a href="#section-1.2">1.2</a> Requirements Language....................................... <a href="#page-3">3</a>
<a href="#section-2">2</a>. IPsec tunnel mode configuration requirements................... <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a> DHCP configuration evaluation............................... <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a> Summary..................................................... <a href="#page-4">4</a>
<a href="#section-3">3</a>. Scenario overview.............................................. <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a> Configuration walk-through.................................. <a href="#page-5">5</a>
<a href="#section-4">4</a>. Detailed description........................................... <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a> DHCPDISCOVER message processing............................. <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a> DHCP Relay behavior......................................... <a href="#page-9">9</a>
<a href="#section-4.3">4.3</a> DHCPREQUEST message processing.............................. <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a> DHCPACK message processing.................................. <a href="#page-10">10</a>
<a href="#section-4.5">4.5</a> Configuration policy........................................ <a href="#page-11">11</a>
<a href="#section-5">5</a>. Security Considerations........................................ <a href="#page-11">11</a>
<a href="#section-6">6</a>. IANA Considerations............................................ <a href="#page-12">12</a>
<a href="#section-7">7</a>. Intellectual Property Statement................................ <a href="#page-12">12</a>
<a href="#section-8">8</a>. References..................................................... <a href="#page-13">13</a>
<a href="#section-8.1">8.1</a> Normative References........................................ <a href="#page-13">13</a>
<a href="#section-8.2">8.2</a> Informative References...................................... <a href="#page-13">13</a>
<a href="#section-9">9</a>. Acknowledgments................................................ <a href="#page-14">14</a>
Appendix - IKECFG evaluation...................................... <a href="#page-15">15</a>
Authors' Addresses................................................ <a href="#page-17">17</a>
Full Copyright Statement ......................................... <a href="#page-18">18</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
In many remote access scenarios, a mechanism for making the remote
host appear to be present on the local corporate network is quite
useful. This may be accomplished by assigning the host a "virtual"
address from the corporate network, and then tunneling traffic via
IPsec from the host's ISP-assigned address to the corporate security
gateway. In IPv4, Dynamic Host Configuration Protocol (DHCP) [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>]
provides for such remote host configuration. This document explores
the requirements for host configuration in IPsec tunnel mode, and
describes how DHCPv4 may be leveraged for configuration.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
This document uses the following terms:
DHCP client
A DHCP client or "client" is an Internet host using DHCP to
obtain configuration parameters such as a network address.
<span class="grey">Patel, et. al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
DHCP server
A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Requirements language</span>
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [<a href="#ref-1" title=""Key words for use in RFCs to Indicate Requirement Levels"">1</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. IPsec tunnel mode configuration requirements</span>
As described in [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>], the configuration requirements of a host with
an IPsec tunnel mode interface include the need to obtain an IPv4
address and other configuration parameters appropriate to the class
of host. In addition to meeting the basic requirements [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>], the
following additional capabilities may be desirable:
a. integration with existing IPv4 address management facilities
b. support for address pool management
c. reconfiguration when required
d. support for fail-over
e. maintaining security and simplicity in the IKE implementation.
f. authentication where required
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. DHCP configuration evaluation</span>
Leveraging DHCP for configuration of IPsec tunnel mode meets the
basic requirements described in [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>]. It also provides the
additional capabilities described above.
Basic configuration
In IPv4, leveraging DHCPv4 [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>] for the configuration of IPsec
tunnel mode satisfies the basic requirements described in [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>].
Since the required configuration parameters described in [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>]
are a subset of those already supported in DHCPv4 options [<a href="#ref-4" title=""DHCP Options and BOOTP Vendor Extensions"">4</a>],
no new DHCPv4 options are required, and no modifications to
DHCPv4 [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>] are required.
Address management integration
Since DHCPv4 is widely deployed for address management today,
reuse of DHCPv4 for IPsec tunnel mode address management
enables compatibility and integration with existing addressing
implementations and IPv4 address management software.
<span class="grey">Patel, et. al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Address pool management
As described in [<a href="#ref-18" title="Indiana">18</a>], DHCPv4 implementations support
conditional behavior so that the address and configuration
parameters assigned can be dependent on parameters included in
the DHCPDISCOVER. This makes it possible for the security
gateway to ensure that the remote host receives an IP address
assignment from the appropriate address pool, such as via the
User Class option, described in [<a href="#ref-16" title=""The User Class Option for DHCP"">16</a>].
Reconfiguration
DHCP supports the concept of configuration leases, and there is
a proposal for handling forced reconfiguration [<a href="#ref-14" title=""DHCP reconfigure extension"">14</a>].
Fail-over support
When leveraging DHCPv4, configuration and addressing state is
kept on the DHCP server, not within the IKE implementation. As
a result, the loss of a tunnel server does not result in the
loss of configuration and addressing state, thus making it
easier to support fail-over [<a href="#ref-12" title=""DHCP Failover Protocol"">12</a>].
Security and simplicity
Leveraging DHCPv4 also makes it easier to maintain security in
the IKE implementation since no IKE modifications are required
to support configuration.
Authentication
Where DHCPv4 authentication [<a href="#ref-5" title=""Authentication for DHCP Messages"">5</a>] is required, this can be
supported on an IPsec tunnel mode interface as it would be on
any other interface.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Summary</span>
As described, DHCPv4 [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>] meets the IPsec tunnel mode configuration
requirements [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>], as well as providing additional capabilities. As
described in the Appendix, IKECFG [<a href="#ref-13" title=""The ISAKMP Configuration Method"">13</a>] does not meet the basic
requirements, nor does it provide the additional capabilities. As a
result, DHCPv4 is the superior alternative for IPsec tunnel mode
configuration.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Scenario overview</span>
IPsec [<a href="#ref-2" title=""Security Architecture for the Internet Protocol"">2</a>], [<a href="#ref-6" title=""IP Authentication Header"">6</a>]-[<a href="#ref-9" title=""The Internet Key Exchange (IKE)"">9</a>] is a protocol suite defined to secure
communication at the network layer between communicating peers.
Among many applications enabled by IPsec, a useful application is to
connect a remote host to a corporate intranet via a security gateway,
using IPsec tunnel mode. This host is then configured in such a
manner so as to provide it with a virtual presence on the internal
network. This is accomplished in the following manner:
<span class="grey">Patel, et. al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
A remote host on the Internet will connect to the security gateway
and then establish an IPsec tunnel to it. The remote host then
interacts via the IPsec tunnel with a DHCPv4 server which provides
the remote host with an address from the corporate network address
space. The remote host subsequently uses this as the source address
for all interactions with corporate resources. Note that this
implies that the corporate security gateway continues to recognize
the host's original, routable IP address as the tunnel endpoint. The
virtual identity assumed by the remote host when using the assigned
address appears to the corporate network as though it were situated
behind a security gateway bearing the original routable IP address.
All the traffic between the remote host and the intranet will be
carried over the IPsec tunnel via the security gateway as shown
below:
corporate net
+------------------+ |
| externally | +--------+ | !~~~~~~~~~~!
|+-------+ visible | | | | ! rmt host !
||virtual| host | |security| |---! virtual !
|| host | |--------|gateway/| | ! presence !
|| |<================>| DHCP |----| !~~~~~~~~~~!
|+-------+ |--------| Relay | |
+------------------+ ^ +--------+ | +--------+
| |---| DHCPv4 |
IPsec tunnel | | server |
with encapsulated | +--------+
traffic inside
This scenario assumes that the remote host already has Internet
connectivity and the host Internet interface is appropriately
configured. The mechanisms for configuration of the remote host's
address for the Internet interface are well defined; i.e., PPP IP
control protocol (IPCP), described in [<a href="#ref-10" title=""The PPP Internet Protocol Control Protocol (IPCP)"">10</a>], DHCPv4, described in [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>],
and static addressing. The mechanisms for auto-configuration of the
intranet are also standardized. It is also assumed that the remote
host has knowledge of the location of the security gateway. This can
be accomplished via DNS, using either A, KX [<a href="#ref-23" title=""Key Exchange Delegation Record for the DNS"">23</a>], or SRV [<a href="#ref-24" title=""A DNS RR for specifying the location of services (DNS SRV)"">24</a>]
records.
A typical configuration of the remote host in this application would
use two addresses: 1) an interface to connect to the Internet
(Internet interface), and 2) a virtual interface to connect to the
intranet (intranet interface). The IP address of the Internet and
intranet interfaces are used in the outer and inner headers of the
IPsec tunnel mode packet, respectively.
<span class="grey">Patel, et. al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Configuration walk-through</span>
The configuration of the intranet interface of the IPsec tunnel mode
host is accomplished in the following steps:
a. The remote host establishes an IKE security association with the
security gateway in a main mode or aggressive mode exchange. This
IKE SA then serves to secure additional quick mode IPsec SAs.
b. The remote host establishes a DHCP SA with the IPsec tunnel mode
server in a quick mode exchange. The DHCP SA is an IPsec tunnel
mode SA established to protect initial DHCPv4 traffic between the
security gateway and the remote host. The DHCP SA MUST only be
used for DHCP traffic. The details of how this SA is set up are
described in <a href="#section-4.1">Section 4.1</a>.
c. DHCP messages are sent back and forth between the remote host and
the DHCPv4 server. The traffic is protected between the remote
host and the security gateway using the DHCP SA established in
step b. After the DHCP conversation completes, the remote host's
intranet interface obtains an IP address as well as other
configuration parameters.
d. The remote host MAY request deletion of the DHCP SA since future
DHCP messages will be carried over a new IPsec tunnel.
Alternatively, the remote host and the security gateway MAY
continue to use the same SA for all subsequent traffic by adding
temporary SPD selectors in the same manner as is provided for name
ID types in [<a href="#ref-2" title=""Security Architecture for the Internet Protocol"">2</a>].
e. If a new IPsec tunnel is required, the remote host establishes a
tunnel mode SA to the security gateway in a quick mode exchange.
In this case, the new address assigned via DHCPv4 SHOULD be used
in the quick mode ID.
At the end of the last step, the remote host is ready to communicate
with the intranet using an IPsec tunnel. All the IP traffic
(including future DHCPv4 messages) between the remote host and the
intranet are now tunneled over this IPsec tunnel mode SA.
Since the security parameters used for different SAs are based on the
unique requirements of the remote host and the security gateway, they
are not described in this document. The mechanisms described here
work best when the VPN is implemented using a virtual interface.
<span class="grey">Patel, et. al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Detailed description</span>
This section provides details relating to the messages exchanged
during the setup and teardown of the DHCP SAs.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. DHCPDISCOVER message processing</span>
The events begin with the remote host intranet interface generating a
DHCPDISCOVER message. Details are described below:
FIELD OCTETS DESCRIPTION
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type. Set to value 31.
signifying an IPsec tunnel mode virtual interface.
hlen 1 Hardware address length
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags. Broadcast bit MUST be set to zero.
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Security gateway interface IPv4 address, used in
booting via a relay agent.
chaddr 16 Client hardware address. Should be unique.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field.
Table 1: Description of fields in the DHCP message
The htype value is set to the value 31, signifying a virtual IPsec
tunnel mode interface, in order to enable the DHCP server to
differentiate VPN from non-VPN requests. The chaddr field of the
DHCPDISCOVER MUST include an identifier unique to the virtual subnet.
The client MUST use the same chaddr field in all subsequent messages
within the same DHCPv4 exchange. In addition, the chaddr SHOULD be
<span class="grey">Patel, et. al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
persistent between reboots so that the DHCP server will be able to
re-assign the same address if desired.
The hlen and chaddr fields SHOULD be determined as follows:
a. If one or more LAN interfaces are available, the hlen and chaddr
fields SHOULD be determined from the active LAN interface with the
lowest interface number. If no active LAN interface is available,
then the parameters SHOULD be determined from the LAN interface
with the lowest interface number. This enables the chaddr to be
persistent between reboots, as long as the LAN interface hardware
is not removed.
b. If there is no LAN interface, the chaddr field SHOULD be
determined by concatenating x'4000', the IPv4 address of the
interface supplying network connectivity, and an additional octet.
The x'4000' value indicates a locally administered unicast MAC
address, thus guaranteeing that the constructed chaddr value will
not conflict with a globally assigned value.
The additional octet (which MAY represent an interface number)
SHOULD be persistent between reboots, so that the chaddr value
will be persistent across reboots if the assigned IPv4 address
remains consistent.
If the above prescription is followed, then the chaddr will always be
unique on the virtual subnet provided that the remote host only
brings up a single tunnel to the security gateway. Where a LAN
interface is available, the chaddr will be globally unique. When a
non-LAN interface is available and a unique Internet address is
assigned to the remote host, the chaddr will also be globally unique.
Where a private IP address [<a href="#ref-22" title=""Address Allocation for Private Internets"">22</a>] is assigned to a non-LAN interface,
it will not be globally unique. However, in this case packets will
not be routed back and forth between the remote host and the security
gateway unless the external network and corporate network have a
consistent addressing plan. In this case the private IP address
assigned to the remote host will be unique on the virtual subnet.
For use in DHCPv4 configuration of IPsec tunnel mode, the client-
identifier option MUST be included, MUST be unique within the virtual
subnet and SHOULD be persistent across reboots. Possibilities
include:
a. The htype/chaddr combination. If assigned as described above,
this will be unique on the virtual subnet. It will be persistent
across reboots for a LAN interface. If a non-LAN interface is
used, it may not be persistent across reboots if the assigned IP
address changes.
<span class="grey">Patel, et. al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
b. The machine FQDN concatenated with an interface number. Assuming
that the machine FQDN does not conflict with that of another
machine, this will be unique on the virtual subnet as well as
persistent across reboots.
c. The user NAI concatenated with an interface number. Assuming that
the user is only connected to the VPN at one location, this will
be unique on the subnet as well as persistent across reboots.
In order to deliver the DHCPDISCOVER packet from the intranet
interface to the security gateway, an IKE Phase 1 SA is established
between the Internet interface and the security gateway. A phase 2
(quick mode) DHCP SA tunnel mode SA is then established. The key
lifetime for the DHCP SA SHOULD be on the order of minutes since it
will only be temporary. The remote host SHOULD use an IDci payload
of 0.0.0.0/UDP/port 68 in the quick mode exchange. The security
gateway will use an IDcr payload of its own Internet address/UDP/port
67. The DHCP SA is established as a tunnel mode SA with filters set
as follows:
From remote host to security gateway: Any to Any, destination: UDP
port 67
From security gateway to remote host: Any to Any, destination: UDP
port 68
Note that these filters will work not only for a client without
configuration, but also with a client that has previously obtained a
configuration lease, and is attempting to renew it. In the latter
case, the DHCP SA will initially be used to send a DHCPREQUEST rather
than a DHCPDISCOVER message. The initial DHCPv4 message
(DHCPDISCOVER or DHCPREQUEST) is then tunneled to the security
gateway using the tunnel mode SA. Note that since the DHCPDISCOVER
packet has a broadcast address destination, the IPsec implementations
on both the remote host and the security gateway must be capable of
handling this.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. DHCP Relay behavior</span>
While other configurations are possible, typically the DHCPv4 server
will not reside on the same machine as the security gateway, which
will act as a DHCPv4 relay, inserting its address in the "giaddr"
field. In this case, the security gateway relays packets between the
client and the DHCPv4 server, but does not request or renew addresses
on the client's behalf. While acting as a DHCP Relay, the security
gateway MAY implement DHCP Relay load balancing as described in [<a href="#ref-19" title=""DHC Load Balancing Algorithm"">19</a>].
<span class="grey">Patel, et. al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Since DHCP Relays are stateless, the security gateway SHOULD insert
appropriate information in the DHCP message prior to forwarding to
one or more DHCP servers. This enables the security gateway to route
the corresponding DHCPOFFER message(s) back to the remote host on the
correct IPsec tunnel, without having to keep state gleaned from the
DISCOVER, such as a table of the xid, chaddr and tunnel.
If the security gateway maintains a separate subnet for each IPsec
tunnel, then this can be accomplished by inserting the appropriate
interface address in the giaddr field. Alternatively, the security
gateway can utilize the DHCP Relay Agent Information Option [<a href="#ref-17" title=""DHCP Relay Agent Information Option"">17</a>]. In
this case, the virtual port number of the tunnel is inserted in the
Agent Circuit ID Sub-option (sub-option code 1).
To learn the internal IP address of the client in order to route
packets to it, the security gateway will typically snoop the yiaddr
field within the DHCPACK and plumb a corresponding route as part of
DHCP Relay processing.
Where allocating a separate subnet for each tunnel is not feasible,
and the DHCP server does not support the Relay Agent Information
Option, stateless Relay Agent behavior will not be possible. In such
cases, implementations MAY devise a mapping between the xid, chaddr,
and tunnel in order to route the DHCP server response to the
appropriate tunnel endpoint. Note that this is particularly
undesirable in large VPN servers where the resulting state will be
substantial.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. DHCPREQUEST message processing</span>
After the Internet interface has received the DHCPOFFER message, it
forwards this to the intranet interface after IPsec processing. The
intranet interface then responds by creating a DHCPREQUEST message,
which is tunneled to security gateway using the DHCP SA.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. DHCPACK message processing</span>
The DHCPv4 server then replies with a DHCPACK or DHCPNAK message,
which is forwarded down the DHCP SA by the security gateway. The
remote host Internet interface then forwards the DHCPACK or DHCPNAK
message to the intranet interface after IPsec processing.
After processing of the DHCPACK, the intranet interface is configured
and the Internet interface can establish a new IPsec tunnel mode SA
to the security gateway. The remote host may now delete the DHCP
tunnel mode SA. All future DHCP messages sent by the client,
including DHCPREQUEST, DHCPINFORM, DHCPDECLINE, and DHCPRELEASE
messages will use the newly established VPN SA. Similarly, all DHCP
<span class="grey">Patel, et. al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
messages subsequently sent by the DHCPv4 server will be forwarded by
the security gateway (acting as a DHCP Relay) using the IPsec tunnel
mode SA, including DHCPOFFER, DHCPACK, and DHCPNAK messages.
It SHOULD be possible to configure the remote host to forward all
Internet-bound traffic through the tunnel. While this adds overhead
to round-trips between the remote host and the Internet, it provides
some added security in return for this, in that the corporate
security gateway may now filter traffic as it would if the remote
host were physically located on the corporate network.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Configuration policy</span>
Several mechanisms can be used to enable remote hosts to be assigned
different configurations. For example, clients may use the User
Class Option [<a href="#ref-16" title=""The User Class Option for DHCP"">16</a>] to request various configuration profiles. The
DHCPv4 server may also take a number of other variables into account,
including the htype/chaddr; the host name option; the client-
identifier option; the DHCP Relay Agent Information option [<a href="#ref-17" title=""DHCP Relay Agent Information Option"">17</a>]; the
vendor-class-identifier option; the vendor-specific information
option; or the subnet selection option [<a href="#ref-15" title=""The IPv4 Subnet Selection Option for DHCP"">15</a>].
Conditional configuration of clients, described in [<a href="#ref-18" title="Indiana">18</a>], can be used
to solve a number of problems, including assignment of options based
on the client operating system; assignment of groups of clients to
address ranges subsequently used to determine quality of service;
allocation of special address ranges for remote hosts; assignment of
static routes to clients [<a href="#ref-20" title=""The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP)"">20</a>], etc. As noted in the security
considerations, these mechanisms, while useful, do not enhance
security since they can be evaded by a remote host choosing its own
IP address.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This protocol is secured using IPsec, and as a result the DHCP
packets flowing between the remote host and the security gateway are
authenticated and integrity protected.
However, since the security gateway acts as a DHCP Relay, no
protection is afforded the DHCP packets in the portion of the path
between the security gateway and the DHCP server, unless DHCP
authentication is used.
Note that authenticated DHCP cannot be used as an access control
mechanism. This is because a remote host can always set its own IP
address and thus evade any security measures based on DHCP
authentication.
<span class="grey">Patel, et. al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
As a result, the assigned address MUST NOT be depended upon for
security. Instead, the security gateway can use other techniques
such as instantiating packet filters or quick mode selectors on a
per-tunnel basis.
As described in [<a href="#ref-17" title=""DHCP Relay Agent Information Option"">17</a>], a number of issues arise when forwarding DHCP
client requests from untrusted sources. These include DHCP
exhaustion attacks, and spoofing of the client identifier option or
client MAC address. These issues can be partially addressed through
use of the DHCP Relay Information Option [<a href="#ref-17" title=""DHCP Relay Agent Information Option"">17</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document requires that an htype value be allocated for use with
IPsec tunnel mode, as described in <a href="#section-4.1">section 4.1</a>. Note that DHCP
relies on the arp-parameters registry for definition of both the hrd
parameter in ARP and the htype parameter in BOOTP/DHCP. As a result,
an assignment in the arp-parameters registry is required, even though
IPsec-DHCP will never use that parameter for ARP purposes, since
conceptually BOOTP/DHCP and ARP share the arp-parameters registry.
This document does not create any new number spaces for IANA
administration.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Intellectual Property Statement</span>
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in <a href="https://www.rfc-editor.org/bcp/bcp11">BCP-11</a>. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
<span class="grey">Patel, et. al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a> Normative References</span>
[<a id="ref-1">1</a>] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-2">2</a>] Atkinson, R. and S. Kent, "Security Architecture for the
Internet Protocol", <a href="./rfc2401">RFC 2401</a>, November 1998.
[<a id="ref-3">3</a>] Droms, R., "Dynamic Host Configuration Protocol", <a href="./rfc2131">RFC 2131</a>,
March 1997.
[<a id="ref-4">4</a>] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", <a href="./rfc2132">RFC 2132</a>, March 1997.
[<a id="ref-5">5</a>] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
<a href="./rfc3118">RFC 3118</a>, June 2001.
[<a id="ref-6">6</a>] Kent, S. and R. Atkinson, "IP Authentication Header", <a href="./rfc2402">RFC 2402</a>,
November 1998.
[<a id="ref-7">7</a>] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", <a href="./rfc2406">RFC 2406</a>, November 1998.
[<a id="ref-8">8</a>] Piper, D., "The Internet IP Security Domain of Interpretation of
ISAKMP", <a href="./rfc2407">RFC 2407</a>, November 1998.
[<a id="ref-9">9</a>] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
<a href="./rfc2409">RFC 2409</a>, November 1998.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a> Informative References</span>
[<a id="ref-10">10</a>] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", <a href="./rfc1332">RFC 1332</a>, May 1992.
[<a id="ref-11">11</a>] Cobb, S., "PPP Internet Protocol Control Protocol Extensions for
Name Server Addresses", <a href="./rfc1877">RFC 1877</a>, December 1995.
[<a id="ref-12">12</a>] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil,
G., Dooley, M. and A. Kapur, "DHCP Failover Protocol", Work in
Progress.
[<a id="ref-13">13</a>] Dukes, D. and R. Pereira, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22The+ISAKMP+Configuration+Method%22'>"The ISAKMP Configuration Method"</a>,
Work in Progress.
[<a id="ref-14">14</a>] T'Joens, Y., Hublet, C. and P. De Schrijver, "DHCP reconfigure
extension", <a href="./rfc3203">RFC 3203</a>, December 2001.
<span class="grey">Patel, et. al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
[<a id="ref-15">15</a>] Waters, G., "The IPv4 Subnet Selection Option for DHCP", <a href="./rfc3011">RFC</a>
<a href="./rfc3011">3011</a>, November 2000.
[<a id="ref-16">16</a>] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A.,
Beser, B. and J. Privat, "The User Class Option for DHCP", <a href="./rfc3004">RFC</a>
<a href="./rfc3004">3004</a>, November 2000.
[<a id="ref-17">17</a>] Patrick, M., "DHCP Relay Agent Information Option", <a href="./rfc3046">RFC 3046</a>,
January 2001.
[<a id="ref-18">18</a>] Droms, R., and Lemon, T., The DHCP Handbook, Macmillan,
Indianapolis, Indiana, 1999.
[<a id="ref-19">19</a>] Volz, B., Gonczi, S., Lemon, T. and R. Stevens, "DHC Load
Balancing Algorithm", <a href="./rfc3074">RFC 3074</a>, February 2001.
[<a id="ref-20">20</a>] Lemon, T., Cheshire, S. and B. Volz, "The Classless Static Route
Option for Dynamic Host Configuration Protocol (DHCP)", <a href="./rfc3442">RFC</a>
<a href="./rfc3442">3442</a>, December 2002.
[<a id="ref-21">21</a>] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote
Access Scenarios", <a href="./rfc3457">RFC 3457</a>, January 2003.
[<a id="ref-22">22</a>] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E.
Lear, "Address Allocation for Private Internets", <a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC</a>
<a href="./rfc1918">1918</a>, February 1996.
[<a id="ref-23">23</a>] Atkinson, R., "Key Exchange Delegation Record for the DNS", <a href="./rfc2230">RFC</a>
<a href="./rfc2230">2230</a>, November 1997.
[<a id="ref-24">24</a>] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", <a href="./rfc2782">RFC 2782</a>,
February 2000.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgments</span>
This document has been enriched by comments from John Richardson and
Prakash Iyer of Intel, Gurdeep Pall and Peter Ford of Microsoft.
<span class="grey">Patel, et. al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Appendix - IKECFG evaluation
Alternatives to DHCPv4, such as ISAKMP CFG, described in [<a href="#ref-13" title=""The ISAKMP Configuration Method"">13</a>], do not
meet the basic requirements described in [<a href="#ref-21" title=""Requirements for IPsec Remote Access Scenarios"">21</a>], nor do they provide
the additional capabilities of DHCPv4.
Basic configuration
While ISAKMP CFG can provide for IP address assignment as well
as configuration of a few additional parameters such as the DNS
server and WINS server addresses, the rich configuration
facilities of DHCPv4 are not supported. Past experience with
similar configuration mechanisms within PPP IPCP [<a href="#ref-11" title=""PPP Internet Protocol Control Protocol Extensions for Name Server Addresses"">11</a>] has
taught us that it is not viable merely to support minimal
configuration. Eventually, either much of the functionality
embodied in the DHCPv4 options [<a href="#ref-4" title=""DHCP Options and BOOTP Vendor Extensions"">4</a>] is duplicated or support for
DHCPINFORM [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>] will be required.
Address management integration
Since IKECFG is not integrated with existing IP address
management facilities, it is difficult to integrate it with
policy management services that may be dependent on the user to
IP address binding.
Address pool management
IKECFG does not provide a mechanism for the remote host to
indicate a preference for a particular address pool. This
makes it difficult to support address pool management.
Reconfiguration
IKECFG does not support the concept of configuration leases or
reconfiguration.
Fail-over support
Since IKECFG creates a separate pool of address state, it
complicates the provisioning of network utility-class
reliability, both in the IP address management system and in
the security gateways themselves.
Security and simplicity
As past history with PPP IPCP demonstrates, once it is decided
to provide non-integrated address management and configuration
facilities within IKE, it will be difficult to limit the
duplication of effort to address assignment. Instead, it will
be tempting to also duplicate the configuration, authentication
and fail-over facilities of DHCPv4. This duplication will
greatly increase the scope of work, eventually compromising the
security of IKE.
<span class="grey">Patel, et. al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Authentication
While IKECFG can support mutual authentication of the IPsec
tunnel endpoints, it is difficult to integrate IKECFG with
DHCPv4 authentication [<a href="#ref-5" title=""Authentication for DHCP Messages"">5</a>]. This is because the security
gateway will not typically have access to the client
credentials necessary to issue an DHCPv4 authentication option
on the client's behalf.
As a result, security gateways implementing IKECFG typically request
allocation of an IP address on their own behalf, and then assign this
to the client via IKECFG. Since IKECFG does not support the concept
of an address lease, the security gateway will need to do the renewal
itself. This complicates the renewal process.
Since <a href="./rfc2131">RFC 2131</a> [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>] assumes that a DHCPREQUEST will not contain a
filled in giaddr field when generated during RENEWING state, the
DHCPACK will be sent directly to the client, which will not be
expecting it. As a result, it is either necessary for the security
gateway to add special code to avoid forwarding such packets, or to
wait until REBINDING state. Since [<a href="#ref-3" title=""Dynamic Host Configuration Protocol"">3</a>] does not specify that the
giaddr field cannot be filled in when in the REBINDING state, the
security gateway may put its own address in the giaddr field when in
REBINDING state, thereby ensuring that it can receive the renewal
response without treating it as a special case.
<span class="grey">Patel, et. al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Authors' Addresses
Baiju V. Patel
Intel Corp
2511 NE 25th Ave
Hillsboro, OR 97124
Phone: +1 503 712 2303
EMail: baiju.v.patel@intel.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Scott Kelly
Airespace
110 Nortech Pkwy
San Jose CA 95134 USA
Phone: +1 (408) 941-0500
EMail: scott@hyperthought.com
Vipul Gupta
Sun Microsystems, Inc.
MS UMTV29-235
2600 Casey Avenue
Mountain View, CA 94303
Phone: +1 650 336 1681
EMail: vipul.gupta@sun.com
<span class="grey">Patel, et. al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3456">RFC 3456</a> DHCPv4 Config. of IPsec Tunnel Mode January 2003</span>
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Patel, et. al. Standards Track [Page 18]
</pre>
|
