idnits 2.17.1 draft-srisuresh-secure-ra-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 165 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 305 has weird spacing: '...nd gain acces...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2, 2000) is 8546 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Ref 1' on line 156 -- Looks like a reference, but probably isn't: 'Ref 2' on line 90 -- Looks like a reference, but probably isn't: 'Ref 5' on line 91 -- Looks like a reference, but probably isn't: 'Ref 8' on line 572 -- Looks like a reference, but probably isn't: 'Ref 3' on line 572 -- Looks like a reference, but probably isn't: 'Ref 4' on line 594 -- Looks like a reference, but probably isn't: '3-255' on line 715 -- Looks like a reference, but probably isn't: 'Ref 11' on line 716 == Unused Reference: '1' is defined on line 720, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 723, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 726, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 729, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 732, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 735, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 738, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 740, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 743, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 746, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 752, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 755, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '2') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2284 (ref. '4') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. '7') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (ref. '9') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (ref. '11') (Obsoleted by RFC 5226) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 P. Srisuresh 2 INTERNET-DRAFT Campio Communications 3 Category: Informational June 2000 4 Expires on December 2, 2000 6 Secure Remote Access with L2TP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may 15 also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 L2TP protocol is a virtual extension of PPP across IP network 32 infrastructure. L2TP makes possible for an access concentrator(LAC) 33 to be near remote clients, while allowing PPP termination server 34 (LNS) to be located in enterprise premises. L2TP allows an 35 enterprise to retain control of RADIUS data base, which is used 36 to control Authentication, Authorization and Accountability (AAA) 37 of dial-in users. The objective of this document is to extend 38 security characteristics of IPsec to remote access users, as they 39 dial-in through the Internet. This is accomplished without creating 40 new protocols and using the existing practices of Remote Access and 41 IPsec. Specifically, the document proposes three new RADIUS 42 parameters for use by the LNS node, acting as Secure Remote Access 43 Server (SRAS) to mandate network level security between remote 44 clients and the enterprise. The document also discusses limitations 45 of the approach. 47 1. Introduction and Overview 49 Now-a-days, it is common practice for employees to dial-in to their 50 enterprise over the PSTN (Public Switched Telephone Network) and 51 perform day-to-day operations just as they would if they were in 52 corporate premises. This includes people who dial-in from their home 53 and road warriors, who cannot be at the corporate premises. As the 54 Internet has become ubiquitous, it is appealing to dial-in through 55 the Internet to save on phone charges and save the dedicated voice 56 lines from being clogged with data traffic. 58 The document suggests an approach by which remote access over the 59 Internet could become a reality. The approach is founded on the 60 well-known techniques and protocols already in place. Remote Access 61 extensions based on L2TP, when combined with the security offered 62 by IPSec can make remote access over the Internet a reality. The 63 approach does not require inventing new protocol(s). 65 The trust model of remote access discussed in this document is 66 viewed principally from the perspective of an enterprise into which 67 remote access clients dial-in. A remote access client may or may not 68 want to enforce end-to-end IPsec from his/her end to the enterprise. 69 However, it is in the interest of the enterprise to mandate security 70 of every packet that it accepts from the Internet into the 71 enterprise. Independently, remote users may also pursue end-to-end 72 IPsec, if they choose to do so. That would be in addition to the 73 security requirement imposed by the enterprise edge device. 75 Section 2 has reference to the terminology used throughout the 76 document. Also mentioned are the limited scope in which some of these 77 terms may be used in this document. Section 3 has a brief description 78 of what constitutes remote access. Section 4 describes what 79 constitutes network security from an enterprise perspective. 80 Section 5 describes the model of secure remote access as a viable 81 solution to enterprises. The solution presented in section 5 has some 82 limitations. These limitations are listed in section 6. Section 7 is 83 devoted to describing new RADIUS attributes that may be configured to 84 turn a NAS device into Secure Remote Access Server. 86 2. Terminology and scope 88 Definition of terms used in this document may be found in one of 89 (a) L2TP Protocol document [Ref 1], (b) IP security Architecture 90 document [Ref 2], or (c) Internet Key Enchange (IKE) document 91 [Ref 5]. 93 Note, the terms Network Access Server (NAS) and Remote Access 94 Server(RAS) are used interchangeably throughout the document. 95 While PPP may be used to carry a variety of network layer 96 packets, the focus of this document is limited to carrying IP 97 datagrams only. 99 "Secure Remote Access Server" (SRAS) defined in this document 100 refers to a NAS that supports tunnel-mode IPsec with its remote 101 clients. Specifically, LNS is the NAS that is referred. Further, 102 involuntary tunneling is assumed for L2TP tunnel setup, in that 103 remote clients initiating PPP session and the LAC that tunnels 104 the PPP sessions are presumed to be distinct physical entities. 106 Lastly, there are a variety of transport mediums by which to 107 tunnel PPP packets between a LAC and LNS. Examples include 108 Frame Relay or ATM cloud and IP network infrastructure. For 109 simplicity, the document assumes a public IP infrastructure as 110 the medium to transport PPP packets between LAC and LNS. 111 Security of IP packets (embedded within PPP) in a trusted 112 private transport medium is less of a concern for the purposes 113 of this document. 115 3. Remote Access operation 117 Remote access is more than mere authentication of remote clients 118 by a Network Access Server(NAS). Authentication, Authorization, 119 Accounting and routing are integral to remote access. A client 120 must first pass the authentication test before being granted 121 link access to the network. Network level services (such as IP) 122 are granted based on the authorization characteristics 123 specificed for the user in RADIUS. Network Access Servers use 124 RADIUS to scale for large numbers of users supported. NAS also 125 monitors the link status of the remote access clients. 127 There are a variety of techniques by which remote access users 128 are connected to their enterprise and the Internet. At a link 129 level, the access techniques include ISDN digital lines, analog 130 plain-old-telephone-service lines, xDSL lines, cable and wireless 131 to name a few. PPP is the most common Layer-2 (L2)protocol used 132 for carrying network layer packets over these remote access 133 links. PPP may be used to carry a variety of network layer 134 datagrams including IP, IPX and AppleTalk. The focus of this 135 document is however limited to IP datagrams only. 137 L2TP is a logical extension of PPP over an IP infrastructure. 138 While a LAC provides termination of Layer 2 links, LNS provides 139 the logical termination of PPP. As a result, LNS becomes the 140 focal point for (a) performing the AAA operations for the remote 141 users, (b) assigning IP address and monitoring the logical 142 link status (i.e., the status of LAC-to-LNS tunnel and the link 143 between remote user and LAC), and (c) maintaining host-route to 144 remote user network and providing routing infrastructure into 145 the enterprise. 147 L2TP uses control messages to establish, terminate and monitor 148 the status of the logical PPP sessions (from remote user to LNS). 149 These are independent of the data messages. L2TP data messages 150 contain an L2TP header, followed by PPP packets. The L2TP header 151 identifies the PPP session (amongst other things) to which the 152 PPP packet belongs. The IP packets exchanged from/to the remote 153 user are carried within the PPP packets. The L2TP data messages, 154 carrying end-to-end IP packets in an IP transport medium may be 155 described as follows. The exact details of L2TP protocol may be 156 found in [Ref 1]. 158 +----------------------+ 159 | IP Header | 160 | (LAC <->LNS) | 161 +----------------------+ 162 | UDP Header | 163 +----------------------+ 164 | L2TP Header | 165 | (incl. PPP Sess-ID) | 166 +----------------------+ 167 | PPP Header | 168 | (Remote User<->LNS) | 169 +----------------------+ 170 | End-to-end IP packet | 171 | (to/from Remote User)| 172 +----------------------+ 174 4. Requirements of an enterprise Security Gateway 176 Today's enterprises are aware of the various benefits of 177 connecting to the Internet. Internet is a vast source of 178 Information and a means to disseminate information and make 179 available certain resources to the external world. However, 180 enterprises are also aware that security breaches (by being 181 connected to the Internet) can severely jeopardize internal 182 network. 184 As a result, most enterprises restrict access to a pre-defined 185 set of resources for external users. Typically, enterprises 186 employ a firewall to restrict access to internal resources and 187 place externally accessible servers in the DeMilitarized Zone 188 (DMZ), in front of the firewall, as described below in figure 1. 190 ---------------- 191 ( ) 192 ( ) 193 ( Internet ) 194 ( ) 195 (_______________ ) 197 WAN | 198 .........|\|.... 199 | 200 +-----------------+ 201 |Enterprise Router| 202 +-----------------+ 203 | 204 | DMZ - Network 205 --------------------------------- 206 | | | 207 +--+ +--+ +----------+ 208 |__| |__| | Firewall | 209 /____\ /____\ +----------+ 210 DMZ-Name DMZ-Web ... | 211 Server Server | 212 | 213 ------------------ 214 ( ) 215 ( Internal Network ) 216 ( (private to the ) 217 ( enterprise) ) 218 (_________________ ) 220 Figure 1: Security model of an Enterprise using Firewall 222 Network Access Servers used to allow direct dial-in access 223 (through the PSTN) to employees are placed within the private 224 enterprise network so as to avoid access restrictions imposed 225 by a firewall. 227 With the above model, private resources of an enterprise are 228 restricted for access from the Internet. Firewall may be 229 configured to occasionally permit access to a certain resource 230 or service but is not recommended on an operational basis as 231 that could constitute a security threat to the enterprise. 232 It is of interest to note that even when the firewall is 233 configured to permit access to internal resources from pre-defined 234 external node(s), many internal servers, such as NFS, enforce 235 address based authentication and do not co-operate when the IP 236 address of the external node is not in corporate IP address 237 domain. In other words, with the above security model, it becomes 238 very difficult to allow employees to access corporate resources, 239 via the Internet, even if you are willing to forego security 240 over the Internet. 242 With the advent of IPsec, it is possible to secure corporate 243 data across the Internet by employing a Security Gateway within 244 the enterprise. Firewall may be configured to allow IKE and 245 IPsec packets directed to a specific Security Gateway behind 246 the firewall. It then becomes the responsibility of the Security 247 Gateway to employ the right access list for external connections 248 seeking entry into the enterprise. Essentially, the access control 249 functionality for IPsec secure packets would be shifted to the 250 Security Gateway (while the access control for clear packets is 251 retained with the firewall). The following figure illustrates the 252 model where a combination of Firewall and Security Gateway control 253 access to internal resources. 255 ------------ 256 ( ) 257 ( ) 258 ( Internet ) 259 ( ) 260 (___________ ) 262 WAN | 263 .........|\|.... 264 | 265 +-----------------+ 266 |Enterprise Router| 267 +-----------------+ 268 | 269 | DMZ - Network 270 ------------------------------------------------------------ 271 | | | 272 +--+ +--+ +----------+ 273 |__| |__| | Firewall | 274 /____\ /____\ +----------+ 275 DMZ-Name DMZ-Web ... | 276 Server Server etc. | LAN 277 | 278 ------------------------------------ 279 | | 280 +----------+ +------------------+ 281 | LNS | | Security Gateway | 282 | Server | | (SGW) | 283 +----------+ +------------------+ 284 | 285 ------------------ 286 ( ) 287 ( Internal Network ) 288 ( (Private to the ) 289 ( enterprise) ) 290 (_________________ ) 292 Figure 2: Security Model based on Firewall and Security Gateway 294 In order to allow employee dial-in over the Internet, an LNS may 295 be placed behind a firewall, and the firewall may be configured to 296 allow UDP access to the LNS from the Internet. Note, it may not be 297 possible to know all the IP addresses of the LACs located on the 298 Internet at configuration time. Hence, the need to allow UDP access 299 from any node on the Internet. The LNS may be configured to process 300 only the L2TP packets and drop any UDP packets that are not L2TP. 302 Such a configuration allows remote access over the Internet. 303 However, the above setup is prone to a variety of security attacks 304 over the Internet. It is easy for someone on the Internet to steal 305 a remote access session and gain access to precious resources of 306 the enterprise. Hence it is important that all packets are 307 preserved with IPsec to a security Gateway (SGW) behind the LNS, 308 so the Security Gateway will not allow IP packets into corporate 309 network unless it can authenticate the same. 311 The trust model of secure remote access assumes that the enterprise 312 and the end user are trusted domains. Everything in between is not 313 trusted. Any examination of the end-to-end packets by the nodes 314 enroute would violate this trust model. From this perspective, even 315 the LAC node enroute must not be trusted with the end-to-end IP 316 packets. Hence, location and operation of LAC is not relevant for 317 the discussion on security. On the other hand, location and 318 operation of LNS and the Security Gateway (SGW) are precisely the 319 basis for discussion. 321 Having security processing done on an independent Security gateway 322 has the following shortcomings. 324 1. Given the trust model for remote access, the SGW must be 325 configured with a set of security profiles, access control lists 326 and IKE authentication parameters for each user. This mandates 327 an independent provisioning of security parameters on a per-user 328 basis. This may not be able to take advantage of the user-centric 329 provisioning on RADIUS, used by the LNS node. 331 2. Unlike the LNS, SGW may not be in the routing path of remote 332 access packets. I.e., there is no guarantee that the egress IP 333 packets wil go through the chain of SGW and LNS before they are 334 delivered to remote user. As a result, packets may be subject 335 to IPSec in one direction, but not in the other. This can be a 336 significant threat to the remote access trust model. 338 3. Lastly, the SGW node does not have a way to know when a remote 339 user node(s) simply died or the LAC-LNS tunnel failed. Being 340 unable to delete the SAs for users that no longer exist could 341 drain the resources of the SGW. Further, the LNS cannot even 342 communicate the user going away to the SGW because, the SGW 343 maintains its peer nodes based on IKE user ID, which could be 344 different the user IDs employed by the LNS node. 346 5. Secure Remote Access 348 Combining the functions of IPsec Security Gateway and LNS into 349 a single system promises to offer a viable solution for secure 350 remote access. By doing this, remote access clients will use a 351 single node as both (a) PPP termination point providing NAS 352 service, and (b) the Security gateway node into the enterprise. 353 We will refer this node as "Secure Remote Access Server" (SRAS). 355 The SRAS can benefit greatly from the confluence of PPP session 356 and IPsec tunnel end points. PPP session monitoring capability 357 of L2TP directly translates to being able to monitor IPsec tunnels. 358 Radius based user authorization ability could be used to configure 359 the security characteristics for IPsec tunnel. This includes setting 360 access control filters and security preferences specific to each 361 user. This may also be extended to configuring IKE authentication 362 and other negotiation parameters, when automated key exchange is 363 solicited. Security attributes that may be defined in Radius 364 are discussed in detail in section 7. Needless to say, the 365 centralized provisioning capability and scalability of Radius helps 366 in the configuration of IPsec. 368 As for remote access, the benefit is one of IPsec security as 369 befitting the trust model solicited by enterprises for the 370 end-to-end IP packets traversing the Internet. You may use simply AH 371 where there is no fear of external eaves-dropping, but you simply 372 need to authenticate packet data, including the source of packet. 373 You may use ESP (including ESP-authentication), where there is no 374 trust of the network and you donot want to permit eaves-dropping 375 on corporate activities. 377 Operation of SRAS requires that the firewall be configured to permit 378 UDP traffic into the SRAS node. The SRAS node in turn will process 379 just the L2TP packets and drop the rest. Further, the SRAS will 380 require all IP packets embedded within PPP to be one of AH and 381 ESP packets, directed to itself. In addition, the SRAS will also 382 permit IKE UDP packets (with source and destination ports sets 383 to 500) directed to itself in order to perform IKE negotiation 384 and generate IPsec keys dynamically. All other IP packets embedded 385 within PPP will be dropped. This enforces the security policy for 386 the enterprise by permitting only the secure remote access packets 387 into the enterprise. When a PPP session is dropped, the IPsec and 388 ISAKMP SAs associated with the remote access user are dropped from 389 the SRAS. All the shortcomings listed in the previous section with 390 LNS and SGW on two systems disappear withe Secure Remote Access 391 Server. Figure 3 below is a typical description of an enterprise 392 supporting remote access users using SRAS system. 394 ------------ 395 Remote Access +-------------+ ( ) 396 +--+______ Link | Local Access| ( ) 397 |__| /___________| Concentrator|----( Internet ) 398 /____\ | (LAC) | ( ) 399 RA-Host +-------------+ (____________) 401 WAN | 402 .........|\|.... 403 | 404 +-----------------+ 405 |Enterprise Router| 406 +-----------------+ 407 | 408 | DMZ - Network 409 ------------------------------------------ 410 | | | 411 +--+ +--+ +----------+ 412 |__| |__| | Firewall | 413 /____\ /____\ +----------+ 414 DMZ-Name DMZ-Web ... | 415 Server Server etc. | LAN 416 | 417 ------------------------------------ 418 | 419 +---------------+ 420 | Secure Remote | 421 | Access Server | 422 | (SRAS) | 423 +---------------+ 424 | 425 --------------------- 426 ( ) 427 +--+ ( Internal Network ) 428 |__|------( (Private to the ) 429 /____\ ( enterprise) ) 430 Ent-Host (______________________) 432 Figure 3: Secure Remote Access Server operation in an Enterprise 434 The following is an illustration of secure remote access data flow 435 as end-to-end IP packets traverse the Internet and the SRAS. The 436 example shows IP packet tunneling and IPsec transformation as 437 packets are exchanged between a remote Access host (RA-Host) and a 438 host within the enterprise (say, Ent-Host). 440 Note, the IP packets originating from or directed to RA-Host are 441 shown within PPP encapsulation, whereas, all other packets are shown 442 simply as IP packets. It is done this way to highlight the PPP 443 packets encapsulated within L2TP tunnel. The PPP headers below are 444 identified by their logical source and destination in parenthesis. 445 Note, however, the source and recipient information of the PPP data 446 is not a part of PPP header. This is described thus, just for 447 clarity. In the case of an L2TP tunnel, the L2TP header carries the 448 PPP session ID, which indirectly identifies the PPP end points to the 449 LAC and the LNS. Lastly, the IPsec Headers section below include the 450 tunneling overhead and the AH/ESP headers that are attached to the 451 tunnel. 453 RA-Host to Ent-Host Packet traversal: 454 ------------------------------------ 456 RA-Host LAC SRAS Ent-Host 457 ===================================================================== 459 +----------------------+ 460 | PPP Header | 461 | (RA-Host ->SRAS) | 462 +----------------------+ 463 | Tunnel-Mode IPsec | 464 | Hdr(s)(RA-Host->SRAS)| 465 +----------------------+ 466 | End-to-end IP packet | 467 | transformed as needed| 468 | (RA-Host->Ent-Host) | 469 +----------------------+ 470 ----------------------> 472 +----------------------+ 473 | IP Header | 474 | (LAC->SRAS) | 475 +----------------------+ 476 | UDP Header | 477 +----------------------+ 478 | L2TP Header | 479 | (incl. PPP Sess-ID) | 480 +----------------------+ 481 | PPP Header | 482 | (RA-Host ->SRAS) | 483 +----------------------+ 484 | Tunnel-Mode IPsec | 485 | Hdr(s)(RA-Host->SRAS)| 486 +----------------------+ 487 | End-to-end IP packet | 488 | transformed as needed| 489 | (RA-Host->Ent-Host) | 490 +----------------------+ 491 ----------------------> 493 +----------------------+ 494 | End-to-end IP packet | 495 | (RA-Host->Ent-Host) | 496 +----------------------+ 497 ----------------------> 498 Ent-Host to RA-Host Packet traversal: 499 ------------------------------------ 501 Ent-Host SRAS LAC RA-Host 502 ===================================================================== 504 +----------------------+ 505 | End-to-end IP packet | 506 | (Ent-Host->Ra-Host) | 507 +----------------------+ 508 ----------------------> 510 +----------------------+ 511 | IP Header | 512 | (SRAS->LAC) | 513 +----------------------+ 514 | UDP Header | 515 +----------------------+ 516 | L2TP Header | 517 | (incl. PPP Sess-ID) | 518 +----------------------+ 519 | PPP Header | 520 | (SRAS->RA-Host) | 521 +----------------------+ 522 | Tunnel-Mode IPsec | 523 | Hdr(s)(SRAS->RA-Host)| 524 +----------------------+ 525 | End-to-end IP packet | 526 | transformed as needed| 527 | (Ent-Host->RA-Host) | 528 +----------------------+ 529 ----------------------> 531 +----------------------+ 532 | PPP Header | 533 | (SRAS->RA-Host) | 534 +----------------------+ 535 | Tunnel-Mode IPsec | 536 | Hdr(s)(SRAS->RA-Host)| 537 +----------------------+ 538 | End-to-end IP packet | 539 | transformed as needed| 540 | (Ent-Host->RA-Host) | 541 +----------------------+ 542 ----------------------> 543 6. Limitations to Secure Remote Access using L2TP 545 The SRAS model described is not without its limitations. Below is 546 a list of the limitations. 548 1. Tunneling overhead: There is considerable tunneling overhead on 549 the end-to-end IP packet. Arguably, there is overlap of 550 information between tunneling headers. This overhead will 551 undercut packet throughput. 553 The overhead is particularly apparent at the LAC and SRAS nodes. 554 Specifically, the SRAS has the additional computational overhead 555 of IPsec processing on all IP packets exchanged with remote 556 users. This can be a significant bottleneck in the ability of 557 SRAS to scale for large numbers of remote users. 559 2. Fragmentation and reassembly: Large IP packets may be required to 560 undergo Fragmentation and reassembly at the LAC or the LNS as a 561 result of multiple tunnel overhead tagged to the packet. 562 Fragmentation and reassembly can havoc on packet throughput and 563 latency. However, it is possible to avoid the overhead by 564 reducing the MTU permitted within PPP frames. 566 3. Multiple identity and authentication requirement: Remote Access 567 users are required to authenticate themselves to the SRAS in 568 order to be obtain access to the link. Further, when they require 569 the use of IKE to automate IPsec key exchange, they will need to 570 authenticate once again with the same or different ID and 571 a distinct authentication approach. The authentication 572 requirements of IKE phase 1 [Ref 8] and LCP [Ref 3] are 573 different. 575 However, it is possible to have a single authentication approach 576 (i.e., a single ID and authentication mechanism) that can be 577 shared between LCP and IKE phase 1. The Extended Authentication 578 Protocol(EAP) [Ref 4] may be used as the base to transport IKE 579 authentication mechanism into PPP. Note, the configuration 580 overhead is not a drag on the functionality perse. 582 4. Weak security of Link level authentication: As LCP packets 583 traverse the Internet, the Identity of the remote user and the 584 password (if a password is used) is sent in the clear. This makes 585 it a target for someone on the net to steal the information and 586 masquerade as remote user. Note, however, this type of password 587 stealing will not jeopardize the security of the enterprise per 588 se, but could result in denial of service to remote users. An 589 intruder can collect the password data and simply steal the 590 link, but will not be able to run any IP applications 591 subsequently, as the SRAS will fail non-IPsec packet data. 593 A better approach would be to employ Extended Authentication 594 Protocol (EAP) [Ref 4] and select an authentication technique 595 that is not prone to stealing over the Internet. Alternately, 596 the LAC and the SRAS may be independently configured to use 597 IPsec to secure all LCP traffic exchanged between themselves. 599 7. Configuring RADIUS to support Secure Remote Access. 601 A centralized RADIUS database is used by enterprises to maintain 602 the authentication and authorization requirements of the dial-in 603 Users. It is also belived that direct dial-in access (e.g., through 604 the PSTN network is) safe and trusted and does not need any 605 scrutiny outside of the link level authentication enforced 606 in LCP. This belief is certainly not shared with the dial-in 607 access through the Internet. 609 So, while the same RADIUS database may be used for a user directly 610 dialing-in or dialing in through the Internet, the security 611 requirements may vary. The following RADIUS attributes may be 612 used to mandate IPsec for the users dialing-in through the Internet. 613 The exact values for the attributes and its values may be obtained 614 from IANA (refer Section 10). 616 7.1. Security mandate based on access method 618 A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each 619 user. This attribute may be given one of the following values. 621 NONE (= 0) No IPsec mandated on the IP packets 622 embedded within PPP. 624 LNS_AS_SRAS (=1) Mandates Tunnel mode IPsec on the IP 625 packets embedded within PPP, only so 626 long as the PPP session terminates 627 at an LNS. LNS would be the tunnel 628 mode IPsec end point. 630 SRAS (=2) Mandates Tunnel mode IPsec on the IP 631 packets embedded within PPP, 632 irrespective of the NAS type the PPP 633 terminates in. I.e., the IPsec mandate 634 is not specific to LNS alone, and is 635 applicable to any NAS, terminating 636 PPP. NAS would be the tunnel mode 637 IPsec end point. 639 When IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or SRAS, 640 that would direct the NAS to drop any IP packets in PPP that are not 641 associated with an AH or ESP protocol. As an exception, the NAS will 642 continue to process IKE packets (UDP packets, with source and 643 destination port set to 500) directed from remote users. Further, the 644 security profile parameter, defined in the following section may add 645 additional criteria for which security is not mandatory. 647 7.2. Security profile for the user 649 A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to 650 describe security access requirements for the users. The profile 651 could contain information such as the access control security 652 filters, security preferences and the nature of Keys (manual or 653 automatic generated via the IKE protocol) used for security 654 purposes. 656 The SECURITY-PROFILE attribute can be assigned a filename, as a 657 string of characters. The contents of the file could be vendor 658 specific. But, the contents should include (a) a prioritized 659 list access control security policies, (b) Security Association 660 security preferences associated with each security policy. 662 7.3. IKE negotiation profile for the user 664 If the security profile of a user requires dynamicic generation of 665 security keys, the parameters necessary for IKE negotiation may be 666 configured separately using a new IKE_NEGOTIATION_PROFILE (93) 667 parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be 668 assigned a filename, as a string of characters. The contents of 669 the file could however be vendor specific. The contents would 670 typically include (a) the IKE ID of the user and SRAS, 671 (b) preferred authentication approach and the associated 672 parameters, such as a pre-shared-key or a pointer to X.509 digital 673 Certificate, and, (c) ISAKMP security negotiation preferences for 674 phase I. 676 8. Acknowledgements 678 The author would like to express sincere thanks to Steve Willens 679 for initially suggesting this idea. The author is also thankful to 680 Steve for the many informal conversations which were instrumental 681 in the author being able to appreciate the diverse needs of the 682 Remote Access area. 684 9. Security Considerations 686 This document is about providing secure remote access to 687 enterprises via the Internet. However, the document does 688 not address security issues for network layers other than 689 IP. While the document focus is on security over the 690 Internet, the security model provided is not limited to the 691 Internet or the IP infrastructure alone. It may also be 692 applied over other transport media such as Frame Relay and 693 ATM clouds. If the transport media is a trusted private 694 network infrastructure, the security measures described may 695 not be as much of an issue. The solution suggested in the 696 document is keeping in view the trust model between a 697 remote user and enterprise. 699 10. IANA Considerations 701 This document proposes a total of three new RADIUS attributes to 702 be maintained by the IANA. These attributes IPSEC_MANDATE, 703 SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE may be assigned 704 the values 91, 92 and 93 respectively so as not to conflict with 705 the defintions for recognized radius types, as defined in 706 http://www.isi.edu/in-notes/iana/assignments/radius-types. 708 The following sub-section explains the criteria to be used by 709 the IANA to assign additional numbers as values to the 710 IPSEC-MANDATE attribute described in section 7.1. 712 10.1. IPSEC-MANDATE attribute Value 714 Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in 715 Section 7.1; the remaining values [3-255] are available for 716 assignment by the IANA with IETF Consensus [Ref 11]. 718 REFERENCES 720 [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 721 Palter, B. "Layer Two Tunneling Protocol L2TP", RFC 2661 723 [2] Rigney, C., Rubens, A., Simpson, W. and Willens, S. 724 "Remote Authentication Dial In User Service (RADIUS)", RFC2138 726 [3] Simpson, W. "The Point-to-Point Protocol (PPP)", STD 51, 727 RFC 1661 729 [4] Blunk, L., and Vollbrecht, J. "PPP Extensible Authentication 730 Protocol (EAP)", RFC 2284 732 [5] S. Kent, R. Atkinson, "Security Architecture for the Internet 733 Protocol", RFC 2401 735 [6] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 736 (ESP)", RFC 2406 738 [7] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 740 [8] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 741 RFC 2409 743 [9] D. Piper, "The Internet IP Security Domain of Interpretation 744 for ISAKMP", RFC 2407 746 [10] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700. 747 See also http://www.iana.org/numbers.html 749 [11] Narten, T., Alvestrand, H., "Guidelines for writing an IANA 750 Considerations Section in RFCs", BCP 26, RFC 2434. 752 [12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", 753 RFC 1968 755 [13] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 756 Version 2(DESE-bis)", RFC 2419 758 Author's Address: 760 Pyda Srisuresh 761 Campio Communications 762 630 Alder Drive 763 Milpitas, CA 95035 764 U.S.A. 766 Voice: +1 (408) 519-3849 767 EMail: srisuresh@yahoo.com