As per Relevance of the word implementation, we have this rfc below:
Network Working Group G.
Request for Comments: 3104 Sun Microsystems, Inc
Category: Experimental M.
October 2001
RSIP Support for End-to-end
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard of any kind
Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
IESG
The IESG notes that the set of documents describing the
technology imply significant host and gateway changes for a
implementation. In addition, the floating of port numbers can
problems for some applications, preventing an RSIP-enabled host
interoperating transparently with existing applications in some
(e.g., IPsec). Finally, there may be significant
complexities associated with using RSIP. Some of these and
complications are outlined in section 6 of the RFC 3102, as well
in the Appendices of RFC 3104. Accordingly, the costs and
of using RSIP should be carefully weighed against other means
relieving address shortage
This document proposes mechanisms that enable Realm Specific
(RSIP) to handle end-to-end IPsec (IP Security).
Montenegro & Borella Experimental [Page 1]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Table of
1. Introduction .................................................. 2
2. Model ......................................................... 2
3. Implementation Notes .......................................... 3
4. IKE Handling and Demultiplexing ............................... 4
5. IPsec Handling and Demultiplexing ............................. 5
6. RSIP Protocol Extensions ...................................... 6
6.1 IKE Support in RSIP ....................................... 6
6.2 IPsec Support in RSIP ..................................... 7
7. IANA Considerations ........................................... 10
8. Security Considerations ....................................... 10
9. Acknowledgements .............................................. 10
References ....................................................... 11
Authors' Addresses ............................................... 12
Appendix A: On Optional Port Allocation to RSIP Clients .......... 13
Appendix B: RSIP Error Numbers for IKE and IPsec Support ......... 14
Appendix C: Message Type Values for IPsec Support ................ 14
Appendix D: A Note on Flow Policy Enforcement .................... 14
Appendix E: Remote Host Rekeying ................................. 14
Appendix F: Example Application Scenarios ........................ 15
Appendix G: Thoughts on Supporting Incoming Connections .......... 17
Full Copyright Statement ......................................... 19
1.
This document specifies RSIP extensions to enable end-to-end IPsec
It assumes the RSIP framework as presented in [RSIP-FW],
specifies extensions to the RSIP protocol defined in [RSIP-P].
terminology follows [NAT-TERMS].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
2.
For clarity, the discussion below assumes this model
RSIP client RSIP server
Xa Na Nb
+------------+ Nb1 +------------+
[X]------| Addr space |----[N]-----| Addr space |-------[Y
| A | Nb2 | B |
+------------+ ... +------------+
Montenegro & Borella Experimental [Page 2]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Hosts X and Y belong to different address spaces A and B
respectively, and N is an RSIP server. N has two addresses: Na
address space A, and Nb on address space B. For example, A could
a private address space, and B the public address space of
general Internet. Additionally, N may have a pool of addresses
address space B which it can assign to or lend to X
This document proposes RSIP extensions and mechanisms to enable
RSIP client X to initiate IKE and IPsec sessions to a legacy IKE
IPsec node Y. In order to do so, X exchanges RSIP protocol
with the RSIP server N. This document does not yet address IKE/
session initiation from Y to an RSIP client X. For some thoughts
this matter see Appendix G
The discussion below assumes that the RSIP server N is examining
packet sent by Y, destined for X. This implies that "source"
to Y and "destination" refers to Y's peer, namely, X's presence at N
This document assumes the use of the RSAP-IP flavor of RSIP (
that port number assignments are optional), on top of which
values are used for demultiplexing. Because of this, more than
RSIP client may share the same global IP address
3. Implementation
The RSIP server N is not required to have more than one address
address space B. RSIP allows X (and any other hosts on address
A) to reuse Nb. Because of this, Y's SPD SHOULD NOT be configured
support address-based keying. Address-based keying implies that
one RSIP client may, at any given point in time, use address Nb
exchanging IPsec packets with Y. Instead, Y's SPD SHOULD
configured to support session-oriented keying, or user-
keying [Kent98c]. In addition to user-oriented keying, other
of identifications within the IKE Identification Payload are
effective at disambiguating who is the real client behind the
address Nb [Piper98].
Because it cannot rely on address-based keying, RSIP support
IPsec is similar to the application of IPsec for remote access
dynamically assigned addresses. Both cases impose
requirements which are not met by minimally compliant
implementations [Gupta]:
Note that a minimally-compliant IKE implementation (which
implements Main mode with Pre-shared keys for Phase
authentication) cannot be used on a remote host with a
assigned address. The IKE responder (gateway) needs to look
the initiator's (mobile node's) pre-shared key before it
Montenegro & Borella Experimental [Page 3]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
decrypt the latter's third main mode message (fifth overall
Phase I). Since the initiator's identity is contained in
encrypted message, only its IP address is available for lookup
must be predictable. Other options, such as Main mode
digital signatures/RSA encryption and Aggressive mode,
accommodate IKE peers with dynamically assigned addresses
IKE packets are typically carried on UDP port 500 for both source
destination, although the use of ephemeral source ports is
precluded [ISAKMP]. IKE implementations for use with RSIP
employ ephemeral ports, and should handle them as follows [IPSEC
MSG]:
IKE implementations MUST support UDP port 500 for both source
destination, but other port numbers are also allowed. If
implementation allows other-than-port-500 for IKE, it sets
value of the port numbers as reported in the ID payload to 0
(meaning "any port"), instead of 500. UDP port numbers (500
not) are handled by the common "swap src/dst port and reply
method
It is important to note that IPsec implementations MUST be aware
RSIP, at least in some peripheral sense, in order to receive
SPIs and perhaps other parameters from an RSIP client. Therefore
bump-in-the-stack (BITS) implementations of IPsec are not expected
work "out of the box" with RSIP
4. IKE Handling and
If an RSIP client requires the use of port 500 as its IKE source
this prevents that field being used for demultiplexing. Instead,
"Initiator Cookie" field in the IKE header fields must be used
this purpose. This field is appropriate as it is guaranteed to
present in every IKE exchange (Phase 1 and Phase 2), and
guaranteed to be in the clear (even if subsequent IKE payloads
encrypted). However, it is protected by the Hash payload in
[IKE]. Because of this, an RSIP client and server must agree upon
valid value for the Initiator Cookie
Once X and N arrive at a mutually agreeable value for the
Cookie, X uses it to create an IKE packet and tunnels it the
server N. N decapsulates the IKE packet and sends it on
space B
The minimum tuple negotiated via RSIP, and used for
incoming IKE responses from Y at the RSIP server N, is
Montenegro & Borella Experimental [Page 4]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
- IKE destination port
- Initiator
- Destination IP
One problem still remains: how does Y know that it is supposed
send packets to X via Nb? Y is not RSIP-aware, but it is
IKE-aware. Y sees IKE packets coming from address Nb. To prevent
from mistakenly deriving the identity of its IKE peer based on
source address of the packets (Nb), X MUST exchange
identifiers with Y
- IDii, IDir if in Phase 1,
- IDci, IDcr if in Phase 2.
The proper use of identifiers allows the clear separation
those identities and the source IP address of the packets
5. IPsec Handling and
The RSIP client X and server N must arrive at an SPI value to
the incoming IPsec security association from Y to X. Once N and
make sure that the SPI is unique within both of their SPI spaces,
communicates its value to Y as part of the IPsec security
establishment process, namely, Quick Mode in IKE [IKE] or
assignment
This ensures that Y sends IPsec packets (protocols 51 and 50 for
and ESP, respectively) [Kent98a,Kent98b] to X via address Nb
the negotiated SPI
IPsec packets from Y destined for X arrive at RSIP server N.
are demultiplexed based on the following minimum tuple
demultiplexing fields
- protocol (50 or 51)
-
- destination IP
If N is able to find a matching mapping, it tunnels the packet to
according to the tunneling mode in effect. If N cannot find
appropriate mapping, it MUST discard the packet
Montenegro & Borella Experimental [Page 5]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
6. RSIP Protocol
The next two sections specify how the RSIP protocol [RSIP-P]
extended to support both IKE (a UDP application) and the IPsec
defined AH and ESP headers (layered directly over IP with their
protocol numbers).
If a server implements RSIP support for IKE and IPsec as defined
this document, it MAY include the RSIP Method parameter for RSIP
IPsec in the REGISTER_RESPONSE method sent to the client.
method is assigned a value of 3:
3 RSIP with IPsec (RSIPSEC
Unless otherwise specified, requirements of micro and macro flow
based policy are handled according to [RSIP-P].
6.1 IKE Support in
As discussed above, if X's IPsec implementation allows use of
ephemeral source port for IKE, then incoming IKE traffic can
demultiplexed by N based on the destination address and port tuple
This is the simplest and most desirable way of supporting IKE,
IPsec implementations that interact with RSIP SHOULD allow it
However, if X must use source port 500 for IKE, there are
techniques with which X and N can arrive at a mutually
Initiator Cookie
- Trial and error
- Negotiation via an extension of the RSIP protocol
The trial and error technique consists of X first obtaining
with which to use IPsec (via ASSIGN_REQUEST_RSIPSEC, defined below),
and then randomly choosing an Initiator Cookie and transmitting
first packet to Y. Upon arrival at N, the RSIP server examines
Initiator Cookie for uniqueness per X's assigned address (Nb).
the cookie is unique, N allows the use of this cookie for this an
subsequent packets between X and Y on this RSIP binding. If
cookie is not unique, N drops the packet
When an IKE packet is determined to be lost, the IKE client
attempt to retransmit at least three times [IKE]. An RSIP-aware
client SHOULD use different Initiator Cookies for each of
retransmissions
Montenegro & Borella Experimental [Page 6]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
The probability of an Initiator Cookie collision at N and
retransmissions by X, is infinitesimal given the 64-bit cookie space
According to the birthday paradox, in a population of 640
RSIP clients going through the same RSIP server, the chances of
first collision is just 1%. Thus, it is desirable to use the
and error method over negotiation, for these reasons
- Simpler implementation
- It is highly unlikely that more than one round trip between
and N will be necessary
6.2 IPsec Support in
This section defines the protocol extensions required for RSIP
support AH and ESP. The required message types
ASSIGN_REQUEST_RSIPSEC and ASSIGN_RESPONSE_RSIPSEC
ASSIGN_REQUEST_
The ASSIGN_REQUEST_RSIPSEC message is used by an RSIP client
request IPsec parameter assignments. An RSIP client MUST
an IP address and SPIs in one message
If the RSIP client wishes to use IPsec to protect a TCP or
application, it MUST use the port range parameter (see
A). Otherwise, it MUST set the port parameters to the "don'
need" value. This is accomplished by setting the length field
0, and by omitting both the number field and the port field.
informs the server that the client does not actually need any
assignments
The client may initialize the SPI parameter to the "don't care
value (see below). In this case, it is requesting the server
assign it a valid SPI value to use
Alternatively, the client may initialize the SPI parameter to
value it considers valid. In this case, it is suggesting
value to the server. Of course, the server may choose to
that suggestion and return an appropriate error message
Montenegro & Borella Experimental [Page 7]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
The format of this message is
::=
[Message Counter
[Lease Time
[Tunnel Type
The following message-specific error conditions exist. The
behavior of ASSIGN_REQUEST_RSIP_IPSEC follows that
ASSIGN_REQUEST_RSAP-IP for all non-IPsec errors
- If the client is not allowed to use IPsec through the server
the server MUST respond with an ERROR_RESPONSE containing
IPSEC_UNALLOWED parameter
- If the SPI parameter is a "don't care" value and the
server cannot allocate ANY SPIs, the RSIP server MUST
with an ERROR_RESPONSE containing the IPSEC_SPI_
error
- If an SPI parameter is not a "don't care" value and the
server cannot allocate it because the requested address and
tuple is in use, the RSIP server MUST respond with
ERROR_RESPONSE containing the IPSEC_SPI_INUSE error
ASSIGN_RESPONSE_
The ASSIGN_RESPONSE_RSIPSEC message is used by an RSIP server
assign parameters to an IPsec-enabled RSIP client
Montenegro & Borella Experimental [Page 8]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
The format of this message is
RESPONSE_RSIPSEC> ::=
[Address (tunnel endpoint)]
[Message Counter
If the port parameters were set to the "don't need" value in
request (see above), the RSIP server must do the same in
response
Additionally, RSIP support for IPsec requires the following
parameter
Code Length Number SPI
+------+--------+---------+---------+ +---------+
| 22 | 2 | 2 bytes | 4 bytes | ... | 4 bytes |
+------+--------+---------+---------+ +---------+
Sent by the RSIP client in ASSIGN_REQUEST_RSIPSEC messages to ask
a particular number of SPIs to be assigned. Also sent by the
server to the client in ASSIGN_RESPONSE_RSIPSEC messages
The "SPI" fields encode one or more SPIs. When a single SPI
specified, the value of the number field is 1 and there is one
field following the number field. When more than one SPI
specified, the value of the number field will indicate the
number of SPIs contained, and the parameter may take one of
forms. If there is one SPI field, the SPIs specified are
to be contiguous starting at the SPI number specified in the
field. Alternatively, there may be a number of SPI fields equal
the value of the number field. The number of SPI fields can
extrapolated from the value of the length field
Montenegro & Borella Experimental [Page 9]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
In some cases, it is necessary to specify a "don't care" value
one or more SPIs. This is accomplished by setting the length
to 2 (to account for the 2 bytes in the Number field), setting
number field to the number of SPIs necessary, and omitting all
fields. The value of the number field MUST be greater than or
to one
7. IANA
All of the designations below are tentative
- RSIP IPsec error codes (see below).
- ASSIGN_REQUEST_RSIP_IPSEC message type code
- SPI parameter code
8. Security
This document does not add any security issues to those already
by NAT, or normal routing operations. Current routing
typically are based on a tuple with only one element: destination
address. This document just adds more elements to the tuple
Furthermore, by allowing an end-to-end mode of operation and
introducing a negotiation phase to address reuse, the
described here are more secure and less arbitrary than NAT
A word of caution is in order: SPI values are meant to be semi
random, and, thus serve also as anti-clogging tokens to reduce off
the-path denial-of-service attacks. However, RSIP support for IPsec
renders SPI's a negotiated item: in addition to being unique
at the receiver X, they must also be unique at the RSIP server, N
Limiting the range of the SPI values available to the RSIP
reduces their entropy slightly
9.
Many thanks to Bernard Aboba, Vipul Gupta, Jeffrey Lo, Dan Nessett
Gary Jaszewski and Prakash Iyer for helpful discussions
Montenegro & Borella Experimental [Page 10]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
[Gupta] Gupta, V., "Secure Remote Access over the Internet
IPSec", Work in Progress
[IKE] Harkins, D. and D. Carrel, "The Internet Key
(IKE)", RFC 2409, November 1998.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M. and J. Turner
"Internet Security Association and Key
Protocol (ISAKMP)", RFC 2408, November 1998.
[IPSEC-MSG] Ted Ts'o, message to the IETF's IPsec mailing list
Message-Id:<199911232216.RAA01932@trampoline.thunk.org>,
November 23, 1999.
[Jenkins] Jenkins, T., "IPsec Rekeying Issues", Work in Progress
[Kent98a] Kent, S. and R. Atkinson, "IP Encapsulating Payload",
2406, November 1998.
[Kent98b] Kent, S. and R. Atkinson, "IP Authentication Header",
2402, November 1998.
[Kent98c] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[Piper98] Piper, D., "The Internet IP Security Domain
Interpretation for ISAKMP", RFC 2407, November 1998.
[NAPT] Srisuresh, P. and K. Egevang, "Traditional IP
Address Translator (Traditional NAT)", RFC 3022,
2001.
[NAT-TERMS] Srisuresh, P. and M. Holdredge, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.
[RSIP-FW] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro
"Realm Specific IP: A Framework", RFC 3102, October 2001.
[RSIP-P] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi
"Realm Specific IP: Protocol Specification", RFC 3103,
October 2001.
Montenegro & Borella Experimental [Page 11]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Authors'
Gabriel E.
Sun
Laboratories,
29, chemin du Vieux
38240
Phone: +33 476 18 80 45
EMail: gab@sun.
Michael
3800 Golf Rd
Rolling Meadows IL 60008
Phone: (847) 262-3083
EMail: mike_borella@commworks.
Montenegro & Borella Experimental [Page 12]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Appendix A: On Optional Port Allocation to RSIP
Despite the fact that SPIs rather than ports are used
demultiplex packets at the RSIP server, the RSIP server
still allocate mutually exclusive port numbers to the
clients. If this does not happen, there is the possibility
two RSIP clients using the same IP address attempt an
session with the same server using the same source
numbers
+-------------+
| RSIP client |
| X1 +--+
| | | +-------------+
+-------------+ | | |
+---------+ RSIP server +----------------
+-------------+ | | N |
| RSIP client | | +-------------+
| X2 +--+ private
| | | network
+-------------+ |
|
|
For example, consider hosts X1 and X2 depicted above. Assume
they both are using public address Nb, and both are contacting
external server Y at port 80. If they are using IPsec but are
allocated mutually exclusive port numbers, they may both choose
same ephemeral port number to use when contacting Y at port 80.
Assume client X1 does so first, and after engaging in an
negotiation begins communicating with the public server using IPsec
When Client X2 starts its IKE session, it sends its identification
the public server. The latter's SPD requires that
identities use different flows (port numbers). Because of this,
IKE negotiation will fail. Client X2 will be forced to try
ephemeral port until it succeeds in obtaining one which is
not in use by any other security association between the
server and any of the RSIP clients in the private network
Each such iteration is costly in terms of round-trip times and
usage. Hence --and as a convenience to its RSIP clients--, an
server may also assign mutually exclusive port numbers to its
RSIP clients
Montenegro & Borella Experimental [Page 13]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Despite proper allocation of port numbers, an RSIP server
prevent their misuse because it cannot examine the port fields
packets that have been encrypted by the RSIP clients. Presumably,
the RSIP clients have gone through the trouble of negotiating
numbers, it is in their best interest to adhere to these assignments
Appendix B: RSIP Error Numbers for IKE and IPsec
This section provides descriptions for the error values in the
error parameter beyond those defined in [RSIP-P].
401: IPSEC_UNALLOWED. The server will not allow the
to use end-to-end IPsec
402: IPSEC_SPI_UNAVAILABLE. The server does not have an
available for client use
403: IPSEC_SPI_INUSE. The client has requested an SPI
another client is currently using
Appendix C: Message Type Values for IPsec
This section defines the values assigned to RSIP message types
those defined in [RSIP-P].
22 ASSIGN_REQUEST_
23 ASSIGN_RESPONSE_
Appendix D: A Note on Flow Policy
An RSIP server may not be able to enforce local or remote micro-
policy when a client uses ESP for end-to-end encryption, since
TCP/UDP port numbers will be encrypted. However, if AH without
is used, micro-flow policy is enforceable. Macro-flow policy
always be enforceable
Appendix E: Remote Host
Occasionally, a remote host with which an RSIP client has
an IPsec security association (SA) will rekey [Jenkins]. SA
is only an issue for RSIP when IKE port 500 is used by the client
the rekey is of ISAKMP phase 1 (the ISAKMP SA). The problem is
the remote host will transmit IKE packets to port 500 with a
initiator cookie. The RSIP server will not have a mapping for
cookie, and SHOULD drop the the packets. This will cause the
Montenegro & Borella Experimental [Page 14]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
SA between the RSIP client and remote host to be deleted, and
lead to undefined behavior given that current implementations
rekeying in a number of different ways
If the RSIP client uses an ephemeral source port, rekeying will
be an issue for RSIP. If this cannot be done, there are a number
RSIP client behaviors that may reduce the number of occurrences
this problem, but are not guaranteed to eliminate it
- The RSIP client's IKE implementation is given a smaller
SA lifetime than is typically implemented. This would
cause the RSIP client to rekey the ISAKMP SA before the
host. Since the RSIP client chooses the Initiator Cookie
there will be no problem routing incoming traffic at the
server
- The RSIP client terminates the ISAKMP SA as soon as the
IPsec SA is established. This may alleviate the situation
some degree if the SA is coarse-grained. On the other hand
this exacerbates the problem if the SA is fine-grained (
that it cannot be reused by other application-
connections), and the remote host needs to initialize
back to the RSIP client
Note that the unreliability of UDP essentially makes the
source approach the only robust solution
Appendix F: Example Application
This section briefly describes some examples of how RSIP may be
to enable applications of IPsec that are otherwise not possible
The SOHO (small office, home office)
---------------------------------------------
+----------+
|RSIP |
|client X1 +--+
| | | +-------------+ +-------+
+----------+ | |NAPT gateway | |public |
+--+ and +--.......---+IPsec |
+----------+ | |RSIP server | |peer Y |
|RSIP | | +-------------+ +-------+
|client X2 +--+ private
| | | "home"
+----------+ |
|
|
Montenegro & Borella Experimental [Page 15]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Suppose the private "home" network is a small installation
somebody's home, and that the RSIP clients X1 and X2 must use
RSIP server N as a gateway to the outside world. N is connected
an ISP and obtains a single address which must be shared by
clients. Because of this, N has NAPT, functionality. Now, X1
to establish an IPsec SA with peer Y. This is possible because N
also an RSIP server augmented with the IPsec support defined in
document. Y is IPsec-capable, but is not RSIP aware. This
perhaps the most typical application scenario
The above is equally applicable in the ROBO (remote office,
office) scenario
The Roadwarrior
------------------------
+---------+ +------------+ +----------+
|RSIP | |Corporate | | IPsec |
|client X +--..........--+Firewall +---+ peer Y |
| | public | and | | (user's |
+---------+ Internet |RSIP server | | desktop) |
| N | | |
+------------+ +----------+
private
In this example, a remote user with a laptop gains access to
Internet, perhaps by using PPP or DHCP. The user wants to access
corporation private network. Using mechanisms not specified in
document, the RSIP client in the laptop engages in an
authentication and authorization phase with the RSIP server at
firewall. After that phase is completed, the IPsec extensions
RSIP defined here are used to establish an IPsec session with a peer
Y, that resides within the corporation's network. Y could be,
example, the remote user's usual desktop when at the office.
corporate firewall complex would use RSIP to selectively enable
traffic between internal and external systems
Note that this scenario could also be reversed in order to allow
internal system (Y) to initiate and establish an IPsec session
an external IPsec peer (X).
Montenegro & Borella Experimental [Page 16]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Appendix G: Thoughts on Supporting Incoming
Incoming IKE connections are much easier to support if the peer Y
initiate IKE exchanges to a port other than 500. In this case,
RSIP client would allocate that port at the RSIP server
ASSIGN_REQUEST_RSAP-IP. Alternatively, if the RSIP client is able
allocate an IP address at the RSIP server via ASSIGN_REQUEST_RSA-IP
Y could simply initiate the IKE exchange to port 500 at that address
If there is only one address Nb that must be shared by the
server and all its clients, and if Y can only send to port 500,
problem is much more difficult. At any given time, the
of address Nb and UDP port 500 may be registered and used by only
RSIP system (including clients and server).
Solving this issue would require demultiplexing the incoming
connection request based on something other than the port and
combination. It may be possible to do so by first registering
identity with a new RSIP command of LISTEN_RSIP_IKE. Note that
identity could not be that of the IKE responder (the RSIP client),
but that of the initiator (Y). The reason is that IKE Phase 1
allows the sender to include its own identity, not that of
intended recipient (both, by the way, are allowed in Phase 2).
Furthermore, the identity must be in the clear in the first
packet for the RSIP server to be able to use it as a demultiplexor
This rules out all variants of Main Mode and Aggressive Mode
Public Key Encryption (and Revised Mode of Public Key Encryption),
since these encrypt the ID payload
The only Phase 1 variants which enable incoming IKE sessions
Aggressive Mode with signatures or with pre-shared keys.
this scheme involves the RSIP server demultiplexing based on
identity of the IKE initiator, it is conceivable that only one
client at a time may register interest in fielding requests from
given peer Y. Furthermore, this precludes more than one RSIP client
s being available to any unspecified peer Y
Once the IKE session is in place, IPsec is set up as discussed
this document, namely, by the RSIP client and the RSIP
agreeing on an incoming SPI value, which is then communicated to
peer Y as part of Quick Mode
The alternate address and port combination must be discovered by
remote peer using methods such as manual configuration, or the use
KX (RFC2230) or SRV (RFC2052) records. It may even be possible
the DNS query to trigger the above mechanisms to prepare for
incoming and impending IKE session initiation. Such a
would allow more than one RSIP client to be available at any
Montenegro & Borella Experimental [Page 17]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
time, and would also enable each of them to respond to
initiations from unspecified peers. Such a DNS query, however,
not guaranteed to occur. For example, the result of the query
be cached and reused after the RSIP server is no longer listening
a given IKE peer's identity
Because of the limitations implied by having to rely on the
of the IKE initiator, the only practical way of supporting
connections is for the peer Y to initiate the IKE session at a
other than 500.
Montenegro & Borella Experimental [Page 18]
RFC 3104 RSIP Support for End-to-end IPsec October 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Montenegro & Borella Experimental [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
