One document matched: draft-ietf-pppext-l2f-00.txt
PPP Working Group A. Valencia
INTERNET DRAFT M. Littlewood
Category: Experimental Draft T. Kolar
Title: draft-ietf-pppext-l2f-00.txt Cisco Systems
Date: February 1996
Level Two Forwarding (Protocol) "L2F"
Status of this Memo
This memo is an experimental draft. It describes an implemented pro-
tocol, but one which is expected to change significantly as a result
of review in the working group.
Abstract
Virtual dial-up allows many separate and autonomous protocol domains
to share common access infrastructure including modems, Access
Servers, and ISDN routers. Previous RFCs have specified protocols
for supporting IP dial-up via SLIP and multiprotocol dial-up via PPP.
This document describes the Level Two Forwarding protocol (L2F) which per-
mits the tunneling of the link level (i.e., HDLC, async HDLC, or SLIP
frames) of higher level protocols. Using such tunnels, it is possi-
ble to divorce the location of the initial dial-up server from the
location at which the dial-up protocol connection is terminated and
access to the network provided.
Table of Contents
1.0 Introduction 2
1.1 Conventions
2.0 Problem Space Overview 3
2.1 Initial Assumptions
2.2 Topology
2.3 Virtual dial-up Service - a walk-though 4
3.0 Service Model Issues 6
3.1 Security
3.2 Address allocation
3.3 Authentication 7
3.4 Accounting
4.0 Protocol Definition 8
4.1 Encapsulation within L2F 8
4.1.1 Encapsulation of PPP within L2F
4.1.2 Encapsulation of SLIP within L2F 9
4.2 L2F Packet Format
4.2.1 Overall Packet Format
Valencia expires August 1996 [Page 1]
RFC DRAFT January 1996
4.2.2 Packet Header 10
4.2.3 Version field
4.2.4 Protocol field
4.2.5 Sequence Number 11
4.2.6 Packet Multiplex ID
4.2.7 Client ID
4.2.8 Length 12
4.2.9 Packet Checksum
4.2.10 Payload Offset
4.2.11 Packet Key 13
4.3 L2F Tunnel Establishment
4.3.1 Normal Tunnel Negotiation Sequence
4.3.2 Normal Client Negotiation Sequence 15
4.4 L2F management message types
4.4.1 L2F message type: Invalid 16
4.4.2 L2F_CONF
4.4.3 L2F_OPEN 17
4.4.4 L2F_CLOSE 18
4.4.5 L2F_ECHO 19
4.4.6 L2F_ECHO_RESP
4.5 L2F Message Delivery 20
4.5.1 Sequenced Delivery
4.5.2 Flow Control
4.5.3 Tunnel State Table
4.5.4 Client State Table 21
5.0 Protocol Considerations
5.1 PPP Features
5.2 Termination 22
5.3 Extended Authentication
5.4 MNP4 and Apple Remote Access Protocol
6.0 Acknowledgments
7.0 References 23
8.0 Authors' Addresses
1.0 Introduction
The traditional dial-up network service on the Internet is for regis-
tered IP addresses only. A new class of virtual dial-up application
which allows multiple protocols and unregistered IP addresses is also
desired on the Internet. Examples of this class of network applica-
tion are support for privately addressed IP, IPX, and AppleTalk dial-
up via SLIP/PPP across existing Internet infrastructure.
The support of these multiprotocol virtual dial-up applications is of
significant benefit to end users and Internet Service providers as it
allows the sharing of very large investments in access and core
infrastructure and allows local calls to be used. It also allows
existing investments in non-IP protocol applications to be supported
Valencia expires August 1996 [Page 2]
RFC DRAFT January 1996
in a secure manner while still leveraging the access infrastructure
of the Internet.
It is the purpose of this RFC to identify the issues encountered in
integrating multiprotocol dial-up services into an existing Internet
Service Provider's Point of Presence (hereafter referred to as ISP
and POP, respectively), and to describe the L2F protocol which per-
mits the leveraging of existing access protocols.
1.1. Conventions
The following language conventions are used in the items of specifi-
cation in this document:
o MUST, SHALL, or MANDATORY -- This item is an absolute
requirement of the specification.
o SHOULD or RECOMMEND -- This item should generally be followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- This item is truly optional and may be
followed or ignored according to the needs of the implementor.
2.0 Problem Space Overview
In this section we describe in high level terms the scope of
the problem that will be explored in more detail in later sections.
2.1 Initial Assumptions
We begin by assuming that Internet access is provided by an ISP and that the
ISP wishes to offer services other than traditional registered IP address
based services to dial-up users of the network.
We also assume that the user of such a service wants all of the security
facilities that are available to him in a dedicated dial-up configuration.
In particular, the end user requires:
+ End System transparency: Neither the remote end system nor his home site
hosts should require any special software to use this service in a secure
manner.
+ Authentication as provided via dial-up PPP CHAP or PAP, or through other
dialogs as needed for protocols without authentication (e.g., SLIP). This
will include TACACS+ and RADIUS solutions as well as support for smart cards
and one-time passwords. The authentication should be manageable by the user
independently of the ISP.
Valencia expires August 1996 [Page 3]
RFC DRAFT January 1996
+ Addressing should be as manageable as dedicated dial-up solutions. The
address should be assigned by the home site and not the ISP.
+ Authorization should be managed by the home site as it would in a direct
dial-up solution.
+ Accounting should be performed both by the ISP (for billing purposes) and
by the user (for charge-back and auditing).
2.2 Topology
Shown below is a generic Internet with Public switched Telephone Network
(PSTN) access (i.e., async PPP via modems) and Integrated Services Digital
Network (ISDN) access (i.e., synchronous PPP access). Remote users (either
async PPP or SLIP, or ISDN) will access the Home LAN as if they were dialed
into the Home Gateway, although their physical dial-up is via the ISP
Network Access Server.
...----[L]----+---[L]-----...
|
|
[H]
|
________|________________________
| |
________|__ ______|________
| | | |
| PSTN [R] [R] ISDN |
| Cloud | | Cloud [N]__[U]
| | Internet | |
| | [R] |
[N]______[R] |_____________|
| | |
| | |
[U] |________________________________|
[H] = Home Gateway
[L] = Home LAN(s)
[R] = Router
[U] = Remote User
[N] = ISP Network Access Server ("NAS")
Valencia expires August 1996 [Page 4]
RFC DRAFT January 1996
2.3 Providing Virtual dial-up Services - a walk-through
To motivate the following discussion, this section walks through an
example of what might happen when a Virtual dial-up client initiates
access.
The Remote User initiates a PPP connection to an ISP via either the
PSTN or ISDN. The Network Access Server (NAS) accepts the connection
and the PPP link is established.
The ISP authenticates the end system/user via CHAP or PAP. Only the
username field is interpreted to determine whether the user requires
a Virtual dial-up service. It is expected that usernames will be
structured (e.g. littlewo@cisco.com) or that the ISP maintains a
database mapping users to services. In the case of Virtual dial-up,
the mapping will name a specific endpoint, the Home Gateway.
If a virtual dial-up service is not required, standard access to the
Internet may be provided.
If no tunnel connection currently exists to the desired Home Gateway,
one is initiated. The details of such tunnel creation are outside
the scope of this specification; L2F requires only that the tunnel
media provide point-to-point connectivity. Obvious examples of such
media are UDP, Frame Relay PVC's, or X.25 VC's.
Once the tunnel exists, an unused Multiplex ID (hereafter, "MID") is
allocated, and a connect indication is sent to notify the Home Gate-
way of this new dial-up session. The Home Gateway either accepts the
connection, or rejects. Rejection may include a reason indication,
which may be displayed to the dial-up user, after which the call
should be disconnected.
The initial setup notification may include the authentication infor-
mation required to allow the Home Gateway to authenticate the user
and decide to accept or decline the connection. In the case of CHAP,
the set-up packet includes the challenge, username and raw password.
For PAP or text dialog (i.e., for SLIP users), it includes username
and clear text password. The Home Gateway may choose to use this
information to complete its authentication, avoiding an additional
cycle of authentication.
For PPP, the initial setup notification may also include a copy of
the the LCP CONFACKs sent in each direction which completed LCP nego-
tiation. The Home Gateway may use this information to initialize its
own PPP state (thus avoiding an additional LCP negotiation), or it
may choose to initiate a new LCP CONFREQ exchange.
Valencia expires August 1996 [Page 5]
RFC DRAFT January 1996
If the Home Gateway accepts the connection, it creates a "virtual
interface" for SLIP or PPP in a manner analogous to what it would use
for a direct-dialed connection. With this "virtual interface" in
place, link level frames may now pass over this tunnel in both direc-
tions. Frames from the remote user are received at the POP, stripped
of any link framing or transparency bytes, encapsulated in L2F, and
forwarded over the appropriate tunnel.
The Home Gateway accepts these frames, strips L2F, and processes them
as normal incoming frames for the appropriate interface and protocol.
The "virtual interface" behaves very much like a hardware interface,
with the exception that the hardware in this case is physically
located at the ISP POP. The other direction behaves analogously,
with the Home Gateway encapsulating the packet in L2F, and the POP
stripping L2F before transmitting it out the physical interface to
the remote user.
At this point, the connectivity is a point-to-point PPP or SLIP con-
nection whose endpoints are the remote user's networking application
on one end and the termination of this connectivity into the Home
Gateway's SLIP or PPP support on the other. Because the remote user
has become simply another dial-up client of the Home Gateway access
server, client connectivity can now be managed using traditional
mechanisms with respect to further authorization, protocol access,
and filtering.
Accounting can be performed at both the NAS as well as the Home Gate-
way. This document illustrates some Accounting techniques which are
possible using L2F, but the policies surrounding such Accounting are
outside the scope of this specification.
Because L2F connect notifications for PPP clients contain sufficient
information for a Home Gateway to authenticate and initialize its LCP
state machine, it is not required that the remote user be queried a
second time for CHAP authentication, nor that the client undergo mul-
tiple rounds of LCP negotiation and convergence. These techniques
are intended to optimize connection setup, and are not intended to
deprecate any functions required by the PPP specification.
3.0 Service Model Issues
There are several significant differences between the standard Inter-
net access service and the Virtual dial-up service with respect to
authentication, address allocation, authorization and accounting.
The details of the differences between these services and the prob-
lems presented by these differences are described below. The mecha-
nisms used for Virtual Dial-up service are intended to coexist with
more traditional mechanisms; it is intended that an ISP's POP can
Valencia expires August 1996 [Page 6]
RFC DRAFT January 1996
simultaneously service a ISP clients as well as Virtual dial-up
clients.
3.1 Security
For the Virtual dial-up service, the ISP pursues authentication only
to the extent required to discover the user's apparent identity (and
by implication, their desired Home Gateway). As soon as this is
determined, a connection to the Home Gateway is initiated with the
authentication information gathered by the ISP. The Home Gateway
completes the authentication by either accepting the connection, or
rejecting it.
The Home Gateway must also protect against attempts by third parties
to establish tunnels to the Home Gateway. Tunnel establishment
involves an ISP-to-Home Gateway authentication phase to protect
against such attacks.
3.2 Address Allocation
For an Internet service, the user accepts that the IP address may be
allocated dynamically from a pool of Service provider addresses.
This model often means that the remote user has little or no access
to their home network's resources, due to firewalls and other secu-
rity policies applied by the home network to accesses from external
IP addresses.
For the Virtual dial-up service, the Home Gateway can exist behind
the home firewall, allocating addresses which are internal (and, in
fact, can be RFC1597 addresses, or non-IP addresses). Because L2F
tunnels exclusively at the frame level, the actual policies of such
address management are irrelevant to correct Virtual dial-up service;
for all purposes of PPP or SLIP protocol handling, the dial-in user
appears to have connected at the Home Gateway.
3.3 Authentication
The authentication of the user occurs in three phases; the first at
the ISP, and the second and optional third at the Home gateway.
The ISP uses the username to determine that a Virtual dial-up service
is required and initiate the tunnel connection to the appropriate
Home Gateway. Once a tunnel is established, a new MID is allocated
and a session initiated by forwarding the gathered authentication
information.
The Home Gateway undertakes the second phase by deciding whether or
not to accept the connection. The connection indication may include
Valencia expires August 1996 [Page 7]
RFC DRAFT January 1996
CHAP, PAP, or textual authentication information. Based on this
information, the Home Gateway may accept the connection, or may
reject it (for instance, it was a PAP request and the user-
name/password are found to be incorrect).
Once the connection is accepted, the Home Gateway is free to pursue a
third phase of authentication at the PPP or SLIP level. These activ-
ities are outside the scope of this specification, but might include
proprietary PPP extensions, or textual challenges carried via a
TCP/IP telnet session.
3.4 Accounting
It is a requirement that both the Access gateway and the Home Gateway
can provide accounting data and hence both my may count packets,
octets and connection start and stop times.
Since Virtual dial-up is an access service, accounting of connection
attempts (in particular, failed connection attempts) is of signifi-
cant interest. The Home Gateway can reject new connections based on
the authentication information gathered by the ISP, with correspond-
ing logging. For cases where the Home Gateway accepts the connection
and then continues with further authentication, the Home Gateway
might subsequently disconnect the client. For such scenarios, the
disconnection indication back to the ISP may also include a reason.
Because the Home Gateway can decline a connection based on the
authentication information collected by the ISP, accounting can eas-
ily draw a distinction between a series of failed connection attempts
and a series of brief successful connections. Lacking this facility,
the Home Gateway must always accept connection requests, and would
need to exchange a number of PPP packets with the remote system.
4.0 Protocol Definition
The protocol definition for Virtual dial-up services requires two
areas of standardization:
+ Encapsulation of PPP packets within L2F: the ISP NAS and the Home
gateway require a common understanding of the encapsulation protocol
so that SLIP/PPP packets can be successfully transmitted and received
across the Internet.
+ Connection management of L2F and MIDs: the tunnel must be initiated
and terminated, as must MIDs within the tunnel. Termination includes
diagnostic codes to assist in the diagnosis of problems and to sup-
port accounting.
Valencia expires August 1996 [Page 8]
RFC DRAFT January 1996
While providing these services, the protocol must address the follow-
ing required attributes:
+ Low overhead. The protocol must impose a minimal additional over-
head. This requires a compact encapsulation, and a structure for
omitting some portions of the encapsulation where their function is
not required.
+ Efficiency. The protocol must be efficient to encapsulate and
deencapsulate.
+ Protocol independence. The protocol must make very few assumptions
about the substrate over which L2F packets are carried.
4.1 Encapsulation within L2F
4.1.1 Encapsulation of PPP within L2F
The PPP packets may be encapsulated within L2F. The packet encapsu-
lated is the packet as it would be transmitted over a physical link.
The following are NOT present in the packet:
+ Flags
+ Transparency data (ACCM for async, bit stuffing for sync)
The following ARE still present:
+ Address, control, and protocol (unless negotiated away by LCP)
+ CRC
4.1.2 Encapsulation of SLIP within L2F
SLIP is encapsulated within L2F in much the same way as PPP. The
transparency characters are removed before encapsulating within L2F,
as is the framing.
4.2 L2F Packet Format
4.2.1 Overall Packet Format
Valencia expires August 1996 [Page 9]
RFC DRAFT January 1996
The entire encapsulated packet has the form:
---------------------------------
| |
| L2F Header |
| |
---------------------------------
| |
| Payload packet (SLIP/PPP) |
| |
---------------------------------
| |
| Checksum (optional) |
| |
---------------------------------
4.2.2 Packet Format
An L2F packet has the form:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|K|0|0|0|0|0|0|0|0|0|0|C| Ver | Protocol | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multiplex ID | Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Offset (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ (payload) |
+ ..... +
+ ..... +
+ ..... +
+ (payload) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.3 Version field
The Ver ("Version") field represents the major version of the L2F
software creating the packet. It MUST contain the value 001.
Valencia expires August 1996 [Page 10]
RFC DRAFT January 1996
If any bits are non-zero after bit K but before bit C, an implementa-
tion MUST discard the packet and initiate disconnect of the entire
tunnel. This would correspond to a packet containing extensions not
understood by the receiving end. Handling of the "Key" field must be
taken in preference to this processing, to avoid denial-of-service
attacks.
4.2.4 Protocol field
The Protocol specifies the protocol carried within the L2F packet.
Legal values (represented here in hexadecimal) are:
Value Type Description
0x00 L2F_ILLEGAL Illegal
0x01 L2F_PROTO L2F management packets
0x02 L2F_PPP PPP tunneled inside L2F
0x03 L2F_SLIP SLIP tunneled inside L2F
4.2.5 Sequence Number
The Sequence number starts at 0 for the first L2F packet under a tun-
nel. Each subsequent packet is sent with the next increment of the
sequence number. The sequence number is thus a free running counter
represented modulo 256.
For non-L2F management packets, the sequence number is transmitted as
0, does not increment the local sequence counter, and does not affect
the processing of received traffic. For L2F management packets, the
sequence number is used to protect against duplication of packets, as
follows:
The receiving side of the tunnel records the sequence number of each
valid L2F packet it receives. If a received packet appears to have a
value less than or equal to the last received value, the packet MUST
be silently discarded. Otherwise, the packet is accepted and the
sequence number in the packet recorded as the latest value last
received.
For purposes of detecting duplication, a received sequence value is
considered less than or equal to the last received value if its value
lies in the range of the last value and its 127 successor values.
For example, if the last received sequence number was 15, then pack-
ets with sequence numbers 0 through 15, as well as 144 through 255,
would be considered less than or equal to, and would be silently dis-
carded. Otherwise it would be accepted.
Valencia expires August 1996 [Page 11]
RFC DRAFT January 1996
4.2.6 Packet Multiplex ID
The Multiplex ID ("MID") identifies a particular connection within
the tunnel. Each new connection is assigned a MID currently unused
within the tunnel. It is recommended that the MID cycle through the
entire 32-bit namespace, to reduce aliasing between previous and cur-
rent sessions.
The MID with value 0 is special; it is used to communicate the state
of the tunnel itself, as distinct from any connection within the tun-
nel.
4.2.7 Client ID
The Client ID ("CLID") is used to assist endpoints in demultiplexing
tunnels when the underlying point-to-point substrate lacks an effi-
cient or dependable technique for doing so directly. Using CLID, it
is possible to demultiplex multiple tunnels whose packets arrive over
the point-to-point media interleaved, without requiring media-
specific semantics.
When transmitting the L2F_CONF message (described below), the peer's
CLID must be communicated via the Assigned_CLID field. This must be
a unique non-zero value on the sender's side, which is to be expected
in all future non-L2F_CONF packets received.
The CLID value from the last valid L2F_CONF message received should
be recorded and used as the CLID field value for all subsequent pack-
ets sent to the peer.
Packets with an unknown Client ID must be silently discarded.
For the initial packet sent during tunnel establishment, where no
L2F_CONF has yet been received, the CLID field must be 0.
Thus, during L2F_CONF each side is told its CLID value. All later
packets sent, tagged with this CLID value, serve as a tag which
uniquely identifies this peer.
4.2.8 Length
Length is the size in octets of the entire packet, including header,
all fields present, and payload. Length does not reflect the addi-
tion of the checksum, if one is present. The packet should be
silently discarded if the received packet is shorter than the indi-
cated length. Additional bytes present in the packet beyond the
indicated length must be silently ignored.
Valencia expires August 1996 [Page 12]
RFC DRAFT January 1996
4.2.9 Packet Checksum
The Checksum is present if the C bit is present in the header flags.
It is a 16-bit CRC as used by PPP/HDLC. Is is applied over the
entire packet starting with the first byte of L2F flags, through the
last byte of payload data. The checksum is then added as two bytes
immediately following the last byte of payload data.
4.2.10 Payload Offset
The Offset is present if the F bit is set in the header flags. This
field specifies the number of bytes past the header at which the pay-
load data is expected to start. If it is 0, or the F bit is not set,
the first byte following the last byte of L2F header is the first
byte of payload data.
It is recommended that data skipped due to the payload offset be ini-
tialized to 0's.
4.2.11 Packet Key
The Key is the authentication response last given to the peer during
tunnel creation (the details of tunnel creation are provided in the
next section). It serves as a key during the life of a session to
resist attacks based on spoofing. If a packet is received in which
the Key does not match the expected value, the packet MUST be
silently discarded.
4.3 L2F Tunnel Establishment
When the point-to-point link is first initiated between the NAS and
the Home Gateway, the endpoints communicate on MID 0 prior to provid-
ing general L2F services to clients. This communication is used to
verify the presence of L2F on the remote end, and to permit any
needed authentication.
The protocol for such negotiation is always 1, indicating L2F manage-
ment. The message itself is structured as a sequence of single
octets indicating an option, followed by zero or more further octets
formatted as needed for the option.
4.3.1 Normal Tunnel Negotiation Sequence
The establishment sequence is best illustrated by a "typical" connec-
tion sequence. Detailed description of each functions follows, along
with descriptions of the handling of exceptional conditions.
Each packet is described as a source->destination on one line, a
Valencia expires August 1996 [Page 13]
RFC DRAFT January 1996
description of the L2F packet field contents on the next, and the
contents of the packet's body on following lines. The exact encoding
of octets will be described later.
Note that this example uses the Key option, but does not use the Off-
set and Checksum options. The Length field would be present,
reflecting the actual length of the packets as encoded as an octet
stream.
1. NAS->GW:
Proto=L2F, Seq=0, MID=0, CLID=0, Key=0
L2F_CONF
Name: NAS_name
Challenge: Rnd
Assigned_CLID: 22
The NAS decides that a tunnel must be initiated from the NAS to the
GW. An L2F packet is sent with the Proto field indicating an L2F
management message is contained.
Because the tunnel is being initiated, Key is set to 0. The sequence
number starts at 0; the MID is 0 to reflect the establishment of the
tunnel itself. Since the NAS has not yet received an L2F_CONF, the
CLID is set to 0.
The body of the packet specifies the claimed name of the NAS, and a
challenge random number which GW will use in authenticating itself as
a valid tunnel endpoint. Assigned_CLID is generated to be a value
not currently assigned out to any other tunnel to any other Home
Gateway.
2. GW->NAS:
Proto=L2F, Seq=0, MID=0, CLID=22, Key=C(Rnd)
L2F_CONF
Name: GW_name
Challenge: Rnd2
Assigned_CLID: 73
The Home Gateway has processed the previous packet, and sends a
response. The protocol continues to be L2F, with a sequence number 0
(each side maintains its own sequence number for transmissions). MID
continues to be 0 to reflect tunnel establishment. CLID reflects the
Assigned_CLID field of the L2F_CONF received. The Key is a CHAP-
style hash of the random number received; each packet hereafter will
reflect this calculated value, which serves as a key for the life of
the tunnel.
The body contains the Home Gateway's name and its own random number
Valencia expires August 1996 [Page 14]
RFC DRAFT January 1996
challenge. and its own Assigned_CLID for the NAS to place in the
CLID field of future packets. The CLID is generated in an analogous
manner to that of the NAS. After this, all packets received from the
NAS must be tagged with a CLID field containing 73, and all packets
sent to the NAS must be tagged with a CLID field containing 22.
3. NAS->GW
Proto=L2F, Seq=1, MID=0, CLID=73, Key=C(Rnd2)
L2F_OPEN
The NAS responds with its Key now set to reflect the shared secret.
Like the Home Gateway, the NAS will use this Key for the life of the
tunnel.
4. GW->NAS
Proto=L2F, Seq=1, MID=0, CLID=22, Key=C(Rnd)
L2F_OPEN
The Home Gateway provides closure of the key from the NAS. The tun-
nel is now available for clients to be established.
4.3.2 Normal Client Negotiation Sequence
This section describes the establishment of a Virtual dial-up client
on a NAS into a Home Gateway. It assumes a tunnel has been created
in the way described in 4.3.1. The client for this example is a PPP
client configured for CHAP.
Treatment of Checksum, Length, and Offset are as in 4.3.1.
1. NAS->GW
Proto=L2F, Seq=2, MID=1, CLID=73, Key=C(Rnd2)
L2F_OPEN
Authen: CHAP
Client: CHAP-name
Challenge: Rnd3
Response: <Value received, presumably C(Rnd3)>
The NAS has received a call, tried CHAP with a challenge value of
Rnd3, and found that the client responded. The claimed name lead the
NAS to believe it was a Virtual dial-up client hosted by the Home
Gateway. The next free MID is allocated, and the information associ-
ated with the CHAP challenge/response is included in the connect
notification.
2. GW->NAS
Proto=L2F, Seq=2, MID=1, CLID=22, Key=C(Rnd)
L2F_OPEN
Valencia expires August 1996 [Page 15]
RFC DRAFT January 1996
The Home Gateway, by sending back the L2F_OPEN, accepts the client.
3. NAS->GW
Proto=PPP, Seq=0, MID=1, CLID=73, Key=C(Rnd2)
<Frame follows>
4. GW->NAS
Proto=PPP, Seq=0, MID=1, CLID=22, Key=C(Rnd)
<Frame follows>
Traffic is now free to flow in either direction as sent by the remote
client or the home site. The contents is uninterpreted data, HDLC in
this case. Data traffic, since it is not the L2F protocol, does not
use the Seq field, which is set to 0 in non-L2F messages.
4.4 L2F management message types
When an L2F packet's Proto field specifies L2F management, the body
of the packet is encoded as zero or more options. An option is a
single octet "message type", followed by zero or more sub-options.
Each sub-option is a single byte sub-option value, and further bytes
as appropriate for the sub-option.
Options in L2F are:
Hex Value Abbreviation Description
-------- ------------ -----------
0x00 Invalid Invalid message
0x01 L2F_CONF Request configuration
0x01 L2F_CONF_TYPE Type of authentication used
0x02 L2F_CONF_NAME Name of peer sending L2F_CONF
0x03 L2F_CONF_CHAL Random number peer challenges with
0x04 L2F_CONF_CLID Assigned_CLID for peer to use
0x02 L2F_OPEN Accept configuration
0x01 L2F_OPEN_CHAP CHAP name received from client
0x02 L2F_OPEN_CHAL Challenge CHAP client received
0x03 L2F_OPEN_RESP CHAP challenge response from client
0x04 L2F_ACK_LCP1 LCP CONFACK accepted from client
0x05 L2F_ACK_LCP2 LCP CONFACK sent to client
0x03 L2F_CLOSE Request disconnect
0x01 L2F_CLOSE_WHY Reason code for close
0x02 L2F_CLOSE_STR ASCII string description
0x04 L2F_ECHO Verify presence of peer
0x05 L2F_ECHO_RESP Respond to L2F_ECHO
Valencia expires August 1996 [Page 16]
RFC DRAFT January 1996
4.4.1 L2F message type: Invalid
If a message is received with this value, or any value higher than
the last recognized option value, the packet is considered invalid.
The packet MUST be discarded, and an L2F_CLOSE of the entire tunnel
MUST be requested. Upon receipt of an L2F_CLOSE, the tunnel itself
may be closed. All other received message MUST be discarded. An
implementation MAY close the tunnel after an interval of time appro-
priate to the characteristics of the tunnel.
Invalid sub-option values, even if present under a valid option, must
be treated as if the entire message type was invalid.
4.4.2 L2F_CONF
The L2F message type is used to establish the tunnel between the NAS
and the Home Gateway. MID is always set to 0. The body of such a
message starts with the octet 0x01 (L2F_CONF), followed by one more
more sub-options.
The L2F_CONF_TYPE sub-option must be present. It is encoded as the
octet 0x01, followed by a single byte describing the type of authen-
tication the NAS exchanged with the client in detecting the client's
claimed identification. The authentication types are:
0x01 Textual username/password exchange
0x02 PPP CHAP
0x03 PPP PAP
The L2F_CONF_NAME sub-option must be present. It is encoded as the
octet value 0x02, followed by an octet specifying a non-zero length,
followed by the indicated number of bytes, which are interpreted as
the sender's ASCII name.
The L2F_CONF_CHAL sub-option must be present. It is encoded as the
octet value 0x03, followed by four bytes of challenge value.
The challenge value should be generated using whatever techniques
provide the highest quality of random numbers available to a given
implementation.
The L2F_CONF_CLID sub-option must be present. It is encoded as the
octet 0x04, followed by four bytes of Assigned_CLID value. The
Assigned_CLID value is generated as a non-zero value unique across
all tunnels which exist on the sending system.
The CLID field is sent as 0 a L2F_CONF packet is received from the
peer. After this, the Assigned_CLID value of the last L2F_CONF
Valencia expires August 1996 [Page 17]
RFC DRAFT January 1996
packet received must be placed in the CLID of all packets being sent.
When sent from a NAS to a Home Gateway, the L2F_CONF is the initial
packet in the conversation. Key is set to 0, since no challenge has
been received yet.
When sent from the Home Gateway to the NAS, an L2F_CONF indicates the
Home Gateway's recognition of the tunnel creation request. The Home
Gateway must provide its name and its own challenge in the message
body. Key must be set to the CHAP-style hash of the received chal-
lenge bytes.
4.4.3 L2F_OPEN
The L2F_OPEN message is used to establish a client connection within
a tunnel previously established by L2F_CONF messages. When sent from
the NAS to the Home Gateway, it is used to indicate the presence of a
new dial-in client. When sent back from the Home Gateway to the NAS,
it indicates acceptance of the client. This message starts with the
octet 0x02. When sent from the NAS, it may contain further sub-
options. When sent from the Home Gateway, it may not contain any
options.
The L2F_OPEN_CHAP sub-option is encoded as the octet 0x01, followed
by an octet specifying the length of the CHAP name received, followed
by the indicated number of bytes of CHAP name.
The L2F_OPEN_CHAL sub-option is encoded as the octet 0x02, followed
by an octet specifying the length of the CHAP challenge sent, fol-
lowed by the CHAP challenge itself.
The L2F_OPEN_RESP sub-option is encoded as the octet 0x03, followed
by an octet specifying the length of the CHAP response sent, followed
by the client's response to the CHAP challenge.
This message must be treated as invalid if L2F_OPEN_CHAP,
L2F_OPEN_CHAL, and L2F_OPEN_RESP do not all appear within the same
message.
The L2F_ACK_LCP1 and L2F_ACK_LCP2 sub-options are encoded as the
octets 0x04 and 0x05 respectively, followed in either case by two
octets in network byte order specifying the length of the LCP CONFACK
last received from or sent to the client. Following these octets is
an exact copy of the CONFACK packet.
The Home Gateway may choose to ignore any sub-option of the L2F_OPEN,
and accept the connection anyway. The Home Gateway would then have
to undertake its own LCP negotiations and authentication.
Valencia expires August 1996 [Page 18]
RFC DRAFT January 1996
4.4.4 L2F_CLOSE
This message is encoded as the byte 0x03. An L2F_CLOSE may be sent
by either side of the tunnel at any time. When sent with MID of 0,
it indicates the desire to terminate the entire tunnel and all
clients within the tunnel. When sent from the Home Gateway in
response to an L2F_OPEN, it indicates that the Home Gateway has
declined the connection. When sent with a non-zero MID, it indicates
the termination of that client within the tunnel.
The L2F_CLOSE_WHY sub-option is encoded as the byte 0x01 followed
four bytes in network byte order specifying a bit mask of reasons for
the disconnection. The bits are encoded as:
0x00000001 Authentication failed
0x00000002 Out of resources
0x00000004 Administrative intervention
0x00000008 User quota exceeded
0x00000010 Protocol error
0x00000020 Unknown user
0x00000040 Incorrect password
0x00000080 PPP configuration incompatible
Bits in the mask 0xFF000000 are reserved for per-vendor interpreta-
tion.
An implementation can choose to not provide status bits even if it
detects a condition described by one of these bits. For instance, an
implementation may choose to not use 0x00000020 due to security con-
siderations, as it can be used to probe user name space.
The L2F_CLOSE_STR sub-option is encoded as the byte 0x02, followed by
a two-byte length in network byte order, followed by the indicated
number of bytes, which are interpreted as descriptive ASCII text
associated with the disconnection. This string may be ignored, but
could be recorded in a log to provide detailed or auxiliary informa-
tion associated with the L2F_CLOSE.
4.4.5 L2F_ECHO
Transmission of L2F_ECHO messages is optional. If an implementation
transmits L2F_ECHO messages, it must not transmit more than one such
request each second. The payload size must be 64 bytes or less in
length. It is recommended that at least 5 L2F_ECHO messages be sent
without response before an implementation assumes that its peer has
terminated.
Valencia expires August 1996 [Page 19]
RFC DRAFT January 1996
The L2F_ECHO message is encoded as the single byte 0x04. It may be
sent by either side once the tunnel is established. MID must be 0.
An L2F_ECHO_RESP (documented below) must be sent back in response.
4.4.6 L2F_ECHO_RESP
All implementations must respond to L2F_ECHO, using L2F_ECHO_RESP.
The received packet must be sent back verbatim, except that the CLID,
sequence number, and checksum (if any) must be updated, and the
L2F_ECHO message type changed to an L2F_ECHO_RESP. Payload data fol-
lowing the 0x04 octet, if any, must be preserved in the response.
When an L2F_ECHO_RESP is received, the payload data may be used to
associate this response with a previously sent L2F_ECHO, or the
packet may be silently discarded.
4.5 L2F Message Delivery
L2F is designed to operate over point-to-point unreliable links. It
is not designed to provide flow control of the data traffic, nor does
it provide reliable deliver of this traffic; each protocol tunnel via
L2F is expected to manage flow control and retry itself. Thus, it is
only L2F control messages which must be retransmitted; this process
is described in this section.
4.5.1 Sequenced delivery
All L2F control messages (i.e., those L2F packets with a protocol
type of 0x01) are transmitted with a sequence number. The sequence
number is a per-L2F tunnel free running counter which is incremented
(modulo 256) after each packet is transmitted. It is used to permit
the receiving end to detect duplicated or out-of-order packets, and
to discard such packets. Section 4.2.5 describes the process in
detail.
4.5.2 Flow control
L2F control messages are expected to be exchanged lock-step. Thus,
per-client activities can not occur until tunnel setup is complete.
Neither can one client be serviced until the L2F message exchange is
complete for a previous client. Thus, it is expected that rarely--if
ever--should a flow control action be required. If the input queue
of L2F control messages reaches an objectionable level for an imple-
mentation, the implementation may silently discard all messages in
the queue to stabilize the situation.
Valencia expires August 1996 [Page 20]
RFC DRAFT January 1996
4.5.3 Tunnel State table
The following enumerates the handling of L2F messages for tunnel cre-
ation in state table format. Events name an L2F_ message type (the
L2F_ portion of the named message is omitted to permit a more compact
table). A start ("*") matches any event not otherwise matched for
the named state.
State Event Action New State
----- ----- ------ ---------
Start1 CONF Send CONF Start2
Start1 * (discard) Start1
Start2 OPEN MID=0 Send OPEN MID=0 Open
Start2 CONF Send CONF Start2
Start2 * Send INVALID Start1
Open OPEN MID=0 Send OPEN MID=0 Open
Open ECHO CID=0 Send ECHO CID=1 Open
Open CLOSE Send CLOSE Close1
Open * Send INVALID Start1
Close1 CLOSE Send CLOSE Close1
Close1 (10 secs) (none) Start1
Close1 * (discard) Close1
4.5.4 Client State table
This table is similar to the previous one, but enumerates the states
for a client connection within a tunnel in the Open state from 4.5.3.
As this sequence addresses clients, MID will be non-zero.
State Event Action New State
----- ----- ------ ---------
Start1 OPEN Send OPEN Open
Start2 * Send INVALID Start1
Open OPEN Send OPEN Open
Open CLOSE Send CLOSE Close1
Open (data) Forward Open
Open * Send INVALID Start1
Close1 CLOSE Send CLOSE Close1
Close1 (10 secs) (none) Start1
Close1 * (discard) Close1
Valencia expires August 1996 [Page 21]
RFC DRAFT January 1996
5. Protocol Considerations
Several aspects of operation over L2F, while outside the realm of the
protocol description itself, serve to clarify the operation of L2F.
5.1 PPP Features
Because L2F in operation carries uninterpreted frames, it permits
operation of features without explicit knowledge of these features.
For instance, if a PPP session is carried, L2F is simply transporting
HDLC frames. The two PPP endpoints can negotiate higher-level fea-
tures, such as reliable link, compression, multi-link, or encryption.
These features then operate between the two PPP endpoints (the dial-
in client on one end, and the Home Gateway on the other), with L2F
continuing to simply ship HDLC frames back and forth.
For similar reasons, PPP echo requests, NCP configuration negotia-
tion, and even termination requests, are all simply tunneled HDLC
frames.
5.2 Termination
As L2F simply tunnels link-level frames, it does not detect frames
like PPP TERMREQ. L2F termination in these scenarios is driven from
a protocol endpoint; for instance, if a Home Gateway receives a
TERMREQ, its action will be to "hang up" the PPP session. It is the
responsibility of the L2F implementation at the Home Gateway to con-
vert a "hang up" into an L2F_CLOSE action, which will shut down
client's session in the tunnel cleanly. L2F_CLOSE_WHY and
L2F_CLOSE_STR may be included to describe the reason for the shut-
down.
5.3 Extended Authentication
L2F is compatible with both PAP and CHAP protocols. SLIP does not
provide authentication within the protocol itself, and thus requires
an ASCII exchange of username and password before SLIP is started.
L2F is compatible with this mode of operation as well.
One-time password cards have become very common. To the extent the
NAS can capture and forward the one-time password, L2F operation is
compatible with password cards. For the most general solution, an
arbitrary request/response exchange must be supported. In an L2F
environment, the protocol must be structured so that the NAS can
detect the apparent identity of the user and establish a tunnel con-
nection to the Home Gateway, where the arbitrary exchange can occur.
Valencia expires August 1996 [Page 22]
RFC DRAFT January 1996
5.4 MNP4 and Apple Remote Access Protocol
L2F appears compatible with Apple's ARAP protocol. Its operation
under L2F has not been described simply because this experimental RFC
does not have a corresponding implementation of such operation.
6.0 Acknowledgments
L2F uses a packet format inspired by GRE. Thanks to Fred Baker for
consultation, Dave Carrel for consulting on security aspects, and to
Paul Traina for philosophical guidance.
7.0 References
[1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661,
07/21/1994
[3] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing
Encapsulation (GRE)", RFC 1701, 10/21/1994
[4] J. Romkey, "A Nonstandard for Transmission of IP Datagrams over
Serial Lines: SLIP", RFC 1055, June 1988
8.0 Authors' Addresses
Tim Kolar
Morgan Littlewood
Andy Valencia
Cisco Systems
170 West Tasman Drive
San Jose CA 95134-1706
tkolar@cisco.com
littlewo@cisco.com
valencia@cisco.com
Valencia expires August 1996 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-22 23:21:43 |