File: rfc2809.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1291 lines) | stat: -rw-r--r-- 47,259 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291






Network Working Group                                          B. Aboba
Request for Comments: 2809                                    Microsoft
Category: Informational                                         G. Zorn
                                                                  Cisco
                                                             April 2000


         Implementation of L2TP Compulsory Tunneling via RADIUS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document discusses implementation issues arising in the
   provisioning of compulsory tunneling in dial-up networks using the
   L2TP protocol.  This provisioning can be accomplished via the
   integration of RADIUS and tunneling protocols. Implementation issues
   encountered with other tunneling protocols are left to separate
   documents.

1. Terminology

   Voluntary Tunneling
              In voluntary tunneling, a tunnel is created by the user,
              typically via use of a tunneling client.

   Compulsory Tunneling
              In compulsory tunneling, a tunnel is created without any
              action from the user and without allowing the user any
              choice.

   Tunnel Network Server
              This is a server which terminates a tunnel. In L2TP
              terminology, this is known as the L2TP Network Server
              (LNS).








Aboba & Zorn                 Informational                      [Page 1]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   Network Access Server
              The Network Access Server (NAS) is the device that clients
              contact in order to get access to the network. In L2TP
              terminology, a NAS performing compulsory tunneling is
              referred to as the L2TP Access Concentrator (LAC).

   RADIUS authentication server
              This is a server which provides for
              authentication/authorization via the protocol described in
              [1].

   RADIUS proxy
              In order to provide for the routing of RADIUS
              authentication requests, a RADIUS proxy can be employed.
              To the NAS, the RADIUS proxy appears to act as a RADIUS
              server, and to the RADIUS server, the proxy appears to act
              as a RADIUS client.  Can be used to locate the tunnel
              endpoint when realm-based tunneling is used.

2.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [4].

3.  Introduction

   Many applications of tunneling protocols involve dial-up network
   access.  Some, such as the provisioning of secure access to corporate
   intranets via the Internet, are characterized by voluntary tunneling:
   the tunnel is created at the request of the user for a specific
   purpose. Other applications involve compulsory tunneling: the tunnel
   is created without any action from the user and without allowing the
   user any choice.

   Examples of applications that might be implemented using compulsory
   tunnels are Internet software upgrade servers, software registration
   servers and banking services.  These are all services which, without
   compulsory tunneling, would probably be provided using dedicated
   networks or at least dedicated network access servers (NAS), since
   they are characterized by the need to limit user access to specific
   hosts.

   Given the existence of widespread support for compulsory tunneling,
   however, these types of services could be accessed via any Internet
   service provider (ISP).  The most popular means of authorizing dial-
   up network users today is through the RADIUS protocol. The use of
   RADIUS allows the dial-up users' authorization and authentication



Aboba & Zorn                 Informational                      [Page 2]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   data to be maintained in a central location, rather than on each NAS.
   It makes sense to use RADIUS to centrally administer compulsory
   tunneling, since RADIUS is widely deployed and was designed to carry
   this type of information.  New RADIUS attributes are needed to carry
   the tunneling information from the RADIUS server to the NAS. Those
   attributes are defined in [3].

3.1.  Advantages of RADIUS-based compulsory tunneling

   Current proposals for routing of tunnel requests include static
   tunneling, where all users are automatically tunneled to a given
   endpoint, and realm-based tunneling, where the tunnel endpoint is
   determined from the realm portion of the userID. User-based tunneling
   as provided by integration of RADIUS and tunnel protocols offers
   significant advantages over both of these approaches.

   Static tunneling requires dedication of a NAS device to the purpose.
   In the case of an ISP, this is undesirable because it requires them
   to dedicate a NAS to tunneling service for a given customer, rather
   than allowing them to use existing NASes deployed in the field. As a
   result static tunneling is likely to be costly for deployment of a
   global service.

   Realm-based tunneling assumes that all users within a given realm
   wish to be treated the same way. This limits flexibility in account
   management.  For example, BIGCO may desire to provide Janet with an
   account that allows access to both the Internet and the intranet,
   with Janet's intranet access provided by a tunnel server located in
   the engineering department. However BIGCO may desire to provide Fred
   with an account that provides only access to the intranet, with
   Fred's intranet access provided by a tunnel network server located in
   the sales department. Such a situation cannot be accommodated with
   realm-based tunneling, but can be accommodated via user-based
   tunneling as enabled by the attributes defined in [3].

