idnits 2.17.1 draft-dasilva-l2tp-relaysvc-08.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2003) is 7437 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) ** Downref: Normative reference to an Informational RFC: RFC 2516 (ref. '1') ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. M. Townsley 2 Internet-Draft cisco Systems 3 Ron da Silva 4 AOL Time Warner 5 December 2003 7 Layer 2 Tunneling Protocol (L2TP) 8 Active Discovery Relay for 9 PPP over Ethernet (PPPoE) 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026 . 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 The Point-to-Point Protocol (PPP) provides a standard method for 39 transporting multi-protocol datagrams over point-to-point links. 40 Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP 41 packets across an intervening packet-switched network. And yet a 42 third protocol, PPP over Ethernet (PPPoE) describes how to build PPP 43 sessions and to encapsulate PPP packets over Ethernet. 45 L2TP Active Discovery Relay for PPPoE describes a method to relay 46 Active Discovery and Service Selection functionality from PPPoE over 47 the reliable control channel within L2TP. Two new L2TP control 48 message types and associated PPPoE-specific Attribute Value Pairs 49 (AVPs) for L2TP are defined. This relay mechanism provides enhanced 50 integration of a specific feature in the PPPoE tunneling protocol 51 with L2TP. 53 Contents 55 Status of this Memo.......................................... 1 56 1.0 Introduction.......................................... 2 57 2.0 Protocol Operation.................................... 3 58 2.1 PPPoE Active Discovery Stage.......................... 3 59 2.2 Session Establishment and Teardown.................... 4 60 2.3 PPPoE PAD Message Exchange Coherency.................. 6 61 2.4 PPPoE Service Relay Capabilities Negotiation.......... 8 62 2.4.1 PPPoE Service Relay Response Capability AVP...... 8 63 2.4.2 PPPoE Service Relay Forward Capability AVP....... 9 64 3.0 L2TP Service Relay Messages........................... 10 65 3.1 Service Relay Request Message (SRRQ).................. 10 66 3.2 Service Relay Reply Message (SRRP).................... 10 67 4.0 PPPoE Relay AVP....................................... 10 68 5.0 Security Considerations............................... 11 69 6.0 IANA Considerations................................... 11 70 7.0 Acknowledgements...................................... 12 71 8.0 References............................................ 12 72 8.1 Normative References.................................. 12 73 8.2 Informative References................................ 12 74 9.0 Author's Addresses.................................... 12 76 Appendix A: PPPoE Relay in Point to Multipoint Environments.. 13 78 Appendix B: PAD Message Exchange Coherency Examples.......... 13 80 1.0 Introduction 82 PPPoE [1] is often deployed in conjunction with L2TP [2] to carry PPP 83 [3] frames over a network beyond the reach of the local Ethernet 84 network to which a PPPoE Host is connected. For example, PPP frames 85 tunneled within PPPoE may be received by an L2TP Access Concentrator 86 (LAC) and then tunneled to any L2TP Network Server (LNS) reachable 87 via an IP network. 89 In addition to tunneling PPP over Ethernet, PPPoE defines a simple 90 method for discovering services offered by PPPoE Access Concentrators 91 (PPPoE AC) reachable via Ethernet from the PPPoE Host. Since the 92 packets used in this exchange are not carried over PPP, they are not 93 tunneled with the PPP packets over L2TP, thus the discovery 94 negotiation cannot extend past the LAC without adding functionality. 96 This document describes a simple method for relaying PPPoE Active 97 Discovery (PAD) messages over L2TP by extracting the PAD messages and 98 sending them over the L2TP control channel. After the completion of 99 setup through the processing of PAD messages, PPP packets arriving 100 via PPPoE are then tunneled over L2TP in the usual manner as defined 101 in L2TP [2]. Thus, there are no data plane changes required at the 102 LAC or LNS to support this feature. Also, by utilizing the L2TP 103 control channel, the PPPoE discovery mechanism is transported to the 104 LNS reliably, before creation of any L2TP sessions, and may take 105 advantage of any special treatment applied to control messages in 106 transit or upon receipt. 108 2.0 Protocol Operation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [4]. 114 When PPPoE PAD messages are received at a PPPoE Access Concentrator, 115 the messages are passed over the L2TP control connection via a newly 116 defined Service Relay Request Message (SRRQ) on an established tunnel 117 (Section 3.1). When received, the PPPoE PAD message is processed at 118 the L2TP node, or relayed to another L2TP node or PPPoE Access 119 Concentrator. PPPoE PAD messages sent as replies are handled in a 120 similar manner over a newly defined Service Relay Reply Message 121 (SRRP) (Section 3.2). 123 2.1 PPPoE Active Discovery Stage 125 When a PPPoE Active Discovery Initiation packet (PADI) is received by 126 an L2TP LAC that is providing PPPoE Service Relay, the PADI MUST be 127 packaged in its entirety (including the Ethernet MAC header) within 128 the PPPoE Relay AVP and transmitted over established L2TP Control 129 Connection(s) associated with the interface on which the PADI 130 arrived. 132 The PPPoE Relay AVP is sent via the Service Relay Request Message 133 (SRRQ) defined in Section 3. The SRRQ message MUST NOT be sent to an 134 L2TP node which did not include the PPPoE Service Relay Response 135 Capability AVP during control connection establishment. If no 136 acceptable control connection is available or cannot be created, 137 PPPoE PAD operation MUST be handled locally by some means (including 138 intentionally ignoring the PPPoE PAD message, though this must be a 139 deliberate act). 141 It is a matter of local policy as to which control connections will 142 be established for relay and associated with a given interface, and 143 when the Control Connections will be established. For instance, an 144 implementation may "nail up" a control connection to a particular 145 L2TP destination and associate the connection with an interface over 146 which PPPoE PADI packets will arrive. Alternatively, an 147 implementation might dynamically establish a Control Connection to a 148 predetermined destination upon receipt of a PADI, or upon receipt of 149 a PADI from a particular source. 151 Upon receipt of the SRRQ, the included PPPoE PADI message MUST be 152 processed as described in [3], be relayed to another L2TP control 153 connection, or be relayed to another PPPoE AC. 155 After processing of a PADI, any resultant PPPoE Active Discovery 156 Offer packet (PADO) MUST be encapsulated in a PPPoE Relay AVP and 157 delivered via the Service Relay Reply Message (SRRP) to the sender of 158 the SRRQ. 160 Upon receipt of an SRRP message with relayed PADO, a LAC MUST send 161 the encapsulated PADO message to the corresponding PPPoE Host. The 162 source MAC address of the PADO message MUST be one which the LAC will 163 respond to, perhaps requiring substitution of its own MAC address. 165 In each exchange above, the PPPoE Host-Uniq TAG or AC-Cookie TAG MUST 166 be used as described in Section 2.3. 168 Following is an example of the PAD exchange between an PPPoE Host, 169 LAC and LNS up to this point, assuming the L2TP Control Connection 170 has already been established. Examples that include AC-Cookie TAG and 171 Host-Uniq TAG operation are included in the Appendix. 173 PPPoE Host LAC Tunnel Switch LNS 175 PADI -> 176 SRRQ (w/PADI) -> SRRQ (w/PADI) -> 177 <- SRRP (w/PADO) <- SRRP (w/PADO) 178 <- PADO 180 2.2 Session Establishment and Teardown 182 When a LAC that is providing the PPPoE Service Relay feature receives 183 a valid PPPoE Active Discovery Request packet (PADR), the LAC MUST 184 treat this an an action for creation of a Incoming Call Request 185 (ICRQ) as defined in [2]. The resultant ICRQ message MUST contain 186 the PPPoE Relay AVP containing the PADR in its entirety. 188 Upon receipt of an L2TP ICRQ message, the LNS parses the PADR message 189 as described in [3]. If this is an acceptable PPPoE service 190 connection (e.g. the Service-Name-Error TAG would not be included in 191 a PPPoE Active Discovery Session-confirmation packet (PADS) 192 response), the L2TP Incoming-Call-Reply (ICRP) message that is sent 193 to the LAC includes the resultant PPPoE PADS encapsulated within the 194 PPPoE Relay AVP. If the service is unacceptable, the PADS with a 195 Service-Name-Error Tag is delivered via the Relay Session AVP within 196 a Call-Disconnect-Notify (CDN) message, which also tears down the 197 L2TP session. The PPPoE PADS SESSION_ID in the PPPoE Relay AVP MUST 198 always be zero as it will be selected and filled in by the LAC. 200 Upon receipt of an ICRP with the PPPoE Relay AVP, the LAC parses the 201 PADS from the AVP, inserts a valid PPPoE SESSION_ID, and responds to 202 the PPPoE Host with the PADS. The MAC address of the PADS MUST be the 203 same as that which was utilized during the PADI/PADO exchange 204 described above. The LAC also completes the L2TP session 205 establishment by sending an Incoming-Call-Connected (ICCN) to the LNS 206 and binds the L2TP session with the PPPoE session. PPP data packets 207 may now flow between the PPPoE session and the L2TP session in the 208 traditional manner. 210 If the L2TP session is torn down for any reason, the LAC MUST send a 211 PPPoE Active Discovery Terminate packet (PADT) to the host to 212 indicate that the connection has been terminated. This PADT MAY be 213 received from the LNS via the PPPoE Relay AVP within a CDN message if 214 this was a graceful shutdown initiated by the PPPoE subsystem at the 215 LNS. As with the PADS, the SESSION_ID in the PADT message is zero 216 until filled in with the proper SESSION_ID at the LAC. 218 If the LAC receives a PADT from the PPPoE Host, the L2TP session MUST 219 be shut down via the standard procedures defined in [2]. The PADT 220 MUST be sent in the CDN message to the LNS via the PPPoE Relay AVP. 221 If the PPPoE system at the LNS disconnects the session, a PADT SHOULD 222 be sent in the CDN. In the event that the LAC receives a disconnect 223 from L2TP and did not receive a PADT, it MUST generate a properly 224 formatted PADT and send it to the PPPoE Host as described in [3]. 226 Session Establishment 228 PPPoE Host LAC Tunnel Switch LNS 230 PADR -> 231 ICRQ (w/PADR) -> 232 ICRQ (w/PADR) -> 233 <- ICRP (w/PADS) 234 <- ICRP (w/PADS) 235 <- PADS 236 ICCN -> 237 ICCN -> 239 Session Teardown (LNS Initiated) 241 PPPoE Host LAC Tunnel Switch LNS 243 <- CDN (w/PADT) 244 <- CDN (w/PADT) 245 <- PADT 247 Session Teardown (Host Initiated) 249 PPPoE Host LAC Tunnel Switch LNS 251 PADT -> 252 CDN (w/PADT) -> 253 CDN (w/PADT) -> 255 2.3 PPPoE PAD Message Exchange Coherency 257 PPPoE PAD messages will arrive from multiple ethernet interfaces and 258 be relayed across multiple L2TP control connections. In order to 259 track which PAD messages must be sent where, we utilize the Host-Uniq 260 TAG and AC-Cookie TAG. Each are used in the same manner, depending on 261 which PAD message is being sent or replied to. Both take advantage of 262 the fact that any PAD message sent as a reply to another PAD message 263 MUST echo these TAGs in their entirety [3]. 265 For purposes of this discussion, it is useful to define two 266 "directions" which PAD messages will traverse during a relayed PPPoE 267 PAD message exchange. Thus, for the following example, 269 "Upstream" -----------------------> 271 PPPoE Host ------ LAC ----- Tunnel Switch ------ LNS 273 <--------------------- "Downstream" 275 PAD messages being sent from the PPPoE Host, through the LAC, Tunnel 276 Switch, and LNS, are defined to be traversing "Upstream." PAD 277 messages being sent in the opposite direction are defined to be 278 traversing "Downstream." 280 Consider further, the following observation for this example: 282 PAD messages that are sent Upstream: PADI, PADR, PADT 283 PAD messages that are sent Downstream: PADO, PADS, PADT 285 Also, there is a request/response connection between the PADI and 286 PADO which must be linked with some common value. Similarly, there is 287 a request/response connection between PADO and PADR. The PADS is sent 288 on its own with no response, but must be delivered to the sender of 289 the PADR. The PADT must be sent with the same SESSION_ID as 290 established in the PADS. 292 The goal for PAD message exchange coherency is to ensure that the 293 connections between the PADI/PADO, PADO/PADR, and PADR/PADS and 294 PADS/PADT all remain intact as the PAD messages are relayed from node 295 to node. 297 The basic mechanism for ensuring this for PADI, PADO, and PADR 298 messages is the AC-Cookie TAG and Host-Uniq TAG. Both of these TAGs 299 are defined as arbitrary data which must be echoed in any message 300 sent as a response to another message. This is the key to tying these 301 PAD messages together at each hop. The following two rules makes 302 this possible: 304 For PAD messages that are sent Upstream, a new Host-Uniq TAG MUST 305 be inserted at each relaying node before the PAD message is 306 forwarded. There SHOULD be at most one Host-Uniq TAG per PAD 307 message. 309 For PAD messages being sent Downstream, a new AC-Cookie TAG MUST 310 be inserted at each relaying node before the PAD message is 311 forwarded. There SHOULD be at most one AC-Cookie TAG per PAD 312 message. Additionally, for an LNS receiving multiple PAD messages 313 from upstream, there SHOULD be at most one PAD message forwarded 314 downstream per received SRRP Message. In other words, there 315 SHOULD be exactly one PPPoE Relay AVP per L2TP SRRP Message. 317 The exception here is the PADS, which cannot carry an AC-Cookie TAG 318 (and, thankfully, doesn't need to), and the PADT. We will discuss 319 these later in this section. Using the above rules, PADI, PADO, and 320 PADR messages may be relayed through an arbitrary number of nodes, 321 each inserting its own value to link a message response that it might 322 receive. 324 In order to implement this exchange without tying up resources at 325 each L2TP node, it is desirable to not require ephemeral state at 326 each node waiting for a message response from each forwarded PAD 327 message. This is achievable if one is willing to be very intelligent 328 about the values that will be sent in the PPPoE TAGs used for message 329 coherency. Given that the TAGs are of arbitrary size and composition 330 and are always echoed in their entirety, one may use the information 331 here to map any next relay hop information. For example, the L2TP 332 Tunnel ID (Control Connection ID) could be encoded in the TAG in 333 order to identify where to relay the message when it arrives. If one 334 chooses this method, the encoding MUST incorporate some method of 335 encryption and authentication of the value. Note that this is a 336 relatively simple proposition given that it is only the source of the 337 encrypted and data that will ever need to decrypt and authenticate 338 the value upon receipt (thus, no key exchanges are necessary, and any 339 of a myriad of algorithms may be chosen). Note that individual TAGs 340 MUST never exceed 255 octets in length, and the length of an entire 341 PPPoE message MUST never exceed the maximum segment size of the 342 underlying ethernet. In the event that a TAG exceeds 255 octets in 343 length, a compression scheme which may include storage of state at an 344 L2TP node may be necessary before constructing a new TAG. 346 The PADS and PADT messages do not rely on the AC-Cookie TAG or Host- 347 Uniq TAG for directing to the proper node. As described in Section 348 2.2, the L2TP session is created upon receipt of a valid PADR at the 349 L2TP LAC. Since the PADS is sent as an AVP on this message exchange, 350 its coherency may be secured via the L2TP session itself. Similarly 351 for the PADT, as it is carried in the L2TP disconnect message (CDN) 352 for the L2TP session. 354 Clients are supposed to treat an AC-Cookie TAG as an opaque object. 355 They differentiate PADOs only by MAC address, Service-Name TAG(s) and 356 by AC-Name TAG(s). If an LAC sends multiple PADOs, they should 357 contain different AC-Name TAGs. 359 Furthermore, a node performing PPPoE L2TP Relay (such as an LAC) 360 SHOULD attempt to distinguish or rate limit retransmitted PADx 361 messages (perhaps via the source MAC address and/or arriving 362 interface of the message) in order to limit the overloading of L2TP. 364 Examples of this operation for a number of scenarios and 365 considerations for certain deployment situations may be found in the 366 Appendix of this document. 368 2.4 PPPoE Service Relay Capabilities Negotiation 370 If the extensions defined in this document are present and configured 371 for operation on a given Control Connection, the AVPs listed in this 372 section MUST be present in the Start-Control-Connection-Request 373 (SCCRQ) or Start-Control-Connection-Reply (SCCRP) messages during 374 control connection setup. 376 2.4.1 PPPoE Service Relay Response Capability AVP 378 The PPPoE Service Relay Response Capability AVP, Attribute Type TBA, 379 indicates to an L2TP peer that the PPPoE Service Relay (SRRQ, SRRP) 380 messages and the PPPoE Relay AVP will be processed and responded to 381 when received. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |M|H| rsvd | Length | Vendor ID | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Attribute Type | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 The Vendor ID is the IETF Vendor ID of 0. 393 This AVP MAY be hidden (the H bit MAY be 0 or 1). 395 The M bit for this AVP may be set to 0 or 1. If the sender of this 396 AVP does not wish to establish a connection to a peer which does not 397 understand this L2TP extension, it SHOULD set the M bit to 1, 398 otherwise it MUST be set to 0. 400 The Length of this AVP is 6. 402 The AVP may be present in the following messages: SCCRQ, SCCRP 404 2.4.2 PPPoE Service Relay Forward Capability AVP 406 The PPPoE Service Relay Forward Capability AVP, Attribute Type TBA, 407 indicates to an L2TP peer that PPPoE Service Relay (SRRQ, SRRP) 408 messages and the PPPoE Relay AVP may be sent by this L2TP peer. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 |M|H| rsvd | Length | Vendor ID | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Attribute Type | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 The Vendor ID is the IETF Vendor ID of 0. 420 This AVP MAY be hidden (the H bit MAY be 0 or 1). 422 The M bit for this AVP may be set to 0 or 1. If the sender of this 423 AVP does not wish to establish a connection to a peer which does not 424 understand this L2TP extension, it SHOULD set the M bit to 1, 425 otherwise it MUST be set to 0. 427 The Length of this AVP is 6. 429 The AVP may be present in the following messages: SCCRQ, SCCRP 431 3.0 L2TP Service Relay Messages 433 This section identifies two new L2TP messages used to deliver PPPoE 434 PADI and PADO messages. 436 3.1 Service Relay Request Message (SRRQ) 438 The Service Relay Request Message (SRRQ), Message Type TBD, is sent 439 by an LAC to relay requests for services. This document defines one 440 new AVP that may be present to request service in section 2. Further 441 service relay mechanisms may also use this message in a similar 442 context. Discussion of other service relay mechanisms are outside 443 the scope of this document. 445 3.2 Service Relay Reply Message (SRRP) 447 The Service Relay Reply Message (SRRP), Message Type TBD, is sent by 448 an LAC to relay responses of requests for services. This document 449 defines one new AVP that may be present as a response to a request 450 for service in section 2. Further service relay mechanisms may also 451 use this message in a similar context. Discussion of other service 452 relay mechanisms are outside the scope of this document. 454 4.0 PPPoE Relay AVP 456 The PPPoE Relay AVP, Attribute Type TBA, carries the entire PADI, 457 PADO, PADR, PADS and PADT messages within, including Ethernet MAC 458 source and destination addresses. This is the only AVP necessary for 459 relay of all PAD messages via L2TP. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |M|H| rsvd | Length | Vendor ID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Attribute Type | PPPoE PAD Message ... 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 ... (Until end of message is reached) | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 The Vendor ID is the IETF Vendor ID of 0. 473 This AVP MAY be hidden (the H bit MAY be 0 or 1). 475 The M bit for this AVP may be set to 0 or 1. If the sender of this 476 AVP does not wish to establish a connection to a peer which does not 477 understand this L2TP extension, it SHOULD set the M bit to 1, 478 otherwise it MUST be set to 0. 480 The Length of this AVP is 6 plus the length of the PPPoE PAD Message. 482 The AVP may be present in the following messages: SRRQ, SRRP, ICRQ, 483 ICRP, ICCN, and CDN. 485 5.0 Security Considerations 487 PPPoE has a number of known security weaknesses that are not 488 described here. For example, an intruder between a PPPoE Host and a 489 PPPoE AC who can observe or modify PPPoE Active Discovery traffic has 490 numerous opportunities for denial of service and other attacks. The 491 use of the L2TP extensions described here makes it possible to tunnel 492 PPPoE discovery packets between the LAC and LNS, extending the path 493 which the PPPoE Active Discovery packets are transported. There are 494 two possible implications of this. First, the tunneled packets may 495 now be observable by an intruder having access to traffic along the 496 L2TP tunnel path. This MAY make information regarding service 497 offerings or host identity easier to obtain to a rogue party given 498 that it is being sent over a wider variety of media, and presumably 499 over a longer distance and/or more hops or administrative domains. 500 Whether this information could be used for malicious purposes depends 501 on the information contained within, but it is conceivable that this 502 could be sensitive information, and this mechanism increases the 503 possibility that this information would be presented to an 504 interloper. Second, it may also be possible for an intruder to modify 505 PPPoE Active Discovery traffic while it is being carried within L2TP 506 control messages. 508 There are at least two methods defined to help thwart this inspection 509 or modification by an unauthorized individual. One of the two MUST be 510 used if the service discovery information is considered to be 511 sensitive and is traversing an untrusted network. The first suggested 512 method is AVP hiding described in [2]. This may be used to hide the 513 contents of the packets in transit, though offers no integrity 514 protection against modification of data in the AVP. The second and 515 more secure method is protecting L2TP with IPsec as defined in [6]. 517 6.0 IANA Considerations 519 This document requires one new "AVP Attribute" (attribute type) 520 to be assigned through IETF Consensus [5] as indicated in 521 Section 10.1 of [2]. 523 1. PPPoE Relay AVP (section 4.0) 525 This document requires two new "Message Type" to be assigned through 526 IETF Consensus [5] as indicated in Section 10.2 of [2]. 528 1. Service Relay Request Message (SRRQ) (Section 3.1) 529 2. Service Relay Reply Message (SRRP) (Section 3.2) 531 There are not additional requirements on IANA to manage numbers in 532 this document or assign any other numbers. 534 7.0 Acknowledgements 536 Thanks to Vinay Shankarkumar for valuable review, comment, and 537 implementation. 539 Thanks to David Skoll and a number of others on pppoe@ipsec.org for 540 providing very helpful discussion about their PPPoE implementations. 542 Thanks to Ross Wheeler, Louis Mamakos, and David Carrel for providing 543 valuable clarifications of PPPoE [3] while designing this protocol. 545 8.0 References 547 8.1 Normative References 549 [1] Mamakos, Lidl, Evarts, Carrel, Simone, Wheeler, 550 "A Method for Transmitting PPP Over Ethernet (PPPoE)", 551 RFC 2516, February 1999. 553 [2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer 554 Two Tunneling Protocol 'L2TP'", RFC 2661, June 1999. 556 [3] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 557 RFC 1661, July 1994. 559 [4] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", RFC 2119, March 1997 562 [5] Narten, Alvestrand, "Guidelines for Writing an IANA 563 Considerations Section in RFCs", RFC 2434, October 1998. 565 8.2 Informative References 567 [6] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing 568 L2TP Using IPsec," RFC 3193, November 2001 570 9.0 Author's Addresses 572 W. Mark Townsley 573 cisco Systems 574 7025 Kit Creek Road 575 Research Triangle Park, NC 27709 576 mark@townsley.net 578 Ron da Silva 579 AOL Time Warner 580 12100 Sunrise Valley Dr 581 Reston, VA 20191 582 ron@aol.net 584 Appendix A: PPPoE Relay in Point to Multipoint Environments 586 The PPPoE PADI message in its native form, is sent as a broadcast 587 message on an Ethernet link. Thus, more than one AC concentrator 588 could conceivably receive and respond to this message. Similarly, a 589 PPPoE interface could be associated with more than one L2TP Control 590 Connection, in order to query multiple LNSs with potentially varying 591 service profiles, as well as to load balance requests. 593 As the PADI message is propagated, one may choose to replicate the 594 message to multiple Control Connections in order to mimic the 595 behavior of the PADI being sent on an ethernet link with multiple ACs 596 attached. If the number of replicated nodes is large, and the number 597 of hops deep, then an unmanageable "fan-out" of PADI propagation may 598 occur. Thus, care should be taken here to only replicate messages to 599 multiple Control Connections when it is absolutely necessary. 601 The only case where it is seems necessary to replicate messages to 602 multiple destinations is in the case where each destination is known 603 to have varying 604 service policies that all need to be advertised to a PPPoE Host for 605 its gathering and selection. At the time of this writing, the authors 606 know of no PPPoE Host implementations that take advantage of this 607 ability (instead, responding to only a single PPPoE PADO). This, of 608 course, is subject to change if and when PPPoE implementations are 609 advanced to this stage. 611 In cases where multiple Control Connections may exist to multiple 612 LNSs for load balancing purposes, L2TP Service Relay should take 613 measures to try one Control Connection at a time, rather than 614 broadcasting to all Control Connections simultaneously. 616 Appendix B: PAD Message Exchange Coherency Examples 617 Example 1: "PPPoE Relay With Multiple LNSs" 619 ,--- LNS1 620 / 621 Host --- LAC 622 \ 623 `--- LNS2 625 This example assumes that there is good reason to send a copy of the 626 PADI to both LNSs (e.g. each LNS may have a different service profile 627 to offer). 629 1) a. Host sends PADI via broadcast MAC address to LAC 631 b. LAC replicates the PADI message and forwards a copy to LNS1 632 Host-Uniq = R1 (assigned) 634 c. LAC replicates the PADI message and forwards a copy to LNS2 635 Host-Uniq = R2 (assigned) 637 2) a. LNS1 responds with PADO to LAC 638 Host-Uniq = R1 (echoed) 639 AC-Cookie = C1 (assigned) 641 b. LNS1 responds with PADO to LAC 642 Host-Uniq = R2 (echoed) 643 AC-Cookie = C2 (assigned) 645 c. LAC forwards both PADO messages to Host with source MAC set to 646 MAC address of LAC. PADO from (2a) is assigned new AC-Cookie 647 C1' 648 and PADO from (2b) is given AC-Cookie C2' 650 3) a. Host sends PADR to MAC address of LAC (choosing one) 651 AC-Cookie = C1' (echoed) 653 b. LAC knows to forward PADR to LNS1 based on C1' 654 AC-Cookie = C1 (echoed) 656 4) Session Establishment at the LAC commences, with further PAD 657 messages 658 carried within the context of the L2TP session itself. No need to 659 inspect the AC-Cookie TAG or Host-Uniq TAG from this point 660 forward in order to direct messages properly. 662 Example 2: "PPPoE Relay With L2TP Tunnel-Switching" 664 Host --- LAC ---- LNS1 ---- LNS2 666 1) a. Host sends PADI to LAC. 668 b. LAC sends PADI to LNS1 669 Host-Uniq = R1 (assigned) 671 c. LNS1 sends PADI to LNS2 672 Host-Uniq = R2 (assigned) 674 2) a. LNS2 responds to LNS1 with PADO 675 Host-Uniq = R2 (echoed) 676 AC-Cookie = C1 (assigned) 678 b. LNS1 relays PADO to LAC 679 Host-Uniq = R1 (echoed) 680 AC-Cookie = C1' (assigned) 682 c. LAC sends PADO to Host 683 AC-Cookie = C1'' (assigned) 685 3) a. Host sends PADR to MAC address of LAC 686 AC-Cookie = C1'' (echoed) 688 b. LAC sends PADR to LNS1 689 AC-Cookie = C1' (echoed) 691 c. LNS1 sends PADR to LNS2 692 AC-Cookie = C1 (echoed) 694 4) Session Establishment at the LAC, LNS1 and LNS2 commences, with 695 further PAD messages carried within the context of the L2TP 696 session itself. No need to inspect the AC-Cookie TAG or 697 Host-Uniq TAG from this point forward in order to direct 698 messages properly. 700 Example 3: "PPPoE Relay With Multiple PPPoE ACs" 702 ,--- AC1 703 / 704 Host --- LAC ---- LNS 705 \ 706 `--- AC2 708 In this example, AC1 and AC2 are PPPoE access concentrators on a 709 broadcast domain. Sequence of operation is as follows. 711 1) a. Host sends PADI to LAC. 713 b. LAC sends PADI to LNS 714 Host-Uniq = R1 (assigned) 716 c. LNS broadcasts PADI to AC1 and AC2 717 Host-Uniq = R2 (assigned) 719 2) a. AC1 sends PADO to LNS 720 Host-Uniq = R2 (echoed) 721 AC-Cookie = C1 (assigned) 723 b. AC2 sends PADO to LNS 724 Host-Uniq = R2 (echoed) 725 AC-Cookie = C2 (assigned) 727 c. LNS sends two PADOs to LAC 728 Host-Uniq = R1 (echoed) 729 AC-Cookie (assigned) = C1' and C2', respectively 731 d. LAC sends two PADOs to Host 732 Host-Uniq = R1 733 AC-Cookie (assigned) = C1'' and C2'', respectively 735 3) a. Host sends PADR with to LAC to select service from AC2. 736 AC-Cookie = C2'' (echoed) 738 b. LAC sends PADR to LNS AC-Cookie = C2' (echoed) 740 c. LAC sends PADR to AC2 741 AC-Cookie = C1 (echoed) 743 4) Session Establishment at the LAC, LNS and AC2 commences, with 744 further PAD messages carried within the context of the L2TP 745 session or PPPoE session itself. No need to inspect 746 the AC-Cookie TAG or Host-Uniq TAG from this point forward in 747 order to direct messages properly.