RFC 2107 INFORMATIONAL VPN · TUNNELING · MOBILITY
Ascend Tunnel Management Protocol - ATMP
A tunnel protocol for remote dial-in users to reach their home network.
RFC EDITOR
Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, DOI 10.17487/RFC2107, February 1997, <https://www.rfc-editor.org/info/rfc2107>.
BIBTEX
@misc{rfc2107,
series = {Request for Comments},
number = 2107,
howpublished = {RFC 2107},
publisher = {RFC Editor},
doi = {10.17487/RFC2107},
url = {https://www.rfc-editor.org/info/rfc2107},
author = {K. Hamzeh},
title = {{Ascend Tunnel Management Protocol - ATMP}},
pagetotal = 21,
year = 1997,
month = feb,
} RFC text
Contents
Network Working Group K. Hamzeh
Request for Comments: 2107 Ascend Communications
Category: Informational February 1997
Ascend Tunnel Management Protocol - ATMP
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
IESG Note:
This note documents a private protocol for tunnel management. This
protocol is NOT the product of an IETF working group nor is it a
standards track document. There is ongoing effort in an IETF working
group which could result in a standards track document which
specifies a protocol which provides similar functionality.
Abstract
This document specifies a generic tunnel management protocol that
allows remote dial-in users to access their home network as if they
were directly attached to the home network. The user's client
software uses an address contained in the home network address space
for the remote access. Packets to and from the home network are
tunneled by the Network Access Server (NAS) to which the user
connects and a Home Agent (HA) on the user's home network. This
allows for the support of access to Virtual Private Networks and also
allows for the use of protocols other than IP to be carried over the
tunnel. An example of how the RADIUS (Remote Authentication Dial In
User Service) can be used to provide the necessary configuration
information to support this service is also provided.
1. Introduction
The Ascend Tunnel Management Protocol (ATMP) is a protocol currently
being used in Ascend Communication products to allow dial-in client
software to obtain virtual presence on a user's home network from
remote locations. A user calls into a remote NAS but, instead of
using an address belonging to a network directly supported by the
NAS, the client software uses an address belonging to the user's
"Home Network". This address can be either provided by the client
software or assigned from a pool of addresses from the Home Network
address space. In either case, this address belongs to the Home
Network and therefore special routing considerations are required in
order to route packets to and from these clients. A tunnel between
the NAS and a special "Home Agent" (HA) located on the Home Network
is used to carry data to and from the client.
ATMP currently allows for both IP and IPX protocols to be tunneled
between the NAS and the HA. The protocol to be used, the HA to use,
and other user specific information is provided by some configuration
mechanism that is beyond the scope of this document. Appendix A
illustrates how RADIUS [5] is used to convey this information to the
NAS.
The determination of the Home Network address to be used can be
accomplished in different ways. It could, for example, be configured
in the client and negotiated by IPCP (or IPXCP). Alternatively, it
could be defined to be an address specific to the given user ID, or
it could be assigned from a pool of addresses provided by the Home
Network for the purpose of remote dial-in access. Again, how this
address is assigned and how the NAS decides to invoke ATMP for a
specific call is beyond the scope of this document.
1.1 Protocol Goals and Assumptions
The ATMP protocol is implemented only by the NAS and HA. No other
systems need to be aware of ATMP. All other systems communicate in
the normal manner and are unaware that they may be communicating with
remote clients. The clients themselves are unaware of ATMP. It is
assumed that standard PPP [8] (or SLIP) clients are being used.
Unlike the mobile-IP protocol [3], ATMP assumes that a single NAS
will provide the physical connection to a remote client for the
duration of the session. The client will not switch between NASes
expecting to keep the same IP address and all associated sessions
active during these transitions. A particular client can be
registered with a given HA only once at any given time.
Deregistration with a HA implies loss of all higher layer sessions
for that client.
IP multicasting is currently not provided by ATMP.
1.2 Terminology
The terminology used in this document is similar to that used in
mobile-IP. As pointed out in the previous section, however, ATMP
provides a subset of the functionality provided by mobile-IP and the
meanings of the various terms used herein have been modified
accordingly.
Connection Profile
A table used to route packets other than by destination
address. The Connection Profile is a named entity that
contains information indicating how packets addressed to it are
to be routed. It may be used to route packets to unregistered
IP addresses and for routing protocols other than IP (e.g.,
IPX).
Foreign Agent (FA)
A routing entity that resides in a NAS on a remote network that
allows a mobile node to utilize a home network address. It
tunnels datagrams to, and detunnels datagrams from, the home
agent for the given home network.
Home Address
An address that is assigned for an extended period of time to a
mobile node. It may remain unchanged regardless of where the
MN is attached to the Internet. Alternatively, it could be
assigned from a pool of addresses. The management of this pool
is beyond the scope of this document.
Home Agent (HA)
A router on a mobile node's home network which tunnels
datagrams for delivery to, and detunnels datagrams from, a
mobile node when it is away from home.
Home Network
The address space of the network to which a user logically
belongs. When a workstation is physically connected to a LAN,
the LAN address space is the user's home network. ATMP
provides for a remote virtual connection to a LAN.
Mobile Node (MN)
A host that wishes to use a Home Network address while
physically connected by a point-to-point link (phone line,
ISDN, etc.) to a NAS that does not reside on the Home Network.
Also referred to as the client.
Mobility Binding
The association of a Home Address with a Foreign Agent IP
address and a Tunnel ID.
Network Access Server (NAS)
A device providing temporary, on-demand, network access to
users. This access is point-to-point using phone or ISDN
lines.
Tunnel
The path followed by a datagram when it is encapsulated. The
model is that, while it is encapsulated, a datagram is routed
to a knowledgeable decapsulation agent, which decapsulates the
datagram and then correctly delivers it to its ultimate
destination. Each mobile node connecting to a home agent does
so over a unique tunnel, identified by a tunnel identifier
which is unique to a given FA-HA pair. A tunnel can carry both
IP and IPX datagrams simultaneously.
1.3 Protocol Overview
A mobile node that wishes to use a home address while connected to a
remote NAS must register with the appropriate home agent. The
foreign agent entity of the remote NAS performs this registration on
behalf of the MN. Once registered, a tunnel is established between
the FA and HA to carry datagrams to and from the MN. While a MN is
registered with an HA, the HA must intercept any packets destined for
the MN's home address and forward them via the tunnel to the FA. When
the FA detects that the MN has disconnected from the NAS, it issues a
deregister request to the HA.
Because ATMP allows protocols other than IP to be carried on its
tunnels and also allows unregistered IP address to be used to provide
for access to enterprise networks, the HA doesn't necessarily route
datagrams received from the MN in the conventional manner. The
registration request allows for a named "Connection Profile" to be
specified in the registration request. This Connection Profile
contains configuration information that tells the HA where to send
packets that it receives from the MN.
1.4 Specification Language
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means
that the definition is an absolute requirement
of the specification.
MUST NOT This phrase means that the definition is an
absolute prohibition of the specification.
SHOULD This word, or the adjective "recommended",
means that, in some circumstances, valid
reasons may exist to ignore this item, but
the full implications must be understood and
carefully weighed before choosing a different
course. Unexpected results may result
otherwise.
MAY This word, or the adjective "optional", means
that this item is one of an allowed set of
alternatives. An implementation which does
not include this option MUST be prepared to
interoperate with another implementation which
does include the option.
silently discard The implementation discards the datagram
without further processing, and without
indicating an error to the sender. The
implementation SHOULD provide the capability of
logging the error, including the contents of
the discarded datagram, and SHOULD record the
event in a statistics counter.
2.0 Protocol Specification
ATMP defines a set of request and reply messages sent with UDP [4].
The HA listens on UDP port 5150 [6]) for requests from FA's. The UDP
checksum field MUST be computed and verified. There are 7 different
ATMP message types represented by the following Type values:
Message Type Type code
Registration Request 1
Challenge Request 2
Challenge Reply 3
Registration Reply 4
Deregister Request 5
Deregister Reply 6
Error Notification 7
2.1 Registration Request
The FA issues a Registration Request to request the HA to establish a
mobility binding for the specified MN home address. The request is
issued to the HA by the FA upon detecting a MN that wishes to use a
home address supported by the HA receiving the request.
IP fields
Source Address The IP address of the foreign agent
interface from which the request is
issued.
Destination Address The IP address of the home agent.
UDP fields:
Source Port variable
Destination Port 5150 (or port number configured in FA
for given HA)
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foreign Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node IPX Net |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Mobile Node IPX Station . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Network Name . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 1 for Registration Request.
Identifier A 16 bit number used to match replies
with requests. A new value should be
provided in each new request.
Retransmissions of the same request
should use the same identifier.
Foreign Agent The IP address of the foreign agent
issuing the request (typically the same
as the UDP source address).
Mobile Node The IP address to be used by the mobile
node. This is the mobile node's home
address. This field can be all 0's if
IPX is to be tunneled to the mobile node.
Mobile Node Mask The network bit mask for the mobile node.
Currently this value should be set to all
1's.
Mobile Node IPX Net The Network portion of the mobile node's
IPX address. This value should be set to
all 0's if only IP is to be tunneled.
Mobile Node IPX Station The 6 octet value used to represent the
station portion of the mobile node's IPX
address. This value should be set to all
0's if only IP is to be tunneled instead
of IPX.
Reserved This field is for future extensibility
and MUST be set to all 0's.
HN Name This is the name of the "Connection
Profile" to be used by the home agent to
forward all packets received from the
mobile node. This character string is
terminated by a NUL character and can be
up to 32 characters long, including the
NUL terminator.
2.2 Challenge Request
The Home Agent issues a Challenge Request in response to the receipt
of a Registration Request from a Foreign Agent. It is used by the
Home Agent, in conjunction with the Challenge Reply, to authenticate
the Foreign Agent.
IP fields
Source Address The IP address of the Home Agent
interface from which the request is
issued.
Destination Address Copied form the Source Address of the
Registration Request.
UDP fields:
Source Port variable
Destination Port Copied from the Source Port of the
Registration Request.
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 2 for Challenge Request
Identifier A 16 bit number used to match replies
with requests. A new value should be
provided in each new request.
Retransmissions of the same request
should use the same identifier.
Authenticator A series of 16 octet values randomly
generated by the Home Agent. The
receiving Foreign Agent is to perform an
MD5 [7] hash of these values along with a
shared secret. The resultant digest is
returned in the Challenge Reply. See
Sec. 2.3 Retransmissions of the Challenge
Request should use the same Authenticator
value.
A value of all 0's in this field
indicates an error occurred with the
Registration Request. The error code
will be in the following field.
Result Code If non-zero, this value indicates the
error condition that occurred. See Sec.
2.8 for a list of Result Code values and
their meanings.
A non-zero value in this field implies
that the Authenticator field will be
zero.
2.3 Challenge Reply
The Foreign Agent issues a Challenge Reply upon receipt of a valid
Challenge Request (one with a Result Code of 0) from the Home Agent.
The Foreign Agent uses the randomly generated Authenticator value
from the Challenge Request along with a shared secret to produce an
MD5 digest value which is returned to the Home Agent in the Challenge
Reply.
IP fields
Source Address The IP address of the Foreign Agent
interface from which the reply is issued.
Destination Address Copied from the Source Address of the
Challenge Request.
UDP fields:
Source Port variable
Destination Port Copied from the Source Port of the
Challenge Request.
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reply Length | Reply . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 3 for Challenge Reply
Identifier Copied from the corresponding
Deregistration Request.
Reply Length This field specifies the length of the
challenge reply computation based on the
received Authenticator and the shared
secret. For MD5 this length will always
be 16. This field is provided for future
extensibility.
Reply This is the computed challenge reply. It
is computed by performing an MD5 message
digest computation over the Authenticator
value received in the Challenge Request
appended with the secret shared between
the Foreign Agent and the Home Agent.
The digests produced by MD5 are always 16
octets long.
2.4 Registration Reply
A Registration Reply is issued by a Home Agent in reply to a
Challenge Reply received from a Foreign Agent. The Registration
Reply indicates to the Foreign Agent whether the registration was
accepted by the Home Agent or not. It also provides a "tunnel ID" to
uniquely identify the tunnel to be associated with this session.
The Home Agent calculates the same MD5 hash on the Challenge Request
Authenticator field and the shared secret. The resulting digest is
compared with the Reply value in the Challenge Reply and if it is
equal, authentication is successful. Otherwise the registration is
not accepted and the Foreign Agent is informed by the Result Code of
the Registration Reply that registration failed due to an
authentication failure.
IP fields
Source Address The IP address of the Home Agent
interface from which the reply is issued.
Destination Address Copied from the Source Address of the
Challenge Reply.
UDP fields:
Source Port variable
Destination Port Copied from the Source Port of the
Challenge Reply.
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 4 for Registration Reply
Identifier Copied from the corresponding
Registration Request.
Result Code Specifies the result of the registration
and authentication attempt by the Foreign
Agent. Sec. 2.8 for a list of Result
Code values and their meanings.
Tunnel ID This is the identifier used to indicate a
given mobility binding between a given
Mobile Node and Home Agent. This
identifier is used to distinguish
multiple tunnels between a given Foreign
Agent-Home Agent pair. It is carried in
the "key" field of the GRE [1] tunnel
packets that ATMP uses as the tunnel
protocol. It is also used in
Deregistration Requests and Error
Notification messages to indicate the
particular mobility binding to which they
relate.
2.5 Deregistration Request
The Deregistration Request is issued by the Foreign Agent to the Home
Agent to indicate that the specified mobility binding is to be ended.
This request may result from the Foreign Agent detecting that its
connection to the Mobile Node has terminated. It can also be issued
in response to a detected error condition by the Foreign Agent or
receipt of an Error Notification message from the Home Agent.
IP fields
Source Address The IP address of the Foreign Agent
interface from which the request is
issued.
Destination Address 5150 (or port number configured in FA
for given HA)
UDP fields:
Source Port variable
Destination Port Copied from the Source Port of the
Challenge Reply.
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 5 for Deregistration Request
Identifier A 16 bit number used to match replies
with requests. A new value should be
provided in each new request.
Retransmissions of the same request
should use the same identifier.
Tunnel ID Tunnel identifier of the mobility binding
to be terminated.
2.6 Deregistration Reply
The Deregistration Reply is issued by the Home Agent in response to a
Deregistration Request received from a Foreign Agent. If the
Deregistration Request was valid, the Home Agent removes the
specified mobility binding from its tables and issues an affirmative
reply. Otherwise the Home Agent issues a Deregistration Reply with a
Result Code indicating the reason for failure of the Deregistration
Request.
IP fields
Source Address The IP address of the Home Agent
interface from which the reply is issued.
Destination Address Copied from the Source Address of the
received Deregistration Request.
UDP fields:
Source Port variable
Destination Port Copied from the Source Port of the
received Deregistration Request.
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 6 for Deregistration Reply
Identifier Copied from the corresponding
Deregistration Request.
Result Code Specifies the result of the registration
and authentication attempt by the Foreign
Agent. Sec. 2.8 for a list of Result
Code values and their meanings.
Tunnel ID Tunnel identifier of the mobility binding
specified in the Deregistration Request.
2.7 Error Notification
This message is sent by either agent to inform the other agent that
an error condition has occurred. It provides a last-ditch error
recovery mechanism that is used for conditions that cannot be
reported back to the sender by the normal request-reply mechanism,
such as the receipt of a spontaneously generated reply.
IP fields
Source Address The IP address of the issuing agent
interface from which this message is
issued.
Destination Address The IP address of the Home Agent or
Foreign Agent to which this message is to
be issued.
UDP fields:
Source Port variable
Destination Port If issued to a Home Agent, 5150 (or the
port number configured for the given HA).
If issued to a Foreign Agent, the source
port number saved from the original
Registration Request.
The UDP header is followed by the ATMP fields shown below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version The ATMP protocol version. MUST be 1.
Type 7 for Error Notification
Identifier If issued in response to a received reply
type message, this value should be copied
from the identifier field of the reply.
Otherwise the identifier should be the
value that would be used for the next
generated request.
Result Code This indicates the type of error
detected. The possible result codes are
defined in Sec. 2.8.
Tunnel ID Tunnel identifier of the mobility binding
to which this message pertains. If the
Error Notification is being sent in
response to an unsolicited reply, the
Tunnel ID is copied from the reply.
2.8 Result Codes
Error Code Description
0 NO_ERROR Successful operation
1 AUTH_FAILED Authentication of the Foreign Agent failed.
Registration denied.
2 NOT_ENABLED The Home Agent is not configured to run ATMP.
3 TOO_MANY Too many Mobile Node sessions. Home Agent is out
of resources.
4 PARAMETER_ERROR An invalid value was detected in an ATMP message.
5 INVALID_TUNNEL_ID The Tunnel ID contained in a GRE packet is
invalid or the corresponding mobility binding
does not exist. This usually occurs when either
the MN or HA has reset.
6 TIMEOUT A response to an ATMP request was not received in
time.
7 NET_UNREACHABLE The Home Network for this mobility binding is not
operational (the "Connection Profile" is "down"
or is not defined).
8 GENERAL_ERROR General Error indication.
2.9 Protocol Operation
Upon detection of a Mobile Node requiring ATMP service, the NAS
invokes its ATMP Foreign Agent entity.The FA retrieves configuration
information for the user involved.This information is obtained in a
method particular to the NAS and is not specified by this document.
The information obtained MUST include the Home Agent address and the
shared secret for this HA.It also MAY include the Home Network Name,
if a Connection Profile is to be used for this session.
The FA then sends a Registration Request to the HA informing it that
an MN wishes to register with it. The FA then waits for the HA to
respond with a Challenge Request. The FA retransmits the
Registration Request every 2 seconds until it receives the Challenge
Request. If, after 10 retransmissions, no Challenge Request is
received, the FA will terminate the Registration Request, logs the
registration failure, and disconnects the MN.
Upon receipt of the Challenge Request, the FA examines the Result
code. If it indicates an error condition, the condition is logged
and the MN is disconnected. If the result is zero, the FA generates
a Challenge Reply. The Challenge Reply is generated by appending the
Authenticator obtained from the Challenge Request with the shared
secret (obtained from the configuration data) and then computing the
MD5 hash of this concatenated string (authenticator + secret). The
16 octet hash is then returned in the Challenge Reply for validation
by the HA.
Upon receipt of the Challenge Reply from the FA, the HA does the same
computation of the MD5 hash based on the Challenge Request
Authenticator and the shared-secret (which it too must be configured
with). If this digest matches that provided in the Challenge Reply
by the FA then the authentication is successful and the registration
is accepted. If the authentication fails, or resource limitations
prohibit the registration attempt, the HA returns a Registration
Reply with a non-zero result code to the FA.
If the HA accepts the Challenge Reply from the FA, it assigns a
Tunnel ID to this session and returns this Tunnel ID in a
Registration Reply with a zero result code. This Tunnel ID needs to
be unique for the FA-HA pair. The Tunnel ID is used to multiplex and
demultiplex the packets sent between a given FA-HA pair.
At the time the HA decides to accept a registration, it creates a
control block that associates the Tunnel ID with the appropriate
routing information. If the Registration Request included a Home
Network Name, this name is saved in the table and used as the name of
the Connection Profile for this session.
Upon receipt of the Registration Reply, the FA examines the result
code. If it is non-zero, the FA logs the registration failure and
disconnects the MN. If it is zero, the FA saves the Tunnel ID in a
control block associated with the MN session. The FA and HA are now
ready to exchange data packets for this MN session.
On the FA side, all data received from the MN will be encapsulated
using GRE and sent to the HA with the assigned Tunnel ID included in
the GRE Key field. When the HA receives a GRE packet it decapsulates
it and routes it using the routing information contained in the HA's
control block associated with this Tunnel ID.
When the HA receives a packet destined for the MN's Home Address, it
MUST encapsulate it in a GRE packet and forward it to the appropriate
FA. The Tunnel ID is included in the GRE Key field to allow the FA
to demultiplex the packet.
When the FA receives a GRE packet, it will examine the Tunnel ID in
the GRE Key field to see if it matches the Tunnel ID assigned to any
of the MN's currently connected to the FA. If so, the packet is
decapsulated and forwarded to the MN. If the Tunnel ID doesn't match
any active MN's, an Error Notification message is issued to the HA
and the GRE packet is silently discarded.
When the FA wishes to disconnect the MN from the HA, it issues a
Deregistration Request. This request is issued every 2 seconds. If
after 10 attempts a Deregistration Reply is not received from the HA,
an error condition is logged and the MN is disconnected. Upon
receipt of a Deregistration Reply from the HA, the FA deallocates the
Tunnel ID and disconnects the MN.
3.0 Security Considerations
The Registration function of ATMP is protected by a
Challenge/Response mechanism similar to CHAP [2]. The Home Agent
challenges each registration attempt by a Foreign Agent for
authentication.This authentication requires the configuration of a
shared secret for each HA/client pair.
4.0 Author's Address
Kory Hamzeh
Ascend Communications
1275 Harbor Bay Parkway
Alameda, CA 94502
EMail: kory@ascend.com
5.0 References
[1] Hanks, S. Li, T., Farinacci, D., and Traina, P., "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[2] Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
RFC 1334, October 1992.
[3] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[4] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1990.
[5] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2058,
January 1997.
[6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October, 1994.
[7] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[8] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
Appendix A
Additional RADIUS Attributes for ATMP
This appendix indicates the RADIUS attributes that have been added by
Ascend to support ATMP for IP. Currently these are defined as non-
vendor-specific attributes but have been included in [5].
Attribute: "Ascend-Home-Agent-IP-Addr"
Type: IP-Address
Value: The IP address of the Home Agent
Attribute: "Ascend-Home-Agent-Password"
Type: String
Value: Secret shared for this user with HA
Attribute: "Ascend-Home-Network-Name"
Type: String
Value: Name of Connection Profile for this session
Attribute: "Ascend-Home-Agent-UDP-Port"
Type: Integer
Value: The destination UDP port number for the specified HA
Appendix B
IPX Operation
ATMP specifies a mechanism which allows IPX clients to receive
mobility services from a HA. Section 2 details the protocol used
to register, deregister, and authenticate a tunnel used for IPX.
Note that ATMP is based on IP datagrams for the management of
tunnels and, thus, IPX tunneling with ATMP always requires an
underlying IP network.
Each IPX mobile client requires an IPX network number and node
address pair. Since IPX does not support a similar facility to
IP's "host route," an enterprise-unique network number needs to be
chosen for each home agent. This network number MUST be distinct
from the IPX network number assigned to any of the home agent's
LAN interfaces. Each mobile client tunneled to the home agent MUST
use the same IPX network number.
For example, consider a home agent which supports two mobile
clients. The home agent is on a LAN network with an IPX address
of AA000001. The home agent's client network may be assigned
AA000002. The two mobile clients may have addresses
AA000002:0040F1000001 and AA000002:0040F1000002 respectively.
IPX node numbers need to be unique on a given network. A mechanism
must exist to guarantee that for each home agent's network, a
given mobile client's node address is unique. Several techniques
may be employed to assure unique node addresses. The current
implementation of ATMP described in this document relies on RADIUS
to assign a node address at the foreign agent. The following
RADIUS attributes are included for IPX operation in addition to
the attributes described in Appendix A for IP operation:
Attribute: "Framed-IPX-Network" (See [5] for details).
Attribute: "Ascend-IPX-Node-Addr"
Type: String
String: The node address for the mobile client in 12 octet
ASCII representing the hexadecimal string. Both
lower and upper case characters are permissible.
AI ELI5
On this page
PROBLEMRemote dial-in users need to appear as if they are directly connected to their home network, even though they are connecting through a Network Access Server on a remote network.
MECHANISMATMP establishes a tunnel between a Foreign Agent (the NAS) and a Home Agent (on the home network) using shared-secret authentication, encapsulating traffic with GRE and a tunnel ID.
WHY IT MATTERSRemote users can use home network addresses and access both IP and IPX traffic as if physically present, though this is a vendor-specific protocol that did not become an Internet standard.
§1The Tunnel Vision Problem
Ascend Tunnel Management Protocol (ATMP) solves a mobility problem: when a remote user dials into a Network Access Server, they need to appear to have a home network address, not an address from the remote network. The RFC specifies how a Foreign Agent (the NAS) and a Home Agent (on the home network) set up a secure tunnel to carry this traffic.
ATMP assumes a simple model: one user stays connected to one NAS for the duration of their session. Unlike Mobile IP, which allows a mobile node to roam between foreign agents while keeping the same address, ATMP is designed for dial-in scenarios where the connection is more stable. The protocol supports both IP and IPX traffic, allowing users to run protocols beyond just TCP/IP.
When you call your office from the road, a tunnel carries all your data to your home office network so you look like you're at your desk.
§2The Three-Way Handshake
ATMP uses three key entities: the Mobile Node (the remote user's client), the Foreign Agent (the NAS it connects to), and the Home Agent (on the home network). The client is unaware of ATMP; it simply uses standard PPP and believes it has a home network address.
The FA and HA perform a registration dance. First, the FA sends a Registration Request with the user's home address. The HA replies with a Challenge Request containing a randomly generated 16-octet Authenticator value. The FA computes an MD5 hash of this Authenticator plus a shared secret, and returns it in a Challenge Reply. The HA verifies the hash matches (proving the FA knows the shared secret), then issues a Registration Reply with a unique Tunnel ID that identifies this session's tunnel.
Once registered, all traffic from the mobile node is encapsulated by the FA in GRE packets, carrying the Tunnel ID in the GRE Key field. The HA decapsulates and routes these packets according to a Connection Profile, which specifies how to forward traffic for this user. When the user disconnects, the FA issues a Deregistration Request to close the tunnel.
The office and the hotel work out a secret password, verify each other knows it, then set up a tunnel with a unique ID so the office knows which guest's traffic is which.
Mobile NodeForeign AgentHome Agent
- Dials in
- Registration Request
- Challenge Request
- Challenge Reply (MD5 hash)
- Registration Reply (Tunnel ID)
- Tunnel established
§3The Protocol Messages
ATMP defines seven message types, all sent over UDP port 5150. Every message starts with a Version field (always 1), a Type field, and a 16-bit Identifier to match requests and replies.
Registration Request (Type 1) contains the Foreign Agent's IP address, the Mobile Node's home address and netmask, optional IPX network and station numbers, and the name of a Connection Profile to use for routing. Challenge Request (Type 2) carries a 16-octet Authenticator (or a Result Code if an error occurred). Challenge Reply (Type 3) returns the MD5 digest of the Authenticator plus shared secret. Registration Reply (Type 4) includes a Result Code and a Tunnel ID if successful.
When the session ends, the FA sends a Deregistration Request (Type 5) with the Tunnel ID. The HA responds with a Deregistration Reply (Type 6). If either agent detects a problem (such as an unexpected reply), it sends an Error Notification (Type 7) with a Result Code and Tunnel ID. Result Codes indicate success, authentication failure, resource exhaustion, parameter errors, invalid Tunnel IDs, timeouts, network unreachability, or general errors.
Seven types of messages pass between the office and hotel: a registration request, a challenge, a response to the challenge, a confirmation, and later a deregistration and its response, plus error messages if anything goes wrong.
§4Authentication and Trust
ATMP protects the registration phase using a Challenge-Response mechanism similar to CHAP (Challenge Handshake Authentication Protocol). The Home Agent issues a random challenge; only a Foreign Agent that possesses the shared secret can correctly compute the MD5 response. The HA verifies the response and accepts the registration only if it matches.
This mechanism authenticates the Foreign Agent, preventing unauthorized agents from establishing tunnels. However, once registered and a Tunnel ID is issued, the actual data packets encapsulated in GRE are not individually authenticated by ATMP; security of the tunnel depends on the GRE encapsulation and physical network security. The shared secret must be securely configured on both the FA and HA out of band, and the UDP checksum must be computed and verified on all messages.
The RFC notes that configuration information—including the Home Agent address, shared secret, and Connection Profile name—is typically delivered via RADIUS (Remote Authentication Dial In User Service), as shown in an appendix. This allows centralized management of tunnel parameters without hardcoding them in each NAS.
The secret password proves the hotel knows who it is before the office opens the tunnel. After that, trust is maintained by the fact that data is wrapped in a secure envelope and physical network security.
§5References
[1]RFC 1701Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994.October 1994[2]RFC 1334Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.October 1992[3]RFC 2002Perkins, C., "IP Mobility Support", RFC 2002, October 1996.October 1996[4]RFC 768Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.August 1980[5]RFC 2058Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997.January 1997