CURRENT MEETING REPORT
Reported by John Zao, BBN Corporation
Minutes of the IP Routing for Wireless/Mobile
Hosts Working Group (mobileip)
The MOBILEIP Working Group met twice on
March 6th and 7th at the Los Angles IETF. The first meeting was
focused on IPv6 mobility and the second was primarily concerned
with IPv4 mobility. The organization of these minutes is by topic
area: first IPv6 then IPv4.
IPv6 Mobility
The first meeting started with Charlie Perkins <perk@watson.ibm.com> presenting an overview of the working group's IPv6 Mobility draft, co-authored by Charlie and Dave Johnson's <dbj@cs.cmu.edu> (see draft-ietf-mobileip-ipv6-00.txt).
Mobile Nodes will be able to construct care-of addresses using IPv6 neighbor discovery protocols and obtain subnet prefix. Hence, they can be the natural end of IP tunneling or other form of packet redirection. Explicit FAs are no longer needed.
All IPv6 nodes will be mobility aware. This implies automatic route optimization and thus lightens the load of HAs.
CH can place the care-of address of MN in routing headers and compute the packet authenticator. Only HA needs to use IP encapsulation to effect packet redirection because it can not alter the authenticator.
IPv6 Mobile IP Requirements
Questions and Discussions:
Plenty of discussions arose on the issues
of access control which led smoothly into the discussions of using
Mobile IP with firewalls (the next agenda item).
An issue was raised in regards to accounting
with the absence of explicit FAs. IPv4 enforces the use of an
explicit FA to relay registration messages by setting the R bit
in the messages. Similar mechanism was felt to be needed to perform
access control functions. However, the general consensus prefers
to deal with the problem as a security issue for assigning local
IP addresses -- a DHCP problem rather than a MIP problem. Authentication
methods should be built into the address assignment scheme and
IPv6 routers should be able to recognize bad local address and
drop the packets. The use of RADIUS Working Group technology was
also suggested. All these provides only a philosophical framework
for possible solutions; no solid scheme was proposed.
Firewall Issues
A lengthy discussion took place regarding
the issues of packet passing to MNs through the firewalls. Two
different problems were identified: (1) passing MN packets through
the firewalls FROM the FOREIGN SUBNET, and (2) passing MN packets
through the firewalls INTO the HOME SUBNET. The first problem
seems to be more difficult although the two problems may be equivalent
in some situations.
The difficulty of passing packets through
the firewalls FROM the FOREIGN SUBNET is caused by the fact that
firewalls drop packets which are not originated from hosts belonging
to the local subnet, and the process will likely be performed
without any warning such as ICMP error messages. The suggestion
of hiding true source addresses of MNs will not work because future
firewalls should be able to defeat similar host masquerading.
The real solution can only come with embedding certain authentication
tokens (negotiated between MNs and foreign firewalls) into the
packets so that the identity of their true sources can be authenticated
and accepted according to the security policy. The problem of
passing MN packets through the firewalls INTO the HOME SUBNET
is simpler because it should be easier for the MNs to set up certain
mechanism with their home subnet so that they can authenticate
themselves to the firewalls.
These problems were recognized as generally
applying to host mobility, not limited to IPv6 Mobile IP. Hence,
the Working Group was concerned, at one point, about the impact
of the problems towards the standardization of IPv4 Mobile IP.
Decisions were finally made that the firewall traversal issues
will affect many protocols besides Mobile IP. The Mobile IP Working
Group will thus produce a description of the problems and prepare
to accommodate the future solution of the problems as they arise
in the IPv6 community. An attempt to address the simpler problem
of passing packets INTO HOME SUBNETS was also suggested.
Mobile Mesh Network BOF (added item)
Ran Orr <rorr@venice.sedd.trw.com>
initiated a discussion on the relations between IPv6 Mobile IP
and the work in Mobile Mesh Network (MMNet) BOF. With the recognition
that the issues of MMNet form a superset of those of Mobile IP,
the discussion was recommended to be conducted after the meeting.
Alternative Design of IPv6 Routing Header
Fumio Teraoka (SONY) <tera@csl.sony.co.jp>
proposed a different design of IPv6 routing header which may help
the MN packets to pass through the firewalls and leave the foreign
subnets. His design exchanges the positions of MN's care-of address
(COA) and home addresses in the IPv6 Header and the Destination
Option Header:
As a result, the IPv6 Header will contain
the local care-of addresses of MNs and hence may have less of
a problem traversing the firewalls. It was noted, however, that
firewall technology would likely adapt to this situation and restrict
packets so constructed.
Discussions on firewall problems were triggered
once again by the presentation and were centered around the effects
of using different routing headers. Source routing will not work
with firewalls; nor will simple encapsulation. Likely, packets
needs to be tunneled through the firewalls by adding another level
of encapsulation. Questions about special vs ordinary tunneling
were also raised.
IPv4 Mobility
The second meeting of Mobile IP working
group put its focus on IPv4 mobility. It was conducted with the
following agenda:
Last Call for Discussions before Standardization
of Basic Mobile IP
The Internet-Draft, "IP Mobility Support"
<draft-ietf-mobileip-protocol-15.txt>, is in IESG Last Call
for advancement to Proposed Standard RFC. At the meeting, a final
round of discussion was called by working group Co-Chairman, Jim
Solomon to address some concerns posted to the IETF mailing list.
Explicit notification of the community about the final resolutions
of these issues must be arranged before standardization of the
protocol.
Concern was raised that MN may not obtain
the next nonce value from HA if it moves from the FA before completion
of current registration. MN would then have to use an old nonce
in the next registration and thus caused a registration failure.
This problem was considered non-critical
in all rapid movements among FAs for the new registration request
will always be relayed by the new FA and cause the reply (of registration
failure) to be send through the correct path, i.e. via the new
FA to MN. MN can then extract the new nonce from the reply and
obtain re-synchronization of nonces.
The only problematic case arises when MN
travels back to home subnet before completing the last registration.
Since the deregistration request will be sent from the home subnet
with MN home address, the reply of failure will be sent to the
old FA instead of the true location of MN.
A solution was suggested which requires
HA to examine the source addresses of deregistration messages.
If the messages are sent by MN directly then the replies of these
messages will be sent to MN on the home network. In some implementations,
this would involve temporarily brining down the MN's tunnel to
send the registration request, and then reinstating the tunnel.
Definition of Start and End Time of Registration
Periods
Since the delay between registration requests
and replies is not always negligible comparing with the lifetime
of registration, it is important to specify the start and end
time of registration period, and determine when the MN should
initiate a re-registration.
The discussion concluded that at the MN,
the period should start at the time it sends the registration
request, and end when the lifetime specified in the registration
reply expires counted from the defined start. At HA, the registration
period starts at the time the request is processed, and ends when
the lifetime specified in the reply expires counted from the defined
start. At the FA, it was suggested that the period should start
when the request is forwarded and end when the granted lifetime
expires, counting from the defined start time.
Broadcast / Multicast Preference Extension of Mobile IP [C. Perkins]
Charlie Perkins <perk@watson.ibm.com>
and Baiju Patel <baiju@watson.ibm.com> proposed a Broadcast
Preference Extension to the Mobile IP Registration Request message
[see draft-perkins-mobileip-bcastpref-00.txt]. The extension allows
a MN to specify the IP broadcast datagrams it wants to receive
from its home network (via its HA).
The Broadcast Preference extension may be
included several times within a single registration request; each
selects a particular kind of datagrams that the MN wants to receive.
The extension specifies conditions on the protocol number and
the port number, which must both be satisfied by the datagrams
before the HA should forward them to the MN. It also provides
four flags: C (Clean), P (Permanent), A (Additional) and X (Exclude)
to specify the action to the list of selected datagrams that is
caused by the extension.
Comments were invited after the presentation
especially on the additional constraints (beside of protocol and
port numbers) necessary for selecting the broadcast / multicast
datagrams. A question was raised by the audience on the difference
between the use of P and A flags. The answer was that the selection
marked by a P flag can only be cleared by an extension with C
flag set while the selection marked by an A flag can also be cleared
by an extension containing the same selection marked by an X flag.
PPP Mobility Extension of IPCP [B.Patel]
Baiju Patel and Charlie Perkins also proposed
a new option called the Mobility Agent Configuration Option to
the IP Control Protocol (IPCP) in PPP protocol suite [draft-patel-mobileip-pppext-00.txt].
The option allows a requesting peer to determine whether the responding
peer is capable of and willing to function as either home or foreign
agent of Mobile IP. From the transaction, the requesting peer
can also obtain a care-of address from the responding peer.
The Mobility Agent Configuration Option
will be sent by a PPP requesting peer with a valid IP address.
When a PPP peer receives the option, it must respond with Configure-Ack,
Configure-Nak or Configure-Rej to indicate if it can be a mobility
agent and whether it will serve as a HA or a FA. In the FA case,
a care-of address will also be dispatched.
After the discussion, there was a discussion
on the proper order to send IPCP messages with Mobility Agent
Configuration and IP Address options. It is recommended that a
mobile IP peer should first try to use the Mobility Agent Configuration
option and then the IP Address option, if necessary. There was
some question as to the need for the Mobility Agent Configuration
option.
Hierarchical FA and Regional Registration [C.Perkins & D.Johnson]
Increasingly, the Mobile IP community realizes
the inefficiency of requiring the MNs to register with their HAs
*every time* they change their FAs. The registration procedure
may become too expensive (if the HAs are far away) or even impossible
to complete (if partitions exist among networks).
Charlie Perkins and Dave Johnson <dbj@cs.cmu.edu>
proposed two different schemes to enable regional registration
using a hierarchy of FAs. Both schemes employ a tree hierarchy
of FAs with each level of the hierarchy embedded in network regions
with different granularity. When a MN moves between the regions,
it can register only with the FA, which is at the root of the
hierarchy including both its previous and current FAs, but not
with its HA. The registration will be a local procedure if the
movements of MN are minute. Charlie's and Dave's schemes, however,
are different in their ways of establishing the hierarchy of FAs.
In Charlie's scheme, the hierarchy is "static" with
FAs being pre-positioned into every level of the hierarchy. In
Dave's scheme, the hierarchy can be constructed "dynamically":
MN can choose *any* FA in a network region as its primary FA;
as the MN moves within the region, it will notify the primary
FA of its current binding with new FAs known as the secondary
FAs. In both schemes, new registration messages, security architecture
and failure recovery mechanisms must be devised in order to guarantee
robust operation.
In the discussion after the presentations,
security (especially key management) was acknowledged to be a
key issue in the development of both schemes. It was also pointed
out that the biggest benefit of the hierarchical approach lies
with the increase of maximum handoff rate; the total size of binding
tables in all the FAs is actually increased not decreased with
the introduction of the hierarchy. Finally, basic Mobile IP can
be used to handle all the transaction between the primary FAs
and the HAs.
Route-Optimized Mobile IP [D.Johnson]
Dave Johnson announced the release of a
new Internet draft on Route-optimized Mobile IP [draft-ietf-mobileip-optim-04.txt].
New features in the draft include key distribution mechanisms
between HA-FA and HA-CH and nonce dispatch mechanism.
The audience suggested the use of public-key
certificates instead of bare public keys in all key distribution,
and voiced concerns about potential security policy problems with
the use of HAs as KDCs to dispatch keys between MNs and FAs. Charlie
Perkins urged the group to put more effort into this protocol.
Route-Optimization with IP-squared Protocol [K.Okanoue]
Kazuhiro Okanoue <okanoue@nwk.CL.nec.co.jp>
presented the design of an Internet router with agent functionality
(A+R) and its use to perform route-optimized Mobile IP.
The router will be equipped with three additional
functions: (1) MN location binding caching, (2) mobility security
association with HAs, and (3) datagram encapsulation. It will
be placed between CHs and MNs to tunnel datagrams from non-MIP-compliant
CHs to the MNs.
In the discussion after the presentation,
a doubt was cast as to whether such a router was already implied
by the route-optimized Mobile IP. A closer look would be needed
in order to understand the contribution of this work.
Secure Domain-Based Mobile IP [J.Zao]
John Zao <jzao@bbn.com> presented
an ARPA-funded project at BBN to develop a scalable secure Mobile
IP supporting fast mobility and access control.
The project aims at developing two pieces
of technology: (1) a public/hybrid key management infrastructure
which can be used to support authenticated location updates and
secure IP tunneling, and (2) a domain based extension of the basic
Mobile IP which can be used to both hide fast host mobility and
conduct access control within the domain. The first technology
will enable the secure use of route optimized Mobile IP among
all CHs covered by the security infrastructure and the establishment
of secure tunnels between MN-FA, FA-HA, MN-CH, etc. The second
technology, which is similar to Perkins' hierarchical FA scheme,
makes possible large scale and fast host migration in the global
Internet. However, compliment to the other hierarchical FA development,
this work focuses on the security issues of access control, domain-based
key management and firewall traversal.
Ideas on a Firewall Traversal Extension [C.Perkins]
Realizing the pressing issues pertain to the use of Mobile IP among firewalls, Charlie Perkins presented his first ideas of a message extension for allowing datagrams from MN to pass through the firewalls in the foreign domain. Inclusion of the SPI of proper security associations was suggested. More work is definitely needed in this area.