4.  Authentication alternatives

   RADIUS-based compulsory tunneling can support both single
   authentication, where the user is authenticated at the NAS or tunnel
   server, or dual authentication, where the user is authenticated at
   both the NAS and the tunnel server. When single authentication is
   supported, a variety of modes are possible, including telephone-
   number based authentication.  When dual-authentication is used, a
   number of modes are available, including dual CHAP authentications;







Aboba & Zorn                 Informational                      [Page 3]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP
   authentication, using the same EAP type for both authentications. EAP
   is described in [5].

   The alternatives are described in more detail below.

4.1.  Single authentication

   Single authentication alternatives include:

   NAS authentication
   NAS authentication with RADIUS reply forwarding
   Tunnel server authentication

4.1.1.  NAS authentication

   With this approach, authentication and authorization (including
   tunneling information) occurs once, at the NAS. The advantages of
   this approach are that it disallows network access for unauthorized
   NAS users, and permits accounting to done at the NAS.  Disadvantages
   are that it requires that the tunnel server trust the NAS, since no
   user authentication occurs at the tunnel server. Due to the lack of
   user authentication, accounting cannot take place at the tunnel
   server with strong assurance that the correct party is being billed.

   NAS-only authentication is most typically employed along with LCP
   forwarding and tunnel authentication, both of which are supported in
   L2TP, described in [2].  Thus, the tunnel server can be set up to
   accept all calls occurring within authenticated tunnels, without
   requiring PPP authentication.  However, this approach is not
   compatible with roaming, since the tunnel server will typically only
   be set up to accept tunnels from a restricted set of NASes. A typical
   initiation sequence looks like this:

   Client and NAS: Call Connected
   Client and NAS: PPP LCP negotiation
   Client and NAS: PPP authentication
   NAS to RADIUS Server: RADIUS Access-request
   RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
   NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP Incoming-Call-Connected
   Client and Tunnel Server: NCP negotiation








Aboba & Zorn                 Informational                      [Page 4]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   The process begins with an incoming call to the NAS, and the PPP LCP
   negotiation between the client and the NAS. In order to authenticate
   the client, the NAS will send a RADIUS Access-Request to the RADIUS
   server and will receive a RADIUS Access-Accept including tunnel
   attributes, or an Access-Reject.

   In the case where an L2TP tunnel is indicated, the NAS will now bring
   up a control connection if none existed before, and the NAS and
   tunnel server will bring up the call. At this point, data will begin
   to flow through the tunnel.  The NAS will typically employ LCP
   forwarding, although it is also possible for the tunnel server to
   renegotiate LCP.  If LCP renegotiation is to be permitted, the NAS
   SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather
   than sending an LCP CONFACK, the NAS will instead send an LCP
   Configure-Request packet, described in [6].  The Client MAY then
   renegotiate LCP, and from that point forward, all PPP packets
   originated from the client will be encapsulated and sent to the
   tunnel server.

   Since address assignment will occur at the tunnel server, the client
   and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will
   occur between the client and the tunnel server.

4.1.2.  NAS authentication with RADIUS reply forwarding

   With this approach, authentication and authorization occurs once at
   the NAS and the RADIUS reply is forwarded to the tunnel server. This
   approach disallows network access for unauthorized NAS users; does
   not require trust between the NAS and tunnel server; and allows for
   accounting to be done at both ends of the tunnel. However, it also
   requires that both ends share the same secret with the RADIUS server,
   since that is the only way that the tunnel server can check the
   RADIUS Access-Reply.

   In this approach, the tunnel server will share secrets with all the
   NASes and associated RADIUS servers, and there is no provision for
   LCP renegotiation by the tunnel server. Also, the tunnel server will
   need to know how to handle and verify RADIUS Access-Accept messages.

   While this scheme can be workable if the reply comes directly from a
   RADIUS server, it would become unmanageable if a RADIUS proxy is
   involved, since the reply would be authenticated using the secret
   shared by the client and proxy, rather than the RADIUS server. As a
   result, this scheme is impractical.







