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]
|