Network Working Group I D Puleston Internet Draft Global Village Communication (UK) Ltd. expires in six months February 1996 PPP Protocol Spoofing Control Protocol (PSCP) Status of this Memo This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes a Network Control Protocol which will allow the two ends of a connection to agree to carry out protocol spoofing when an idle link is temporarily disconnected in order to save on connection charges. This work was originally motivated by the desire to exploit the fast call setup capability of ISDN, but is equally applicable in any situation in which a PPP connection is made over a link which can be temporarily suspended for whatever reason. Puleston expires in six months [Page i] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 Table of Contents 1. Introduction .......................................... 1 2. Overview of Protocol Spoofing ......................... 2 2.1 Limiting Session Length ............................ 4 2.2 Information Required for Protocol Spoofing ......... 4 3. PPP Link Control Protocol Extensions .................. 5 3.1. LCP Configuration Options .......................... 5 3.1.1. Call Reference Number .......................... 6 4. The Protocol Spoofing Control Protocol ................ 9 4.1 Call Connection and Re-Connection .................. 10 4.2 Call Termination / Suspension ...................... 10 4.3 Killing Off a Suspended Connection ................. 11 4.4. Call Collision when Resuming a Connection .......... 12 4.5. Use with PPP Multilink ............................. 12 5. PSCP Packet Formats ................................... 13 5.1 Terminate Request .................................. 13 6. PSCP Configuration Options ............................ 14 6.1 Maximum Call Suspension Time ....................... 15 6.2 Spoofed Protocol Support ........................... 16 6.3 Maximum Protocol Sessions .......................... 18 6.4 Re-activation on Final Termination ................. 19 6.5 Call-Back Number ................................... 20 6.6 Call-Back Name ..................................... 22 7. PSCP Termination Options .............................. 23 7.1 Call Termination Reason ............................ 23 APPENDIX 1: Switch-Over to a Low-Cost Secondary Channel ...... 24 SECURITY CONSIDERATIONS ...................................... 25 REFERENCES ................................................... 25 ACKNOWLEDGEMENTS ............................................. 25 CHAIR'S ADDRESS .............................................. 26 AUTHOR'S ADDRESS ............................................. 26 Puleston expires in six months [Page ii] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 1. Introduction With a transfer medium such as ISDN, calls can be connected and disconnected very quickly, and this gives devices scope to bring a connection up and down as and when required, in order to keep call charges to a minimum. A call can be dropped during periods of inactivity, and then automatically re-connected when data activity is resumed, without the higher-layer protocols being aware of any change. This will be referred to here as "suspending" the connection. Suspending a call in this way, however, gives rise to a problem with protocols which generate intermittent protocol messages even when a connection is idle (for example Novell transfers regular "Keep Alive" messages between servers and clients). If the link were to be re- connected in order to transfer every protocol message, then unnecessary call charges would be incurred. This is a particular problem in the case of LAN interconnection via WAN links, such as ISDN. The protocols running on the LAN are typically designed specifically for the LAN where the topology is fixed, and hence they assume that a connection across the LAN will be permanently physically connected throughout its duration. The problem is solved by monitoring the traffic on the link and recognising individual sessions of the relevant protocols. When a connection is suspended, then the devices at the two ends can themselves generate the protocol messages locally ("spoof" the protocols) instead of re-connecting the call for the transfer of protocol messages. In order for two independent devices at either end of a connection to carry out protocol spoofing, it is only necessary for them to agree on what they are spoofing, not on how they actually carry out the spoofing. Once the connection is suspended each will take care of its end of the connection independently of the other. Protocol spoofing requires the exchange of information between the two ends so that each knows what the other is doing. At the very least, it is necessary for the two ends to know that a terminating call is being temporarily suspended rather than permanently disconnected, and to be able to identify a new call as being a resumption of a particular suspended connection. This specification defines a PPP Network Control Protocol to achieve this. Puleston expires in six months [Page 1] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 2. Overview of Protocol Spoofing Protocol Spoofing takes place when the communications medium is temporarily disconnected during periods of inactivity, and makes sure that the higher-layer protocols are unaware of the lower layers having been disconnected. This prevents problems such as login sessions being terminated, or remote resources disappearing. The spoofing of a protocol would typically involve the device at each end of the suspended link: 1. Filtering out certain protocol messages from the local hosts so that these do not themselves cause the ISDN call to re-connect. 2. Generating the protocol messages to fool the local hosts into believing that the remote hosts are still connected. Protocols requiring spoofing basically fall into two categories: 1. Protocols using solicited messages, where one end sends out requests to which the remote end should respond. In these cases the local device must spoof the protocol whilst the link is suspended by generating the response itself when it receives a request (as shown in the diagram below). 2. Protocols involving unsolicited messages (e.g. advertising protocols, where one end sends out unsolicited messages advertising its presence). In these cases the remote device must spoof the protocol whilst the link is suspended by generating the messages itself at the relevant times. The following shows an example of how a typical server-client LAN protocol may regularly send out a protocol message to check that a client is still connected using a request-response protocol: Puleston expires in six months [Page 2] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 Server Router Router Client | LAN | PPP-Link | LAN | | | | | | Are you there ? | | | |--------------------+--------------------+--------------->| | | | | | Here I am | | | |<-------------------+--------------------+----------------| | | | | And the following shows how the first router would spoof this protocol whilst the PPP link is suspended: Server Router Router Client | LAN | Link Suspended | LAN | | | | | | Are you there ? | | | |------------------->| | | | | | | | Here I am | | | |<-------------------| | | | | | | Assuming that two devices each have the ability to carry out protocol spoofing, then the basic requirement for their spoofing systems to inter-work is that whilst a connection is suspended: - if a session is alive and being spoofed at one end, then the other end should also, if relevant, be spoofing it, - one end should not keep spoofing a session if that session has been terminated at the other end. This means that the basic requirement for an inter-working protocol between them is that each knows exactly which protocol sessions are being spoofed by the other, and when the spoofing of each session will cease. Some examples of protocols which require spoofing when connections are suspended are: - Novell IPX/SPX - Novell RIP/SAP - NetBIOS / NetBEUI - TCP implementations which use TCP "Keep Alives"[3] - OSI Transport Class 4 - Ping over IP (there are some systems which implement a form of "keep alive" by regularly sending a "ping" to the remote end). Puleston expires in six months [Page 3] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 An additional complexity is that when certain protocols can be run in combination with other protocols, then the ability to spoof them may depend on which they are used with (for example a device which can spoof NetBIOS over LLC1 may not be able to spoof NetBIOS over TCP/IP). 2.1. Limiting Session Length A potential problem with the idea of suspending connections comes about in a situation where many users require access to a limited number of shared resources (such as the ISDN channels on a LAN access server). If one user leaves his connection suspended because it is costing him nothing in call charges, then he is "hogging" resources which others may require. Because of this it may be desirable to limit the time for which protocol spoofing can be maintained on a connection. An additional benefit is that if a device is, for example, turned-off whilst it has a connection suspended, the remote end will time-out and abort the connection. 2.2. Information Required for Protocol Spoofing Protocol spoofing requires exchange of information between the two ends so that each knows what the other is doing. Each end must know: 1. When a call is cleared-down due to the connection being temporarily suspended rather than permanently disconnected. 2. When a new call is a resumption of a suspended connection, and which particular suspended connection is being resumed. 3. The capabilities of the device at the other end (for example the spoofing of some protocols may not be supported by both). 4. Any limits (such as the maximum time for which a spoofing session should be maintained) which must be agreed with the device at the other end. 5. Call-back information, supplied by the calling party so that the called party can call back in order to resume a suspended connection. This can include the number to call, authentication information, etc. Puleston expires in six months [Page 4] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 3. PPP Link Control Protocol Extensions There are certain options of various Network Control Protocols which, when a suspended connection is re-connected, must be the same as they were in the initial call (one example could be the IP address negotiated by IPCP). Because of this, both ends must know whether a call is a re-connection, and if so, which call is being re-connected, before they start the NCP negotiations. This is achieved by associating a "Call Reference" number with each connection. This call reference number will remain valid when the connection is suspended, and will be used to identify it when it is re-connected. The "Call Reference" number MUST be negotiated prior to the start of the NCP negotiations, and is therefore negotiated by the Link Control Protocol[1]. 3.1. LCP Configuration Options The Protocol Spoofing Control Protocol introduces the use of an additional LCP Configuration Option: Call Reference Number The value of this LCP Configuration Option will be specified in the "Assigned Numbers" RFC [5]. Puleston expires in six months [Page 5] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 3.1.1. Call Reference Number Description The Call Reference Number Configuration Option is used to negotiate unique reference numbers, which can then be used to identify the connection if it is suspended. Each end indicates a number which it can use to identify the connection, and the numbers provided by the two ends do not need to be the same. It will be used as follows when the Protocol Spoofing Control Protocol is to be used: - On a new connection, the calling end SHOULD include this option in its Configure Request with the value zero. The called end should then return a Configure Nak, putting in a non-zero value which it can use to uniquely identify the connection. - The called end SHOULD NOT include this option in its initial Configure Request (since it does not at that point know whether it is a new connection or a re-connection). On a new connection, the calling end SHOULD then return a Configure Nak, supplying a non- zero value which it can use to uniquely identify the connection. - On re-connection of a suspended connection, the calling end should include this option in its Configure Request with the non-zero value which was indicated by the remote end in the initial call. The called peer will use this value to identify the suspended connection. Note that the calling end can then tell if a call is is a new connection or a re-connection, since the value of this option in the caller's initial Configure Request is zero in the former case, and non-zero in the latter. When a connection which has been suspended is re-connected, the calling end MAY return a Configure Nak, with the non-zero value which it itself indicated in the initial call, but this is not strictly necessary. The following diagrams illustrate how this option is used: Puleston expires in six months [Page 6] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 1. Initial Setup of a New Connection End A End B | | | Call Sent | |--------------------------------------------------------->| | | | Call Acknowledged | |<---------------------------------------------------------| | | | Configure Req: No call Ref option | |<---------------------------------------------------------| | | | Configure Req: Call Ref. =3D 0 | |--------------------------------------------------------->| | | | Configure Nak: Call Ref. =3D A's ref. | |--------------------------------------------------------->| | | | Configure Nak: Call Ref. =3D B's ref. | |<---------------------------------------------------------| | | | Configure Req: Call Ref. =3D A's ref. | |<---------------------------------------------------------| | | | Configure Req: Call Ref. =3D B's ref. | |--------------------------------------------------------->| | | 2. Re-Connection of a Suspended Connection End A End B | | | Call Sent | |--------------------------------------------------------->| | | | Call Acknowledged | |<---------------------------------------------------------| | | | Configure Req: No call Ref option | |<---------------------------------------------------------| | | | Configure Req: Call Ref. =3D B's ref. | |--------------------------------------------------------->| | | In summary, a Configure Request contains the reference number which is meaningful to the remote end, and a Configure Nak is used to inform the other end of this in the first place. A Configure Request Puleston expires in six months [Page 7] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 with the value zero in this option is used to request the remote end's reference number, and indicates a new connection. If a Configure-Request is received with the Call Reference Number option indicating a re-connection of a suspended connection, but no suspended connection exists with the given Call Reference Number, then the call SHOULD be terminated. A call reference value MUST be negotiated by this option for both ends of the call if the Protocol Spoofing Control Protocol is to be used. Note that if authentication (e.g. PAP/CHAP) is used, then on re- connection of a suspended connection, the called end SHOULD check that the authentication user ID is the same as in the original call. If it is not the same, then it should terminate the call. An implementation MAY also choose to similarly check the Endpoint Discriminator when this is used. A summary of the Call Reference Number Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reference Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 4 Reference Number This specifies the call reference number to be used. Puleston expires in six months [Page 8] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 4. The Protocol Spoofing Control Protocol The Protocol Spoofing Control Protocol (PSCP) is responsible for enabling the two ends of the point-to-point link to negotiate what can be spoofed, and any limits to be imposed. It is also responsible for enabling the two ends to agree that a PPP connection is to be suspended, and for controlling resumption of a suspended connection. PSCP uses the same packet exchange mechanism as the Link Control Protocol [1]. PSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. PSCP packets received before this phase is reached SHOULD be silently discarded. PSCP may only be started if call reference values have been negotiated for both ends of the connection by LCP. The Protocol Spoofing Control Protocol is exactly the same as the Link Control Protocol with the following exceptions: Data Link Layer Protocol Field Exactly one PSCP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates PSCP (the value will be specified in the "Assigned Numbers" RFC [5]). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes SHOULD be treated as unrecognized and SHOULD result in Code-Rejects. Timeouts PSCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation SHOULD be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation should give up only after user intervention or a configurable amount of time. Packet Formats The Terminate-Request and Terminate-Ack messages used by PSCP include parameters for controlling the suspension of a connection. Configuration Option Types PSCP has a distinct set of Configuration Options, which are defined in this document. Puleston expires in six months [Page 9] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 A PSCP Configuration Request can be sent by either end at any time during the life of the call, in order to re-negotiate the configuration options. In particular, as new protocol sessions are established, an implementation may with to re-negotiate the set of protocols whose spoofing is supported, 4.1. Call Connection and Re-Connection The Link Control Protocol's Call Reference Number configuration option enables a device receiving an incoming call to know whether it is a new connection, or a resumption of a suspended connection, and to be able to identify the suspended connection in the latter case. Other parameters required for protocol spoofing are negotiated by PSCP configuration messages when the call is connected or re- connected. It SHOULD NOT be assumed that a suspended connection will necessarily be re-connected on the same link when multiple links are available (e.g. ISDN B-channels). Re-connection of a suspended connection MAY be initiated by either end, although some implementations may only allow the original caller to do this. 4.2. Call Termination / Suspension The PSCP Terminate-Request message includes a parameter indicating the reason for call disconnection as one of: - final call termination. - temporary suspension of the call. Call suspension can be initiated by either end. The length of time for which a connection has to be idle before it is suspended is not negotiated by PSCP, and hence the two ends could be configured to suspend the connection at a different time. An implementation should allow for the remote end possibly suspending the connection before its own idle timer has expired. If a device which has sent a Terminate-Request message indicating temporary suspension of a connection receives a Terminate-Request message indicating final call termination, or vice-versa, then the latter SHOULD override the former, and the connection SHOULD be terminated rather than suspended. Puleston expires in six months [Page 10] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 A PPP device should only initiate temporary suspension of a connection if: - PPP has reached the Network-Layer phase and PSCP has reached the Opened state, - and there are no sessions running over the link using protocols whose spoofing has been negotiated off. The devices should then only enter the spoofing state if a Terminate- Request has been sent indicating temporary suspension of the connection, and a Terminate-Ack has been sent in reply to this. If a connection is left suspended for more than the agreed maximum time, then spoofing should be stopped and, where relevant, any protocol sessions terminated locally. If the "Re-activation on Final Termination" option has been negotiated on, then the connection should be re-activated to inform the remote end accordingly (see below). 4.3. Killing Off a Suspended Connection If a connection is currently in the suspended state when it is to be finally terminated, then three methods can be used: 1. Re-connect the connection in order to inform the remote end that we are terminating it. 2. Just terminate the connection locally without informing the remote end. 3. Terminate the connection locally without immediately informing the remote end and then, when a subsequent connection is made to the same destination, "piggy-back" an indication that the previous connection has been terminated. In the first case extra call charges will be incurred, but in the second case the remote end will be left thinking that there is still a logical connection - hence possibly preventing other calls from being accepted until the configured timeout has expired. The third case is a compromise between the two, but could work well in certain situations. Some equipment may implement a method for getting round the problem of connections being left logically connected after the caller has finished (e.g. by having enough "spare" resources that it does not matter, or by disconnecting the oldest suspended connection if a new call arrives) and hence may be willing to allow suspended connections to be terminated in this way. Other equipment may not do so. Whether to re-activate a suspended connection in order to terminate Puleston expires in six months [Page 11] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 it will be a PSCP configuration option. If either end tries to negotiate it to ON, then the other end SHOULD accept this and agree to do it. 4.4. Call Collision when Resuming a Connection Under certain circumstances, there could be a possibility that both ends might decide that a suspended connection is to be resumed at the same time. This could result in calls being issued in both directions for the same connection (i.e. "call collision"). An implementation should record which end issued the most recent call for each current connection. If it then receives an incoming call which indicates the Call Reference number of a connection which is not currently suspended, and it itself issued the last call on that connection, then this must be a call collision situation. The call collision situation is resolved by the use of the "Magic Number" configuration option negotiated by LCP. A device which detects such a call collision MUST terminate LCP on the call which was issued by the end with the smaller magic number. 4.5. Use with PPP Multilink If used with a PPP Multilink call[4], then PSCP negotiations should take place when the Multilink "Bundle" is established or terminated (although, as with other NCPs, they can actually take place either on the Bundle, or on member links). There is no need to perform PSCP negotiations when a link is added to, or removed from, the bundle. Note that when Multilink is used, LCP negotiations take place separately on each link within a Multilink bundle, and hence the Call Reference number will be negotiated separately on individual member links. When adding a link to an established Multilink bundle, there is no requirement for LCP to specify a Call Reference number on the new link, so long as the bundle is not at that time suspended. When a Multilink call is being resumed, if two or more links are to be initially established concurrently, then the Call Reference number SHOULD be indicated on each, since it cannot be assumed which will complete first. An implementation SHOULD therefore be prepared to recieve an incoming call which indicates the Call Reference number of a Multilink connection which is not currently suspended if the new call is to be a member link of the bundle. Where the Call Reference number is indicated on more than one link within a Multilink bundle, an implementation MUST ensure that the same Call Reference value is indicated on each link. Puleston expires in six months [Page 12] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 5. PSCP Packet Formats Packets used by PSCP are formatted exactly the same as the those of the Link Control Protocol [1]. In the case of the Terminate Request, however, the Data field is defined as containing Termination Options, as follows. 5.1 Terminate Request A summary of the Terminate-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 1 for Terminate-Request. Identifier As per the Link Control Protocol[1]. Options The options field is variable in length, and contains the list of zero or more Termination Options. The format of Termination Options is further described in a later chapter. Puleston expires in six months [Page 13] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6. PSCP Configuration Options PSCP Configuration Options allow the spoofing details to be negotiated. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed. PSCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. Up-to-date values of the PSCP Option Type field will be specified in the most recent "Assigned Numbers" RFC [5]. Current values are assigned as follows: 1 Maximum Call Suspension Time 2 Spoofed Protocol Support 3 Maximum Protocol Sessions 4 Re-activation on Final Termination 5 Call-back Number 6 Call-back Name Puleston expires in six months [Page 14] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6.1. Maximum Call Suspension Time Description The Maximum Call Suspension Time Configuration Option is used to negotiate a limit on how long a connection can be left in the suspended state. This value MAY be negotiated downwards, but MUST NOT be negotiated upwards. If this option is not present then the default is that a connection can be left in the suspended state indefinitely. If a connection is left suspended for more than the agreed maximum time, then it should be terminated as described previously. A summary of the Maximum Call Suspension Time Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Time Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 4 Time Limit This value specifies the maximum time for which a connection can be left in the suspended state, in minutes. The value zero means that there is no limit. Puleston expires in six months [Page 15] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6.2. Spoofed Protocol Support Description The Spoofed Protocol Support Configuration Option is used to indicate the set of protocols whose spoofing is supported. This option MUST be present in a Configure-Request. Each device should send a list of the protocols which it supports in its Configure-Request, and the recipient should then use a Configure- Nak to remove any protocols which it does not support. Hence both ends should arrive at a list of protocols whose spoofing is supported by both. A summary of the Spoofed Protocol Support Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Protocols ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length >=3D 3 Puleston expires in six months [Page 16] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 Protocols This field contains a list of protocol values, each 8-bits wide, indicating the protocols whose spoofing is supported. Currently assigned values are as follows: 0 Novell NCP (the IPX Netware Core Protocol) 1 Novell SPX 2 Novell RIP/SAP 3 NetBEUI (NetBIOS over LLC2)[8] 4 NetBIOS over TCP/IP[7] 5 TCP Keep Alives [3] 6 OSI Transport Class 4 over Null Network Layer 7 LLC2 8 SMB Echo Requests 9 Microsoft NetBIOS over IPX 10 Novell NetBIOS over IPX 11 Spanning Tree BPDUs 12 Ping over IP Puleston expires in six months [Page 17] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6.3. Maximum Protocol Sessions Description The Maximum Protocol Sessions Configuration Option is to negotiate a limit on the number of protocol sessions of any type which can be spoofed at any time. This value MAY be negotiated downwards, but MUST NOT be negotiated upwards. If this option is not present then the default is that it an unlimited number of protocol sessions can be spoofed. How a device uses this limit is implementation-specific. A summary of the Maximum Protocol Sessions Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 4 Limit This value specifies the limit on the number of protocol sessions which can be spoofed at any time. The value zero means that there is no limit. Puleston expires in six months [Page 18] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6.4. Re-activation on Final Termination Description The Re-activation on Final Termination Configuration Option is to negotiate whether to re-activate connections in order to finally terminate a connection which is to be terminated whilst suspended, as described previously. If either end tries to negotiate this option to enable re-activation of connections for this purpose, then the other end SHOULD accept this and agree to do it. If this option is not present then the default value is that connections should be re-activated if a connection is to be terminated whilst suspended. A summary of the Re-activation on Final Termination Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Enable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length 3 Enable If the value is 1 then connections should be re-activated if a connection is to be terminated whilst suspended. If the value is 0 then they should not. Puleston expires in six months [Page 19] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6.5. Call-Back Number Description The Call-Back Number Configuration Option is used by the calling party to inform the called party of the number to use to call back in order to resume a suspended connection. This option can appear more than once in a PSCP Configuration Request, hence allowing a set of call back numbers to be specified. Where there is more than one number, the recipient SHOULD use these in the order given when attempting to call back. This option also provides for the numbers not necessarily being limited to the same medium that was used for the original call (for example, a caller could give an ISDN number as the primary call-back number, but also supply a telephone number to use in case the ISDN is busy). A summary of the Call-Back Number Option format is shown below. Note that this option is very similar to the LCP "Endpoint Discriminator" option (as defined for Multilink PPP[4]) but has an additional Call- Type field. The fields are transmitted from left to right. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Class | Call-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address ... +-+-+-+-+-+-+-+-+ Type 5 Length 4 + length of Address Class The Class field is one octet and indicates the type of number. The value is as per the Class in the LCP "Endpoint Discriminator" option. Puleston expires in six months [Page 20] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 Call-Type The Call-Type field is one octet and indicates the type of call to make for a call-back using this number. Note that this is different to the Class since, for example, the E.164 number class could be either an ISDN or telephone number. The most up-to-date values of the PSCP Call-Back Number Type field will be specified in the most recent "Assigned Numbers" RFC [5]. Current values are assigned as follows: 0 No type specified (type is inherent in the Class) 1 Telephone call 2 ISDN call Address The Address field is one or more octets and indicates the call- back address within the selected class. The value is as per the Address field in the LCP "Endpoint Discriminator" option. Puleston expires in six months [Page 21] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 6.6. Call-Back Name Description The Call-Back Name Configuration Option is used by the calling party to inform the called party of the name to use for authentication when it makes a call back in order to resume a suspended connection. This option MAY be omitted in circumstances where the calling party knows the name of the called party (for example, with CHAP authentication[6] the called party has a "system name" which was quoted in its original CHAP challenge). If this option is not present then the called party MUST use the same name which it used during authentication of the original call. Note that for security reasons the password, or CHAP secret, is not communicated. It is therefore a requirement that the same password/secret that was used for the original call is used in a call-back. This may have configuration implications at the calling end. A summary of the Call-Back Name Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 Length 2 + length of Name Name The Name field is one or more octets and indicates the name to use for authentication in a call-back. Puleston expires in six months [Page 22] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 7. PSCP Termination Options PSCP Termination Options allow information pertaining to a call being closed to be indicated in a Terminate-Request packet. The Termination Options are coded in the same way as the Configuration Options in a Configure-Request packet, as defined for LCP [1]. Up-to-date values of the PSCP Termination Option Type field will be specified in the most recent "Assigned Numbers" RFC [5]. Current values are assigned as follows: 1 Call Termination Reason 7.1. Call Termination Reason Description The Call Termination Reason Termination Option is used in a Terminate Request to indicate the reason for the call being dropped. If this option is not present then the default value is that the connection is to be finally terminated. A summary of the Call Termination Reason Option format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 3 Reason If the value is 0 the connection is to be finally terminated, and if the value is 1 the connection is to be suspended. Puleston expires in six months [Page 23] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 APPENDIX 1 Switch-Over to a Low-Cost Secondary Channel An alternative to protocol spoofing is to switch over to using a low- cost low-bandwidth secondary channel, if one is available, when a connection is idle. An example of this is the ISDN D-channel. The ability to switch smoothly between PPP channels without disruption of data flow can be achieved using the PPP Multilink procedure[4], as follows: The connection is initially established on one or more links using the PPP Multilink procedure. PSCP is then negotiated on the Multilink "Bundle", agreeing that "switch-over" is required rather than "spoofing". When a peer decides to initiate "switch-over" it should use the PPP Multilink procedure to establish a call on the low-cost secondary channel, and should make this a member-link of the Multilink group. When this link has reached the Network-Layer phase, then it should initiate termination of all other member links of the Multilink group (the primary channel(s)). Note that in this case no PSCP Terminate-Request is required. The same procedure is used to switch back to the primary channel(s) if the traffic on the link increases. The use of this switch-over method could possibly be negotiated in the PSCP Configuration-Request options, or could be the subject of a separate Network Control Protocol. This is for further study. Configuring for this method will only be allowed if PPP Multilink has been established. If an attempt is made to enable it in a Configure- Request on a non-Multilink call, then a Configure-Nak should be returned. If an implementation is not able to operate a low-cost secondary channel (e.g. an ISDN device with no D-channel capability) then it should Configure-Nak this option. Puleston expires in six months [Page 24] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [2] Simpson, W., Editor, "PPP over ISDN", RFC 1618, Daydreamer, May 1994. [3] "Requirements for Internet hosts - communication layers ", RFC 1122, October 1989. [4] Sklower, K., "The PPP Multilink Protocol (MP)", RFC 1717, November 1994. [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [6] Lloyd, B. / Simpson, W., "PPP Authentication Protocols", RFC 1334, October 1992. [7] "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications ", RFC 1002, March 1987. [8] "Local Area Network Technical Reference", IBM document SC30- 3383-03 Acknowledgments Thanks go to Sam Lau and Robert Bell of Global Village Communication (UK) Ltd. for information on protocol spoofing used to compile this document, to Anthony Discolo and his colleagues at Microsoft for their comments, which have been incorporated into the document, and to Jim Phillippo of Xyplex for some additional information. Puleston expires in six months [Page 25] =0C DRAFT PPP Protocol Spoofing Control Protocol February 1996 Chair's Address The working group can be contacted via the current chair: Fred Baker Senior Software Engineer Cisco Systems 519 Lado Drive Santa Barbara, California 93111 Phone: (408) 526-4257 EMail: fred@cisco.com Author's Address Questions about this memo can also be directed to: Ian David Puleston Global Village Communication (UK) Ltd. Tempest Court Broughton Hall Skipton, North Yorkshire, BD23 3AE England Tel: +44 (0) 1756 702500 Fax: +44 (0) 1756 797866 EMail: ian_puleston@globalvillage.co.uk or: ianp@knx.co.uk Puleston expires in six months [Page 26]