Aboba & Zorn                 Informational                      [Page 5]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


4.1.2.1. Tunnel server authentication

   In this scheme, authentication and authorization occurs once at the
   tunnel server.  This requires that the NAS determine that the user
   needs to be tunneled (through RADIUS or NAS configuration). Where
   RADIUS is used, the determination can be made using one of the
   following methods:

   Telephone-number based authentication
   UserID

4.1.2.2.  Telephone-number based authentication

   Using the Calling-Station-Id and Called-Station-Id RADIUS attributes,
   authorization and subsequent tunnel attributes can be based on the
   phone number originating the call, or the number being called. This
   allows the RADIUS server to authorize users based on the calling
   phone number or to provide tunnel attributes based on the Calling-
   Station-Id or Called-Station-Id.  Similarly, in L2TP the tunnel
   server MAY choose to reject or accept the call based on the Dialed
   Number and Dialing Number included in the L2TP Incoming-Call-Request
   packet sent by the NAS.  Accounting can also take place based on the
   Calling-Station-Id and Called-Station-Id.

   RADIUS as defined in [1] requires that an Access-Request packet
   contain a User-Name attribute as well as either a CHAP-Password or
   User-Password attribute, which must be non-empty.  To satisfy this
   requirement the Called-Station-Id or Calling-Station-Id MAY be
   furnished in the User-Name attribute and a dummy value MAY be used in
   the User-Password or CHAP-Password attribute.

   In the case of telephone-number based authentication, a typical
   initiation sequence looks like this:

   Client and NS: Call Connected
   NAS to RADIUS Server: RADIUS Access-request
   RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
   NAS to Tunnel Server: L2TP Incoming-Call-Request
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP  Incoming-Call-Connected
   Client and Tunnel Server: PPP LCP negotiation
   Client and Tunnel Server: PPP authentication
   Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
   RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
   Client and Tunnel Server: NCP negotiation






Aboba & Zorn                 Informational                      [Page 6]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   The process begins with an incoming call to the NAS. If configured
   for telephone-number based authentication, the NAS sends a RADIUS
   Access-Request containing the Calling-Station-Id and the Called-
   Station-Id attributes. The RADIUS server will then respond with a
   RADIUS Access-Accept or Access-Reject.

   The NAS MUST NOT begin PPP authentication before bringing up the
   tunnel.  If timing permits, the NAS MAY bring up the tunnel prior to
   beginning LCP negotiation with the peer. If this is done, then LCP
   will not need to be renegotiated between the peer and tunnel server,
   nor will LCP forwarding need to be employed.

   If the initial telephone-number based authentication is unsuccessful,
   the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS
   MUST send an LCP-Terminate and disconnect the user.

   In the case where tunnel attributes are included in the RADIUS
   Access-Accept, and an L2TP tunnel is indicated, the NAS will now
   bring up a control connection if none existed before. This is
   accomplished by sending an L2TP Start-Control-Connection-Request
   message to the tunnel server.  The tunnel server will then reply with
   an L2TP Start-Control-Connection-Reply.  If this message indicates an
   error, or if the control connection is terminated at any future time,
   then the NAS MUST send an LCP-Terminate and disconnect the user.

   The NAS will then send an L2TP Incoming-Call-Request message to the
   tunnel server. Among other things, this message will contain the Call
   Serial Number, which along with the NAS-IP-Address and Tunnel-
   Server-Endpoint is used to uniquely identify the call. The tunnel
   server will reply with an L2TP Incoming-Call-Reply message. If this
   message indicates an error, then the NAS MUST send an LCP-Terminate
   and disconnect the user. If no error is indicated, the NAS then
   replies with an L2TP Incoming-Call-Connected message.

   At this point, data can begin to flow through the tunnel. If LCP
   negotiation had been begun between the NAS and the client, then LCP
   forwarding may be employed, or the client and tunnel server will now
   renegotiate LCP and begin PPP authentication. Otherwise, the client
   and tunnel server will negotiate LCP for the first time, and then
   move on to PPP authentication.

   If a renegotiation is required, at the time that the renegotiation
   begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP
   negotiation, and the client and NAS MUST NOT have begun NCP
   negotiation.  Rather than sending an LCP CONFACK, the NAS will
   instead send an LCP Configure-Request Packet, described in [6].  The
   Client MAY then renegotiate LCP, and from that point forward, all PPP
   packets originated from the client will be encapsulated and sent to



