idnits 2.17.1 draft-ietf-pppext-secure-ra-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 49 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 302 has weird spacing: '...nd gain acces...' == Line 637 has weird spacing: '... When the IP...' -- 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 (September 1999) is 8989 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Ref 1' on line 153 -- 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 571 -- Looks like a reference, but probably isn't: 'Ref 3' on line 571 -- Looks like a reference, but probably isn't: 'Ref 4' on line 593 -- Looks like a reference, but probably isn't: '3-255' on line 714 -- Looks like a reference, but probably isn't: 'Ref 11' on line 715 == Unused Reference: '1' is defined on line 719, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 722, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 725, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 728, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 731, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 734, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 737, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 739, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 742, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 745, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 748, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 751, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 754, 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: 15 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPPEXT Working Group P. Srisuresh 2 INTERNET-DRAFT Consultant 3 Category: Proposed Standard September 1999 4 Expire in six months 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. 103 Lastly, there are a variety of transport mediums by which to 104 tunnel PPP packets between a LAC and LNS. Examples include 105 Frame Relay or ATM cloud and IP network infrastructure. For 106 simplicity, the document assumes a public IP infrastructure as 107 the medium to transport PPP packets between LAC and LNS. 108 Security of IP packets (embedded within PPP) in a trusted 109 private transport medium is less of a concern for the purposes 110 of this document. 112 3. Remote Access operation 114 Remote access is more than mere authentication of remote clients 115 by a Network Access Server(NAS). Authentication, Authorization, 116 Accounting and routing are integral to remote access. A client 117 must first pass the authentication test before being granted 118 link access to the network. Network level services (such as IP) 119 are granted based on the authorization characteristics 120 specificed for the user in RADIUS. Network Access Servers use 121 RADIUS to scale for large numbers of users supported. NAS also 122 monitors the link status of the remote access clients. 124 There are a variety of techniques by which remote access users 125 are connected to their enterprise and the Internet. At a link 126 level, the access techniques include ISDN digital lines, analog 127 plain-old-telephone-service lines, xDSL lines, cable and wireless 128 to name a few. PPP is the most common Layer-2 (L2)protocol used 129 for carrying network layer packets over these remote access 130 links. PPP may be used to carry a variety of network layer 131 datagrams including IP, IPX and AppleTalk. The focus of this 132 document is however limited to IP datagrams only. 134 L2TP is a logical extension of PPP over an IP infrastructure. 135 While a LAC provides termination of Layer 2 links, LNS provides 136 the logical termination of PPP. As a result, LNS becomes the 137 focal point for (a) performing the AAA operations for the remote 138 users, (b) assigning IP address and monitoring the logical 139 link status (i.e., the status of LAC-to-LNS tunnel and the link 140 between remote user and LAC), and (c) maintaining host-route to 141 remote user network and providing routing infrastructure into 142 the enterprise. 144 L2TP uses control messages to establish, terminate and monitor 145 the status of the logical PPP sessions (from remote user to LNS). 146 These are independent of the data messages. L2TP data messages 147 contain an L2TP header, followed by PPP packets. The L2TP header 148 identifies the PPP session (amongst other things) to which the 149 PPP packet belongs. The IP packets exchanged from/to the remote 150 user are carried within the PPP packets. The L2TP data messages, 151 carrying end-to-end IP packets in an IP transport medium may be 152 described as follows. The exact details of L2TP protocol may be 153 found in [Ref 1]. 155 +----------------------+ 156 | IP Header | 157 | (LAC <->LNS) | 158 +----------------------+ 159 | UDP Header | 160 +----------------------+ 161 | L2TP Header | 162 | (incl. PPP Sess-ID) | 163 +----------------------+ 164 | PPP Header | 165 | (Remote User<->LNS) | 166 +----------------------+ 167 | End-to-end IP packet | 168 | (to/from Remote User)| 169 +----------------------+ 171 4. Requirements of an enterprise Security Gateway 173 Today's enterprises are aware of the various benefits of 174 connecting to the Internet. Internet is a vast source of 175 Information and a means to disseminate information and make 176 available certain resources to the external world. However, 177 enterprises are also aware that security breaches (by being 178 connected to the Internet) can severely jeopardize internal 179 network. 181 As a result, most enterprises restrict access to a pre-defined 182 set of resources for external users. Typically, enterprises 183 employ a firewall to restrict access to internal resources and 184 place externally accessible servers in the DeMilitarized Zone 185 (DMZ), in front of the firewall, as described below in figure 1. 187 ---------------- 188 ( ) 189 ( ) 190 ( Internet ) 191 ( ) 192 (_______________ ) 194 WAN | 195 .........|\|.... 196 | 197 +-----------------+ 198 |Enterprise Router| 199 +-----------------+ 200 | 201 | DMZ - Network 202 --------------------------------- 203 | | | 204 +--+ +--+ +----------+ 205 |__| |__| | Firewall | 206 /____\ /____\ +----------+ 207 DMZ-Name DMZ-Web ... | 208 Server Server | 209 | 210 ------------------ 211 ( ) 212 ( Internal Network ) 213 ( (private to the ) 214 ( enterprise) ) 215 (_________________ ) 217 Figure 1: Security model of an Enterprise using Firewall 219 Network Access Servers used to allow direct dial-in access 220 (through the PSTN) to employees are placed within the private 221 enterprise network so as to avoid access restrictions imposed 222 by a firewall. 224 With the above model, private resources of an enterprise are 225 restricted for access from the Internet. Firewall may be 226 configured to occasionally permit access to a certain resource 227 or service but is not recommended on an operational basis as 228 that could constitute a security threat to the enterprise. 229 It is of interest to note that even when the firewall is 230 configured to permit access to internal resources from pre-defined 231 external node(s), many internal servers, such as NFS, enforce 232 address based authentication and do not co-operate when the IP 233 address of the external node is not in corporate IP address 234 domain. In other words, with the above security model, it becomes 235 very difficult to allow employees to access corporate resources, 236 via the Internet, even if you are willing to forego security 237 over the Internet. 239 With the advent of IPsec, it is possible to secure corporate 240 data across the Internet by employing a Security Gateway within 241 the enterprise. Firewall may be configured to allow IKE and 242 IPsec packets directed to a specific Security Gateway behind 243 the firewall. It then becomes the responsibility of the Security 244 Gateway to employ the right access list for external connections 245 seeking entry into the enterprise. Essentially, the access control 246 functionality for IPsec secure packets would be shifted to the 247 Security Gateway (while the access control for clear packets is 248 retained with the firewall). The following figure illustrates the 249 model where a combination of Firewall and Security Gateway control 250 access to internal resources. 252 ------------ 253 ( ) 254 ( ) 255 ( Internet ) 256 ( ) 257 (___________ ) 259 WAN | 260 .........|\|.... 261 | 262 +-----------------+ 263 |Enterprise Router| 264 +-----------------+ 265 | 266 | DMZ - Network 267 ------------------------------------------------------------ 268 | | | 269 +--+ +--+ +----------+ 270 |__| |__| | Firewall | 271 /____\ /____\ +----------+ 272 DMZ-Name DMZ-Web ... | 273 Server Server etc. | LAN 274 | 275 ------------------------------------ 276 | | 277 +----------+ +------------------+ 278 | LNS | | Security Gateway | 279 | Server | | (SGW) | 280 +----------+ +------------------+ 281 | 282 ------------------ 283 ( ) 284 ( Internal Network ) 285 ( (Private to the ) 286 ( enterprise) ) 287 (_________________ ) 289 Figure 2: Security Model based on Firewall and Security Gateway 291 In order to allow employee dial-in over the Internet, an LNS may 292 be placed behind a firewall, and the firewall may be configured to 293 allow UDP access to the LNS from the Internet. Note, it may not be 294 possible to know all the IP addresses of the LACs located on the 295 Internet at configuration time. Hence, the need to allow UDP access 296 from any node on the Internet. The LNS may be configured to process 297 only the L2TP packets and drop any UDP packets that are not L2TP. 299 Such a configuration allows remote access over the Internet. 300 However, the above setup is prone to a variety of security attacks 301 over the Internet. It is easy for someone on the Internet to steal 302 a remote access session and gain access to precious resources of 303 the enterprise. Hence it is important that all packets are 304 preserved with IPsec to a security Gateway (SGW) behind the LNS, 305 so the Security Gateway will not allow IP packets into corporate 306 network unless it can authenticate the same. 308 The trust model of secure remote access assumes that the enterprise 309 and the end user are trusted domains. Everything in between is not 310 trusted. Any examination of the end-to-end packets by the nodes 311 enroute would violate this trust model. From this perspective, even 312 the LAC node enroute must not be trusted with the end-to-end IP 313 packets. Hence, location and operation of LAC is not relevant for 314 the discussion on security. On the other hand, location and 315 operation of LNS and the Security Gateway (SGW) are precisely the 316 basis for discussion. 318 Having security processing done on an independent Security gateway 319 has the following shortcomings. 321 1. Given the trust model for remote access, the SGW must be 322 configured with a set of security profiles, access control lists 323 and IKE authentication parameters for each user. This mandates 324 an independent provisioning of security parameters on a per-user 325 basis. This may not be able to take advantage of the user-centric 326 provisioning on RADIUS, used by the LNS node. 328 2. Unlike the LNS, SGW may not be in the routing path of remote 329 access packets. I.e., there is no guarantee that the egress IP 330 packets wil go through the chain of SGW and LNS before they are 331 delivered to remote user. As a result, packets may be subject 332 to IPSec in one direction, but not in the other. This can be a 333 significant threat to the remote access trust model. 335 3. Lastly, the SGW node does not have a way to know when a remote 336 user node(s) simply died or the LAC-LNS tunnel failed. Being 337 unable to delete the SAs for users that no longer exist could 338 drain the resources of the SGW. Further, the LNS cannot even 339 communicate the user going away to the SGW because, the SGW 340 maintains its peer nodes based on IKE user ID, which could be 341 different the user IDs employed by the LNS node. 343 5. Secure Remote Access 345 Combining the functions of IPsec Security Gateway and LNS into 346 a single system promises to offer a viable solution for secure 347 remote access. By doing this, remote access clients will use a 348 single node as both (a) PPP termination point providing NAS 349 service, and (b) the Security gateway node into the enterprise. 350 We will refer this node as "Secure Remote Access Server" (SRAS). 352 The SRAS can benefit greatly from the confluence of PPP session 353 and IPsec tunnel end points. PPP session monitoring capability 354 of L2TP directly translates to being able to monitor IPsec tunnels. 355 Radius based user authorization ability could be used to configure 356 the security characteristics for IPsec tunnel. This includes setting 357 access control filters and security preferences specific to each 358 user. This may also be extended to configuring IKE authentication 359 and other negotiation parameters, when automated key exchange is 360 solicited. Security attributes that may be defined in Radius 361 are discussed in detail in section 7. Needless to say, the 362 centralized provisioning capability and scalability of Radius helps 363 in the configuration of IPsec. 365 As for remote access, the benefit is one of IPsec security as 366 befitting the trust model solicited by enterprises for the 367 end-to-end IP packets traversing the Internet. You may use simply AH 368 where there is no fear of external eaves-dropping, but you simply 369 need to authenticate packet data, including the source of packet. 370 You may use ESP (including ESP-authentication), where there is no 371 trust of the network and you donot want to permit eaves-dropping 372 on corporate activities. 374 Operation of SRAS requires that the firewall be configured to permit 375 UDP traffic into the SRAS node. The SRAS node in turn will process 376 just the L2TP packets and drop the rest. Further, the SRAS will 377 require all IP packets embedded within PPP to be one of AH and 378 ESP packets, directed to itself. In addition, the SRAS will also 379 permit IKE UDP packets (with source and destination ports sets 380 to 500) directed to itself in order to perform IKE negotiation 381 and generate IPsec keys dynamically. All other IP packets embedded 382 within PPP will be dropped. This enforces the security policy for 383 the enterprise by permitting only the secure remote access packets 384 into the enterprise. When a PPP session is dropped, the IPsec and 385 ISAKMP SAs associated with the remote access user are dropped from 386 the SRAS. All the shortcomings listed in the previous section with 387 LNS and SGW on two systems disappear withe Secure Remote Access 388 Server. Figure 3 below is a typical description of an enterprise 389 supporting remote access users using SRAS system. 391 ------------ 392 Remote Access +-------------+ ( ) 393 +--+______ Link | Local Access| ( ) 394 |__| /___________| Concentrator|----( Internet ) 395 /____\ | (LAC) | ( ) 396 RA-Host +-------------+ (____________) 398 WAN | 399 .........|\|.... 400 | 401 +-----------------+ 402 |Enterprise Router| 403 +-----------------+ 404 | 405 | DMZ - Network 406 ------------------------------------------ 407 | | | 408 +--+ +--+ +----------+ 409 |__| |__| | Firewall | 410 /____\ /____\ +----------+ 411 DMZ-Name DMZ-Web ... | 412 Server Server etc. | LAN 413 | 414 ------------------------------------ 415 | 416 +---------------+ 417 | Secure Remote | 418 | Access Server | 419 | (SRAS) | 420 +---------------+ 421 | 422 --------------------- 423 ( ) 424 +--+ ( Internal Network ) 425 |__|------( (Private to the ) 426 /____\ ( enterprise) ) 427 Ent-Host (______________________) 429 Figure 3: Secure Remote Access Server operation in an Enterprise 431 The following is an illustration of secure remote access data flow 432 as end-to-end IP packets traverse the Internet and the SRAS. The 433 example shows IP packet tunneling and IPsec transformation as 434 packets are exchanged between a remote Access host (RA-Host) and a 435 host within the enterprise (say, Ent-Host). 437 Note, the IP packets originating from or directed to RA-Host are 438 shown within PPP encapsulation, whereas, all other packets are shown 439 simply as IP packets. It is done this way to highlight the PPP 440 packets encapsulated within L2TP tunnel. The PPP headers below are 441 identified by their logical source and destination in parenthesis. 442 Note, however, the source and recipient information of the PPP data 443 is not a part of PPP header. This is described thus, just for 444 clarity. In the case of an L2TP tunnel, the L2TP header carries the 445 PPP session ID, which indirectly identifies the PPP end points to the 446 LAC and the LNS. Lastly, the IPsec Headers section below include the 447 tunneling overhead and the AH/ESP headers that are attached to the 448 tunnel. 450 RA-Host to Ent-Host Packet traversal: 451 ------------------------------------ 453 RA-Host LAC SRAS Ent-Host 454 ===================================================================== 456 +----------------------+ 457 | PPP Header | 458 | (RA-Host ->SRAS) | 459 +----------------------+ 460 | Tunnel-Mode IPsec | 461 | Hdr(s)(RA-Host->SRAS)| 462 +----------------------+ 463 | End-to-end IP packet | 464 | transformed as needed| 465 | (RA-Host->Ent-Host) | 466 +----------------------+ 467 ----------------------> 469 +----------------------+ 470 | IP Header | 471 | (LAC->SRAS) | 472 +----------------------+ 473 | UDP Header | 474 +----------------------+ 475 | L2TP Header | 476 | (incl. PPP Sess-ID) | 477 +----------------------+ 478 | PPP Header | 479 | (RA-Host ->SRAS) | 480 +----------------------+ 481 | Tunnel-Mode IPsec | 482 | Hdr(s)(RA-Host->SRAS)| 483 +----------------------+ 484 | End-to-end IP packet | 485 | transformed as needed| 486 | (RA-Host->Ent-Host) | 487 +----------------------+ 488 ----------------------> 490 +----------------------+ 491 | End-to-end IP packet | 492 | (RA-Host->Ent-Host) | 493 +----------------------+ 494 ----------------------> 496 Ent-Host to RA-Host Packet traversal: 497 ------------------------------------ 499 Ent-Host SRAS LAC RA-Host 500 ===================================================================== 502 +----------------------+ 503 | End-to-end IP packet | 504 | (Ent-Host->Ra-Host) | 505 +----------------------+ 506 ----------------------> 508 +----------------------+ 509 | IP Header | 510 | (SRAS->LAC) | 511 +----------------------+ 512 | UDP Header | 513 +----------------------+ 514 | L2TP Header | 515 | (incl. PPP Sess-ID) | 516 +----------------------+ 517 | PPP Header | 518 | (SRAS->RA-Host) | 519 +----------------------+ 520 | Tunnel-Mode IPsec | 521 | Hdr(s)(SRAS->RA-Host)| 522 +----------------------+ 523 | End-to-end IP packet | 524 | transformed as needed| 525 | (Ent-Host->RA-Host) | 526 +----------------------+ 527 ----------------------> 529 +----------------------+ 530 | PPP Header | 531 | (SRAS->RA-Host) | 532 +----------------------+ 533 | Tunnel-Mode IPsec | 534 | Hdr(s)(SRAS->RA-Host)| 535 +----------------------+ 536 | End-to-end IP packet | 537 | transformed as needed| 538 | (Ent-Host->RA-Host) | 539 +----------------------+ 540 ----------------------> 542 6. Limitations to Secure Remote Access using L2TP 544 The SRAS model described is not without its limitations. Below is 545 a list of the limitations. 547 1. Tunneling overhead: There is considerable tunneling overhead on 548 the end-to-end IP packet. Arguably, there is overlap of 549 information between tunneling headers. This overhead will 550 undercut packet throughput. 552 The overhead is particularly apparent at the LAC and SRAS nodes. 553 Specifically, the SRAS has the additional computational overhead 554 of IPsec processing on all IP packets exchanged with remote 555 users. This can be a significant bottleneck in the ability of 556 SRAS to scale for large numbers of remote users. 558 2. Fragmentation and reassembly: Large IP packets may be required to 559 undergo Fragmentation and reassembly at the LAC or the LNS as a 560 result of multiple tunnel overhead tagged to the packet. 561 Fragmentation and reassembly can havoc on packet throughput and 562 latency. However, it is possible to avoid the overhead by 563 reducing the MTU permitted within PPP frames. 565 3. Multiple identity and authentication requirement: Remote Access 566 users are required to authenticate themselves to the SRAS in 567 order to be obtain access to the link. Further, when they require 568 the use of IKE to automate IPsec key exchange, they will need to 569 authenticate once again with the same or different ID and 570 a distinct authentication approach. The authentication 571 requirements of IKE phase 1 [Ref 8] and LCP [Ref 3] are 572 different. 574 However, it is possible to have a single authentication approach 575 (i.e., a single ID and authentication mechanism) that can be 576 shared between LCP and IKE phase 1. The Extended Authentication 577 Protocol(EAP) [Ref 4] may be used as the base to transport IKE 578 authentication mechanism into PPP. Note, the configuration 579 overhead is not a drag on the functionality perse. 581 4. Weak security of Link level authentication: As LCP packets 582 traverse the Internet, the Identity of the remote user and the 583 password (if a password is used) is sent in the clear. This makes 584 it a target for someone on the net to steal the information and 585 masquerade as remote user. Note, however, this type of password 586 stealing will not jeopardize the security of the enterprise per 587 se, but could result in denial of service to remote users. An 588 intruder can collect the password data and simply steal the 589 link, but will not be able to run any IP applications 590 subsequently, as the SRAS will fail non-IPsec packet data. 592 A better approach would be to employ Extended Authentication 593 Protocol (EAP) [Ref 4] and select an authentication technique 594 that is not prone to stealing over the Internet. Alternately, 595 the LAC and the SRAS may be independently configured to use 596 IPsec to secure all LCP traffic exchanged between themselves. 598 7. Configuring RADIUS to support Secure Remote Access. 600 A centralized RADIUS database is used by enterprises to maintain 601 the authentication and authorization requirements of the dial-in 602 Users. It is also belived that direct dial-in access (e.g., through 603 the PSTN network is) safe and trusted and does not need any 604 scrutiny outside of the link level authentication enforced 605 in LCP. This belief is certainly not shared with the dial-in 606 access through the Internet. 608 So, while the same RADIUS database may be used for a user directly 609 dialing-in or dialing in through the Internet, the security 610 requirements may vary. The following RADIUS attributes may be 611 used to mandate IPsec for the users dialing-in through the Internet. 612 The exact values for the attributes and its values may be obtained 613 from IANA (refer Section 10). 615 7.1. Security mandate based on access method 617 A new RADIUS attribute IPSEC_MANDATE (91) may be defined for each 618 user. This attribute may be given one of the following values. 620 NONE (= 0) implying no IPsec mandate on the 621 end-to-end IP packets embedded 622 within PPP. 624 LNS_AS_SRAS (=1) implying IPsec mandate on the 625 end-to-end IPsec packets embedded 626 within PPP. However, this mandate is 627 only for an LNS node and the LNS must 628 be the end point for the IPsec packets. 630 SRAS (=2) implying IPsec mandate only on the 631 end-to-end IPsec packets embedded 632 within PPP. This mandate is applicable 633 to any NAS node (not specific to an LNS). 634 The NAS node must be the end point for 635 the IPsec packets. 637 When the IPSEC_MANDATE attribute is set to one of LNS_AS_SRAS or 638 simply SRAS, that would direct the NAS to drop any IP packets in the 639 PPP that are not associated with an AH or ESP protocol. As an 640 exception, the NAS will continue to process IKE packets (UDP packets, 641 with source and destination port set to 500) directed from remote 642 users. Further, the security profile parameter, defined in the 643 following section may add additional criteria for which security 644 is not mandatory. 646 7.2. Security profile for the user 648 A new SECURITY_PROFILE (92) parameter may be defined in RADIUS to 649 describe security access requirements for the users. The profile 650 could contain information such as the access control security 651 filters, security preferences and the nature of Keys (manual or 652 automatic generated via the IKE protocol) used for security 653 purposes. 655 The SECURITY-PROFILE attribute can be assigned a filename, as a 656 string of characters. The contents of the file could be vendor 657 specific. But, the contents should include (a) a prioritized 658 list access control security policies, (b) Security Association 659 security preferences associated with each security policy. 661 7.3. IKE negotiation profile for the user 663 If the security profile of a user requires dynamicic generation of 664 security keys, the parameters necessary for IKE negotiation may be 665 configured separately using a new IKE_NEGOTIATION_PROFILE (93) 666 parameter in RADIUS. IKE-NEGOTIATION_PROFILE attribute may be 667 assigned a filename, as a string of characters. The contents of 668 the file could however be vendor specific. The contents would 669 typically include (a) the IKE ID of the user and SRAS, 670 (b) preferred authentication approach and the associated 671 parameters, such as a pre-shared-key or a pointer to X.509 digital 672 Certificate, and, (c) ISAKMP security negotiation preferences for 673 phase I. 675 8. Acknowledgements 677 The author would like to express sincere thanks to Steve Willens 678 for initially suggesting this idea. The author is also thankful to 679 Steve for the many informal conversations which were instrumental 680 in the author being able to appreciate the diverse needs of the 681 Remote Access area. 683 9. Security Considerations 685 This document is about providing secure remote access to 686 enterprises via the Internet. However, the document does 687 not address security issues for network layers other than 688 IP. While the document focus is on security over the 689 Internet, the security model provided is not limited to the 690 Internet or the IP infrastructure alone. It may also be 691 applied over other transport media such as Frame Relay and 692 ATM clouds. If the transport media is a trusted private 693 network infrastructure, the security measures described may 694 not be as much of an issue. The solution suggested in the 695 document is keeping in view the trust model between a 696 remote user and enterprise. 698 10. IANA Considerations 700 This document proposes a total of three new RADIUS attributes to 701 be maintained by the IANA. These attributes IPSEC_MANDATE, 702 SECURITY_PROFILE and IKE_NEGOTIATION_PROFILE may be assigned 703 the values 91, 92 and 93 respectively so as not to conflict with 704 the defintions for recognized radius types, as defined in 705 http://www.isi.edu/in-notes/iana/assignments/radius-types. 707 The following sub-section explains the criteria to be used by 708 the IANA to assign additional numbers as values to the 709 IPSEC-MANDATE attribute described in section 7.1. 711 10.1. IPSEC-MANDATE attribute Value 713 Values 0-2 of the IPSEC-MANDATE-Type Attribute are defined in 714 Section 7.1; the remaining values [3-255] are available for 715 assignment by the IANA with IETF Consensus [Ref 11]. 717 REFERENCES 719 [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 720 Palter, B. "Layer Two Tunneling Protocol L2TP", RFC 2661 722 [2] Rigney, C., Rubens, A., Simpson, W. and Willens, S. 723 "Remote Authentication Dial In User Service (RADIUS)", RFC2138 725 [3] Simpson, W. "The Point-to-Point Protocol (PPP)", STD 51, 726 RFC 1661 728 [4] Blunk, L., and Vollbrecht, J. "PPP Extensible Authentication 729 Protocol (EAP)", RFC 2284 731 [5] S. Kent, R. Atkinson, "Security Architecture for the Internet 732 Protocol", RFC 2401 734 [6] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 735 (ESP)", RFC 2406 737 [7] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 739 [8] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 740 RFC 2409 742 [9] D. Piper, "The Internet IP Security Domain of Interpretation 743 for ISAKMP", RFC 2407 745 [10] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700. 746 See also http://www.iana.org/numbers.html 748 [11] Narten, T., Alvestrand, H., "Guidelines for writing an IANA 749 Considerations Section in RFCs", BCP 26, RFC 2434. 751 [12] Meyer, G., "The PPP Encryption Control Protocol (ECP)", 752 RFC 1968 754 [13] Sklower, K., Meyer, G., "The PPP DES Encryption Protocol, 755 Version 2(DESE-bis)", RFC 2419 757 Author's Address: 759 Pyda Srisuresh 760 849 Erie Circle 761 Pleasanton, CA 95035 762 U.S.A. 764 Voice: +1 (408) 263-7527 765 EMail: srisuresh@yahoo.com