idnits 2.17.1 draft-ietf-pppext-mppp-01.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 201: '...tunnel setup, the LNS MUST include the...' RFC 2119 keyword, line 203: '... new LAC MUST NOT attempt to use the...' RFC 2119 keyword, line 210: '...mobility feature MUST interpret a ICRQ...' RFC 2119 keyword, line 215: '...call handover, the LNS MUST send a CDN...' RFC 2119 keyword, line 217: '... MUST send a Call Disconnect Notify ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 1999) is 9081 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) -- No information found for draft-ietf-pppext-l2tp-116 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-05) exists of draft-ietf-pppext-l2tp-security-01 -- Possible downref: Normative reference to a draft: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group M. Chuah 2 Internet Draft G. Rai 3 Expires December 1999 J. Teplitsky 4 Lucent Technologies Bell Laboratories 5 D. Grosser 6 IBM Corporation 7 June 1999 9 Mobile PPP 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 This document is the product of the Point-to-Point Protocol 31 Extensions Working Group of the Internet Engineering Task Force 32 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 33 mailing list. 35 Distribution of this memo is unlimited. 37 Abstract 39 This document describes a new feature for L2TP: it allows for a 40 change of LACs during the lifetime of a PPP session without the 41 latency of re-creating a new PPP session where possible. This feature 42 is especially useful for wireless data services where the foreign 43 wireless service provider (WSP) may be different than the user's home 44 service provider and where a user's mobility may result in a change 45 of LAC during an on-going PPP session. This proposal presents 2 46 different methods of supporting this feature. The simplest method 47 requires only minor changes to both LACs and LNSs and yields a larger 48 handover latency. The other method has shorter handover latency and 49 allows the L2TP session to be extended by an additional hop. 51 This document is the product of the Point-to-Point Protocol Working 52 Group of the Internet Engineering Task Force (IETF). Comments should 53 be submitted to the ietf-ppp@merit.edu mailing list. 55 Applicability 57 These extensions are intended for those implementations which desire 58 to use the mobile feature of L2TP. 60 Table of Contents 62 1. Introduction ............................................... 4 63 1.1. Limitations of L2TP for wireless services ................ 5 64 2. Overview of Mobile PPP ..................................... 5 65 2.1. Simple AVP Approach (SAA) ................................ 5 66 2.2. Independent Tunnel Approach (ITA) ........................ 7 67 3. Service Model Issues ....................................... 10 68 3.1. Authentication ........................................... 10 69 3.2. Accounting ............................................... 10 70 4. Control Message Processing ................................. 11 71 4.1. Newly Defined Control Message and AVPs ................... 11 72 4.1.1. Authentication Request (Auth_REQ) ...................... 11 73 4.1.2. Newly Defined AVPs ..................................... 11 74 4.1.2.1. Mobile AVP ........................................... 12 75 4.1.2.2. User's AVP ........................................... 12 76 5. Security Issues ............................................ 13 77 6. Legal Issues ............................................... 13 78 7. Acknowledgements ........................................... 14 79 8. Contacts ................................................... 14 80 9. References ................................................. 15 82 1. Introduction 84 Serving PPP 85 IWF Server 86 -- -- --------- 87 MN <---> | | <------->| | <----> R ( Internet) 88 -- -- --------- 89 MN: Mobile Node 90 R: Router 91 IWF: Interworking Function 93 Figure 1: Typical wide area wireless access network architecture 95 Figure 1 shows the architecture of a typical wide area wireless 96 access network like CDMA, GSM, or TDMA. Current wireless standards 97 allow mobile nodes (MN) to dial up a PPP server to access the inter- 98 net. A link level tunnel is created between the serving IWF and the 99 PPP server. If the mobile node moves to another serving IWF, link- 100 layer messages are exchanged so that the tunnel between the old serv- 101 ing IWF and the PPP server is torn down and a new one set up between 102 a new serving IWF and the PPP server. If the mobile node moves 103 further such that it has to change the PPP server, then current wire- 104 less standards force a termination of the PPP session. A new PPP ses- 105 sion has to be negotiated between the mobile node and the new PPP 106 server. In addition, current wireless standards do not provide vir- 107 tual private networking services to mobile nodes. 109 In current wireless architectures, the PPP server authenticates 110 mobile nodes using the negotiated PPP authentication protocol e.g. 111 CHAP. Since it is not aware of mobile node handovers in the wireless 112 network, it does not perform any authentication when a mobile node 113 changes its serving IWF. 115 In this document, we propose a mobile feature to the current IETF 116 L2TP protocol to provide wide area mobility to nodes without having 117 to renegotiate the PPP session during a handover. According to this 118 proposal, mobile nodes need only implement the TCP/IP/PPP stack with 119 no modifications. All current PCs and the future crop of hand held 120 data devices are expected to have this stack. 122 There are two methods to provide this mobile feature, namely (a) Sim- 123 ple AVP Approach (SAA), (b) Independent Tunnel Approach (ITA). Both 124 the SAA and ITA require changes to both LAC and LNS software. We 125 list the advantages and disadvantages of these 2 different approaches 126 in later sections. 128 This proposal is independent of the wireless access technologies. It 129 provides a way to carry mobile node security credentials between net- 130 work access servers in a technology independent manner. It also makes 131 no assumptions about the methods by which wireless terminals are 132 identified or about the encryption and authentication methods used by 133 the wireless networks. 135 1.1. Limitations of L2TP for wireless services 137 The current L2TP draft [1] does not allow for a transfer of Network 138 Access Server (NAS) during an existing PPP session. In a cellular 139 environment, a change of NAS may occur during the lifetime of a PPP 140 session. A user may start a PPP session and move into another service 141 provider's coverage area which has a different NAS. The current L2TP 142 draft forces the user to drop the currrent PPP session and renego- 143 tiate a new session. Instead of terminating the existing PPP session 144 and starting a new one which takes time and can be expensive in high 145 capacity, micro-cellular wireless networks, one solution is to let 146 the old NAS (LAC) transfer the PPP session to the new NAS (LAC). 148 The current L2TP draft also does not allow mobile data users visiting 149 a foreign wireless ISP to use the wireless ISP for virtual private 150 networking services from an area where their home (wireless) ISP is 151 not in operation. 153 2. Overview of Mobile PPP 155 The mobile feature can be provided using two methods which differ in 156 terms of their implementation complexity. These two methods are (i) 157 Simple AVP Approach (SAA), (ii) Independent Tunnel Approach (ITA). 159 2.1. Simple AVP Approach (SAA) 161 In the Simple AVP approach, both the existing LAC and LNS need to be 162 enhanced to process the User AVP, a newly defined AVP. 164 -------- ---------- 165 | Old | Tunnel=2 | | 166 | LAC | ----------| LNS | 167 -------- callid=5 --------- 168 / 169 / 171 / Tunnel=3, callid=1 173 --------- 174 | New LAC | 175 --------- 177 New LAC LNS Old LAC 178 Link 179 Msg 1 SCCRQ 180 ---> ----------------------> 181 SCCRP (with Mobile AVP) 182 <-------------------- 183 SCCCN 184 -------------------> 185 ICRQ (with User AVP) 186 ---------------------> 187 CDN 188 ----------> 189 ICRP (with ACCM AVP) 190 <-------------------- 191 ICCN 192 -------------------> 193 User-level reauthentication (optional) 194 <--------------------------------> 196 Figure 2: Simple AVP Approach 198 In Figure 2, we assume that the link layer message contains some sub- 199 scriber information. Such information allows the new LAC, via the 200 help of its local AAA server, to determine which LNS the new LAC 201 should connect with. During tunnel setup, the LNS MUST include the 202 new Mobile AVP in its SCCRP if it supports the mobility feature. The 203 new LAC MUST NOT attempt to use the mobility feature unless the 204 Mobile AVP is received during tunnel setup. 206 It is assumed that if LNS supports the mobile feature and requires 207 user level reauthentication, then the LNS will use CHAP or other 208 related authentication mechanism that supports reauthentication. 210 An LNS that supports the mobility feature MUST interpret a ICRQ with 211 an attached User AVP as a handover request for an existing PPP call. 212 Using the information provided in the User AVP, the LNS can use its 213 connection table to determine the which call is to be exchanged. 215 If the LNS cannot accept the call handover, the LNS MUST send a CDN 216 message to the new LAC. If the LNS can accept the handover, the LNS 217 MUST send a Call Disconnect Notify (CDN) message to the old LAC and 218 reply with an ICRP message to the new LAC as stated in [1]. To sup- 219 port the handover feature, the ACCM AVP need to be included in the 220 ICRP message. L2TP sequence numbers will be re-initialized after the 221 handover. 223 The advantage of SAA is : (a) it is very simple. 225 The disadvantages of SAA are: (a) Both the LAC and LNS software need 226 to be updated to recognise the newly defined User AVP message. (b) 227 The handover latency may be long since the LAC may be located within 228 the WSP intranet while the LNS is located within the ISP or corporate 229 network far away. (c) Roaming service may be limited to a smaller 230 geographical area because the LACs within the WSP intranets and the 231 LNSs within a corporate network do not trust one another unless there 232 is a direct agreement between different WSPs and the corporate net- 233 work. 235 However, there may be cases where this approach is not secure or 236 feasible. For such cases, we may need to extend the PPP session to a 237 2-hop session. A new entity called the Anchor LAC is introduced for 238 the 2-hop session. 240 2.2. Independent Tunnel Approach (ITA) 242 In the Independent Tunnel Approach, there are two L2TP data sessions 243 per PPP call: one between the Serving LAC and the Anchor LAC; one 244 between the Anchor LAC and LNS. To the Serving LAC, the Anchor LAC 245 looks like the LNS. To the LNS, the Anchor LAC looks like the LAC. 246 The Anchor LAC needs to provide a mapping table to map the tunnel and 247 call identities of one data session to those of the related data ses- 248 sion that belong to the same PPP call. Thus, the Anchor LAC has to 249 maintain 2N data sessions for N PPP calls in ITA. 251 ---------- -------- 252 | Anchor | Tunnel=1 | LNS | 253 | LAC |-----------| | 254 --------- callid=3 -------- 255 | 256 | 257 | Tunnel=3, callid=1 258 ------------- 259 |Serving LAC | 260 ------------- 262 S-LAC: Serving LAC A-LAC: Anchor LAC 264 Client S-LAC A-LAC LNS 265 Link Layer 266 Msg1 SCCRQ 267 ---------> ----------> 268 SCCRP (with Mobile AVP) 269 <--------- 270 SCCCN 271 ------------> 272 ICRQ (with User AVP) 273 -------------> 274 ICRP (with ACCM AVP) 275 <------------- 276 ICCN 277 -------------> 278 ACK 279 <---------- 281 User-level Reauthentication 282 <---------------------------------------> 283 Link Layer 284 Msg2 285 <--------- 287 One hop to 2-hop Handover Scenario 289 Figure 3: Independent Tunnel Approach 291 In Figure 3, we assume that the mobile subscriber first establishes a 292 PPP call between the Anchor LAC and the LNS (tunnelid=1, callid=3). 293 Then, the mobile subscriber roams to the coverage area of another new 294 LAC (referred to as the Serving LAC). From the link-layer handoff 295 message, the Serving LAC discovers that there is an existing PPP 296 call. Thus, the Serving LAC sends an ICRQ message which contains a 297 User AVP. The Anchor LAC will first determine if this existing PPP 298 call requests for an extended hop or for a change of LAC. Such a 299 decision can be made with the help of the local AAA server and the 300 information contained in the User AVP. Next, the Anchor LAC decides 301 if this PPP call already has a 2-hop L2TP tunnel. If the Anchor LAC 302 determines that this existing PPP call needs an extended hop, it will 303 create an entry in its mapping table (MT) so that the L2TP headers of 304 all packets with (tunnelid=1,callid=3) from the incoming interface 305 can be swapped with an L2TP header with (tunnelid=3, callid=1) at the 306 outgoing interface. If a user-level re-authentication is desired, the 307 Anchor LAC can send an Authentication Request message (an optional 308 newly defined L2TP control message) to the LNS. LNS can then re- 309 authenticate the user. Again, as before, we assume that LNS uses CHAP 310 or any other authentication mechanism that supports reauthentication. 311 If re-authentication fails, the connection will be torn. 313 -------- ---------- -------- 314 |Serving| Tunnel=3 | Anchor | Tunnel=1 | LNS | 315 | LAC1 | ----------| LAC |-----------| | 316 -------- callid=1 --------- callid=3 -------- 317 / 318 / 319 / Tunnel=2, callid=5 320 ------------- 321 | New | 322 |Serving LAC2 | 323 ------------- 325 Client S-LAC2 A-LAC LAC1 LNS 326 Link Layer 327 Msg1 SCCRQ 328 ---------> ----------> 329 SCCRP (Mobile AVP) 330 <--------- 331 SCCCN 332 ------------> 333 ICRQ (with User AVP) 334 -------------> CDN 335 ------------> 336 ICRP 337 <------------- 338 ICCN Auth_Req (Optional) 339 -------------> ------------------------> 340 ACK 341 <---------- 342 Link Layer 343 Msg2 344 <--------- 345 2-hop to 2-hop Handover Scenario 347 Figure 4: Independent Tunnel Approach 349 In Fig 4, we show a 2-hop to 2-hop handover scenario. When the Anchor 350 LAC receives the ICRQ with an attached User AVP, and finds an entry 351 in the mapping table, it concludes that this is a 2-hop to 2-hop 352 handover scenario. Therefore, the Anchor LAC sends a CDN message to 353 the old LAC, and updates the mapping table with the new tunnel and 354 call identities carried within the ICRQ message. Again, if a user- 355 level re-authentication is desired, the Anchor LAC can send an 356 Authentication Request message to the LNS to trigger such a reaction. 358 The advantages of ITA are: (a) the handover latency is reduced due 359 to a shorter hop distance between the Serving LAC and the Anchor LAC. 360 The hop between the Anchor LAC and the LNS remains unchanged. (b) 361 Roaming service can be more flexible. As long as there is an agree- 362 ment between the home WSP and the corporate network, and between the 363 home WSP and other WSPs, the subscribers can roam to more places 364 without having to terminate the PPP session. 366 The disadvantages of ITA are (a) more complex than the Simple AVP 367 approach (b) the Anchor LAC needs to maintain 2N flow-controlled data 368 sessions for N PPP calls. 370 3. Service Model Issues 372 3.1. Authentication 374 As in [1], the authentication of the user occurs in four phases; 375 the 376 first at the visiting WSP, the second at the Home WSP, and the 377 third 378 and optionally the fourth at the LNS. 380 3.2. Accounting 382 It is a requirement that the Serving LAC, the Anchor LAC and the 383 LNS be capable of providing accounting data and hence all three 384 parties may count packets, octets and connection start and stop 385 times. 387 Accounting statistics collected by the Serving LAC and the Anchor 388 LAC are sent to their AAA Servers. The accounting Server 389 in the Foreign Network may forward accounting statistics 390 to the Home Accounting Server periodically (weekly, monthly). 392 4. Control Message Processing 394 For the 3-hop scenario, we assume that any party, namely the Serving 395 LAC, the Anchor LAC or the LNS can terminate the session by sending a 396 Call Disconnect Notify. If the Anchor LAC desires to terminate the 397 session, then the Anchor LAC has to send a Call Disconnect Notify 398 message to both the Serving LAC and the LNS. 400 Note that in the three hop scenario, the Hello messages for the con- 401 trol connections between the Serving/Anchor LACs and between the 402 Anchor LAC and LNS are done independently of one another for the 403 Independent Tunnel approach. The Anchor LAC is expected to relay all 404 the Set-Link-Info, and Wan-Error-Notify messages. 406 4.1. Newly Defined Control Message and AVPs 408 To support the tunnel extension and call transfer features, we define 409 one optional control message, namely the Auth_Request (Auth_REQ) mes- 410 sage. This message allows the LAC to inform the LNS to trigger a PPP 411 level re-authentication with the PPP client during handover. 413 In addition, we define three new AVPs: (i) Mobile AVP, (ii) User AVP, 415 4.1.1. Authentication Request (Auth_REQ) 417 Authentication Request message is sent from a LAC to an LNS to 418 trigger the LNS from initiating a PPP reauthentication with an exist- 419 ing user. 421 0 1 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Message Type=17 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 5: Authentication Request 428 4.1.2. Newly Defined AVPs 429 The new AVP is encoded as Vendor ID 1751 which reflects Lucent 430 Systems, the initial developer of this specification, and it 431 should be changed to 0 and an official Attribute value chosen if 432 this specification advances on a standards track). 434 0 1 2 3 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 |M|H|0|0|0|0| Overall Length | Vendor ID | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Attribute | Value... | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | [until Overall Length is reached]... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 The first six bits are a bit mask, describing the general 444 attributes of the AVP. 446 The three newly defined AVPs are: 447 Attr M Len Attribute Name 448 40 1 6 Mobile AVP 449 41 1 16+ User AVP 451 4.1.2.1. Mobile AVP 452 This AVP is used by the LNS/A-LAC to inform a LAC that the 453 LNS/A-LAC supports the mobility feature. 455 0 1 2 3 456 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 |1|1|0|0| Length | Lucent-Vendor ID | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | 40 | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 6: Mobile AVP Format 465 4.1.2.2. User's AVP 467 This AVP is used to provide user's name and user's credentials. 468 The user's credentials may include information like user's 469 identity (IMSI), phone number. 471 Message Format for User's AVP 473 0 1 2 3 474 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |1|1|0|0| Length | Lucent-Vendor ID | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | 41 | User-Service | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | ASCII Representation of 15 digit No | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Phone-No | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Old LAC's IP Address | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Call Serial No | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 User's AVP 490 - contains information about the user's name and user's creden- 491 tials 492 e.g. multihop virtual dial up service, user's identity (MIN), ser- 493 vice 494 provider's phone number, user level authentication information, 495 etc. 496 It also includes a combination of both the IP Address of the old 497 LAC 498 and the call serial number if both exist. This pair of information 499 can uniquely identify an existing PPP session. 501 5. Security Issues 503 In our proposal, the Serving and Anchor LACs may belong to the same 504 WSP or they may belong to different WSPs. For the case where they 505 belong to the same WSP, we do not introduce any new security threats. 506 For the case where they belong to different WSPs, we assume that both 507 the LAC and LNS will support the Authentication Request AVP. We 508 further assume that LNS uses CHAP such that user-level reauthentica- 509 tion can be done with the PPP client if the LNS so desires. 511 In addition, IP security can be supported between the Serving LAC and 512 LNS for the 2-hop scenario using extended ideas described in the 513 draft "Securing L2TP using IPSEC" [2]. 515 6. Legal Issues 517 The patent licensing policy of Lucent Technologies Inc with respect 518 to any patents or patent applications relating to this submission is 519 stated in the March 1, 1999, letter to the IETF from Dr Roger E. 520 Stricker, Intellectual Property Vice President, Lucent Technologies, 521 Inc. This letter is on file in the offices of the IETF Secretariat. 523 7. Acknowledgements 525 The author wishes to thank George Gross for comments on earlier ver- 526 sion. 528 8. Contacts 530 M. C. Chuah 531 Lucent Technologies 532 101, Crawfords Corner Road, 533 Holmdel, NJ 07733 534 chuah@lucent.com 535 (732)-949-7206 537 Don Grosser 538 IBM Corporation 539 3039 Cornwallis Road, 540 Research Triangle Park, NC 27709 541 grosser@us.ibm.com 542 (919)-254-2160 544 G. Rai 545 1101 Warrenville Road, 546 Naperville, IL 547 grai@lucent.com 548 (630)-979-8131 550 Jacob Teplitsky 551 RABU 552 Lucent Technologies 553 4464 Willow Rd, 554 Pleasanton, CA 94588 555 jacobt@livingston.com 556 (925)-737-2189 558 9. References 560 [1] A. Valencia, etal, Layer Two Tunneling Protocol, Internet draft, 561 draft-ietf-pppext-l2tp-116.txt, June, 1999 562 [2] B. Patel, B. Aboba Security L2TP using IPSEC, Internet draft, 563 draft-ietf-pppext-l2tp-security-01.txt, March 1998