Aboba & Zorn                 Informational                      [Page 7]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   the tunnel server.  When LCP re-negotiation has been concluded, the
   NCP phase will begin, and the tunnel server will assign an address to
   the client.

   If L2TP is being used as the tunnel protocol, and LCP renegotiation
   is required, the NAS MAY in its initial setup notification include a
   copy of the LCP CONFACKs sent in each direction which completed LCP
   negotiation. The tunnel server MAY then use this information to avoid
   an additional LCP negotiation. With L2TP, the initial setup
   notification can also include the authentication information required
   to allow the tunnel server to authenticate the user and decide to
   accept or decline the connection. However, in telephone-number based
   authentication, PPP authentication MUST NOT occur prior to the NAS
   bringing up the tunnel.  As a result, L2TP authentication forwarding
   MUST NOT be employed.

   In performing the PPP authentication, the tunnel server can access
   its own user database, or alternatively can send a RADIUS Access-
   Request.  The latter approach is useful in cases where authentication
   forwarding is enabled, such as with roaming or shared use networks.
   In this case, the RADIUS and tunnel servers are under the same
   administration and are typically located close together, possibly on
   the same LAN.  Therefore having the tunnel server act as a RADIUS
   client provides for unified user administration. Note that the tunnel
   server's RADIUS Access-Request is typically sent directly to the
   local RADIUS server rather than being forwarded via a proxy.

   The interactions involved in initiation of a compulsory tunnel with
   telephone-number based authentication are summarized below. In order
   to simplify the diagram that follows, we have left out the client.
   However, it is understood that the client participates via PPP
   negotiation, authentication and subsequent data interchange with the
   Tunnel Server.


















Aboba & Zorn                 Informational                      [Page 8]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call connected
   Send RADIUS
    Access-Request
    with Called-Station-Id,
    and/or Calling-Station-Id
   LCP starts
                                                      IF authentication
                                                      succeeds
                                                       Send ACK
                                                      ELSE Send NAK
   IF NAK DISCONNECT
   ELSE
    IF no control
     connection exists
     Send
     Start-Control-Connection-Request
     to Tunnel Server
                                Send
                                Start-Control-Connection-Reply
                                to NAS
    ENDIF

   Send
   Incoming-Call-Request
   message to Tunnel Server
                                Send Incoming-Call-Reply
                                to NAS
   Send
   Incoming-Call-Connected
   message to Tunnel Server

   Send data through the tunnel
                                Re-negotiate LCP,
                                authenticate user,
                                bring up IPCP,
                                start accounting











Aboba & Zorn                 Informational                      [Page 9]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


4.1.2.3.  User-Name

   Since authentication will occur only at the tunnel-server, tunnel
   initiation must occur prior to user authentication at the NAS. As a
   result, this scheme typically uses either the domain portion of the
   userID or attribute-specific processing on the RADIUS server.  Since
   the user identity is never verified by the NAS, either the tunnel
   server owner must be willing to be billed for all incoming calls, or
   other information such as the Calling-Station-Id must be used to
   verify the user's identity for accounting purposes.

   In attribute-specific processing RADIUS may be employed and an
   attribute is used to signal tunnel initiation.  For example, tunnel
   attributes can be sent back if the User-Password attribute contains a
   dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID
   beginning with a special character ('*') could be used to indicate
   the need to initiate a tunnel.  When attribute-specific processing is
   used, the tunnel server may need to renegotiate LCP.

   Another solution involves using the domain portion of the userID; all
   users in domain X would be tunneled to address Y. This proposal
   supports compulsory tunneling, but does not provide for user-based
   tunneling.

   In order for the NAS to start accounting on the connection, it would
   need to use the identity claimed by the user in authenticating to the
   tunnel server, since it did not verify the identity via RADIUS.
   However, in order for that to be of any use in accounting, the tunnel
   endpoint needs to have an account relationship with the NAS owner.
   Thus even if a user has an account with the NAS owner, they cannot
   use this account for tunneling unless the tunnel endpoint also has a
   business relationship with the NAS owner. Thus this approach is
   incompatible with roaming.

   A typical initiation sequence involving use of the domain portion of
   the userID looks like this:

   Client and NAS: Call Connected
   Client and NAS: PPP LCP negotiation
   Client and NAS: Authentication
   NAS to Tunnel Server: L2TP Incoming-Call-Request
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP  Incoming-Call-Connected
   Client and Tunnel Server: PPP LCP re-negotiation
   Client and Tunnel Server: PPP authentication
   Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
   RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
   Client and Tunnel Server: NCP negotiation



