|
9.9.
ASSIGN_RESPONSE_RSAP-IP
9.9.1. Description
The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP
gateway to
deliver parameter assignments to an RSIP host. A host-wise
unique
bind ID, lease time, and tunnel type must be provided for
every
assignment.
9.9.2. Format
<ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
9.9.3. Behavior
Regardless of local flow policy, a local address and port(s)
MUST be
assigned to the host. If macro-flow based local policy is
used, the
host is assigned an address and one or more ports. If
micro-flow
based local policy is used, the host is assigned an address
and
exactly one port.
If no remote flow policy is used, the RSIP gateway MUST use
"don't
care" values for the remote address and ports parameters. If
macro-
flow based remote policy is used, the remote address
parameter MUST
contain the address specified in the associated request, and
the
remote ports parameter must contain a "don't care" value. If
micro-
flow based remote policy is used, the remote address and
remote ports
parameters MUST contain the address and port information
specified in
the associated request.
----------------------------------------------------------------[Page
26]
If the host detects an error or otherwise does not
"understand" the
gateway's response, it SHOULD send a FREE_REQUEST with the
bind ID
from the said ASSIGN_RESPONSE_RSAP-IP. This will serve to
help
synchronize the states of the host and gateway.
The address of a tunnel endpoint that is not the RSIP
gateway MAY be
specified. If this parameter is not specified, the RSIP
gateway MUST
be assumed to be the tunnel endpoint.
9.10. EXTEND_REQUEST
9.10.1. Description
The EXTEND_REQUEST message is used to request a lease
extension to a
current bind. It may be used with both RSA-IP and RSAP-IP.
The host
MUST specify its client ID and the bind ID in question, and
it MAY
suggest a lease time to the gateway.
9.10.2. Format
<EXTEND_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Lease Time]
[Message Counter]
9.10.3. Behavior
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the
gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the
gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the message contains an incorrect bind ID, the gateway
MUST
respond with an ERROR_RESPONSE containing the BAD_BIND_ID
error.
----------------------------------------------------------------[Page
27]
If the RSIP gateway grants an extension to the host's lease,
it MUST
RESPOND with an appropriate EXTEND_RESPONSE message. If the
lease is
not renewed, the RSIP gateway MAY let it implicitly expire
by doing
nothing or make it explicitly expire by sending an
appropriate
FREE_RESPONSE message.
9.11. EXTEND_RESPONSE
9.11.1. Description
The EXTEND_RESPONSE message is used by an RSIP gateway to
grant a
requested lease extension. The gateway MUST specify the
client ID of
the host, the bind ID in question, and the new assigned
lease time.
9.11.2. Format
<EXTEND_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Lease Time>
[Message Counter]
9.11.3. Behavior
The RSIP gateway will determine lease time as per its local
policy.
The returned time is to be interpreted as the number of
seconds
before the lease expires, counting from the time at which
the message
is sent/received.
9.12. FREE_REQUEST
9.12.1. Description
The FREE_REQUEST message is used by an RSIP host to free a
binding.
The given bind ID identifies the bind to be freed. Resources
may
only be freed using the granularity of a bind ID.
9.12.2. Format
<FREE_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]
----------------------------------------------------------------[Page
28]
9.12.3. Behavior
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the
gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the
gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the message contains an incorrect bind ID, the gateway
MUST
respond with an ERROR_RESPONSE containing the BAD_BIND_ID
error.
If a host receives an error in response to a FREE_REQUEST,
this may
indicate that the host and gateway's states have become
unsynchronized. Therefore, the host SHOULD make an effort to
resynchronize, such as freeing resources then re-requesting
them, or
de-registering then re-registering.
9.13. FREE_RESPONSE
9.13.1. Description
The FREE_RESPONSE message is used by an RSIP gateway to
acknowledge a
FREE_REQUEST sent by an RSIP host, and to asynchronously
deallocate
resources granted to an RSIP host.
9.13.2. Format
<FREE_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]
9.13.3. Behavior
An RSIP host must always be ready to accept a FREE_RESPONSE,
even if
its lease on the specified bind ID is not yet expired.
----------------------------------------------------------------[Page
29]
9.14. QUERY_REQUEST
9.14.1. Description
A QUERY_REQUEST message is used by an RSIP host to ask an
RSIP
gateway whether or not a particular address or network is
local or
remote. The host uses this information to determine whether
to
contact the host(s) directly (in the local case), or via
RSIP (in the
remote case).
This message defines an indicator parameter with a 1-byte
value field
and 2 defined values:
- 1 address
- 2 network
9.14.2. Format
<QUERY_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Address Tuple]...
[Network Tuple]...
where
<Address Tuple> ::= <Indicator (address)>
<Address>
<Network Tuple> ::= <Indicator (network)>
<Address (network)>
<Address (netmask)>
9.14.3. Behavior
One or more address or network tuples may be specified. Each
tuple
encodes a request regarding the locality (local or remote)
of the
encoded address or network. If no tuple is specified, the
RSIP
gateway should interpret the message as a request for all
tuples that
it is willing to provide. Note that the FQDN form of the
address
parameter cannot be used to specify the address of a
network, and
only the netmask form of the address parameter can be used
to specify
the netmask of a network.
If an RSIP gateway cannot determine whether a queried host
or network
is local or remote, it SHOULD transmit a QUERY_RESPONSE with
no
response specified for the said host or network.
----------------------------------------------------------------[Page
30]
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the
gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the
gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
9.15. QUERY_RESPONSE
9.15.1. Description
A QUERY_RESPONSE message is used by an RSIP gateway to
answer a
QUERY_REQUEST from an RSIP host.
This message defines an indicator parameter with a 1-byte
value field
and 4 defined values:
- 1 local address
- 2 local network
- 3 remote address
- 4 remote network
9.15.2. Format
<QUERY_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Local Address Tuple]...
[Local Network Tuple]...
[Remote Address Tuple]...
[Remote Network Tuple]...
where
<Local Address Tuple> ::= <Indicator (local address)>
<Address>
<Local Network Tuple> ::= <Indicator (local network)>
<Address (network)>
<Address (netmask)>
<Remote Address Tuple> ::= <Indicator (remote address)>
<Address>
----------------------------------------------------------------[Page
31]
<Remote Network Tuple> ::= <Indicator (remote network)>
<Address (network)>
<Address (netmask)>
9.15.3. Behavior
An RSIP gateway has some leeway in how it responds to a
QUERY_REQUEST. It may just provide the information
requested, if it
can provide such information. It may provide its complete
list of
address and networks, in order to minimize the number of
requests
that the host needs to perform in the future. How an RSIP
gateway
responds may depend on network traffic considerations as
well.
If an RSIP gateway sends a QUERY_RESPONSE that does not
contain any
tuples, or a QUERY_RESPONSE that does not contain a tuple
that
applies to an associated tuple in the associated
QUERY_REQUEST, this
should be interpreted that the RSIP gateway does not know
whether the
queried host or network is local or remote. Appropriate host
behavior upon receipt of such a message is to assume that
the queried
host or network is remote.
Note that an RSIP gateway is not expected to maintain a
complete list
of all remote hosts and networks. In fact, a typical RSIP
gateway
will only maintain a list of the networks and hosts that it
knows are
local (private with respect to the RSIP host).
9.16. LISTEN_REQUEST
9.16.1. Description
A LISTEN_REQUEST message is sent by an RSIP host that wants
to
register a service on a particular address and port number.
The host
must include its client ID, local address parameter and
ports
parameters, and remote address and ports parameters. The
client MAY
suggest a lease time and one or more tunnel types.
----------------------------------------------------------------[Page
32]
9.16.2. Format
<LISTEN_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]...
9.16.3. Behavior
If the host wants to listen on a particular address or port,
it may
specify these in the address and ports parameters. Otherwise
it may
leave one or both of these parameters with "don't care"
values.
If no remote flow policy is being used, the host MUST fill
both the
remote address and ports parameters with "don't care"
values. If
macro-flow based remote policy is used, the host MUST
specify the
remote address, but MAY or MAY NOT specify the remote
port(s). If
micro-flow based remote policy is used, the host MUST
specify the
remote address and ports parameter.
Once a LISTEN_REQUEST has been granted, the RSIP gateway
MUST forward
all packets destined to the address and port in question to
the host,
even if the remote host address and port tuple has not been
previously contacted by the host.
LISTEN_REQUEST is not necessary for RSA-IP.
The following message-specific error conditions exist:
- If the host is not registered with the gateway, the
gateway
MUST respond with an ERROR_RESPONSE containing the
REGISTER_FIRST error.
- If the message contains an incorrect client ID, the
gateway
MUST respond with an ERROR_RESPONSE containing the
BAD_CLIENT_ID error.
- If the local address parameter is a don't care value and
the
RSIP gateway cannot allocate ANY addresses, the RSIP gateway
MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
----------------------------------------------------------------[Page
33]
- If the local address parameter is not a don't care value
there
are five possible error conditions:
o If the RSIP gateway cannot allocate ANY addresses, it MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNAVAILABLE error.
o If the RSIP gateway cannot allocate the requested address
because it is in use, the RSIP gateway MUST respond with an
ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
o If the RSIP gateway cannot allocate the requested address
because it is not allowed by policy, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
o If the RSIP gateway cannot allocate the requested address
/
port tuple because it is in use, the RSIP gateway MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_INUSE error.
o If the RSIP gateway cannot allocate the requested address
/
port tuple because it is not allowed by policy, the
RSIP
gateway MUST respond with an ERROR_RESPONSE containing the
LOCAL_ADDRPORT_UNALLOWED error.
- If macro-flow based remote policy is used and the
requested
remote address is not allowed by the RSIP gateway's
policy, the
RSIP gateway MUST respond with an ERROR_RESPONSE containing
the
REMOTE_ADDR_UNALLOWED error.
- If micro-flow based remote policy is used and the
requested
remote address / port pair is not allowed by the RSIP
gateway's
policy, the RSIP gateway MUST respond with an ERROR_RESPONSE
containing the REMOTE_ADDRPORT_UNALLOWED error.
- If an unsupported or unallowed tunnel type is specified,
the
RSIP gateway MUST respond with an ERROR_RESPONSE containing
the
BAD_TUNNEL_TYPE error.
- If the host has not specified local or remote address or
port
information in enough detail, the RSIP gateway MUST respond
with an ERROR_RESPONSE containing the
FLOW_POLICY_VIOLATION
error.
----------------------------------------------------------------[Page
34]
9.17. LISTEN_RESPONSE
9.17.1. Description
A LISTEN_RESPONSE message is used by an RSIP gateway to
respond to a
LISTEN_REQUEST message from an RSIP host. The RSIP gateway
MUST
issue a bind ID, and specify the address and port which have
been
granted to the host. The gateway must also specify a tunnel
type and
lease time.
If no remote flow policy is being used, the gateway MUST
fill both
the remote address and ports parameters with "don't care"
values. If
macro-flow based remote policy is used, the gateway MUST
specify the
remote address, but MAY or MAY NOT specify the remote
port(s). If
micro-flow based remote policy is used, the gateway MUST
specify the
remote address and ports parameter.
9.17.2. Format
<LISTEN_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Tunnel Type>
<Lease Time>
[Address (tunnel endpoint)]
[Message Counter]
9.17.3. Behavior
If no remote flow policy is being used, the gateway MUST
fill both
the remote address and ports parameters with "don't care"
values. If
macro-flow based remote policy is used, the gateway MUST
specify the
remote address, but MAY or MAY NOT specify the remote
port(s). If
micro-flow based remote policy is used, the gateway MUST
specify the
remote address and ports parameter.
The address of a tunnel endpoint that is not the RSIP
gateway MAY be
specified. If this parameter is not specified, the RSIP
gateway MUST
be assumed to be the tunnel endpoint.
----------------------------------------------------------------[Page
35]
10. Discussion
10.1. Use of Message Counters, Timeouts, and Retransmissions
Message counters are conceptually similar to sequence
numbers. They
are necessary to facilitate reliability when UDP is the
transport
protocol. Each UDP message is marked with a message counter.
When
such a message is transmitted, the message is stored in a
"last
message" buffer. For RSIP hosts, a timer is set to expire at
the
appropriate timeout value.
General rules:
- When an RSIP host transmits a message with a message
counter
value of n, the RSIP gateway's response will contain a
message
counter value of n.
- An RSIP host will not increment its message counter value
to
n+1 until it receives a message from the RSIP gateway with a
message counter value of n.
- An RSIP gateway begins all sessions with a message counter
value of 1.
- If the message counter value reaches the maximum possible
32-
bit value, it will wrap around to 1, not 0.
- If a message with a message counter value of n is
transmitted
by an RSIP host, but a timer expires before a response to
that
message is received, the copy of the message (from the "last
message" buffer) is retransmitted.
- When an RSIP gateway receives a duplicate copy of a
message
with a message counter value of n, it transmits the contents
of
its "last message" buffer.
- When the RSIP gateway transmits an asynchronous RSIP
message
(an RSIP message for which there was no request by the RSIP
host), a message counter value of 0 MUST be used. Note that
only three RSIP messages can be transmitted asynchronously:
ERROR_RESPONSE, DE-REGISTER_RESPONSE, and FREE_RESPONSE.
These
messages may also be transmitted in response to an RSIP host
request, so their message counter values MAY be non-zero.
- If a message counter is not present in a message from an
RSIP
host, but is required, the RSIP gateway MUST respond with an
ERROR_RESPONSE containing the MESSAGE_COUNTER_REQUIRED
error.
----------------------------------------------------------------[Page
36]
10.2. RSIP Host and Gateway Failure Scenarios
When either the RSIP host or gateway suffers from an
unrecoverable
failure, such as a crash, all RSIP-related state will be
lost. In
this section, we describe the sequence of events that will
occur in
both host and gateway failures, and how the host and gateway
re-
synchronize.
10.2.1. Host Failure
After a host failure, the host will reboot and be unaware of
any RSIP
state held on its behalf at the gateway.
If the host does not immediately attempt to re-establish a
session,
it may receive RSIP packets on the RSIP client application
port that
it was using before it rebooted. If an RSIP client
application is
not active on this port, these packets will be responded to
with ICMP
port unreachable messages. If TCP is the transport protocol,
it is
likely that the connection will be terminated with a TCP
RST. If an
RSIP client is active on this port, it will not recognize
the session
that these packets belong to, and it SHOULD silently ignore
them.
The RSIP host may also receive packets from a remote host
with which
it was communicating before it rebooted. These packets will
be
destined to the RSIP tunnel interface, which should not
exist. Thus
they SHOULD be silently discarded by the RSIP host's stack,
or the
RSIP host will transmit appropriate ICMP messages to the
tunnel
endpoint (e.g., the RSIP gateway). The behavior of the
system with
respect to sessions that were active before the reboot
should be
similar to that of a publically addressable non-RSIP host
that
reboots.
Upon rebooting, an RSIP host may attempt to establish a new
RSIP
session with the RSIP gateway. Upon receiving the
REGISTER_REQUEST
message, the RSIP gateway will be able to determine that, as
far as
it is concerned, the RSIP host is already registered. Thus,
it will
transmit an ERROR_RESPONSE with the ALREADY_REGISTERED
message. Upon
receipt of this message, the RSIP host will know the client
ID of its
old registration, and SHOULD immediately transmit a DE-
REGISTER_REQUEST using this client ID. After this is
accomplished,
the states of the RSIP host and gateway have been
synchronized, and a
new RSIP session may be established.
If the RSIP host does not de-register itself from the RSIP
gateway,
it will eventually receive a DE-REGISTER_RESPONSE from the
gateway,
when the gateway times out the host's session. Since the DE-
REGISTER_RESPONSE will refer to a client ID that has no
meaning to
----------------------------------------------------------------[Page
37]
the host, the host SHOULD silently ignore such a message. At
this
point, the states of the RSIP host and gateway have been
synchronized, and a new RSIP session may be established.
10.2.2. Gateway Failure
After a gateway failure, the gateway will reboot and be
unaware of
any RSIP state held by an RSIP host.
Since the gateway will not attempt to contact any of its
RSIP hosts,
a problem will first be detected when either an RSIP host
sends an
RSIP message to the gateway, an RSIP host sends tunneled
data to the
gateway, or data from a remote host intended for an RSIP
host
arrives.
In the first case, the RSIP gateway SHOULD immediately
response to
all messages (except for a REGISTER_REQUEST) with an
ERROR_RESPONSE
with a REGISTER_FIRST error. Upon receipt of such a message,
an RSIP
host MUST interpret the message as an indication of a loss
of
synchronization between itself and the RSIP gateway. The
RSIP host
SHOULD immediately transmit a DE-REGISTRATION_REQUEST with
its old
client ID (which will generate another error, but this error
SHOULD
be ignored by the host). At this point, the states of the
RSIP host
and gateway have been synchronized, and a new RSIP session
may be
established.
In the second case, all data that an RSIP host sends to the
tunneled
interface of an RSIP server will either (1) be discarded
silently,
(2) responded to with an ICMP Destination Unreachable
message, such
as "Communication Administratively Prohibited", or (3)
blindly routed
to the intended destination. In all of the above cases, the
RSIP
gateway will not have an explicit method to notify the RSIP
host of
the problem. To prevent a long term communications outage,
small
lease times of several minutes can be set by the RSIP
gateway.
In the third case, the RSIP gateway SHOULD discard all
incoming
packets and/or respond with ICMP Port Unreachable messages.
10.3. General Gateway Policy
There is a significant amount of RSIP gateway policy that
may be
implemented, but is beyond the scope of this document. We
expect
that most of this policy will be site-specific or
implementation-
specific and therefore do not make any recommendations.
Examples of
general gateway policy include:
- How ports are allocated to RSIP hosts.
- Preferred length of lease times.
----------------------------------------------------------------[Page
38]
- How flow policy is applied to which hosts.
- How an RSIP gateway with multiple public IP addresses that
may
be leased by RSIP clients determines how to partition
and/or lease these addresses.
10.4. Errors Not From the RSIP Protocol
Once an RSIP host and gateway have established a
relationship and the
host is assigned resources to use, error may occur due to
the host's
misuse of the resources or its attempting to use unassigned
resources. The following error behavior is defined:
- If a host attempts to use a local address which it has not
been
allocated, the RSIP gateway MUST drop the associated
packet(s)
and send the host an ERROR_RESPONSE containing the
LOCAL_ADDR_UNALLOWED error.
- If a host attempts to use a local address / port tuple
which it
has not been allocated, the RSIP gateway MUST drop the
associated packet(s) and send the host an ERROR_RESPONSE
containing the LOCAL_ADDRPORT_UNALLOWED error.
- If a host attempts to contact a remote address which has
not
been properly specified or otherwise approved (e.g., via an
ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow
policy), the RSIP gateway MUST drop the associated packet(s)
and send the host an ERROR_RESPONSE containing the
REMOTE_ADDR_UNALLOWED error.
- If a host attempts to contact a remote address / port
tuple
which has not been properly specified or otherwise approved
(e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote
flow policy), the RSIP gateway MUST drop the associated
packet(s) and send the host an ERROR_RESPONSE containing the
REMOTE_ADDRPORT_UNALLOWED error.
- If a host attempts to establish or use an improper tunnel
type,
the RSIP gateway MUST respond with an ERROR_RESPONSE
containing
the BAD_TUNNEL_TYPE error.
- If the RSIP gateway's detects a local fault which prevents
its
RSIP server module from continuing operation, the RSIP
gateway
MUST respond with an ERROR_RESPONSE containing the
INTERNAL_SERVER_ERROR error.
----------------------------------------------------------------[Page
39]
10.5. Address and Port Requests and Allocation
Regardless of local flow policy, an RSIP host may "suggest"
that it
would like to use a particular local address and/or port
number in a
particular binding. An RSIP gateway that cannot grant such a
request, because the specified resources are already in use,
MUST
respond with an ERROR_RESPONSE containing the
LOCAL_ADDR_INUSE or
LOCAL_ADDRPORT_INUSE values.
10.6. Local Gateways and Flow Policy Interaction
An RSIP host may initialize a publically accessible gateway
(such as
an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST
message to
an RSIP gateway and receiving a LISTEN_RESPONSE. However,
unless no
remote flow policy is used, the gateway will have to specify
the
address or address and port of a single remote host that
will be
allowed to contact it. Obviously, such as restriction is not
very
useful for hosts that require their gateways to be
accessible by any
remote host.
This indicates that there is a conflict between flow-based
policy and
support for gateways. The main purpose of enforcing
flow-based
policy for LISTEN_REQUESTs is that it allows an RSIP gateway
tight
control over how an RSIP host uses ports and the associated
accounting. For example, an RSIP host, operating under
remote
micro-flow based policy and using a protocol such as FTP,
will have
to specify the address and port that it will receive FTP
data on, as
well as the address and port that the gateway will transmit
data
from, in a LISTEN_REQUEST.
In general, an RSIP gateway may not allow arbitrary hosts to
start
public gateways because of the traffic and security
concerns. Thus,
we recommend that if remote micro-flow based policy is used,
that an
RSIP gateway only allow public gateways on RSIP hosts via
administrative override.
Currently, RSIP hosts can only be identified by their local
IP
address or MAC address.
11. Security Considerations
RSIP, in and of itself, does not provide security. It may
provide
the illusion of security or privacy by hiding a private
address
space, but security can only be ensured by the proper use of
security
protocols and cryptographic techniques.
----------------------------------------------------------------[Page
40]
An RSIP gateway should take all measures deemed necessary to
prevent
its hosts from performing intentional or unintentional
denial-of-
service attacks by request large sets of resources.
Currently, RSIP hosts can only be identified by their local
IP
address or, in some cases, MAC address. It is desirable to
allow
RSIP messages sent between a host and gateway to be
authenticated.
Further discussion of such authentication can be found in
[RSIP-
FRAME].
Discussion of RSIP support for end-to-end IPsec can be found
in
[RSIP-IPSEC].
12. IANA Considerations
All of the designations below have been registered by the
IANA.
- RSIP port number: 4555
- RSIP error codes (see Appendix A).
- RSIP message type codes (see Appendix B).
- RSIP tunnel types, methods, and flow policies.
RSIP parameter values are designated as follows:
- 0 Reserved
- 1-240 Assigned by IANA
- 241-255 Reserved for private use
New registrations for the above namespaces are recommended
to be
allocated via the Specification Required method documented
in
[RFC2434].
13. Acknowledgements
The authors would like to specifically thank Gabriel
Montenegro, Pyda
Srisuresh, Brian Carpenter, Eliot Lear, Dan Nessett, Gary
Jaszewski,
Naveen Rajanikantha, Sudhakar Ramakrishna, Jim March, and
Rick Cobb
for their input. The IETF NAT working group as a whole has
been
extremely helpful in the ongoing development of RSIP.
----------------------------------------------------------------[Page
41]
14. Appendix A: RSIP Error Numbers
This section provides descriptions for the error values in
the RSIP
error parameter.
All errors are grouped into the following categories:
100's: General errors.
101: UNKNOWN_ERROR. An error that cannot be identified has
occurred. This error should be used when all other error
messages are inappropriate.
102: USE_TCP. A host has attempted to use UDP on a server
that
only supports TCP.
103: FLOW_POLICY_VIOLATION: A host has not specified address
or
port information in enough detail for its assigned flow
policy.
104: INTERNAL_SERVER_ERROR: An RSIP server application has
detected an unrecoverable error within itself or the RSIP
gateway.
105: MESSAGE_COUNTER_REQUIRED: An RSIP host did not use a
message
counter parameter in a situation in which it should have.
106: UNSUPPORTED_RSIP_VERSION: An RSIP host sent a message
with a
version number that is not supported by the RSIP gateway.
200's: Parameter and message errors. The gateway uses these
errors
when it detects that a parameter or message is malformed, as
well
as when it does not understand a parameter or message.
201: MISSING_PARAM. The request does not contain a required
parameter.
202: DUPLICATE_PARAM. The request contains an illegal
duplicate
parameter.
203: EXTRA_PARAM. The request contains a parameter that it
should
not.
204: ILLEGAL_PARAM. The gateway does not understand a
parameter
type.
205: BAD_PARAM. A parameter is malformed.
----------------------------------------------------------------[Page
42]
206: ILLEGAL_MESSAGE. The gateway does not understand the
message
type. The message type is neither mandatory nor optional.
207: BAD_MESSAGE. A message is malformed and gateway parsing
failed.
208: UNSUPPORTED_MESSAGE: The host has transmitted an
optional
message that the gateway does not support.
300's: Permission, resource, and policy errors. The gateway
uses
these errors when a host has attempted to do something that
it is
not permitted to do, or something that violated gateway
policy.
301: REGISTER_FIRST. The RSIP host has attempted to request
or
use resources without registering.
302: ALREADY_REGISTERED. The host has attempted to register
again
without first de-registering.
303: ALREADY_UNREGISTERED. The host has attempted to
de-register
but it is already in the unregistered state.
304: REGISTRATION_DENIED. The gateway will not allow the
host to
register.
305: BAD_CLIENT_ID. The host has referred to itself with the
wrong client ID.
306: BAD_BIND_ID. The request refers to a bind ID that is
not
valid for the host.
307: BAD_TUNNEL_TYPE. The request refers to a tunnel type
that is
not valid for the host.
308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not
able to
allocate ANY local address, but the host may try again
later.
309: LOCAL_ADDRPORT_UNAVAILABLE. The gateway is currently
not
able to allocate ANY local IP address / port tuple of the
requested magnitude (i.e., number of ports), but the host
may
try again later.
310: LOCAL_ADDR_INUSE. The gateway was not able to allocate
the
requested local address because it is currently used by
another
entity.
----------------------------------------------------------------[Page
43]
311: LOCAL_ADDRPORT_INUSE. The gateway was not able to
allocate
the requested local address / port tuple because it is
currently used by another entity.
312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host
use
the specified local IP address due to policy.
313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the
host
use the specified local address / port pair due to policy.
314: REMOTE_ADDR_UNALLOWED. The gateway will not allow the
host
to establish a session to the specified remote address.
315: REMOTE_ADDRPORT_UNALLOWED. The gateway will not allow
the
host to establish a session to the specified remote address
/
port tuple.
400's: IPsec errors. All errors specific to RSIP / IPsec
operation.
See [RSIP-IPSEC].
15. Appendix B: Message Types
This section defines the values assigned to RSIP message
types. We
also indicate which RSIP entity, host or gateway, produces
each
messages, and whether it is mandatory or optional. All
*_REQUEST
messages are only to be implemented on hosts, while all
*_RESPONSE
messages are only to be implemented on gateways. RSIP
implementations (both host and gateway) MUST support all
mandatory
messages in order to be considered "RSIP compliant".
----------------------------------------------------------------[Page
44]
Value Message Implementation Status
------------------------------------------------------------
1 ERROR_RESPONSE gateway mandatory
2 REGISTER_REQUEST host mandatory
3 REGISTER_RESPONSE gateway mandatory
4 DE-REGISTER_REQUEST host mandatory
5 DE-REGISTER_RESPONSE gateway mandatory
6 ASSIGN_REQUEST_RSA-IP host optional
7 ASSIGN_RESPONSE_RSA-IP gateway optional
8 ASSIGN_REQUEST_RSAP-IP host mandatory
9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory
10 EXTEND_REQUEST host mandatory
11 EXTEND_RESPONSE gateway mandatory
12 FREE_REQUEST host mandatory
13 FREE_RESPONSE gateway mandatory
14 QUERY_REQUEST host optional
15 QUERY_RESPONSE gateway mandatory
16 LISTEN_REQUEST host optional
17 LISTEN_RESPONSE gateway optional
16. Appendix C: Example
RSIP host/gateway transactions
In this appendix, we present an exemplary series of
annotated
transactions between an RSIP host and an RSIP gateway. All
host to
gateway traffic is denote by `C --> S' and all gateway to
host
traffic is denoted by `S --> C'. Parameter values are
denoted inside
of parentheses. Versions, message types, and overall lengths
are not
included in order to save space. "Don't care" values are
indicated
by 0's.
A ports parameter is represented by the number of ports
followed by
the port numbers, separated by dashes. For example,
2-1012-1013
indicates two ports, namely 1012 and 1013, while 16-10000
indicates
16 ports, namely 10000-10015, and 4-0 indicates four ports,
but the
sender doesn't care where they are.
IPv4 addresses are assumed.
16.1. RSAP-IP with Local Macro-flow Based Policy and No
Remote Flow
Policy
This example exhibits the loosest policy framework for
RSAP-IP.
C --> S: REGISTER_REQUEST ()
The host attempts to register with the gateway.
----------------------------------------------------------------[Page
45]
S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy
=
Macro, Remote Flow policy = None, Lease Time = 600)
The gateway responds, assigning a Client ID of 1, local
macro-
flow based policy and no remote flow policy. No RSIP method
is
indicated, so RSAP-IP is assumed. No tunnel type is
indicated,
so IP-IP is assumed. A lease time of 600 seconds is
assigned.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address
(local) =
0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote)
=
0, Lease Time = 3600)
The host requests an address and four ports to use with it,
but
doesn't care which address or ports are assigned. The host
does not specify the remote address or ports either. The
host
suggests a lease time of 3600 seconds.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID =
1,
Address (local) = 149.112.240.156, Ports (local) = 4-1234,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800,
Tunnel Type = IP-IP)
The gateway responds by indicating that a bind ID of 1 has
been
assigned to IP address 149.112.240.156 with ports 1234-1237.
Any remote host may be communicated with, using any remote
port
number. The lease time has been assigned to be 1800 seconds,
and the tunnel type is confirmed to be IP-IP.
The host is now able to communicate with any host on the
public
network using these resources.
C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network,
Address (network) = 10.20.60.0, Address (netmask)
255.255.255.0)
The host asks the gateway if the network 10.20.60.0/24 is
local.
S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator =
network,
Address (network) = 10.20.60.0, Address (netmask) =
255.255.255.0)
The gateway responds indicating that the network in question
is
local.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address
(local) =
149.112.240.156, Ports (local) = 8-1238, Address (remote) =
0,
Ports (remote) = 0, Lease Time = 1800)
----------------------------------------------------------------[Page
46]
The host requests eight more particular ports for use with
RSAP-IP with the same address. A lease of 1800 seconds is
requested. IP-IP tunneling is implied by default.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID =
2,
Address (local) = 149.112.240.156, Ports (local) = 8-1305,
Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
The gateway grants the request with the same address, but
with
a different set of ports. IP-IP tunneling is implied by
default.
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)
The host frees bind ID 1; i.e., ports 1234-1237 from IP
address
149.112.240.156. Note that the address itself is still
assigned to the host because the host is still assigned
ports
1305-1314.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)
The gateway acknowledges that Bind ID 1 has been freed.
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease
Time =
1800)
The host request that the lease on bind ID 1 be extended for
1800 seconds.
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease
Time =
1800)
The gateway confirms the request.
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)
The gateway forces the host to free the resources of bind ID
2.
C --> S: DE-REGISTER_REQUEST (Client ID = 1)
The host de-registers with the sever.
S --> C: DE-REGISTER_RESPONSE (Client ID = 1)
The gateway acknowledges that the host has
de-registered.
----------------------------------------------------------------[Page
47]
16.2. RSAP-IP with Local Micro-flow Based Policy and Remote
Micro-
flow Based Policy
This example exhibits the strictest policy framework for
RSAP-IP.
C --> S: REGISTER_REQUEST ()
The host attempts to register with the gateway.
S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy
=
Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP,
RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE,
Lease
Time = 600)
The gateway responds, assigning a Client ID of 5, local
micro-
flow based policy and remote micro-flow based policy. Both
RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel
types are supported. A lease time of 600 seconds is
assigned.
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address
(local) =
0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports
(remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
The host requests a local address and a port assignment to
use
with it. The host indicates that it wants to contact host
38.196.73.6 at port 21 (FTP control). The host requests a
lease time of 600 seconds and a tunnel type of IP-IP.
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID =
1,
Address (local) = 149.112.240.156, Ports (local) = 2049,
Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease
Time
= 600, Tunnel Type = IP-IP)
The gateway responds by indicating that a bind ID of 1 has
been
assigned to IP address 149.112.240.156 with port 2049. Only
host 38.196.73.6 at port 21 may be contacted. The lease time
has been assigned to be 600 seconds, and the tunnel type is
confirmed to be IP-IP.
C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20)
The host requests a listen port 2050 at the same address
that
it has been assigned. Only host 38.196.73.6 from ports 20
(FTP
data) will be able to contact it.
----------------------------------------------------------------[Page
48]
S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) =
149.112.240.156, Ports (local) = 2050, Address (remote) =
38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel
Type
= IP-IP)
The gateway confirms the request and assigns a lease time of
600 seconds and a tunnel type of IP-IP.
C --> S: DE-REGISTER_REQUEST (Client ID = 5)
The host de-registers with the sever.
S --> C: DE-REGISTER_RESPONSE (Client ID = 5)
The gateway acknowledges that the host has de-registered.
All
of the host's bindings have been implicitly revoked.
16.3. RSA-IP with Local Macro-flow Based Policy and Remote
Macro-
flow based Policy
This example exhibits a medium level of control for RSA-IP.
C --> S: REGISTER_REQUEST ()
The host attempts to register with the gateway.
S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy
=
Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP,
RSIP
Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP,
Lease
Time = 600)
The gateway responds, assigning a Client ID of 3, local
macro-
flow based policy and remote macro-flow based policy. Both
RSAP-IP and RSA-IP are supported. Both IP-IP and L2TP tunnel
types are supported. A lease time of 600 seconds is
assigned.
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address
(local) =
0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)
The host requests a local address and indicates that it
wants
to contact host www.foo.com.
S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED,
Client ID
= 3)
The gateway indicates that the host is not permitted to
establish communication with www.foo.com.
----------------------------------------------------------------[Page
49]
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address
(local) =
0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease
Time = 3600, Tunnel Type = IP-IP)
The host requests a local address and indicates that it
wants
to contact host www.bar.com.
S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID =
1,
Address (local) = 149.112.240.17, Address (remote) =
www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel
Type
= IP-IP)
The gateway responds by granting local IP address
149.112.240.17 to the host, and permitting it to communicate
with www.bar.com, at any port. Requested lease time and
tunnel
type are also granted.
C --> S: DE-REGISTER_REQUEST (Client ID = 3)
The host de-registers with the sever.
S --> C: DE-REGISTER_RESPONSE (Client ID = 3)
The gateway acknowledges that the host has de-registered.
All
of the host's bindings have been implicitly revoked.
17. Appendix D: Example RSIP host state diagram
This appendix provides an exemplary diagram of RSIP host
state. The
host begins in the unregistered state. We assume that for
UDP, if a
message is lost, the host will timeout and retransmit
another copy of
it. We recommend a 7-fold binary exponential backoff timer
for
retransmissions, with the first timeout occurring after 12.5
ms.
This diagram does not include transitions for the
LISTEN_REQUEST
message.
----------------------------------------------------------------[Page
50]
send
REGISTER_REQUEST
+------------+ +------------+
| |------------->|Registration|<-- timeout/send
+--->|Unregistered|<-------------| Pending |--- REGISTER_REQUEST
| | | +------------+
| +------------+ 7th timeout/recv |
| ^ ERROR_RESPONSE |
| | |
| | |
| |7th timeout/recv |recv timeout/send
| |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST
| | | ^ |
| | | | |
| | | send | |
| | send DE- v QUERY_REQUEST | |
| +----------------+ REGISTER_REQUEST+----------+ +----------+
| | Registered |<----------------| |--------->|Registered|
| | De-registration| |Registered| | Query |
| | Pending |---------------->| |<---------| Pending |
| +----------------+ recv +----------+ +----------+
| | ^ ERROR_RESPONSE ^ | 7th timeout/recv
| | | | | QUERY_RESPONSE or
| timeout/send | | ERROR_RESPONSE
| DE-REGISTER_REQUEST 7th timeout/recv| |
| ERROR_RESPONSE | |
| | |
| +----------------+ | |
| |Go to Registered| | |send
| +----------------+ | |ASSIGN_REQUEST
| ^ timeout/send | |
| |Yes FREE_REQUEST | |
| + | | | |
| + + v | | v
| + + 7th timeout/ +--------+ +----------+
| + Are all + recv | Free | |Assignment|<--timeout/send
| + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST
| + freed? + FREE_RESPONSE+--------+ +----------+
| + + ^ | |
| + + | | |
| + | | |recv
| |No send | |recv |ASSIGN_RESPONSE
| v ERROR_REQUEST| |ERROR_ |
| +---------------+ | |RESPONSE |
| | Go to Assigned| | | | 7th timeout/recv
| +---------------+ | | | QUERY_RESPONSE or
| recv | | | ERROR_RESPONSE
| +---------------+ERROR_RESPONSE | v v +-----------+
----------------------------------------------------------------[Page 51]
| | Assigned |-------------->+-------------+-------->| Assigned |
+>|De-registration| | Assigned | | Query |
| Pending |<--------------+-------------+<--------| Pending |
+---------------+ send ^ | +-----------+
^ | DE-REGISTER_REQUEST | | send ^ |
| | | | QUERY_REQUEST | |
| | | | | |
timeout/send 7th/timeout/recv | |send | |
DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send
REQUEST or ERROR_RESPONSE| | QUERY_REQUEST
| |
| v
+----------+
| Assigned |
|Assignment|
| Pending |
+----------+
^ |
| |
timeout/send
ASSIGN_REQUEST
18. References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de
Groot,
G.J. and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
indicate
requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RSIP-FRAME] Borella, M. Lo, J., Grabelsky, D. and G.
Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP-IPSEC] Montenegro, G. and M. Borella, "RSIP Support
for End-
to-end IPSEC", RFC 3104, October 2001.
----------------------------------------------------------------[Page
52]
19. Authors' Addresses
Michael Borella
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008
Phone: (847) 262-3083
EMail: mike_borella@commworks.com
David Grabelsky
CommWorks
3800 Golf Rd.
Rolling Meadows IL 60008
Phone: (847) 222-2483
EMail: david_grabelsky@commworks.com
Jeffrey Lo
Candlestick Networks, Inc
70 Las Colinas Lane,
San Jose, CA 95119
Phone: (408) 284 4132
EMail: yidarlo@yahoo.com
Kunihiro Taniguchi
NEC USA
C&C Research Labs.
110 Rio Robles
San Jose, CA 95134
Phone: (408) 943-3031
EMail: taniguti@ccrl.sj.nec.com
----------------------------------------------------------------[Page
53]
20. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights
Reserved.
This document and translations of it may be copied and
furnished to
others, and derivative works that comment on or otherwise
explain it
or assist in its implementation may be prepared, copied,
published
and distributed, in whole or in part, without restriction of
any
kind, provided that the above copyright notice and this
paragraph are
included on all such copies and derivative works. However,
this
document itself may not be modified in any way, such as by
removing
the copyright notice or references to the Internet Society
or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures
for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages
other than
English.
The limited permissions granted above are perpetual and will
not be
revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is
provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by
the
Internet Society.
----------------------------------------------------------------[Page
54]
Credits
-- UnKnown -- |