home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
mobileip
/
mobileip-minutes-95jul.txt
< prev
next >
Wrap
Text File
|
1995-10-18
|
11KB
|
244 lines
CURRENT_MEETING_REPORT_
Reported by Jim Solomon/Motorola
Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
(MOBILEIP)
Joint Meeting of the MOBILEIP and IPNG Working Groups
The two groups met on the morning of Tuesday, 18 July. This meeting was
co-chaired by Jim Solomon, co-chair of the MOBILEIP Working Group, and
Ross Callon, co-chair of the IPNG Working Group.
Introductory Remarks
The co-chairs took turns introducing the output produced by their
respective working groups. Jim Solomon first introduced the primary
requirements of the IPv4 mobility protocol: (1) mobile nodes must be
able to communicate using only their (permanent) home IP address; and
(2) mobile nodes must be able to inter-operate with the enormous
installed base of (non-mobility-enhanced) IPv4 hosts and routers. A
brief outline of the architecture of IPv4 mobility was also presented.
Ross Callon then introduced IPv6, highlighting the differences between
IPv4 and IPv6. Ross noted that there is no installed base of IPv6,
thereby relaxing the second criteria of IPv4 mobility and increasing the
possible solution space for IPv6 mobility. A fundamental choice for the
design of IPv6 then becomes: should IPv6 be a direct ``port'' of IPv4
mobility or should IPv6 mobility be designed in such a way as to take
advantage of the new functionality that IPv6 contains (as compared to
IPv4).
Presentations
Fumio Teraoka presented his proposal for IPv6 mobility; one based upon
the VIP concept put forth in his IPv4 mobility proposal [1]. This
proposal optimizes routing to mobile node by having routers on the path
between home agent and mobile node learn and cache the (authenticated)
binding between a mobile node's home address and its current location.
Concerns were raised about the amount of processing required by routers
in the Internet due to the presence of a hop-by-hop option in all mobile
registration packets. In particular, the routers must verify an RSA
digital signature in addition to processing the contents of the packet
to obtain the desired location bindings.
Dave Johnson and Charlie Perkins presented their proposal for IPv6
mobility [2]. This proposal leverages off of the ``route optimization''
work within the Mobile IP group for IPv4. This proposal optimizes
routing to mobile nodes by having correspondents (i.e., those host and
routers actually communicating with a mobile node) cache the mobile
node's current location, tunneling packets directly to the mobile node's
current care-of address. The Johnson/Perkins proposal involves using an
IPv6 destination option to provide address bindings to correspondents.
Open Discussion
The floor was opened to comments from the community at large. The
consensus seemed to be that:
1. Mobility for IPv6 should leverage off of the new functionality
provided by IPv6, rather than being a ``direct port'' of IPv6.
2. Mobile IPv6 should be ``owned'' by the MOBILEIP Working Group and
no new working group needs to be formed for Mobile IPv6. If
necessary, the Mobile IP charter will be expanded to reflect this
decision.
3. Due to the fact that IPv4 mobility is being delayed by patent
concerns, now would be a great time for someone with an
unencumbered proposal for IPv6 mobility to step forward.
Tuesday Afternoon -- Mobile IP(v4)
Based upon the results of the morning meeting (joint with the IPng
Working Group), the chairs have an action item to review the Mobile IP
charter and determine whether it must be expanded to include
responsibility for IPv6 mobility.
Patent Issues
IBM has provided a statement viz. Charlie Perkins' patent -- the terms
are ``reasonable and nondiscriminatory'' as required by RFC 1602.
However, the terms are neither ``free'' nor are they a flat fee. At the
request of the co-chairs, Joel Halpern (Routing Area Director) has
requested funds from ISOC for legal counsel to investigate the scope of
infringement of the current working group draft. One possible outcome
of this investigation is that the counsel might suggest that the amount
of exposure of the mobile IP protocol could be significantly reduced by
eliminating certain ``features'' of the protocol (e.g., MN de-tunneling
its own packets by obtaining a local COA; and replay protection using
nonces).
Implementation Reports
Several working group members are implementing and/or have implemented
the protocol. Anders Klemets has an implementation (MN, FA, HA),
running under SunOS v4.1.3 that he is willing to provide people wishing
to perform beta testing. Contact him at <klemets@sics.se> if you would
like a copy.
Interoperability Testing Plans
When enough people have brought their implementations up to Version 11
of the draft, interoperability testing will proceed (hopefully by late
August). Frank Kastenholz of FTP Software will check into the
feasibility of hosting an interoperability shindig. Otherwise, Charlie
Perkins of IBM indicated a willingness to do likewise.
Specification Issues
A) Prefixes in Agent Advertisement. The consensus is that these are
sometimes useful to MNs, thus we have decided to include them as an
option in agent advertisements. The option will contain one prefix for
each router address present in the ``base'' portion (i.e., the RFC 1256
portion) of the advertisement. Tony Li will provide text for this to
the editor.
B) UDP Ports viz. authentication. In the general case, the HA does not
know the source port used by the MN for the registration request,
therefore it is impossible for the HA to verify the authenticator.
Furthermore, it was deemed that the threat of not including the UDP
ports in the computation of the authenticator was minimal. Thus, the
authenticator(s) will now be computed over only the Mobile IP portions
of the packet; equivalently, the authenticator(s) will not be computed
over any portion of the UDP header.
C) TTL: Is the tunnel 1 hop or N hops? The argument for ``1 hop'' is
that it provides no loss of connectivity to a mobile node when it is
away from home. The argument against it is that making the tunnel
``1 hop'' inevitably requires placing a larger TTL in the encapsulating
(outer) header than that of the original datagram. After a long
discussion, the only consensus that was reached was that Mobile IP
should learn from the operational experience of the MBONE and ``do what
mrouted does''. [I suspect that the group needs more discussion about
this on the mailing list. -- Jim Solomon]
D) The working group agreed that the draft needs a ``wholesale''
rewriting in order to make the draft more comprehensible to those that
have not followed Mobile IP for years. Note that the changes here are
all editorial and that changes in content will only be those reflecting
the consensus of the group at the meetings and on the list.
E) Gratuitous Registration Reply from HA to old FA. Anders pointed out
that there is a correctness problem with the protocol in that a stale
entry in an (old) FA's visitor list makes it impossible for that FA to
communicate with an MN which moves to and registers with a (new) FA.
Ensuing discussion revealed that there is a trivial denial-of-service
attack possible by sending bogus registration replys to an FA,
convincing the FA to remove the MN from its visitor list.
Thus, the group decided that gratuitous registration replies should only
be sent to the old FA if the HA shares a security association with that
FA, implying that the FA/HA authenticator can be used. Similarly, the
FA should ignore a registration reply that is: (a) not prompted by a
corresponding registration request; or (b) does not have a valid FA/HA
authentication extension.
This restricts the potential attackers to be those devices on the media
that the MN is visiting. Several working group members pointed out
that, due to the presence of protocols such as ARP, any nodes on the
mobile media can wreak similar havoc using alternative mechanisms and
that we are not making the problem any worse.
Wednesday -- Mobile IP(v4)
Specification Issues -- Continued
F) The topic of MN/FA and FA/HA authentication was raised yet again in
reference to eliminating these authentication extensions and using the
IPSEC authentication header instead. This proposal was rejected due to
uncertainty in the time-frame for IPSEC and, perhaps more importantly,
the fact that it is less work to implement the extensions once the
(mandatory) MN/HA authentication extension is implemented.
G) It was proposed that an MN be able to provide a broadcast ``filter''
to let the HA know which broadcasts it is interested in (e.g., a
specific IPPROTO number, or a specific IPPORT number, etc.). The group
consensus was that a mechanism to support this functionality should not
be part of the base specification and that those requiring this
functionality should submit an Internet-Draft specifying its operation.
H) Noting that the current working group draft contains three
authentication extensions, yet only one key identifier extension, the
group decided that a mechanism must be provided to apply a key
identifier to all of the authentication extensions. It was decided to
integrate a Security Parameter Index (4 bytes) of identical syntax and
semantics to the SPI used in IPSEC into each of the respective
authentication extensions. The extensions now look as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... SPI (cont.) | Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See the IP Authentication Header document [3] for more information on
the use of SPI's.
Route Optimization
Dave Johnson explained his and Charlie Perkins' proposal for route
optimization in IPv4 mobility [4]. The proposal involves a mechanism
for distributing authentic binding information to the nodes which
require it, mitigating to some extent the key-management difficulties.
The authors stressed that the need for feedback on their proposal from
the members of the MOBILEIP Working Group.
References
[1]
ftp://cnri.reston.va.us/internet-drafts/draft-teraoka-ipv6-mobility-sup-01.txt
[2]
ftp://cnri.reston.va.us/internet-drafts/draft-perkins-ipv6-mobility-sup-02.txt
[3]
ftp://cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-auth-02.txt
[4]
ftp://cnri.reston.va.us/internet-drafts/draft-ietf-mobileip-optim-02.txt