Aboba & Zorn                 Informational                     [Page 10]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   The process begins with an incoming call to the NAS, and the PPP LCP
   negotiation between the Client and NAS. The authentication process
   will then begin and based on the domain portion of the userID, the
   NAS will now bring up a control connection if none existed before,
   and the NAS and tunnel server will bring up the call. At this point,
   data MAY begin to flow through the tunnel.  The client and tunnel
   server MAY now renegotiate LCP and will complete PPP authentication.

   At the time that the renegotiation begins, the NAS SHOULD NOT have
   sent an LCP CONFACK completing LCP negotiation, and the client and
   NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP
   CONFACK, the NAS will instead send an LCP Configure-Request packet,
   described in [6].  The Client MAY then renegotiate LCP, and from that
   point forward, all PPP packets originated from the client will be
   encapsulated and sent to the tunnel server.  In single authentication
   compulsory tunneling, L2TP authentication forwarding MUST NOT be
   employed.  When LCP re-negotiation has been concluded, the NCP phase
   will begin, and the tunnel server will assign an address to the
   client.

   In performing the PPP authentication, the tunnel server can access
   its own user database, or it MAY send a RADIUS Access-Request. After
   the tunnel has been brought up, the NAS and tunnel server can start
   accounting.



























Aboba & Zorn                 Informational                     [Page 11]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   The interactions are summarized below.

                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call accepted
   LCP starts
   Authentication
    phase starts
   IF no control
    connection exists
    Send
    Start-Control-Connection-Request
    to Tunnel Server
   ENDIF
                                IF no control
                                 connection exists
                                 Send
                                 Start-Control-Connection-Reply
                                 to NAS
                                ENDIF

   Send
   Incoming-Call-Request
   message to Tunnel Server
                                Send Incoming-Call-Reply
                                to NAS
   Send
   Incoming-Call-Connected
   message to Tunnel Server

   Send data through the tunnel
                                Re-negotiate LCP,
                                authenticate user,
                                bring up IPCP,
                                start accounting

4.2.  Dual authentication

   In this scheme, authentication occurs both at the NAS and the tunnel
   server. This requires the dial-up client to handle dual
   authentication, with attendant LCP re-negotiations. In order to allow
   the NAS and tunnel network server to authenticate against the same
   database, this requires RADIUS client capability on the tunnel
   network server, and possibly a RADIUS proxy on the NAS end.





Aboba & Zorn                 Informational                     [Page 12]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   Advantages of dual authentication include support for authentication
   and accounting at both ends of the tunnel; use of a single
   userID/password pair via implementation of RADIUS on the tunnel
   network server; no requirement for telephone-number based
   authentication, or attribute-specific processing on the RADIUS
   server.

   Dual authentication allows for accounting records to be generated on
   both the NAS and tunnel server ends, making auditing possible. Also
   the tunnel endpoint does not need to have an account relationship
   with the NAS owner, making this approach compatible with roaming.

   A disadvantage of dual authentication is that unless LCP forwarding
   is used, LCP will need to be renegotiated; some clients do not
   support it at all, and others only support only a subset of the dual
   authentication combinations. Feasible combinations include
   PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP,
   CHAP/EAP, EAP/CHAP, and EAP/EAP.  EAP is described in [5].

   In the case of a dual authentication, a typical initiation sequence
   looks like this:

   Client and NAS: PPP LCP negotiation
   Client and NAS: PPP authentication
   NAS to RADIUS Server: RADIUS Access-request
   RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
   NAS to Tunnel Server: L2TP Incoming-Call-Request
   Tunnel Server to NAS: L2TP Incoming-Call-Reply
   NAS to Tunnel Server: L2TP  Incoming-Call-Connected
   Client and Tunnel Server: PPP LCP re-negotiation (optional)
   Client and Tunnel Server: PPP authentication
   Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
   RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
   Client and Tunnel Server: NCP negotiation

   The process begins with an incoming call to the NAS. The client and
   NAS then begin LCP negotiation. Subsequently the PPP authentication
   phase starts, and the NAS sends a RADIUS Access-Request message to
   the RADIUS server. If the authentication is successful, the RADIUS
   server responds with a RADIUS Access-Accept containing tunnel
   attributes.

   In the case where an L2TP tunnel is indicated, the NAS will now bring
   up a control connection if none existed before, and the NAS and
   tunnel server will bring up the call. At this point, data MAY begin
   to flow through the tunnel. The client and tunnel server MAY now
   renegotiate LCP and go through another round of PPP authentication.
   At the time that this renegotiation begins, the NAS SHOULD NOT have



