idnits 2.17.1 draft-ietf-pppext-spoof-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 0) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 280 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 304: '...eference" number MUST be negotiated pr...' RFC 2119 keyword, line 333: '... the calling end SHOULD include this o...' RFC 2119 keyword, line 338: '...- The called end SHOULD NOT include ...' RFC 2119 keyword, line 341: '... calling end SHOULD then return a ...' RFC 2119 keyword, line 356: '... calling end MAY return a Configure ...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 17 has weird spacing: '... Drafts are ...' == Line 18 has weird spacing: '...cuments of t...' == Line 19 has weird spacing: '...ups may also ...' == Line 23 has weird spacing: '... Drafts may b...' == Line 24 has weird spacing: '...iate to use ...' == (275 more instances...) -- 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 (February 1996) is 10297 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) == Unused Reference: '2' is defined on line 1155, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1717 (ref. '4') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1340 (ref. '5') (Obsoleted by RFC 1700) ** Obsolete normative reference: RFC 1334 (ref. '6') (Obsoleted by RFC 1994) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I D Puleston 3 Internet Draft Global Village Communication (UK) Ltd. 4 expires in six months February 1996 6 PPP Protocol Spoofing Control Protocol (PSCP) 7 9 Status of this Memo 11 This document is the product of the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@ucdavis.edu mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 Please check the 1id-abstracts.txt listing contained in the internet- 29 drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 30 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 31 current status of any Internet Draft. 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. 38 This document describes a Network Control Protocol which will allow 39 the two ends of a connection to agree to carry out protocol spoofing 40 when an idle link is temporarily disconnected in order to save on 41 connection charges. 43 This work was originally motivated by the desire to exploit the fast 44 call setup capability of ISDN, but is equally applicable in any 45 situation in which a PPP connection is made over a link which can be 46 temporarily suspended for whatever reason. 48 =0C 50 DRAFT PPP Protocol Spoofing Control Protocol February 1996 52 Table of Contents 54 1. Introduction .......................................... 1 56 2. Overview of Protocol Spoofing ......................... 2 57 2.1 Limiting Session Length ............................ 4 58 2.2 Information Required for Protocol Spoofing ......... 4 60 3. PPP Link Control Protocol Extensions .................. 5 61 3.1. LCP Configuration Options .......................... 5 62 3.1.1. Call Reference Number .......................... 6 64 4. The Protocol Spoofing Control Protocol ................ 9 65 4.1 Call Connection and Re-Connection .................. 10 66 4.2 Call Termination / Suspension ...................... 10 67 4.3 Killing Off a Suspended Connection ................. 11 68 4.4. Call Collision when Resuming a Connection .......... 12 69 4.5. Use with PPP Multilink ............................. 12 71 5. PSCP Packet Formats ................................... 13 72 5.1 Terminate Request .................................. 13 74 6. PSCP Configuration Options ............................ 14 75 6.1 Maximum Call Suspension Time ....................... 15 76 6.2 Spoofed Protocol Support ........................... 16 77 6.3 Maximum Protocol Sessions .......................... 18 78 6.4 Re-activation on Final Termination ................. 19 79 6.5 Call-Back Number ................................... 20 80 6.6 Call-Back Name ..................................... 22 82 7. PSCP Termination Options .............................. 23 83 7.1 Call Termination Reason ............................ 23 85 APPENDIX 1: Switch-Over to a Low-Cost Secondary Channel ...... 24 87 SECURITY CONSIDERATIONS ...................................... 25 89 REFERENCES ................................................... 25 91 ACKNOWLEDGEMENTS ............................................. 25 93 CHAIR'S ADDRESS .............................................. 26 95 AUTHOR'S ADDRESS ............................................. 26 97 =0C 99 DRAFT PPP Protocol Spoofing Control Protocol February 1996 101 1. Introduction 103 With a transfer medium such as ISDN, calls can be connected and 104 disconnected very quickly, and this gives devices scope to bring a 105 connection up and down as and when required, in order to keep call 106 charges to a minimum. A call can be dropped during periods of 107 inactivity, and then automatically re-connected when data activity is 108 resumed, without the higher-layer protocols being aware of any 109 change. This will be referred to here as "suspending" the 110 connection. 112 Suspending a call in this way, however, gives rise to a problem with 113 protocols which generate intermittent protocol messages even when a 114 connection is idle (for example Novell transfers regular "Keep Alive" 115 messages between servers and clients). If the link were to be re- 116 connected in order to transfer every protocol message, then 117 unnecessary call charges would be incurred. 119 This is a particular problem in the case of LAN interconnection via 120 WAN links, such as ISDN. The protocols running on the LAN are 121 typically designed specifically for the LAN where the topology is 122 fixed, and hence they assume that a connection across the LAN will be 123 permanently physically connected throughout its duration. 125 The problem is solved by monitoring the traffic on the link and 126 recognising individual sessions of the relevant protocols. When a 127 connection is suspended, then the devices at the two ends can 128 themselves generate the protocol messages locally ("spoof" the 129 protocols) instead of re-connecting the call for the transfer of 130 protocol messages. 132 In order for two independent devices at either end of a connection to 133 carry out protocol spoofing, it is only necessary for them to agree 134 on what they are spoofing, not on how they actually carry out the 135 spoofing. Once the connection is suspended each will take care of 136 its end of the connection independently of the other. 138 Protocol spoofing requires the exchange of information between the 139 two ends so that each knows what the other is doing. At the very 140 least, it is necessary for the two ends to know that a terminating 141 call is being temporarily suspended rather than permanently 142 disconnected, and to be able to identify a new call as being a 143 resumption of a particular suspended connection. 145 This specification defines a PPP Network Control Protocol to achieve 146 this. 148 =0C 150 DRAFT PPP Protocol Spoofing Control Protocol February 1996 152 2. Overview of Protocol Spoofing 154 Protocol Spoofing takes place when the communications medium is 155 temporarily disconnected during periods of inactivity, and makes sure 156 that the higher-layer protocols are unaware of the lower layers 157 having been disconnected. This prevents problems such as login 158 sessions being terminated, or remote resources disappearing. 160 The spoofing of a protocol would typically involve the device at each 161 end of the suspended link: 163 1. Filtering out certain protocol messages from the local hosts so 164 that these do not themselves cause the ISDN call to re-connect. 166 2. Generating the protocol messages to fool the local hosts into 167 believing that the remote hosts are still connected. 169 Protocols requiring spoofing basically fall into two categories: 171 1. Protocols using solicited messages, where one end sends out 172 requests to which the remote end should respond. In these cases 173 the local device must spoof the protocol whilst the link is 174 suspended by generating the response itself when it receives a 175 request (as shown in the diagram below). 177 2. Protocols involving unsolicited messages (e.g. advertising 178 protocols, where one end sends out unsolicited messages 179 advertising its presence). In these cases the remote device must 180 spoof the protocol whilst the link is suspended by generating the 181 messages itself at the relevant times. 183 The following shows an example of how a typical server-client LAN 184 protocol may regularly send out a protocol message to check that a 185 client is still connected using a request-response protocol: 187 =0C 189 DRAFT PPP Protocol Spoofing Control Protocol February 1996 191 Server Router Router Client 192 | LAN | PPP-Link | LAN | 193 | | | | 194 | Are you there ? | | | 195 |--------------------+--------------------+--------------->| 196 | | | | 197 | Here I am | | | 198 |<-------------------+--------------------+----------------| 199 | | | | 201 And the following shows how the first router would spoof this 202 protocol whilst the PPP link is suspended: 204 Server Router Router Client 205 | LAN | Link Suspended | LAN | 206 | | | | 207 | Are you there ? | | | 208 |------------------->| | | 209 | | | | 210 | Here I am | | | 211 |<-------------------| | | 212 | | | | 214 Assuming that two devices each have the ability to carry out protocol 215 spoofing, then the basic requirement for their spoofing systems to 216 inter-work is that whilst a connection is suspended: 218 - if a session is alive and being spoofed at one end, then the other 219 end should also, if relevant, be spoofing it, 220 - one end should not keep spoofing a session if that session has 221 been terminated at the other end. 223 This means that the basic requirement for an inter-working protocol 224 between them is that each knows exactly which protocol sessions are 225 being spoofed by the other, and when the spoofing of each session 226 will cease. 228 Some examples of protocols which require spoofing when connections 229 are suspended are: 231 - Novell IPX/SPX 232 - Novell RIP/SAP 233 - NetBIOS / NetBEUI 234 - TCP implementations which use TCP "Keep Alives"[3] 235 - OSI Transport Class 4 236 - Ping over IP (there are some systems which implement a form of 237 "keep alive" by regularly sending a "ping" to the remote end). 239 =0C 241 DRAFT PPP Protocol Spoofing Control Protocol February 1996 243 An additional complexity is that when certain protocols can be run in 244 combination with other protocols, then the ability to spoof them may 245 depend on which they are used with (for example a device which can 246 spoof NetBIOS over LLC1 may not be able to spoof NetBIOS over 247 TCP/IP). 249 2.1. Limiting Session Length 251 A potential problem with the idea of suspending connections comes 252 about in a situation where many users require access to a limited 253 number of shared resources (such as the ISDN channels on a LAN access 254 server). If one user leaves his connection suspended because it is 255 costing him nothing in call charges, then he is "hogging" resources 256 which others may require. 258 Because of this it may be desirable to limit the time for which 259 protocol spoofing can be maintained on a connection. 261 An additional benefit is that if a device is, for example, turned-off 262 whilst it has a connection suspended, the remote end will time-out 263 and abort the connection. 265 2.2. Information Required for Protocol Spoofing 267 Protocol spoofing requires exchange of information between the two 268 ends so that each knows what the other is doing. Each end must know: 270 1. When a call is cleared-down due to the connection being 271 temporarily suspended rather than permanently disconnected. 273 2. When a new call is a resumption of a suspended connection, and 274 which particular suspended connection is being resumed. 276 3. The capabilities of the device at the other end (for example the 277 spoofing of some protocols may not be supported by both). 279 4. Any limits (such as the maximum time for which a spoofing 280 session should be maintained) which must be agreed with the 281 device at the other end. 283 5. Call-back information, supplied by the calling party so that the 284 called party can call back in order to resume a suspended 285 connection. This can include the number to call, authentication 286 information, etc. 288 =0C 290 DRAFT PPP Protocol Spoofing Control Protocol February 1996 292 3. PPP Link Control Protocol Extensions 294 There are certain options of various Network Control Protocols which, 295 when a suspended connection is re-connected, must be the same as they 296 were in the initial call (one example could be the IP address 297 negotiated by IPCP). Because of this, both ends must know whether a 298 call is a re-connection, and if so, which call is being re-connected, 299 before they start the NCP negotiations. 301 This is achieved by associating a "Call Reference" number with each 302 connection. This call reference number will remain valid when the 303 connection is suspended, and will be used to identify it when it is 304 re-connected. The "Call Reference" number MUST be negotiated prior to 305 the start of the NCP negotiations, and is therefore negotiated by the 306 Link Control Protocol[1]. 308 3.1. LCP Configuration Options 310 The Protocol Spoofing Control Protocol introduces the use of an 311 additional LCP Configuration Option: 313 Call Reference Number 315 The value of this LCP Configuration Option will be specified in the 316 "Assigned Numbers" RFC [5]. 318 =0C 320 DRAFT PPP Protocol Spoofing Control Protocol February 1996 322 3.1.1. Call Reference Number 324 Description 326 The Call Reference Number Configuration Option is used to negotiate 327 unique reference numbers, which can then be used to identify the 328 connection if it is suspended. Each end indicates a number which it 329 can use to identify the connection, and the numbers provided by the 330 two ends do not need to be the same. It will be used as follows when 331 the Protocol Spoofing Control Protocol is to be used: 333 - On a new connection, the calling end SHOULD include this option in 334 its Configure Request with the value zero. The called end should 335 then return a Configure Nak, putting in a non-zero value which it 336 can use to uniquely identify the connection. 338 - The called end SHOULD NOT include this option in its initial 339 Configure Request (since it does not at that point know whether it 340 is a new connection or a re-connection). On a new connection, the 341 calling end SHOULD then return a Configure Nak, supplying a non- 342 zero value which it can use to uniquely identify the connection. 344 - On re-connection of a suspended connection, the calling end should 345 include this option in its Configure Request with the non-zero 346 value which was indicated by the remote end in the initial call. 347 The called peer will use this value to identify the suspended 348 connection. 350 Note that the calling end can then tell if a call is is a new 351 connection or a re-connection, since the value of this option in the 352 caller's initial Configure Request is zero in the former case, and 353 non-zero in the latter. 355 When a connection which has been suspended is re-connected, the 356 calling end MAY return a Configure Nak, with the non-zero value which 357 it itself indicated in the initial call, but this is not strictly 358 necessary. 360 The following diagrams illustrate how this option is used: 362 =0C 364 DRAFT PPP Protocol Spoofing Control Protocol February 1996 366 1. Initial Setup of a New Connection 367 End A End B 368 | | 369 | Call Sent | 370 |--------------------------------------------------------->| 371 | | 372 | Call Acknowledged | 373 |<---------------------------------------------------------| 374 | | 375 | Configure Req: No call Ref option | 376 |<---------------------------------------------------------| 377 | | 378 | Configure Req: Call Ref. =3D 0 | 379 |--------------------------------------------------------->| 380 | | 381 | Configure Nak: Call Ref. =3D A's ref. | 382 |--------------------------------------------------------->| 383 | | 384 | Configure Nak: Call Ref. =3D B's ref. | 385 |<---------------------------------------------------------| 386 | | 387 | Configure Req: Call Ref. =3D A's ref. | 388 |<---------------------------------------------------------| 389 | | 390 | Configure Req: Call Ref. =3D B's ref. | 391 |--------------------------------------------------------->| 392 | | 394 2. Re-Connection of a Suspended Connection 395 End A End B 396 | | 397 | Call Sent | 398 |--------------------------------------------------------->| 399 | | 400 | Call Acknowledged | 401 |<---------------------------------------------------------| 402 | | 403 | Configure Req: No call Ref option | 404 |<---------------------------------------------------------| 405 | | 406 | Configure Req: Call Ref. =3D B's ref. | 407 |--------------------------------------------------------->| 408 | | 410 In summary, a Configure Request contains the reference number which 411 is meaningful to the remote end, and a Configure Nak is used to 412 inform the other end of this in the first place. A Configure Request 414 =0C 416 DRAFT PPP Protocol Spoofing Control Protocol February 1996 418 with the value zero in this option is used to request the remote 419 end's reference number, and indicates a new connection. 421 If a Configure-Request is received with the Call Reference Number 422 option indicating a re-connection of a suspended connection, but no 423 suspended connection exists with the given Call Reference Number, 424 then the call SHOULD be terminated. 426 A call reference value MUST be negotiated by this option for both 427 ends of the call if the Protocol Spoofing Control Protocol is to be 428 used. 430 Note that if authentication (e.g. PAP/CHAP) is used, then on re- 431 connection of a suspended connection, the called end SHOULD check 432 that the authentication user ID is the same as in the original call. 433 If it is not the same, then it should terminate the call. An 434 implementation MAY also choose to similarly check the Endpoint 435 Discriminator when this is used. 437 A summary of the Call Reference Number Option format is shown below. 438 The fields are transmitted from left to right. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Length | Reference Number | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Type 448 2 450 Length 452 4 454 Reference Number 456 This specifies the call reference number to be used. 458 =0C 460 DRAFT PPP Protocol Spoofing Control Protocol February 1996 462 4. The Protocol Spoofing Control Protocol 464 The Protocol Spoofing Control Protocol (PSCP) is responsible for 465 enabling the two ends of the point-to-point link to negotiate what 466 can be spoofed, and any limits to be imposed. It is also responsible 467 for enabling the two ends to agree that a PPP connection is to be 468 suspended, and for controlling resumption of a suspended connection. 470 PSCP uses the same packet exchange mechanism as the Link Control 471 Protocol [1]. PSCP packets may not be exchanged until PPP has reached 472 the Network-Layer Protocol phase. PSCP packets received before this 473 phase is reached SHOULD be silently discarded. 475 PSCP may only be started if call reference values have been 476 negotiated for both ends of the connection by LCP. 478 The Protocol Spoofing Control Protocol is exactly the same as the 479 Link Control Protocol with the following exceptions: 481 Data Link Layer Protocol Field 483 Exactly one PSCP packet is encapsulated in the PPP Information 484 field, where the PPP Protocol field indicates PSCP (the value will 485 be specified in the "Assigned Numbers" RFC [5]). 487 Code field 489 Only Codes 1 through 7 (Configure-Request, Configure-Ack, 490 Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack 491 and Code-Reject) are used. Other Codes SHOULD be treated as 492 unrecognized and SHOULD result in Code-Rejects. 494 Timeouts 496 PSCP packets may not be exchanged until PPP has reached the 497 Network-Layer Protocol phase. An implementation SHOULD be 498 prepared to wait for Authentication and Link Quality Determination 499 to finish before timing out waiting for a Configure-Ack or other 500 response. It is suggested that an implementation should give up 501 only after user intervention or a configurable amount of time. 503 Packet Formats 505 The Terminate-Request and Terminate-Ack messages used by PSCP 506 include parameters for controlling the suspension of a connection. 508 Configuration Option Types 510 PSCP has a distinct set of Configuration Options, which are 511 defined in this document. 513 =0C 515 DRAFT PPP Protocol Spoofing Control Protocol February 1996 517 A PSCP Configuration Request can be sent by either end at any time 518 during the life of the call, in order to re-negotiate the 519 configuration options. In particular, as new protocol sessions are 520 established, an implementation may with to re-negotiate the set of 521 protocols whose spoofing is supported, 523 4.1. Call Connection and Re-Connection 525 The Link Control Protocol's Call Reference Number configuration 526 option enables a device receiving an incoming call to know whether it 527 is a new connection, or a resumption of a suspended connection, and 528 to be able to identify the suspended connection in the latter case. 529 Other parameters required for protocol spoofing are negotiated by 530 PSCP configuration messages when the call is connected or re- 531 connected. 533 It SHOULD NOT be assumed that a suspended connection will necessarily 534 be re-connected on the same link when multiple links are available 535 (e.g. ISDN B-channels). 537 Re-connection of a suspended connection MAY be initiated by either 538 end, although some implementations may only allow the original caller 539 to do this. 541 4.2. Call Termination / Suspension 543 The PSCP Terminate-Request message includes a parameter indicating 544 the reason for call disconnection as one of: 546 - final call termination. 547 - temporary suspension of the call. 549 Call suspension can be initiated by either end. The length of time 550 for which a connection has to be idle before it is suspended is not 551 negotiated by PSCP, and hence the two ends could be configured to 552 suspend the connection at a different time. An implementation should 553 allow for the remote end possibly suspending the connection before 554 its own idle timer has expired. 556 If a device which has sent a Terminate-Request message indicating 557 temporary suspension of a connection receives a Terminate-Request 558 message indicating final call termination, or vice-versa, then the 559 latter SHOULD override the former, and the connection SHOULD be 560 terminated rather than suspended. 562 =0C 564 DRAFT PPP Protocol Spoofing Control Protocol February 1996 566 A PPP device should only initiate temporary suspension of a 567 connection if: 568 - PPP has reached the Network-Layer phase and PSCP has reached the 569 Opened state, 570 - and there are no sessions running over the link using protocols 571 whose spoofing has been negotiated off. 573 The devices should then only enter the spoofing state if a Terminate- 574 Request has been sent indicating temporary suspension of the 575 connection, and a Terminate-Ack has been sent in reply to this. 577 If a connection is left suspended for more than the agreed maximum 578 time, then spoofing should be stopped and, where relevant, any 579 protocol sessions terminated locally. If the "Re-activation on Final 580 Termination" option has been negotiated on, then the connection 581 should be re-activated to inform the remote end accordingly (see 582 below). 584 4.3. Killing Off a Suspended Connection 586 If a connection is currently in the suspended state when it is to be 587 finally terminated, then three methods can be used: 589 1. Re-connect the connection in order to inform the remote end that 590 we are terminating it. 592 2. Just terminate the connection locally without informing the 593 remote end. 595 3. Terminate the connection locally without immediately informing 596 the remote end and then, when a subsequent connection is made to 597 the same destination, "piggy-back" an indication that the 598 previous connection has been terminated. 600 In the first case extra call charges will be incurred, but in the 601 second case the remote end will be left thinking that there is still 602 a logical connection - hence possibly preventing other calls from 603 being accepted until the configured timeout has expired. The third 604 case is a compromise between the two, but could work well in certain 605 situations. 607 Some equipment may implement a method for getting round the problem 608 of connections being left logically connected after the caller has 609 finished (e.g. by having enough "spare" resources that it does not 610 matter, or by disconnecting the oldest suspended connection if a new 611 call arrives) and hence may be willing to allow suspended connections 612 to be terminated in this way. Other equipment may not do so. 614 Whether to re-activate a suspended connection in order to terminate 616 =0C 618 DRAFT PPP Protocol Spoofing Control Protocol February 1996 620 it will be a PSCP configuration option. If either end tries to 621 negotiate it to ON, then the other end SHOULD accept this and agree 622 to do it. 624 4.4. Call Collision when Resuming a Connection 626 Under certain circumstances, there could be a possibility that both 627 ends might decide that a suspended connection is to be resumed at the 628 same time. This could result in calls being issued in both directions 629 for the same connection (i.e. "call collision"). 631 An implementation should record which end issued the most recent call 632 for each current connection. If it then receives an incoming call 633 which indicates the Call Reference number of a connection which is 634 not currently suspended, and it itself issued the last call on that 635 connection, then this must be a call collision situation. 637 The call collision situation is resolved by the use of the "Magic 638 Number" configuration option negotiated by LCP. A device which 639 detects such a call collision MUST terminate LCP on the call which 640 was issued by the end with the smaller magic number. 642 4.5. Use with PPP Multilink 644 If used with a PPP Multilink call[4], then PSCP negotiations should 645 take place when the Multilink "Bundle" is established or terminated 646 (although, as with other NCPs, they can actually take place either on 647 the Bundle, or on member links). There is no need to perform PSCP 648 negotiations when a link is added to, or removed from, the bundle. 650 Note that when Multilink is used, LCP negotiations take place 651 separately on each link within a Multilink bundle, and hence the Call 652 Reference number will be negotiated separately on individual member 653 links. When adding a link to an established Multilink bundle, there 654 is no requirement for LCP to specify a Call Reference number on the 655 new link, so long as the bundle is not at that time suspended. 657 When a Multilink call is being resumed, if two or more links are to 658 be initially established concurrently, then the Call Reference number 659 SHOULD be indicated on each, since it cannot be assumed which will 660 complete first. An implementation SHOULD therefore be prepared to 661 recieve an incoming call which indicates the Call Reference number of 662 a Multilink connection which is not currently suspended if the new 663 call is to be a member link of the bundle. 665 Where the Call Reference number is indicated on more than one link 666 within a Multilink bundle, an implementation MUST ensure that the 667 same Call Reference value is indicated on each link. 669 =0C 671 DRAFT PPP Protocol Spoofing Control Protocol February 1996 673 5. PSCP Packet Formats 675 Packets used by PSCP are formatted exactly the same as the those of 676 the Link Control Protocol [1]. In the case of the Terminate Request, 677 however, the Data field is defined as containing Termination Options, 678 as follows. 680 5.1 Terminate Request 682 A summary of the Terminate-Request packet format is shown below. The 683 fields are transmitted from left to right. 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Code | Identifier | Length | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Options ... 691 +-+-+-+-+ 693 Code 695 1 for Terminate-Request. 697 Identifier 699 As per the Link Control Protocol[1]. 701 Options 703 The options field is variable in length, and contains the list of 704 zero or more Termination Options. The format of Termination 705 Options is further described in a later chapter. 707 =0C 709 DRAFT PPP Protocol Spoofing Control Protocol February 1996 711 6. PSCP Configuration Options 713 PSCP Configuration Options allow the spoofing details to be 714 negotiated. If a Configuration Option is not included in a 715 Configure-Request packet, the default value for that Configuration 716 Option is assumed. 718 PSCP uses the same Configuration Option format defined for LCP [1], 719 with a separate set of Options. 721 Up-to-date values of the PSCP Option Type field will be specified in 722 the most recent "Assigned Numbers" RFC [5]. Current values are 723 assigned as follows: 725 1 Maximum Call Suspension Time 726 2 Spoofed Protocol Support 727 3 Maximum Protocol Sessions 728 4 Re-activation on Final Termination 729 5 Call-back Number 730 6 Call-back Name 732 =0C 734 DRAFT PPP Protocol Spoofing Control Protocol February 1996 736 6.1. Maximum Call Suspension Time 738 Description 740 The Maximum Call Suspension Time Configuration Option is used to 741 negotiate a limit on how long a connection can be left in the 742 suspended state. 744 This value MAY be negotiated downwards, but MUST NOT be negotiated 745 upwards. 747 If this option is not present then the default is that a connection 748 can be left in the suspended state indefinitely. 750 If a connection is left suspended for more than the agreed maximum 751 time, then it should be terminated as described previously. 753 A summary of the Maximum Call Suspension Time Option format is shown 754 below. The fields are transmitted from left to right. 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type | Length | Time Limit | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Type 764 1 766 Length 768 4 770 Time Limit 772 This value specifies the maximum time for which a connection can 773 be left in the suspended state, in minutes. The value zero means 774 that there is no limit. 776 =0C 778 DRAFT PPP Protocol Spoofing Control Protocol February 1996 780 6.2. Spoofed Protocol Support 782 Description 784 The Spoofed Protocol Support Configuration Option is used to indicate 785 the set of protocols whose spoofing is supported. 787 This option MUST be present in a Configure-Request. 789 Each device should send a list of the protocols which it supports in 790 its Configure-Request, and the recipient should then use a Configure- 791 Nak to remove any protocols which it does not support. Hence both 792 ends should arrive at a list of protocols whose spoofing is supported 793 by both. 795 A summary of the Spoofed Protocol Support Option format is shown 796 below. The fields are transmitted from left to right. 798 0 1 2 799 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | Protocols ... 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Type 806 2 808 Length 810 >=3D 3 812 =0C 814 DRAFT PPP Protocol Spoofing Control Protocol February 1996 816 Protocols 818 This field contains a list of protocol values, each 8-bits wide, 819 indicating the protocols whose spoofing is supported. Currently 820 assigned values are as follows: 822 0 Novell NCP (the IPX Netware Core Protocol) 823 1 Novell SPX 824 2 Novell RIP/SAP 825 3 NetBEUI (NetBIOS over LLC2)[8] 826 4 NetBIOS over TCP/IP[7] 827 5 TCP Keep Alives [3] 828 6 OSI Transport Class 4 over Null Network Layer 829 7 LLC2 830 8 SMB Echo Requests 831 9 Microsoft NetBIOS over IPX 832 10 Novell NetBIOS over IPX 833 11 Spanning Tree BPDUs 834 12 Ping over IP 836 =0C 838 DRAFT PPP Protocol Spoofing Control Protocol February 1996 840 6.3. Maximum Protocol Sessions 842 Description 844 The Maximum Protocol Sessions Configuration Option is to negotiate a 845 limit on the number of protocol sessions of any type which can be 846 spoofed at any time. 848 This value MAY be negotiated downwards, but MUST NOT be negotiated 849 upwards. 851 If this option is not present then the default is that it an 852 unlimited number of protocol sessions can be spoofed. 854 How a device uses this limit is implementation-specific. 856 A summary of the Maximum Protocol Sessions Option format is shown 857 below. The fields are transmitted from left to right. 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Type | Length | Limit | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 Type 867 3 869 Length 871 4 873 Limit 875 This value specifies the limit on the number of protocol sessions 876 which can be spoofed at any time. The value zero means that there 877 is no limit. 879 =0C 881 DRAFT PPP Protocol Spoofing Control Protocol February 1996 883 6.4. Re-activation on Final Termination 885 Description 887 The Re-activation on Final Termination Configuration Option is to 888 negotiate whether to re-activate connections in order to finally 889 terminate a connection which is to be terminated whilst suspended, as 890 described previously. 892 If either end tries to negotiate this option to enable re-activation 893 of connections for this purpose, then the other end SHOULD accept 894 this and agree to do it. 896 If this option is not present then the default value is that 897 connections should be re-activated if a connection is to be 898 terminated whilst suspended. 900 A summary of the Re-activation on Final Termination Option format is 901 shown below. The fields are transmitted from left to right. 903 0 1 2 904 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type | Length | Enable | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Type 911 4 913 Length 915 3 917 Enable 919 If the value is 1 then connections should be re-activated if a 920 connection is to be terminated whilst suspended. If the value is 0 921 then they should not. 923 =0C 925 DRAFT PPP Protocol Spoofing Control Protocol February 1996 927 6.5. Call-Back Number 929 Description 931 The Call-Back Number Configuration Option is used by the calling 932 party to inform the called party of the number to use to call back in 933 order to resume a suspended connection. 935 This option can appear more than once in a PSCP Configuration 936 Request, hence allowing a set of call back numbers to be specified. 937 Where there is more than one number, the recipient SHOULD use these 938 in the order given when attempting to call back. 940 This option also provides for the numbers not necessarily being 941 limited to the same medium that was used for the original call (for 942 example, a caller could give an ISDN number as the primary call-back 943 number, but also supply a telephone number to use in case the ISDN is 944 busy). 946 A summary of the Call-Back Number Option format is shown below. Note 947 that this option is very similar to the LCP "Endpoint Discriminator" 948 option (as defined for Multilink PPP[4]) but has an additional Call- 949 Type field. The fields are transmitted from left to right. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Type | Length | Class | Call-Type | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Address ... 957 +-+-+-+-+-+-+-+-+ 959 Type 961 5 963 Length 965 4 + length of Address 967 Class 969 The Class field is one octet and indicates the type of number. The 970 value is as per the Class in the LCP "Endpoint Discriminator" 971 option. 973 =0C 975 DRAFT PPP Protocol Spoofing Control Protocol February 1996 977 Call-Type 979 The Call-Type field is one octet and indicates the type of call to 980 make for a call-back using this number. Note that this is 981 different to the Class since, for example, the E.164 number class 982 could be either an ISDN or telephone number. The most up-to-date 983 values of the PSCP Call-Back Number Type field will be specified 984 in the most recent "Assigned Numbers" RFC [5]. Current values are 985 assigned as follows: 987 0 No type specified (type is inherent in the Class) 989 1 Telephone call 991 2 ISDN call 993 Address 995 The Address field is one or more octets and indicates the call- 996 back address within the selected class. The value is as per the 997 Address field in the LCP "Endpoint Discriminator" option. 999 =0C 1001 DRAFT PPP Protocol Spoofing Control Protocol February 1996 1003 6.6. Call-Back Name 1005 Description 1007 The Call-Back Name Configuration Option is used by the calling party 1008 to inform the called party of the name to use for authentication when 1009 it makes a call back in order to resume a suspended connection. 1011 This option MAY be omitted in circumstances where the calling party 1012 knows the name of the called party (for example, with CHAP 1013 authentication[6] the called party has a "system name" which was 1014 quoted in its original CHAP challenge). If this option is not present 1015 then the called party MUST use the same name which it used during 1016 authentication of the original call. 1018 Note that for security reasons the password, or CHAP secret, is not 1019 communicated. It is therefore a requirement that the same 1020 password/secret that was used for the original call is used in a 1021 call-back. This may have configuration implications at the calling 1022 end. 1024 A summary of the Call-Back Name Option format is shown below. The 1025 fields are transmitted from left to right. 1027 0 1 2 1028 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Type | Length | Name ... 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 Type 1035 7 1037 Length 1039 2 + length of Name 1041 Name 1043 The Name field is one or more octets and indicates the name to use 1044 for authentication in a call-back. 1046 =0C 1048 DRAFT PPP Protocol Spoofing Control Protocol February 1996 1050 7. PSCP Termination Options 1052 PSCP Termination Options allow information pertaining to a call being 1053 closed to be indicated in a Terminate-Request packet. 1055 The Termination Options are coded in the same way as the 1056 Configuration Options in a Configure-Request packet, as defined for 1057 LCP [1]. 1059 Up-to-date values of the PSCP Termination Option Type field will be 1060 specified in the most recent "Assigned Numbers" RFC [5]. Current 1061 values are assigned as follows: 1063 1 Call Termination Reason 1065 7.1. Call Termination Reason 1067 Description 1069 The Call Termination Reason Termination Option is used in a Terminate 1070 Request to indicate the reason for the call being dropped. 1072 If this option is not present then the default value is that the 1073 connection is to be finally terminated. 1075 A summary of the Call Termination Reason Option format is shown 1076 below. The fields are transmitted from left to right. 1078 0 1 2 1079 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type | Length | Reason | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Type 1086 1 1088 Length 1090 3 1092 Reason 1094 If the value is 0 the connection is to be finally terminated, and 1095 if the value is 1 the connection is to be suspended. 1097 =0C 1099 DRAFT PPP Protocol Spoofing Control Protocol February 1996 1101 APPENDIX 1 1103 Switch-Over to a Low-Cost Secondary Channel 1105 An alternative to protocol spoofing is to switch over to using a low- 1106 cost low-bandwidth secondary channel, if one is available, when a 1107 connection is idle. An example of this is the ISDN D-channel. 1109 The ability to switch smoothly between PPP channels without 1110 disruption of data flow can be achieved using the PPP Multilink 1111 procedure[4], as follows: 1113 The connection is initially established on one or more links using 1114 the PPP Multilink procedure. PSCP is then negotiated on the 1115 Multilink "Bundle", agreeing that "switch-over" is required rather 1116 than "spoofing". 1118 When a peer decides to initiate "switch-over" it should use the 1119 PPP Multilink procedure to establish a call on the low-cost 1120 secondary channel, and should make this a member-link of the 1121 Multilink group. When this link has reached the Network-Layer 1122 phase, then it should initiate termination of all other member 1123 links of the Multilink group (the primary channel(s)). Note that 1124 in this case no PSCP Terminate-Request is required. 1126 The same procedure is used to switch back to the primary channel(s) 1127 if the traffic on the link increases. 1129 The use of this switch-over method could possibly be negotiated in 1130 the PSCP Configuration-Request options, or could be the subject of a 1131 separate Network Control Protocol. This is for further study. 1133 Configuring for this method will only be allowed if PPP Multilink has 1134 been established. If an attempt is made to enable it in a Configure- 1135 Request on a non-Multilink call, then a Configure-Nak should be 1136 returned. 1138 If an implementation is not able to operate a low-cost secondary 1139 channel (e.g. an ISDN device with no D-channel capability) then it 1140 should Configure-Nak this option. 1142 =0C 1144 DRAFT PPP Protocol Spoofing Control Protocol February 1996 1146 Security Considerations 1148 Security issues are not discussed in this memo. 1150 References 1152 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 1153 51, RFC 1661, Daydreamer, July 1994. 1155 [2] Simpson, W., Editor, "PPP over ISDN", RFC 1618, Daydreamer, May 1156 1994. 1158 [3] "Requirements for Internet hosts - communication layers ", RFC 1159 1122, October 1989. 1161 [4] Sklower, K., "The PPP Multilink Protocol (MP)", RFC 1717, 1162 November 1994. 1164 [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1165 1340, USC/Information Sciences Institute, July 1992. 1167 [6] Lloyd, B. / Simpson, W., "PPP Authentication Protocols", RFC 1168 1334, October 1992. 1170 [7] "Protocol standard for a NetBIOS service on a TCP/UDP 1171 transport: Detailed specifications ", RFC 1002, March 1987. 1173 [8] "Local Area Network Technical Reference", IBM document SC30- 1174 3383-03 1176 Acknowledgments 1178 Thanks go to Sam Lau and Robert Bell of Global Village Communication 1179 (UK) Ltd. for information on protocol spoofing used to compile this 1180 document, to Anthony Discolo and his colleagues at Microsoft for 1181 their comments, which have been incorporated into the document, and 1182 to Jim Phillippo of Xyplex for some additional information. 1184 =0C 1186 DRAFT PPP Protocol Spoofing Control Protocol February 1996 1188 Chair's Address 1190 The working group can be contacted via the current chair: 1192 Fred Baker 1193 Senior Software Engineer 1194 Cisco Systems 1195 519 Lado Drive 1196 Santa Barbara, California 93111 1198 Phone: (408) 526-4257 1199 EMail: fred@cisco.com 1201 Author's Address 1203 Questions about this memo can also be directed to: 1205 Ian David Puleston 1206 Global Village Communication (UK) Ltd. 1207 Tempest Court 1208 Broughton Hall 1209 Skipton, North Yorkshire, BD23 3AE 1210 England 1211 Tel: +44 (0) 1756 702500 1212 Fax: +44 (0) 1756 797866 1214 EMail: ian_puleston@globalvillage.co.uk 1215 or: ianp@knx.co.uk