Internet DRAFT - draft-floroiu-dynsa-mip
draft-floroiu-dynsa-mip
INTERNET DRAFT J. Floroiu
Date: 30 November 2001 FhG Fokus
Expires: May 2002
Dynamic Security Associations Setup in Mobile IP
<draft-floroiu-dynsa-mip-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes extensions to the Mobile IPv4 base protocol
[RFC2002] enabling mobile nodes and mobility agents to dynamically
setup security associations. Mobile IP is therefore employed as a
supporting protocol for SA negotiation. The proposed mechanism is
based on RSA cryptography [RSA78], entities acting as key
distribution centers and Diffie-Hellman exchanges [DH76].
1. Terminology
Mobile Node (MN)
Mobile IP mobile node
Home Agent (HA)
Mobile IP home agent
Foreign Agent (FA)
Mobile IP foreign agent
Security Association (SA)
Set of parameters describing a simplex secure "connection"
between two peers
RSA
Rivest, Shamir and Adleman public key algorithm
Floroiu [Page 1]
INTERNET DRAFT 30 November 2001
Diffie-Hellman (DH)
A protocol enabling two nodes to securely derive a shared
secrets without having a pre-existent security relationship
Certificate
A data structure which associates an entity (identified for
instance by its name) with a public key and some other possible
extensions, signed by a trusted third party
Network Access Identifier (NAI)
A character string identifying the mobile nodes and mobility
agents
Internet Key Exchange Protocol (IKE)
A protocol which negotiates and provides authenticated keying
material for security associations in a protected manner
2. Introduction
There are several potential methodologies of authenticating Mobile
IP control messages, such as manually distributed shared secrets,
IKE negotiated SAs, AAA key distribution, CA signed certificates
[Jacobs01].
Manually distributed shared secrets have two main disadvantages.
First, it does not scale well as the number of shared secrets
experience a quadratic grow. Secondly, keys need to be
pre-configured on all involved entities as there is also no support
for dynamic keys configuration.
AAA key distribution is based on the idea of having pre-distributed
shared secrets between the interacting entities. This approach
actually shifts the problem rather than addressing it.
IKE provides flexibility and a very good level of security. Peers
authenticate each other through shared secrets, public keys or
certificates. In the first phase IKE sets up the ISAKMP SA which is
used to secure the negotiation of further SAs. In aggressive mode
this process requires three trips. The SA negotiation which takes
place during phase two requires three more trips.
A mobile node to negotiate SAs with FA and HA requires therefore
three round trips to FA and three round trips to HA. This extensive
control message exchange however negatively impacts on hand-over
performance.
Besides, a MN visiting a private addressing realm will not be able
to communicate at the IP level with the HA unless a Mobile IP tunnel
is created, which cannot be done prior to MN authentication.
The proposed protocol does not seek to achieve a level of
flexibility comparable to IKE, but to use Mobile IP as a SA
negotiation supporting protocol which would satisfy the security
needs of a mobile node.
Floroiu [Page 2]
INTERNET DRAFT 30 November 2001
The proposed solution is based on the use of RSA cryptography for
initial authentication of peers and as a mean to secure further SA
negotiation. The advantage of such an approach is that no additional
control message exchange is necessary in order to set up a "main SA"
to protect further exchanges, as IKE does (ISAKMP SA).
3. Assumptions and requirements
In principle the design is based on the idea of using reverse
tunneling [RFC2344], with the tunnel being segmented at the FA level.
Also colocated care-of addresses are envisioned to be used. Such an
architecture supports bridging private IP addressing realms (a
situation which occurs when both home and foreign domain employ
private addressing schemes).
The following requirements have been considered as having particular
importance for the design:
1) The SA setup must be accomplished in one round trip so that the
hand-over performances wouldn't be affected too much (higher delays
are however expected due to the cryptographic operations involved).
2) In real world environments, besides authenticating the Mobile IP
control messages, a MN typically needs to set up an AH tunnel with
the FA (or another administrative entity in the visited domain) and
a MN an ESP encrypted tunnel with the HA. This would protect MN in
visited domains against attacks based on IP and MAC address
spoofing and the MN inter-domain traffic against passive
eavesdropping. Therefore, the SAs set up between the mobility
entities should address these needs as well.
3) MN and FA must not be forced or assumed to have any previous
knowledge of each other. MN and FA should therefore rely on HA for
the initial MN-FA SA setup.
4) The solution should be extensible to hierarchical Mobile IP
architectures. Although the document do not explicitly deal with
hierarchical architectures, support is provided for enabling MN to
perform "local" SA setup with the FA. In an hierarchical
architecture the HA and FA referred throughout the document would be
the gateway FA and the gateway HA. The SA setup schemes within a
hierarchy of FAs or HAs is beyond the scope of the current version
of this document.
4. Key Distribution and Security Associations Setup
For the authentication SAs MN negotiates all parameters except for
the keys, which are provided (initially) by HA and (later on also)
by FA. For the encryption SAs the keys are typically 3DES keys
derived from the shared secrets obtained as result of DH exchanges.
MN and FA need to set up an encryption SA in order to ensure security
of further "local" MN-FA authentication SA negotiations which would
take place without the assistance of HA. As soon as the MN-FA
encryption SA expires, MN should register again via the HA.
Floroiu [Page 3]
INTERNET DRAFT 30 November 2001
HA and FA act as Key Distribution Centers for the authentication SAs.
Only the MN-HA and MN-FA encryption SAs keys are adopted as result to
DH key exchange. This breaks the symmetry of the MN-HA, FA-HA and
MN-HA security relationships in the sense that MN and FA have to
trust the HA and MN has to trust FA as soon as HA has authenticated
the FA.
This is assumed however to be acceptable since:
1) MN is part of the same administrative domain as the HA, with the
HA being the entity which authenticates the MNs, therefore having
some kind of authority over the MN;
2) MN is visiting a foreign domain to which it should present its
credentials, with FA "representing" the local authority;
3) FA must rely on HA for authenticating the MN.
Besides, the control message exchange gets dramatically lower.
4.1. Security associations
The following security associations will be negotiated by the
protocol. Different authentication SAs have been defined for Mobile
IP and AH authentication.
A MN-FA encryption SA was also defined. It aims at protecting the
negotiation of the MN-FA AH SAs without assistance of HA.
+-------------+--------------------+-------------------------+
| Name | Description | How is the key obtained |
+-------------+--------------------+-------------------------+
| MH_MIP_AUTH | MN-HA MIP auth. SA | Key generated by HA |
| MF_MIP_AUTH | MF-HA MIP auth. SA | Key generated by HA |
| HF_MIP_AUTH | HF-HA MIP auth. SA | Key generated by HA |
| | | |
| MH_ESP_ENCR | MN-HA ESP encr. SA | DH Key exchange |
| MH_AH_AUTH | MN-HA AH auth. SA | Key generated by HA |
| | | |
| MF_AH_AUTH | MN-FA AH auth. SA | Key generated by HA, FA |
| MF_MIP_ENCR | MN-FA MIP encr. SA | DH Key exchange |
+-------------+--------------------+-------------------------+
5. Other considerations
Each time a RSA extension is present, a NAI identifying the sender
must also be present. NAI is used to retrieve the corresponding
certificate.
Floroiu [Page 4]
INTERNET DRAFT 30 November 2001
RSA cryptographic operations should be used only if no SA matching
the intended operation is present. There are several reasons for
that:
1) to preserve the entropy of the RSA keys;
2) to save some time by performing shared secret based operations
rather than RSA operations;
3) to save some space since the RSA cipher comes in chunks as large
as the RSA key length.
6. Formats of the extensions
All message extensions are in the form of vendor extensions
[RFC3115]. Every extension has at most one variable long field so
that the length of such a field can be easily deduced from the vendor
extension length field.
6.1. SA Proposal Extension
This extension carries a SA proposal containing the parameters to be
negotiated between the peers. More proposals can be included by the
initiator (MN). Currently SPI, the SA lifetime and the protocol are
defined.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA lifetime | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the Key Extension is TBD.
The Vendor-CVSE-Types (subtypes) are as follows:
3010 MH_MIP_AUTH proposal (PR_MH_MIP_AUTH/PR_HM_MIP_AUTH)
3011 MF_MIP_AUTH proposal (PR_MF_MIP_AUTH/PR_FM_MIP_AUTH)
3012 HF_MIP_AUTH proposal (PR_HF_MIP_AUTH/PR_FH_MIP_AUTH)
3020 MH_AH_AUTH proposal (PR_MH_AH_AUTH/PR_HM_AH_AUTH)
3021 MF_AH_AUTH proposal (PR_MF_AH_AUTH/PR_FM_AH_AUTH)
3030 MH_ESP_ENCR proposal (PR_MH_ESP_ENCR/PR_HM_ESP_ENCR)
3031 MF_MIP_ENCR proposal (PR_MF_MIP_ENCR/PR_FM_MIP_ENCR)
The same CVSE code is used in both directions of the SA negotiation
between two given entities. The content however reflect the proposal
of the sending peer. In the PR_MH_MIP_AUTH in the request for
instance MN proposes the SPI to be used by HA when authenticating
Mobile IP registration reply messages along with the SA lifetime and
protocol to be used. In the PR_HM_MIP_AUTH in the reply on the other
hand HA proposes the SPI to be used by MN when authenticating Mobile
IP registration requests along with the granted SA lifetime and
protocol to be used.
Floroiu [Page 5]
INTERNET DRAFT 30 November 2001
Protocol is one of the following:
1 MD5/prefix+suffix authentication
2 HMAC MD5 authentication
3 HMAC SHA-1 authentication
65 3DES encryption
129 Diffie-Hellman key exchange
6.2. Key Extension
The Key Extension contains the key associated with a certain SA.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key type | Key ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type of the Key Extension is TBD.
The Vendor-CVSE-Types (subtypes) identify the particular SA type this
key is related to. The following types have been defined:
3110 Shared secret for MH_MIP_AUTH (SS_MH_MIP_AUTH)
3111 Shared secret for MF_MIP_AUTH (SS_MF_MIP_AUTH)
3112 Shared secret for HF_MIP_AUTH (SS_HF_MIP_AUTH)
3120 Shared secret for MH_AH_AUTH (SS_MH_IPS_AUTH)
3121 Shared secret for MF_AH_AUTH (SS_MF_IPS_AUTH)
3130 DH public info. for MH_ESP_ENCR (DH_MH_ENCR_pub)
3131 DH public info. for MF_MIP_ENCR (DH_MF_ENCR_pub)
SS_MH_ESP_ENCR is derived by combining DH_MH_ENCR_pub,
DH_MH_ENCR_priv (produced by MN) and DH_HM_ENCR_pub, DH_HM_ENCR_priv
(produced by HA).
SS_MF_MIP_ENCR is derived by combining DH_MF_ENCR_pub,
DH_MF_ENCR_priv (produced by MN) and DH_FM_ENCR_pub, DH_FM_ENCR_priv
(produced by FA).
Note that for DH keys DH_AB_XXX and DH_BA_XXX are different from each
other, while for shared secrets SS_AB_XXX is the same as SS_BA_XXX.
Key Type is one of the following:
Authentication keys (for the MIP and AH authentication SAs):
1 MD5/prefix+suffix authentication (typical length 16 bytes)
2 HMAC MD5 (typical length 16 bytes)
3 HMAC SHA-1 (typical length 20 bytes)
Diffie-Hellman public key (for constructing the shared keys to be
used by MIP and ESP encryption SAs)
129 Diffie-Hellman
Floroiu [Page 6]
INTERNET DRAFT 30 November 2001
Key field is a variable length field specifying the key. The length
of this filed is deduced from the total length of the extension
contained in the Vendor Extension header.
6.3. Authentication Extension
This extension carries an RSA authenticator.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authenticator field is a variable length field containing an
encrypted digest computed over the payload.
6.4. Encrypted Payload Extension
The Encrypted Payload Extension transports a sequence of SA Proposal
and Key extensions in encrypted form.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Payload ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SPI is used for identifying the appropriate SA.
7. The control message exchange
The following diagram depicts a typical control message exchange. The
MN aims at setting up an AH tunnel to FA and an ESP/AH tunnel to HA.
The following notation have been used in order to indicate
authentication and encryption:
{ Message } RSA_priv_Entity A digest of Message was encrypted with
the RSA private key of the indicated
Entity and appended to Message;
{ Message } SS_XXX When used in conjunction with Mobile
IP registration messages denotes an
Mobile IP prefix-suffix authenticator
which is appended to Message;
< Message > Key Message is encrypted using Key (which
might be a RSA key or a 3DES key) and
transferred as chiper.
Floroiu [Page 7]
INTERNET DRAFT 30 November 2001
M N F A H A
| | |
{ RegReq ----------->
NAI
FA-NAI
PR_MH_ESP_ENCR
PR_MH_AH_AUTH
PR_MH_MIP_AUTH
PR_MF_AH_AUTH
PR_MF_MIP_AUTH
DH_MH_ENCR_pub
} RSA_priv_MN
F A H A
| |
{ { RegReq ----------->
NAI
FA-NAI
PR_MH_ESP_ENCR
PR_MH_AH_AUTH
PR_MH_MIP_AUTH
PR_MF_AH_AUTH [1]
PR_MF_MIP_AUTH [2]
DH_MH_ENCR_pub
} RSA_priv_MN
PR_FH_MIP_AUTH
PR_FM_MIP_AUTH [3]
PR_FM_AH_AUTH [4]
} RSA_priv_FA
F A H A
| |
{ { RegRpl <-----------
NAI
FA-NAI
PR_HM_ESP_ENCR
PR_HM_AH_AUTH
PR_HM_MIP_AUTH
PR_FM_MIP_AUTH [3]
PR_FM_AH_AUTH [4]
< SS_HM_AH_AUTH
SS_HM_MIP_AUTH
SS_MF_MIP_AUTH
SS_MF_AH_AUTH
> RSA_pub_MN
DH_HM_ENCR_pub
} RSA_priv_HA
PR_HF_MIP_AUTH
PR_MF_AH_AUTH [1]
PR_MF_MIP_AUTH [2]
< SS_HF_MIP_AUTH
SS_MF_AH_AUTH
SS_MF_MIP_AUTH
> RSA_pub_FA
} RSA_priv_HA
Floroiu [Page 8]
INTERNET DRAFT 30 November 2001
M N F A
| |
{ RegRpl <-----------
NAI
FA-NAI
PR_HM_ESP_ENCR
PR_HM_AH_AUTH
PR_HM_MIP_AUTH
PR_FM_MIP_AUTH [3]
PR_FM_AH_AUTH [4]
< SS_HM_AH_AUTH
SS_HM_MIP_AUTH
SS_MF_MIP_AUTH
SS_MF_AH_AUTH
> RSA_pub_MN
DH_HM_ENCR_pub
} RSA_priv_HA
A secondary objective would be fitting one control messages into one
datagram, since fragmented control messages may introduce severe
delays if fragments got lost. From the perspective of the message
size, the main issue is related to the RSA plain text and cipher
length: the cipher is as long as the RSA key and can accommodate a
plain text almost as long as the RSA key. Therefore, in order to
optimize the space usage, the plain text and the RSA key must be
nearly the same size. Following this idea, and considering the size
of the extensions transfered during a "normal" exchange, the SA
proposal extensions in the reply messages could be encrypted along
with the keys. It should be noted that even if there are multiple
proposals for a given SA, the reply contains only the accepted
proposal.
If the same is done for the SA proposal extensions in the request
packets, the SPI values won't appear in plaintext in the network
which improves the security of the security material being
negotiated.
The exchange depicted below is based on this idea.
M N F A H A
| | |
{ RegReq ----------->
NAI
FA-NAI
< PR_MH_ESP_ENCR
PR_MH_AH_AUTH
PR_MH_MIP_AUTH
PR_MF_AH_AUTH
PR_MF_MIP_AUTH
> RSA_pub_HA
DH_MH_ENCR_pub
} RSA_priv_MN
Floroiu [Page 9]
INTERNET DRAFT 30 November 2001
F A H A
| |
{ { RegReq ----------->
NAI
FA-NAI
< PR_MH_ESP_ENCR
PR_MH_AH_AUTH
PR_MH_MIP_AUTH
PR_MF_AH_AUTH [1]
PR_MF_MIP_AUTH [2]
> RSA_pub_HA
DH_MH_ENCR_pub
} RSA_priv_MN
< PR_FH_MIP_AUTH
PR_FM_MIP_AUTH [3]
PR_FM_AH_AUTH [4]
> RSA_pub_HA
} RSA_priv_FA
F A H A
| |
{ { RegRpl <-----------
NAI
FA-NAI
< PR_HM_ESP_ENCR
PR_HM_AH_AUTH
PR_HM_MIP_AUTH
PR_FM_MIP_AUTH [3]
PR_FM_AH_AUTH [4]
SS_HM_AH_AUTH
SS_HM_MIP_AUTH
SS_MF_MIP_AUTH
SS_MF_AH_AUTH
> RSA_pub_MN
DH_HM_ENCR_pub
} RSA_priv_HA
< PR_HF_MIP_AUTH
PR_MF_AH_AUTH [1]
PR_MF_MIP_AUTH [2]
SS_HF_MIP_AUTH
SS_MF_AH_AUTH
SS_MF_MIP_AUTH
> RSA_pub_FA
} RSA_priv_HA
Floroiu [Page 10]
INTERNET DRAFT 30 November 2001
M N F A
| |
{ RegRpl <-----------
NAI
FA-NAI
< PR_HM_ESP_ENCR
PR_HM_AH_AUTH
PR_HM_MIP_AUTH
PR_FM_MIP_AUTH [3]
PR_FM_AH_AUTH [4]
SS_HM_AH_AUTH
SS_HM_MIP_AUTH
SS_MF_MIP_AUTH
SS_MF_AH_AUTH
> RSA_pub_MN
DH_HM_ENCR_pub
} RSA_priv_HA
8. Addressing Mobile IP hierarchical architectures
One of the requirements identified at the beginning of the draft
states that support for Mobile IP hierarchical architectures should
be provided. Although the current version of the document is far from
exhausting this topic, the proposed protocol addresses the issue.
Taking benefit from the SS_MF_MIP_AUTH distributed by HA during the
initial (inter-domain) registration to both FA and MN, the latter two
engage in further negotiations. Thus, FA and MN exchange
Diffie-Hellman keys by mean of which the distribution of
SS_FM_MIP_AUTH by FA to MN is secured.
M N F A
| |
{ RegReq ----------->
NAI
FA-NAI
PR_MF_AH_AUTH
PR_MF_MIP_ENCR
DH_MF_ENCR_pub
} SS_MF_MIP_AUTH(old - distributed by HA)
{ RegRpl <-----------
NAI
FA-NAI
PR_FM_AH_AUTH
PR_FM_MIP_AUTH
< SS_FM_AH_AUTH
SS_FM_MIP_AUTH(new - generated by FA)
SS_FM_AH_AUTH(new - generated by FA)
> SS_FM_MIP_ENCR
DH_FM_ENCR_pub
} SS_MF_MIP_AUTH(old - distributed by HA)
Floroiu [Page 11]
INTERNET DRAFT 30 November 2001
MN provides a DH public key (DH_MF_ENCR_pub), so that FA can derive
SS_MF_MIP_ENCR based on this key and DH_FM_ENCR_priv - the private
counterpart of DH_FM_ENCR_pub the FA will send in the reply. FA
generates SS_FM_MIP_AUTH and SS_FM_AH_AUTH and encrypts them with
SS_MF_MIP_ENCR. Upon receipt of the reply message, MN will be able
based on DH_FM_ENCR_pub and DH_MF_ENCR_priv to derive the same
SS_MF_MIP_ENCR which he will use then to retrieve SS_FM_MIP_AUTH and
SS_FM_AH_AUTH.
9. Interaction with other key exchange protocols
A mobile node may set up ESP/AH tunnels with correspondent nodes.
Assuming the mobile node establishes an ESP tunnel back to its home
agent as well, the traffic between the mobile node and such
correspondent nodes needs therefore not be sent through the MN-HA ESP
tunnel, since double encryption requires double processing resources
and double the amount of control information per datagram.
This must and can be adjusted using routing mechanisms such as policy
routing and packet filtering. As soon as the mobile node acquires IP
level connectivity to its home network it can use key exchange
protocols such as IKE to negotiate SAs with correspondent nodes. The
IKE exchange and the locally generated ESP traffic will be sent
through the Mobile IP IPnIP tunnel rather than through MN-HA ESP
tunnel. Without going into implementation details it is worth
mentioning that today operating systems provide the necessary support
to implement such routing schemes - a sample suite is mentiond in
[Impl].
10. Certificates considerations
A PKI local to the home domain may be used in order to distribute
certificates to mobile nodes. HA itself may act as a CA signing these
certificates..
The HA - FA secure communication relies however on certificates
issued by a "global" authority.
A discussion on CRL check is beyond the scope of the current version
of the present draft.
The certificates themselves may be transported along with Mobile IP
registration messages, since they are not vulnerable to
man-in-the-middle attacks. However, in order not to end up by having
fragmented control messages - which are at least that bad as large
number of control messages - piggybacking certificates should be used
only when no timely alternate way to retrieve the peer's certificate
is available.
Floroiu [Page 12]
INTERNET DRAFT 30 November 2001
11. Security Considerations
The protocol does not introduce additional security threats beyond
those known so far for the case of Mobile IP.
The protocol provides support for the MN to negotiate authentication
SA with FA. This breaks attacks based on IP and MAC addresses
spoofing in the visited domains.
The protocol provides support for the MN to negotiate encryption SA
with HA. This enables a MN to encrypt all its data traffic up to the
home domain.
The shared keys used for authentication are distributed in encrypted
form by HA and FA following a clear trust model (see chapter 4).
Moreover the SA proposals themselves may be encrypted as well.
The encryption keys are established following a Diffie-Hellman
exchange. PFS is therefore achieved for the MN-FA SA negotiations and
for the MN-HA data traffic.
12. Conclusion
The draft explores the opportunities of making Mobile IP a supporting
protocol for SA negotiation which would satisfy the security needs of
mobile nodes.
Floroiu [Page 13]
INTERNET DRAFT 30 November 2001
References
[Jacobs01] Jacobs, S., Belgard, S., "Mobile IP Public Key Based
Authentication", draft-jacobs-mobileip-pki-auth-03.txt,
July 2001, work in progress
[RFC2002] Perkins, C., editor, "IP mobility support", October 1996.
[RFC2344] Montenegro, G., editor, "Reverse Tunneling for Mobile IP",
May 1998.
[RFC3115] Dommety, G., Leung, K., "Mobile IP
Vendor/Organization-Specific Extensions", April 2001.
[DH76] Diffie, W., Hellman, M. E., "New directions in
cryptography", IEEE Transactions on Information Theory,
IT-22(6):644-654, November 1976
[RSA78] Rivest, R.L., Shamir, A., Adleman, L., "A method for
obtaining digital signatures and public-key cryptosystems",
Communications of the ACM, 21(2):120-126, February 1978
[Impl] Linux Mobile IP/IPsec/routing suite:
The Netfilter Project - http://netfilter.smaba.org
iproute2 utility - ftp://ftp.inr.ac.ru/ip-routing
FreeS/WAN - an implementation of IPSEC & IKE for Linux -
http://www.freeswan.org
Dynamics - an implementation of Mobile IP for Linux -
http://www.cs.hut.fi/Research/Dynamics
Author's Address
Questions about this memo can also be directed to:
John Floroiu
FhG Fokus
31 Kaiserin-Augusta-Allee
10589 Berlin, Germany
Phone: +49 (0)30 3463 7144
Email: floroiu@fokus.fhg.de
Floroiu [Page 14]