Aboba & Zorn                 Informational                     [Page 13]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   sent an LCP CONFACK completing LCP negotiation, and the client and
   NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP
   CONFACK, the NAS will instead send an LCP Configure-Request packet,
   described in [6].  The Client MAY then renegotiate LCP, and from that
   point forward, all PPP packets originated from the client will be
   encapsulated and sent to the tunnel server.  When LCP re-negotiation
   has been concluded, the NCP phase will begin, and the tunnel server
   will assign an address to the client.

   If L2TP is being used as the tunnel protocol, the NAS MAY in its
   initial setup notification include a copy of the LCP CONFACKs sent in
   each direction which completed LCP negotiation. The tunnel server MAY
   then use this information to avoid an additional LCP negotiation.
   With L2TP, the initial setup notification can also include the
   authentication information required to allow the tunnel server to
   authenticate the user and decide to accept or decline the connection.
   However, this facility creates a vulnerability to replay attacks, and
   can create problems in the case where the NAS and tunnel server
   authenticate against different RADIUS servers. As a result, where
   user-based tunneling via RADIUS is implemented, L2TP authentication
   forwarding SHOULD NOT be employed.

   In performing the PPP authentication, the tunnel server can access
   its own user database, or it MAY send a RADIUS Access-Request.  After
   the tunnel has been brought up, the NAS and tunnel server can start
   accounting.

   The interactions involved in initiation of a compulsory tunnel with
   dual authentication are summarized below.






















Aboba & Zorn                 Informational                     [Page 14]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


                                  INITIATION SEQUENCE

   NAS                            Tunnel Server       RADIUS Server
   ---                            -------------       -------------
   Call accepted
   LCP starts
   PPP authentication
    phase starts
   Send RADIUS
    Access-Request
    with userID and
    authentication data
                                                      IF authentication
                                                      succeeds
                                                       Send ACK
                                                      ELSE Send NAK
   IF NAK DISCONNECT
   ELSE
    IF no control
     connection exists
     Send
     Start-Control-Connection-Request
     to Tunnel Server
                                Send
                                Start-Control-Connection-Reply
                                to NAS
    ENDIF

   Send
   Incoming-Call-Request
   message to Tunnel Server
                                Send Incoming-Call-Reply
                                to NAS
   Send
   Incoming-Call-Connected
   message to Tunnel Server

   Send data through the tunnel
                                Re-negotiate LCP,
                                authenticate user,
                                bring up IPCP,
                                start accounting
   ENDIF








Aboba & Zorn                 Informational                     [Page 15]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


