Internet Draft Gateway traversal for Mobile IP Dec.17 1996
Internet Engineering Task Force Masahiro Ishiyama
INTERNET DRAFT Atsushi Inoue
Atsushi Shimbo
Toshio Okamoto
Toshiba R&D Center
Gateway Traversal for Mobile IP using IPSEC primitives
draft-ishiyama-gateway-traversal-00.txt
Status of this memo
This document is an Internet-Draft. 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".
To learn the current status of any Internet-Draft, please check the
"1id-abstract.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes an approach of security support for Mobile IP
protocol. IPSEC and Mobile IP modules are combined and implemented
on gateways of all networks and mobile nodes. Each component
performs IPSEC packet encryption/authentication, and Mobile IP
processing. Using Next-hop negotiation between security gateways,
the packet from a mobile node in the visiting network can be
delivered to the home network through the security gateways in an
authenticated way. This mechanism allows minimal overhead for
traversing security gateways, and minimal information to be held on
each mobile node.
1. Introduction
This memo describes an approach of security support for Mobile IP
protocol, in which how the packet sent from a mobile node in the
Ishiyama, et al. Expires June 22, 1997 [Page 1]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
visiting network can be delivered to a correspondent host (such as
in the home network) through the security gateways is described.
This mechanism allows minimal overhead for traversing security
gateways, and it allows minimal setup on each mobile node.
IPSEC and Mobile IP modules are combined and implemented on gateways
of all networks and mobile nodes. Each component performs IPSEC
packet encryption/authentication, and Mobile IP processing.
Our model of communication in such a system assumes that:
- Between the stationary security gateways, the necessary
information for constructing security associations to each other
is properly maintained.
- Using those information on each security gateway, Next-hop
negotiation mechanism can be used in order to let the packet go
through the security gateways in an authenticated way.
- For mobile nodes, necessary information for setting up the
communication should be minimized. So, dynamic negotiation
procedure between mobile nodes and security gateways are proposed.
Section 2 of this draft explains the system configuration for
combining IPSEC and Mobile IP protocols. Section 3 describes our
model of packet traversal from mobile nodes through the security
gateways. In section 4, an implementation example is proposed,
including the applicability of IPSEC/Mobile-IP combination depending
on the relative location of the mobile node and the correspondent
host. The packet format between the system components are also
described. In Section 5, the future works for the current
implementation is itemized.
2. System configuration
Figure 1 shows the proposed system configuration. The system
consists of,
- Security Gateways (SGW), which perform IPSEC processing, and
packet filtering from the mobile nodes if necessary.
- Security Mobile Nodes (SMN), which perform IPSEC processing by
themselves. SMNs are mobile nodes of Mobile IP protocol, which
performs the mobile registration of current location.
- Home Agents (HA) defined in Mobile IP [1].
Home Agents are placed on the subnet where SMTs are originally
located. In [8], the IPSEC communication between the mobile node and
the home network is discussed, assuming that the HA in the home
network can handle IPSEC packets by itself. But in this draft, we
don't require such IPSEC handling capability on each Home Agent. So,
Ishiyama, et al. Expires June 22, 1997 [Page 2]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
only decrypted (plain IP) packet is delivered to Home Agents. The
current implementation is Popup mode of mobile IP, so there are no
foreign agents in the proposed system now. Supporting foreign agents
is a future work.
[outside]
SMN CH
[Home Network] | | [Other site 1]
+--------------------+ | | +--------------------+
| +-----------+ | | | | CH +----------+ |
| | | | | | | | CH | |
| | HA CH SGW0 --- SGW1-------(Internet)--------SGW2---SGW3 | |
| | | | | | | SMN | |
| +-----------+ CH | | | SMN +----------+ |
+--------------------+ | +--------------------+
+---------SGW4---------+
| CH | SMN |
| | |
| +-------SGW5-------+ |
| | | |
| | CH SMN | |
| +------------------+ |
+----------------------+
[Other site 2]
Figure 1 System Configuration
2.1 Operation of each system component
An SGW is placed on the exit of some network. SGWs can be
nested-placed at the exit of inside network, like SGW0, SGW3, and
SGW5 in Figure 1. When it receives the IP packet from the host
inside the network, it performs IPSEC encryption and authentication
on the packet and forward it to the outside. When it receives the
IPSEC packet destined to the SGW, it performs IPSEC decryption and
authentication on the received packet and forward it to the host or
another SGW inside the network.
An SMN can perform IPSEC processing by itself. It
encrypts/decrypts/authenticates the packet at the endpoint of IPSEC
tunnel (VPN). We assume that the SGW/SMN at the endpoint of VPN
guarantee the security by IPSEC AH/ESP mechanism. An SMN also acts
as a mobile node on Mobile IP protocol. It sends the registration
message to the Home Agent in its home network.
An HA works as defined in Mobile IP protocol[1]. It captures the
packet destined to SMN's home address, performs IP-in-IP
Ishiyama, et al. Expires June 22, 1997 [Page 3]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
encapsulation on the packet, then forward it to SMN's current
Care-of address. As described above, in this draft, the IPSEC
processing capability is not required to HA. Therefore, it receives
packet decrypted at the SGW of home network (home-SGW, SGW0 in
Figure 1), and the mobile IP encapsulated packet will be encrypted
again at the home-SGW and forwarded to the outside.
In Figure 1, We call SMN's Home-domain network as "home network". We
may call [Other site 1] and [Other site 2] as "visitor network".
Also, we call SMN staying inside visitor network as "visiting SMN".
"SGW-protected" means that a host is the network at which an SGW is
placed, that is, in either "home network" or "visitor network" in
Figure 1.
2.2 Addressing rules
We assume the following addressing rules for the proposed system in
Figure 1.
- All SGW-protected networks are private networks. They are managed
with their own addressing rules.
- No address collision occurs between multiple SGW-protected
networks. That is, if an address is given, the position of the
host (which SGW is protecting the host) is uniquely determined.
- Hosts outside the organization is addresses by global addresses.
For the SGWs placed at the boundary to the Internet (SGW1, SGW2,
and SGW4 in Figure 1), global addresses are also assigned.
2.3 Assumption for certificate management
As for the certificates (encryption/authentication keys) for IPSEC,
we assume that each gateway and mobile node can acquire the
necessary certificates in some methods. The detailed configuration
of Certificate Authority and/or the way of delivering certificates
are not discussed in this draft.
Once the necessary certificates are acquired, SGW/SMN should keep
certificate of frequently communicating hosts in its certificate
cache, independently with mobile nodes' mobility registrations.
2.4 Assumption for Position information
When an SMN moves out of private network, It have to know necessary
information for constructing a VPN path toward at least one
Border-SGW in the system. Here Border-SGW is the SGW which is placed
at the border between private network and the Internet. In Figure 1,
SGW1, SGW2, and SGW4 are the Border-SGWs in the system.
Ishiyama, et al. Expires June 22, 1997 [Page 4]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
Also each SGW and SMN have to know all the networks in the system,
which is exchanging security information to each other and VPN can
be constructed among them. For example, Assume that [Home Network],
[Other site 1] and [Other site 2] in Figure 1 are exchanging
security information to each other and the VPNs can be constructed
among these networks. These networks are defined to be VPN-routable.
SGWs/SMNs can distinguish whether a given address belongs to such
VPN-routable network or not. The case when some of the networks are
not VPN-routable is discussed in 3.4.
When an SMN moves around IP network and communicate with IPSEC and
mobile IP autonomously , (1) at least one Border-SGW information,
and (2) VPN-routable network information have to be registered to
that SMN before it moves out.
This VPN-routable network information is implemented, for example,
by maintaining data which express the association between SGW and
its protecting address set. As described in 2.2, all SGW-protected
networks are uniquely addressed. So, if an address is given, we can
uniquely determine one SGW which protects that address. This SGW
look up is also used for determining current location of SMN and CH
(Section 4).
3. Issues for Secure Mobile IP communication
3.1 Communication model
In our communication model, a VPN path is configured from a SMN to
its correspondent host (CH), along which multiple SGWs is placed
(Figure 2).
Each SGW is properly maintained by the system administrator of each
network, and the security policy for the SGW is subject to the
policy of the network. So, packet filtering rule for an SGW might be
determined by the site system administrator regarding the site's
policy. Each SGW knows other SGWs and its protecting hosts. Also
each SGW may know the mobile nodes.
The only assumption about SGW's filtering rule is that even though
once an SGW rejects a packet, if the SGW negotiates with the sender
of that packet and the packet with negotiation information is
delivered to that SGW again, it will let the packet go through.
Therefore, if the SMN goes into a visitor network and tries to
communicate with a host outside the visitor network, it have to
negotiate with the SGW at the exit of the network in order to let
the packet go through the SGW.
Ishiyama, et al. Expires June 22, 1997 [Page 5]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
+---+ +----+ +----+ +----+ +------+ +----+
|SMN+---->+SGW1+-->+SGW2+-->+SGW3+-- ....... --->+SGW(N)+---->+ CH |
+---+ +----+ +----+ +----+ +------+ +----+
Figure 2 The VPN path with SGW/SMN
In [9], a method for authenticated firewall traversal is
introduced. In the method, when a packet sent from mobile node
reaches a firewall, the firewall returns ICMP administration message
to the mobile node. Then the negotiation between the mobile node and
the firewall which rejects the packet, such as cookie exchange, is
performed. After that, the packet from the mobile node can pass the
firewall with authentication information attached on the packet.
If we use this method on our model, the returning of ICMP message and
the negotiation for SGW will be repeated N times in order to arrive
at CH. Even though the negotiation with the SGWs along the path is
successfully completed, N independent negotiated information
(Authentication header/AH, for example) have to be appended to the
packet like,
+-----+-----+-... +-------+-----+-----+---------------+
|AH(1)|AH(2)| |AH(N-1)|AH(N)| ESP | Inner IP data |
+-----+-----+-...-+-------+-----+-----+---------------+
Here, AH(i) means authentication header for negotiating between SMN
and SGW(i). This huge authentication headers attached to the packet
might degrade the total system performance.
In general, a packet need to be checked on each stage of SGW for
security concern. However, if we can assume that all SGWs are
stationary hosts, and are properly maintained by the system
administrators of the networks, that is, the security information
for setting up VPN between each other is registered in advance, an
SGW can perform negotiation using the shared information with the
previous/next stage of SGW. This negotiation method can control the
packet traversal of SGWs. If the packet is allowed to go through the
previous stage of SGW and the negotiation between the previous stage
of SGW and this SGW is valid, the packet is allowed to go through
this SGW also. This negotiation method between two SGW along the VPN
path is called "Next-hop negotiation".
In order to perform Next-hop negotiation efficiently, SGWs can
maintain routing information for other components in the system. If
the destination address of a packet is given, we can easily look up
the Next-hop SGW with the registered routing information.
Ishiyama, et al. Expires June 22, 1997 [Page 6]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
In Figure 2, we assume that SGW1, SGW2, ...., SGW(N) are stationary
nodes, and all the necessary information for VPN routing and
necessary certificates are correctly maintained by the system
administrators. Therefore, when each SGW receives a packet, it can
distinguish the Next-hop SGW from the destination address in the
packet. Here we assume that authentication with AH between two nodes
are used for Next-hop negotiation.
When the packet from a mobile node reaches SGW1, the Next-hop AH
(AH12) with the Next-hop SGW2 is appended to the packet and
forwarded to SGW2. Next at SGW2, the MAC value for AH12 is checked.
If it is valid, then the Next-hop AH is replaced by AH23 (for SGW2
and SGW3) and forwarded to SGW3. On each SGW along the VPN path, the
Next-hop AH will be replaced and finally, the packet will reach
SGW(N).
As long as the packet goes through stationary SGWs which is
correctly setup by the administrators, and if the Next-hop AH is
correctly appended to the packet, failure message (such as ICMP
administration message in [9]) from SGWs will not be returned to the
mobile node. Also, the packet format is always,
+-------+------+-----+---------------+
|next-AH|end-AH| ESP | Inner IP data |
+-------+------+-----+---------------+
and never becomes larger.
3.2 Handling Packets from the Mobile Nodes
As a mobile node (SMN) moves around on the IP network dynamically,
we cannot expect the SMN's location and setup the necessary
information in advance. Rather it might be better to limit the
registered information on the SMN before moving as minimal as
possible.
And in general, just after an SMN is reconnected to IP network on
the visitor site, the SMN cannot understand the environment around
it. Therefore, when an SMN moved into a visitor network and start
the communication, it have to follow an procedure, by which it can
capture necessary information in order to construct communication
path to the outside the visitor network (especially to the SMN's
home network).
In the model on Figure 2, consider the case the mobile node (SMN)
connected at the visitor network tries to communicate with CH in the
home network through multiple SGWs.
Ishiyama, et al. Expires June 22, 1997 [Page 7]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
When an SMN is reconnected, it does not even know that there are
SGWs (SGW1, ..., SGW(N)) along the path toward CH. So, the only thing
SMN can do first is to send a ordinary IP packet to the CH, and see
what happens at the SGWs. In our model of packet traversal from SMN
to home network, we assume the following:
- When the packet from SMN reaches the first SGW without
Next-hop negotiation between SMN and the SGW, failure message
(such as ICMP Security Failures Message[7]) is returned to the SMN
- On the endpoint of VPN, if the home SGW detect that the packet is
from the SMN but End-End negotiation is done by another SGW, then
it distinguish that packet as invalid and returns failure message.
Here we assume that authentication (AH) between two nodes are used
for Next-hop/End-End negotiation. When the IP packet reaches the
first SGW (SGW1), it detects that the packet is from visiting SMN
and illegal (by checking the source address), and returns failure
message to the SMN. With this failure reply, the SMN negotiates the
key for Next-hop AH, computes/attaches Next-hop AH, and resends the
packet to SGW1. Here the packet is authenticated but not encrypted
yet.
When SGW1 receives this packet, it tries to construct VPN with
SGW(N) at the home network of SMN. That means, SGW1 becomes the end
of VPN, so the End-End AH is computed between SGW1 and SGW(N), and
the packet is encrypted. Then, SGW1 relays the packet with Next-hop
AH for Next-stage SGW (SGW2) attached to the packet.
Finally the packet reaches SGW(N). Then Next-hop AH with previous
stage SGW(N-1) is checked and IPSEC processing is done. Here SGW(N)
detects,
- The contents of IPSEC is from the SMN which was originally in its
network.
- But the End-End AH is negotiated with another SGW (SGW1).
and this conflicts with the policy and SGW(N) returns failure message
to the SMN.
When SMN receives this failure message, then it performs IPSEC
processing by itself. It processes End-End AH with SGW(N) by itself.
And using the Next-hop AH key for SGW1 (previously acquired). SMN
puts Next-hop AH and sends to SGW1 again. In this case, SGW1 works
just the same as other SGWs along the VPN, that is, checks/replaces
the Next-hop AH and forward the packet to SGW2. This packet will
successfully traverse the SGWs and reach SGW(N) at the VPN endpoint.
These step is depicted as follows. The notation is the same as that
of Section 4.
Ishiyama, et al. Expires June 22, 1997 [Page 8]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
Step1: Failed at SGW1 because of lack of Next-hop AH
[IP]
SMN SGW1 SGW(N) CH
--------------->X
<---------------
[Failure]
Step2: Failed at SGW(N) because of inconsistency between packet contents
and End-End AH
[IP+NextAH] [IP+endAH]
SMN SGW1 SGW(N) CH
-NNNNNNNNNNNNNNN-EEEEEEEEEEEEEEEEEEEEEEEEE->X <NG>
<----------------EEEEEEEEEEEEEEEEEEEEEEEEE---
[Failure]
Step3: Succeed in constructing VPN through SGW(N)
[IP+AH] [IP+AH] [IP]
SMN SGW1 SGW(N) CH
-NNNNNNNNNNNNNNN NNNNNN NNNNNN NNNNNNNN
-EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE--------->
<End-End AH between SMN/SGW(N)>
3.3 Handling packets from SMNs outside the organization
The scheme in the previous section describes the cases when SMN
moves into SGW-protected networks (organizations), and communicate
with other networks (such as home network) through the SGW placed on
the exit of that network.
As SMNs can perform IPSEC and Mobile IP processings by itself, it
can also move to the IP connection point on the Internet outside the
specific organization (where not protected by SGWs). In such a case,
the necessary information for constructing a VPN path toward at lease
one SGW placed on the boundary of VPN reachable organization
(Border-SGW) have to be installed on the SMN before it moves
outside. This is because we assume that once the packet reaches an
SGW on the VPN-routable network, the SGW knows all the VPN routing
information to deliver the packet toward the CH in the SGW-protected
network. So, when the Border-SGW receives the IPSEC packet from
outside SMN, it decrypts the packet and checks the destination CH
address. And the Border-SGW reencrypts the packet with the
correspondent-SGW (which protects CH). The packet is then delivered
Ishiyama, et al. Expires June 22, 1997 [Page 9]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
through new VPN from Border-SGW to correspondent-SGW.
In some cases, there will be redundant IPSEC route from SMN to CH
via the Border-SGW, but it can be optimized with the negotiation
with SMN, Border-SGW and correspondent-SGW.
For example, in Figure 3, the SMN is outside of the organization,
and assume that CH is in Site-1. Both Site-1 and Site-2 are
SGW-protected network and VPN-routable. And assume that SMN only
knows the Border-SGW2. In such a case, if SMN want to communicate
with CH, SMN have to construct VPN2 toward SGW2 first. Once the VPN2
is established, SGW2 can route the packet toward SGW1-protected CH with
IPSEC between SGW2 and SGW1. If outside SMN knows the Border-SGW of
CH's network (SGW1), or route optimization is done to eliminate the
redundant routing via SGW2, SMN can communicate directly with CH
through SGW1 as [optimized] in Figure 3. In section 4.5.7, the
protocol example of such a case is explained.
<VPN2> [optimized]
++<========SMN.......
[Site-2] // <1> : [Site-1]
+----------------+ // : +----------------+
| |// :..> | |
| SGW2====>====>====>====>====>SGW1 CH |
| | <2> | |
+----------------+ +----------------+
Figure 3 SMN outside the organization
3.4 SMN talking from a network lacking Next-hop information
The discussion in the previous sections assume that all
SGW-protected networks are VPN-routable, that is, any pair of SGWs
are exchanging information for constructing VPN. But in some case,
SMN might move to the network, where VPN is not constructed to other
network because of its site policy. This situation occurs when an
SMN moves into a network, which is not familiar with the SMN's home
network.
Figure 4 shows such an example. Here the policy of Site-1 is that
SGW1 does not exchange security information for constructing VPN
with other SGWs. When SMN moves into Site-1, it can understand
that it is not in the VPN-routable network using the its position
information described in 2.4.
Ishiyama, et al. Expires June 22, 1997 [Page 10]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
[Site-1] [VPN Network]
+-------------+ +------------------------+
| | | +-----------+ |
| | | | | |
| SMN---->SGW1------->(Internet)-------->SGW2--->SGW1--->CH | |
| | | | | |
| | | +-----------+ |
+-------------+ +------------------------+
Figure 4 SMN in VPN unreachable network
SMN in Site-1 first tries to construct VPN to its Border-SGW (SGW2
in Figure 4). This is just the same as discussed in 3.3. When the
IPSEC packet (toward SGW2) reaches SGW1, the failure message is
returned and the negotiation between SMN and SGW1 is performed.
Then SMN sends the packet with Next-hop AH again, and the packet
goes through SGW1 and reaches SGW2.
In some cases, after entering to the VPN network protected by SGW2,
the packet will reach SGW3 inside the VPN network and is rejected
there. Then SGW3 returns failure message to SMN. At this time, SMN
recognizes that the VPN endpoint is not SGW2, but SGW3. Then SMN
processes the packet for VPN endpoint SGW3, with Next-hop AH for
SGW2 and SGW1 appended. This packet goes through SGW1 and SGW2, and
reaches SGW3 successfully. The packet format delivered from SMN to
CH is as follows:
Step1: Failed at SGW1 because of lack of Next-hop AH
SMN SGW1 SGW2 SGW1 CH
-EEEEE->X (--EEEEEEEEEEEEEEEEE--->) (End/End for SMN/SGW2)
<--------
[Failure]
Step2: Reached to SGW2, but failed at SGW3
SMN SGW1 SGW2 SGW3 CH
NNNNNNNN
-EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE------------->X
NNNNNNNNNNNNN
<--------EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE-
[Failure]
Ishiyama, et al. Expires June 22, 1997 [Page 11]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
Step3: Succeed in constructing VPN through CH
SMN SGW1 SGW2 SGW3 CH
NNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
-EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE------------->
The sequence above shows that, if SMN moves into VPN-unroutable
network, the step-by-step negotiation like [9] is necessary for
securely delivering the packet from the SMN.
3.5 Communication with CH outside the organization
If the correspondent host (CH) of SMN is not in SGW-protected
network, SMN cannot communicate with IPSEC. Therefore, SMN
communicates with the CH either of the following way, depending on
the CH's attribute.
- If it is guaranteed that CH is reachable from SMN's home network,
SMN can use Mobile IP, but without IPSEC, though this is not
recommended for security reason.
- If the reachability of CH from SMN's home network is not
guaranteed, SMN uses its Care-of address and directly communicate
with CH by usual IP, though this is not recommended for security
reason. If SMN is in the SGW-protected network the Care-of address
is translated to a global address at the SGW of that network.
Or if SMN can use a proxy in the home network, it works as follows.
3.5.1 Communication through the proxy at home network
On many sites, the Internet access is controlled through proxies.
When the SMN communicate through a proxy in the home network, it
constructs VPN tunnel with home-SGW first. Through this tunnel, the
SMN communicate with the proxy securely by IPSEC. Then at the proxy,
the necessary processing (such as address translation) is done, then
the packet goes out through VPN between SGWs.
For the packet on the reverse direction, it is delivered to the
proxy at home network through VPN between SGWs. Then from the proxy
to SMN outside, the packet goes on mobile IP routing, via Home Agent
(Figure 5).
Ishiyama, et al. Expires June 22, 1997 [Page 12]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
[SMN]
(home)| ^^
| (8) || (1)VPN btwn SMN/Proxy
| ++=====++
(7)IP-in-IP | || (3) toward
------> | VV (2) VPN btwn Proxy/SGW1 CH
[HA]<------[SGW1/Proxy]=========================>[SGW2]------->[CH]
(6) Mobile | <========================= <-------
IP | (5) VPN btwn SGW1/Proxy (4) reply
| from CH
Figure 5 Communication through the proxy in the home network
3.6 Implementation issues
Next-hop negotiation is typically implemented by authentication
between two security nodes (Next-hop authentication). The
authentication is done just the same way as usual IPSEC processing.
That is, in order to let the packet pass through the next stage of
SGW, each SGW put Next-hop authentication header for the two SGWs
ahead of the packet. The next stage of SGW checks the Next-hop AH
for authenticating the sending SGW, and if the MAC value is valid,
then it is allowed to go through. As current implementation of
SGW/SMN uses SKIP [5] for key management protocol, typical packet
format with Next-hop AH is as follows:
+-----+-------+----+-----+-------+----+-----+---------------+
| IP1 | SKIP1 | AH | IP2 | SKIP2 | AH | ESP | Inner IP data |
+-----+-------+----+-----+-------+----+-----+---------------+
<----------> <---------------->
Next-hop End-End
authentication authentication/encryption
Here Next-hop AH is used only for negotiated packet traversal on
SGWs. So, the point is two SGWs (or SGW and SMN) share common
information (Next-hop-AH keys) on the authentication processing.
Data integrity checking is not the purpose of Next-hop
authentication. That means, the MAC computation can be omitted, for
example, only partial data, such as IP/SKIP/AH/ESP header portion
can be used for MAC computation in order to reduce the overhead.
This format is one typical example. In some cases, depending on the
security policy of each site, another form of Next-hop negotiation
can be introduced. For example, if the site policy does not allow
encrypted packets which cannot be decrypted on any host in the
network, Next-hop encryption can be used instead of End-End
encryption.
Ishiyama, et al. Expires June 22, 1997 [Page 13]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
4. Implementation Example
In this section, we will summarize the current status of our
implementation, including the packet format for mobile IP
registration and data transmission.
4.1 Abbreviations and Notation of Figures
HA: Home Agent
CH: Correspondent Host
SGW: Security Gateway
SMN: Security Mobile Node
AH: Authentication Header (Defined in [3])
ESP: Encapsulating Security Payload (Defined in [4])
SKIP: Simple Key management for Internet protocol proposed in [5].
Also means SKIP header in the packet format.
NSID: Name Space Identifier (specified in [5])
MKID: Master Key Identifier (specified in [5])
The notation in packet transmission figures means the following:
@: Relaying Mobile IP packets by HA
MMMMMMMM:Tunneling with IP-in-IP [2]
EEEEEEEE:Tunneling with SKIP/AH/ESP (End/End IPSEC)
NNNNNNNN:Tunneling with SKIP/AH (Next-hop IPSEC)
When encapsulation is done, lower protocol is encapsulated by upper
ones, for example,
MN CH
EEEEEEEEEEEEEEEEEEEEEEEEEE
--MMMMMMMMMMMMMMMMMMMMMMMMMM-->
means that IP-datagram from MN to CH is encapsulated with Mobile IP
protocol (IP-in-IP) and then the result datagram is encapsulated by
End/End IPSEC.
4.2 Classifying the Mobile IP operation
First, the operation is classified whether SMN/CH is SGW-protected
or outside. Here CH is a stationary host. Communication mode
between SMN and CH is classified as the table below. The position of
SMN/CH can be determined by watching home agent advertisement
message and looking up host position information described in 2.4.
Ishiyama, et al. Expires June 22, 1997 [Page 14]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
CH position | SGW-protected | outside
SMN position | |
----------------+--------------------+-----------------------------
SGW-protected |<1>VPN through SGW |<3>Usual (mobile) IP
| See 4.5 | See 3.5
----------------+--------------------+-----------------------------
outside |<2>VPN through SMN |<4>Usual (mobile) IP
| See 4.5 | See 3.5
For the case that CH is outside (<3> and <4>), SMN talks with CH as
described in 3.5. That is, if CH's reachability from the SMN's home
network is not guaranteed, SMN have to talk directly with CH using
its Care-of address and usual IP (though it is not recommended). If
CH's reachability from SMN's home network is guaranteed, SMN can use
Mobile IP without IPSEC. For case <3>, if SMN is using private
managed address, it might be translated at the SGW, or if SMN uses
proxy in the home network, SMN first constructs VPN to the home
network, then the proxy delivers the packet to/from CH, as described
in 3.5.1.
[outside]
SMN CH
[Home Network] | | [Other site 1]
+----------------+ | | +----------------+
| | +--------+----+-+ | CH1 |
| SMN CH0 | | | | |
| SGW0----+ Internet +----SGW1 |
| HA | | | | SMN |
| | +---+-----------+ | |
+----------------+ | +----------------+
+-----SGW2-----+
| |
| |
| CH2 SMN |
+--------------+
[Other site 2]
Figure 6 System Configuration for the current implementation
If we assume the system configuration like Figure 6, VPN through
SGW/SMN (case of <1> and <2>) is classified depending on the
relative position of SMN/CH/HA as follows:
Ishiyama, et al. Expires June 22, 1997 [Page 15]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
CH's position| SMN's | other site|
SMN's position | Home | 1 |
-------------------+---------+------------+
Home Network | (1) | (2) |
-------------------+---------+------------+
Other 1(CH's Home) | (3)* | (4)* |
-------------------+ +------------+
Other 2 | | (5)* |
-------------------+---------+------------+
Outside | (6)* | (7)* |
-------------------+---------+------------+
* means SMN's IPSEC module is used for VPN
The protocols for each case will be examined in 4.5.
4.3 SKIP NSID/MKID Consideration
Current implementation uses SKIP as its key management protocol. In
section 4.5, the packet format including SKIP header is described.
For the NSID/MKID for SMNs, NSID value 1 (IPv4 address) is assigned,
and MKID is set as SMN's home address. This NSID/MKID specification
is introduced in [8], and the MKID is used for looking up the SMN's
security association. The SMN's home address is used because even
after SMN has moved, the same entity can be referenced.
4.4 Mobile IP Registration
The registration of the Care-of address for SMN is done as Mobile IP
registration protocol[1]. With the registration, HA can maintain the
mapping table between the SMNs and corresponding care-of addresses.
In accordance with the security policy for the visitor site,
visiting SMN's outbound packet have to be checked by SGW of visitor
site with Next-hop AH.
[Protocol Image]
SMN SGW1 (Network) SGW0 HA
<1> -EEEEEEEEE <NG> - - -> registration request
<2> <--------- Failure message
NNNNNNN NNNNNNNNNNNNNNNNNNN
--EEEEEEEEEEEEEEEEEEEEEEEEEEEE-------> registration request
<3> <4>
NNNNNNNNNNNNNNNNNNN
<-EEEEEEEEEEEEEEEEEEEEEEEEEEEE-------- registration reply
<5>
Ishiyama, et al. Expires June 22, 1997 [Page 16]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
If the registration request from SMN cannot go through SGW1 at the
Visitor network, the SGW traversal described in 2.3 is used. After
SGW1 returns Failure message (such as ICMP Security Failures
Message[7]), SMN resend the registration request with Next-hop AH
for SGW1 ahead of the packet. The packet format is as follows:
[Packet Format]
<1> (The first registration request from SMN)
IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst = NSID(0)
EndAH+ESP
Inner IP Hdr:(Src=SMN c/o addr, Dst = HA addr)
<2> (Failure message from SGW1)
IP Hdr:(Src=SGW1 addr, Dst=SMN c/o addr)
<3> (The second registration request from SMN)
IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
NextAH:(SMN/SGW1)
IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr2:(Src=NSID(1)/MKID(SMN addr), Dst=NSID(0))
EndAH+ESP:(SMN/SGW0)
Inner IP Hdr:(Src=SMN c/o addr, Dst=HA addr)
<4> (Request Packet from SGW1 to SGW0)
IP Hdr1:(Src=SGW1 addr, Dst=SGW0 addr)
SKIP Hdr1:(Src=NSID(0), Dst=NSID(0))
NextAH:(SGW1/SGW0)
IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP(SMN/SGW0)
Inner IP Hdr:(Src=SMN c/o addr, Dst = HA addr)
<5> (Reply Packet from SGW0 to SGW1)
IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(0), Dst = NSID(0))
NextAH(SGW0/SGW1)
IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr2:(Src=NSID(0), Dst = NSID(1)/MKID(SMN home addr))
EndAH+ESP(SGW0/SMT)
Inner IP Hdr:(Src=HA addr, Dst=SMN c/o addr)
4.5 Data communication
Also for data communication, we assume that the Next-hop AH check is
necessary for the outbound packet from visiting SMN.
Ishiyama, et al. Expires June 22, 1997 [Page 17]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
4.5.1 Both SMN/CH are in Home Network
[Protocol image]
SMN CH0
--------> (Usual IP communication)
<--------
4.5.2 SMN is in Home Network, CH is in Other site (Site 1)
[Protocol image]
SMN SGW0 SGW1 CH1
<1> --------EEEEEEEEEEEEEEEEEEEEEEEE-------> (Usual VPN between SGWs)
<2> <-------EEEEEEEEEEEEEEEEEEEEEEEE--------
[Packet Format]
<1> Packet from SGW0 to SGW1
IP Hdr:(Src=SGW0 addr, Dst=SGW1 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP(SGW0/SGW1)
Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr)
<2> Packet from SGW1 to SGW0
IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP(SGW1/SGW0)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
4.5.3 SMN is in Other site (Site 1), CH is in Home Network
[Protocol image]
SMN SGW1 (Network) SGW0 HA CH0
<1> <2>
NNNNNN NNNNNNNNNNNNNNNNNNNNNNN
-EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE------------->
<3>
NNNNNNNNNNNNNNNNNNNNNNN
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
<-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-@-----
[Packet Format]
<1> Packet from SMN to SGW1
IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
NextAH(SMN/SGW1)
IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr),Dst=NSID(0))
EndAH+ESP(SMN/SGW0)
Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr)
Ishiyama, et al. Expires June 22, 1997 [Page 18]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
<2> Packet from SGW1 to SGW0
IP Hdr1:(Src=SGW1 addr, Dst=SGW0 addr)
SKIP Hdr1:(Src=NSID(0), Dst=NSID(0))
NextAH(SGW1/SGW0)
IP Hdr2:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP(SMN/SGW0)
Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr)
<3> Packet from SGW0 to SGW1
IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(0), Dst=NSID(0))
NextAH(SGW0/SGW1)
IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr))
IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr)
Inner IP Hdr:(Src=CH0 addr, Dst=SMN home addr)
4.5.4 Both SMN/CH are in the same Other site (Site 1)
[Protocol image]
SMN CH1 SGW1 (Network) SGW0 HA
-------> <1>
-------EEEEEEEEEEEEEEEEEE------->@
<2> |
NNNNNNNNNNNNNNNNNN |
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V
<-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+
SMN CH1 SGW1 (Network) SGW0 HA
[Packet Format]
<1> Packet from SGW1 to SGW0
IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP:(SGW1/SGW0)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
<2> Packet from SGW0 to SGW1
IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(0), Dst=NSID(0))
NextAH:(SGW0/SGW1)
IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr))
EndAH+ESP:(SGW0/SMN)
IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
Ishiyama, et al. Expires June 22, 1997 [Page 19]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
4.5.5 SMN is in Other site (Site 1), CH is another Other site (Site 2)
[Protocol image]
SMN SGW1 (Network) SGW2 CH2 (Network) SGW0 HA
<1> <2>
NNNNN NNNNNNNNNNNNNNN
-EEEEEEEEEEEEEEEEEEEEEE------>
+<-----
| <3>
+-EEEEEEEEEEEEEEEEEEEEEE------>@
<4> |
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN |
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V
<-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+
SMN SGW1 (Network) SGW2 CH2 (Network) SGW0 HA
[Packet Format]
<1> Packet from SMN to SGW1
IP Hdr1:(Src=SMN c/o addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
NextAH:(SMN/SGW1)
IP Hdr2:(Src=SMN c/o addr, Dst=SGW2 addr)
SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP:(SMN/SGW2)
Inner IP Hdr:(Src=SMN home addr, Dst=CH2 addr)
<2> Packet from SGW1 to SGW2
IP Hdr1:(Src=SGW1 addr, Dst=SGW2 addr)
SKIP Hdr1:(Src=NSID(0), Dst=NSID(0))
NextAH:(SGW1/SGW2)
IP Hdr2:(Src=SMN c/o addr, Dst=SGW2 addr)
SKIP Hdr2:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP:(SMN/SGW2)
Inner IP Hdr:(Src=SMN home addr, Dst=CH2 addr)
<3> Packet from SGW2 to SGW0
IP Hdr:(Src=SGW2 addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP:(SGW2/SGW0)
Inner IP Hdr:(Src=CH2 addr, Dst=SMN home addr)
<4> Packet from SGW0 to SGW1
IP Hdr1:(Src=SGW0 addr, Dst=SGW1 addr)
SKIP Hdr1:(Src=NSID(0), Dst=NSID(0))
NextAH:(SGW0/SGW1)
IP Hdr2:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr2:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr))
EndAH+ESP:(SGW0/SMN)
IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr)
Inner IP Hdr:(Src=CH2 addr, Dst=SMN home addr)
Ishiyama, et al. Expires June 22, 1997 [Page 20]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
4.5.6 SMN is outside, CH is in Home network
[Protocol image]
SMN (Network) SGW0 HA CH0
<1> -EEEEEEEEEEEEEEEEEEEEEEEEEEEEE-------------->
<2> EEEEEEEEEEEEEEEEEEEEEEEEEEEEE
<-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM--@<-----
[Packet Format]
<1> Packet from SMN to SGW0
IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP:(SMN/SGW0)
Inner IP Hdr:(Src=SMN home addr, Dst=CH0 addr)
<2> Packet from SGW0 to SMN
IP Hdr:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr))
EndAH+ESP:(SGW0/SMN)
IP Hdr2 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr)
Inner IP Hdr:(Src=CH0 addr, Dst=SMN home addr)
4.5.7 SMN is outside, CH is in Other site (Site 1)
If outside SMN only knows Border-SGW of its home network (SGW0), the
data transmission is done as follows.
[Protocol image]
SMN (Network) SGW1 CH1 (Network) SGW0 HA
<1>
-EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE-->
<2> |
<-EEEEEEEEEEEEEEEEEEE--+
|
+------->
+<------
| <3>
+-EEEEEEEEEEEEEEEEEEEEEE------->@
<4> |
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V
<-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+
SMN (Network) SGW1 CH1 (Network) SGW0 HA
[Packet Format]
<1> Packet from SMN to SGW0
IP Hdr:(Src=SMN c/o addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP:(SMN/SGW0)
Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr)
Ishiyama, et al. Expires June 22, 1997 [Page 21]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
<2> Packet from SGW0 to SGW1
IP Hdr:(Src=SGW0 addr, Dst=SGW1 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP:(SGW0/SGW1)
Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr)
<3> Packet from SGW1 to SGW0
IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP:(SGW1/SGW0)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
<4> Packet from SGW0 to SMN
IP Hdr1:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr))
EndAH+ESP(SGW0/SMN)
IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
If outside SMN knows the Border-SGW of CH1's network, or route
optimization is done to eliminate the redundant routing via SGW0,
the data transmission is done as follows.
[Protocol image]
SMN (Network) SGW1 CH1 (Network) SGW0 HA
<1>
-EEEEEEEEEEEEEEE------->
+<------ <2>
+-EEEEEEEEEEEEEEEEEEEEEE------->@
<3> |
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE V
<-MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM-+
SMN (Network) SGW1 CH1 (Network) SGW0 HA
[Packet Format]
<1> Packet from SMN to SGW1
IP Hdr:(Src=SMN c/o addr, Dst=SGW1 addr)
SKIP Hdr:(Src=NSID(1)/MKID(SMN home addr), Dst=NSID(0))
EndAH+ESP:(SMN/SGW1)
Inner IP Hdr:(Src=SMN home addr, Dst=CH1 addr)
<2> Packet from SGW1 to SGW0
IP Hdr:(Src=SGW1 addr, Dst=SGW0 addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(0))
EndAH+ESP:(SGW1/SGW0)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
Ishiyama, et al. Expires June 22, 1997 [Page 22]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
<3> Packet from SGW0 to SMN
IP Hdr1:(Src=SGW0 addr, Dst=SMN c/o addr)
SKIP Hdr:(Src=NSID(0), Dst=NSID(1)/MKID(SMN home addr))
EndAH+ESP(SGW0/SMN)
IP Hdr3 (IP-in-IP):(Src=HA addr, Dst=SMN c/o addr)
Inner IP Hdr:(Src=CH1 addr, Dst=SMN home addr)
5. Future works
5.1 Route Optimization consideration
[10] specifies the route optimization for Mobile IP, assuming that
the mobile nodes, correspondent hosts and the mobility agents keeps
the binding caches, and based on the information kept in the binding
caches, the optimized route is determined. However, this method
forces the ordinary corresponding hosts of the special support for
the Mobile IP, we don't use this.
Instead, we are planning the route optimization, in which the
necessary information is held/exchanged only on each SGW and SMN.
The purpose of this route optimization is not only avoiding
redundant routing caused by mobile IP but also avoiding redundant
decryption/encryption on the Border-SGW, described in 3.3.
In the case of 3.3, if SMN accomplishes VPN towards the CH via one
of the Border-SGW. Once it is confirmed that the CH is directly
routable from the SMT, the route can be optimized. With this
optimization, redundant IPSEC processing (decryption/re-encryption)
at the Border-SGW will be skipped and the overhead of data
transmission will be reduced.
The implementation and evaluation of this route optimization is a
future work.
5.2 FA mode consideration
When there are foreign agents in the system, the packet is processed
in the home network, (1) first IP-in-IP encapsulation at HA, (2)
then IPSEC encapsulation at home-SGW. But when the packet is
delivered to the visitor network, the decrypted packet have to be
passed to FA first, and it conflicts the processing order in the
home network. The possible solutions are:
- home SGW remove the outer IP header (destined to SMN's Care-of
address put by HA), process the packet with IPSEC, and put the
removed IP header again outer of IPSEC processed packet.
- home SGW caches mobility information and acts as proxy HA, and it
encapsulates the packet in IPSEC first and Mobile IP next order.
- Of course if HA/FA processes IPSEC by themselves (like proposed in
Ishiyama, et al. Expires June 22, 1997 [Page 23]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
[8]), there are no such issues of processing order.
6. Security Considerations
This entire document addresses security concerns. The security of
the proposal in this draft completely depends upon IPSEC standard.
Also for treating visiting mobile node properly, the security policy
of each organization have to be configured and maintained properly.
When a mobile node goes outside the organization and communicate to
the Internet directly, proper mechanism for protecting the mobile
node itself, such as packet filtering, is of course need to be
supported.
Acknowledgements
Ideas in this document have benefited from discussions with Mark
Lomas, Tom Markson, Rich Skrenta, Vipul Gupta, and Gabriel
Montenegro.
References
[1] C. Perkins. IP Mobility Support. RFC 2002, October 1996.
[2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1996.
[3] R. Atkinson. IP Authentication Header. RFC 1826, August
1995.
[4] R. Atkinson. IP Encapsulating Payload. RFC 1827, August 1995
[5] A. Aziz, T. Markson, H. Prafullchandra. Simple Key-Management
For Internet Protocols (SKIP),
(I-D draft-ietf-ipsec-skip-07.txt), August 14, 1996
[6] A. Aziz, T. Markson, H. Prafullchandra, R. Skrenta, G.
Caronni. Certificate Discovery Protocol,
(I-D draft-ietf-ipsec-cdp-01.txt), June 6, 1996
[7] P. Karn, W.A. Simpson. ICMP Security Failures Messages. (I-D
draft-simpson-icmp-ipsec-fail-02.txt), April 1996
[8] G. Montenegro, V. Gupta. Firewall Support for Mobile IP,
(I-D draft-montenegro-firewall-sup-00.txt), September 13, 1996
[9] M.C. Richardson. Authenticated Firewall Traversal with IPsec,
(I-D draft-richardson-ipsec-aft-00.txt), April 1996
[10] D.B. Johnson, C. Perkins. Route Optimization in Mobile IP,
(I-D draft-ietf-mobileip-optim-04.txt), February 1996
Author's Address
Masahiro Ishiyama
Toshiba Corporation, R&D Center
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
Ishiyama, et al. Expires June 22, 1997 [Page 24]
Internet Draft Gateway traversal for Mobile IP Dec.17 1996
Email : masahiro@isl.rdc.toshiba.co.jp
Atsushi Inoue
Toshiba Corporation, R&D Center
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
Email : inoue@isl.rdc.toshiba.co.jp
Atsushi Shimbo
Toshiba Corporation, R&D Center
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
Email : shimbo@isl.rdc.toshiba.co.jp
Toshio Okamoto
Toshiba Corporation, R&D Center
1 Komukai Toshiba-cho, Saiwai-ku, Kawasaki 210
Japan
Phone : +81-44-549-2238
Email : oka@isl.rdc.toshiba.co.jp
Ishiyama, et al. Expires May 1997 [Page 25]