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)
<draft-ietf-pppext-spoof-00.txt>
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:
<value to be defined> 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]