5.  Termination sequence

   The tear down of a compulsory tunnel involves an interaction between
   the client, NAS and Tunnel Server. This interaction is virtually
   identical regardless of whether telephone-number based
   authentication, single authentication, or dual authentication is
   being used.  In any of the cases, the following events occur:

        Tunnel Server to NAS: L2TP Call-Clear-Request (optional)
        NAS to Tunnel Server: L2TP Call-Disconnect-Notify

   Tunnel termination can occur due to a client request (PPP
   termination), a tunnel server request (Call-Clear-Request), or a line
   problem (call disconnect).

   In the case of a client-requested termination, the tunnel server MUST
   terminate the PPP session. The tunnel server MUST subsequently send a
   Call-Clear-Request to the NAS. The NAS MUST then send a Call-
   Disconnect-Notify message to the tunnel server, and will disconnect
   the call.

   The NAS MUST also respond with a Call-Disconnect-Notify message and
   disconnection if it receives a Call-Clear-Request from the tunnel
   server without a client-requested termination.

   In the case of a line problem or user hangup, the NAS MUST send a
   Call-Disconnect-Notify to the tunnel server. Both sides will then
   tear down the call.

   The interactions involved in termination of a compulsory tunnel are
   summarized below. In order to simplify the diagram that follows, we
   have left out the client. However, it is understood that the client
   MAY participate via PPP termination and disconnection.


















Aboba & Zorn                 Informational                     [Page 16]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


                                  TERMINATION SEQUENCE

   NAS                            Tunnel Server         RADIUS Server
   ---                            -------------         -------------
   IF user disconnected
    send
    Call-Disconnect-Notify
    message to tunnel server
                                  Tear down the call
                                  stop accounting
   ELSE IF client requests
    termination
                                  send
                                  Call-Clear-Request
                                  to the NAS
    Send
    Call-Disconnect-Notify
    message to tunnel server
    Disconnect the user
                                  Tear down the call
                                  stop accounting
   ENDIF

6.  Use of distinct RADIUS servers

   In the case that the NAS and the tunnel server are using distinct
   RADIUS servers, some interesting cases can arise in the provisioning
   of compulsory tunnels.

6.1.  Distinct userIDs

   If distinct RADIUS servers are being used, it is likely that distinct
   userID/password pairs will be required to complete the RADIUS and
   tunnel authentications. One pair will be used in the initial PPP
   authentication with the NAS, and the second pair will be used for
   authentication at the tunnel server.

   This has implications if the NAS attempts to forward authentication
   information to the tunnel server in the initial setup notification.
   Since the userID/password pair used for tunnel authentication is
   different from that used to authenticate against the NAS, forwarding
   authentication information in this manner will cause the tunnel
   authentication to fail. As a result, where user-based tunneling via
   RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be
   employed.






Aboba & Zorn                 Informational                     [Page 17]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   In order to provide maximum ease of use in the case where the
   userID/password pairs are identical, tunnel clients typically attempt
   authentication with the same userID/password pair as was used in the
   initial PPP negotiation. Only after this fails do they prompt the
   user for the second pair. Rather than putting up an error message
   indicating an authentication failure, it is preferable to present a
   dialog requesting the tunnel userID/password combination.

   A similar issue arises when extended authentication methods are being
   used, as is enabled by EAP, described in [5]. In particular, when
   one-time passwords or cryptographic calculators are being used,
   different passwords will be used for the first and second
   authentications. Thus the user will need to be prompted to enter the
   second password.

6.2.  Multilink PPP issues

   It is possible for the two RADIUS servers to return different Port-
   Limit attributes.  For example, it is conceivable that the NAS RADIUS
   server will only grant use of a single channel, while the tunnel
   RADIUS server will grant more than one channel. In this case, the
   correct behavior is for the tunnel client to open a connection to
   another NAS in order to bring up a multilink bundle on the tunnel
   server. The client MUST NOT indicate to the NAS that this additional
   link is being brought up as part of a multilink bundle; this will
   only be indicated in the subsequent negotiation with the tunnel
   server.

   It is also conceivable that the NAS RADIUS server will allow the
   client to bring up multiple channels, but that the tunnel RADIUS
   server will allow fewer channels than the NAS RADIUS server. In this
   case, the client should terminate use of the excess channels.

7.  UserID Issues

   In the provisioning of roaming and shared use networks, one of the
   requirements is to be able to route the authentication request to the
   user's home RADIUS server. This authentication routing is
   accomplished based on the userID submitted by the user to the NAS in
   the initial PPP authentication. The userID is subsequently relayed by
   the NAS to the RADIUS server in the User-Name attribute, as part of
   the RADIUS Access-Request.

   Similarly, [2] refers to use of the userID in determining the tunnel
   endpoint, although it does not provide guidelines for how RADIUS or
   tunnel routing is to be accomplished. Thus the possibility of
   conflicting interpretations exists.




Aboba & Zorn                 Informational                     [Page 18]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


   The use of RADIUS in provisioning of compulsory tunneling relieves
   the userID from having to do double duty. Rather than being used both
   for routing of the RADIUS authentication/authorization request as
   well for determination of the tunnel endpoint, the userID is now used
   solely for routing of RADIUS authentication/authorization requests.
   Tunnel attributes returned in the RADIUS Access-Response are then
   used to determine the tunnel endpoint.

   Since the framework described in this document allows both ISPs and
   tunnel users to authenticate users as well as to account for
   resources consumed by them, and provides for maintenance of two
   distinct userID/password pairs, this scheme provides a high degree of
   flexibility.  Where RADIUS proxies and tunneling are employed, it is
   possible to allow the user to authenticate with a single
   userID/password pair at both the NAS and the tunnel endpoint. This is
   accomplished by routing the NAS RADIUS Access-Request to the same
   RADIUS server used by the tunnel server.

8.  References

   [1]  Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
        Authentication Dial In User Service (RADIUS)", RFC 2138, April
        1997.

   [2]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
        Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
        August 1999.

   [3]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
        Goyret, I., "RADIUS Attributes for Tunnel Protocol Support",
        Work in Progress.

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

   [5]  Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication
        Protocol (EAP)", RFC 2284, March 1998.

   [6]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
        51, RFC 1661, July 1994.











Aboba & Zorn                 Informational                     [Page 19]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


9.  Security Considerations

   In PPP-based tunneling, PPP security is negotiated between the client
   and the tunnel server, and covers the entire length of the path. This
   is because the client does not have a way to know that they are being
   tunneled. Thus, any security the NAS may negotiate with the tunnel
   server will occur in addition to that negotiated between the client
   and NAS.

   In L2TP compulsory tunneling, this means that PPP encryption and
   compression will be negotiated between the client and the tunnel
   server.  In addition, the NAS may bring up an IPSEC security
   association between itself and the tunnel server. This adds
   protection against a number of possible attacks.

   Where RADIUS proxies are deployed, the Access-Reply sent by the
   RADIUS server may be processed by one or more proxies prior to being
   received by the NAS.  In order to ensure that tunnel attributes
   arrive without modification, intermediate RADIUS proxies forwarding
   the Access-Reply MUST NOT modify tunnel attributes. If the RADIUS
   proxy does not support tunnel attributes, then it MUST send an
   Access-Reject to the NAS. This is necessary to ensure that the user
   is only granted access if the services requested by the RADIUS server
   can be provided.

   Since RADIUS tunnel attributes are used for compulsory tunneling,
   address assignment is handled by the tunnel server rather than the
   NAS.  As a result, if tunnel attributes are present, the NAS MUST
   ignore any address assignment attributes sent by the RADIUS server.
   In addition, the NAS and client MUST NOT begin NCP negotiation, since
   this could create a time window in which the client will be capable
   of sending packets to the transport network, which is not permitted
   in compulsory tunneling.

10.  Acknowledgements

   Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions
   of this problem space, and to Allan Rubens of Tut Systems and
   Bertrand Buclin of AT&T Labs Europe for their comments on this
   document.

   Most of the work on this document was performed while Glen Zorn was
   employed by the Microsoft Corporation.








Aboba & Zorn                 Informational                     [Page 20]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


11.  Chair's Address

   The RADIUS Working Group can be contacted via the current chair:

   Carl Rigney
   Livingston Enterprises
   4464 Willow Road
   Pleasanton, California  94588

   Phone: +1 510-426-0770
   EMail: cdr@livingston.com

12.  Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: +1 425-936-6605
   EMail: bernarda@microsoft.com


   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, WA 98004
   USA

   Phone: +1 425 438 8218
   FAX:   +1 425 438 1848
   EMail: gwz@cisco.com



















Aboba & Zorn                 Informational                     [Page 21]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


13.  Intellectual Property Statement

   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 BCP-11.  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.






























Aboba & Zorn                 Informational                     [Page 22]

RFC 2809          L2TP Compulsory Tunneling via RADIUS        April 2000


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Aboba & Zorn                 Informational                     [Page 23]