Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mobileip/mobileip-minutes-94feb.txt

Text File | 1994-06-07 | 16KB | 350 lines

INTERIM_MEETING_REPORT_

Reported by Alan Quirt/Bell Northern Research

Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
(MOBILEIP)

An interim meeting of the Mobile IP Working Group was held at Qualcomm
in San Diego, Monday and Tuesday 21-22 February 1994.

These minutes mainly summarize the decisions of the meeting.  It is not
practical to report all the discussion, but where it was lengthy some of
the main alternatives are mentioned.


Goal of the Meeting

The goal is to complete the Internet-Draft for Mobile IP, with group
consensus, and publish it promptly after the meeting.  This draft, with
any changes resulting from discussion through the mailing list, should
be presented to IETF in Seattle in late March, for the standards track.

(An alternative was to issue an immediate Experimental RFC for Mobile
IP, planning to enter the standards track next year.  This was rejected
because it would delay the final standard.  Implementation can proceed
just as soon based on an Internet-Draft.)


Administrative Matters

Our editor, Charlie Kunzinger, has resigned.  (Thanks, Charlie, for your
hard work.)  Bill Simpson, our new editor, hopes to have the meeting
draft out by 5 March.

The editor and chairman will obtain a well-known UDP port number for
control messages, an IP protocol number for encapsulation, and two
multicast addresses for beacons and solicitation.

(Several attempts were made to reopen the question of using ICMP for
beacon and solicit messages, but many felt that old issues should not be
reopened.  UDP supporters emphasized ease of implementation on top of
existing commercial protocol stacks.)

Charlie Perkins brought to our attention United States Patent 5,159,592
which was filed by him in October 1990 and assigned to IBM. It describes
a method of issuing temporary IP addresses from a pool, and a gateway
for wireless mobile hosts.  Several earlier patents are cited in it.  It
could have some impact on the current Mobile IP design.  Charlie agreed
to investigate whether IBM will make the patent available ``for a
reasonable fee, on a nondiscriminatory basis.''


Security


Because of recent widespread passive attacks via the Internet, security
was a major topic of the meeting, and strongly influenced other areas.
Wireless operation may increase eavesdropping risk, but the wired
Internet can no longer be trusted much more.

We quickly agreed that the privacy of message content is a separate
end-to-end issue, outside the scope of Mobile IP. We will use the IP
Security Protocol and its successors when they are available.  Our
security goal is to ensure that our protocols do not give outsiders any
easy way to redirect a mobile host's traffic.  We must also ensure that
we do not depend on information that would be hidden by IP security.

The meeting agreed that the minimum acceptable security must include a
way for a mobile host and its home agent to authenticate each other's
messages.  Today this can be done most easily using a strong hash
function such as MD5, with a manually configured shared secret key.

This allows only authentication of messages between the mobile and its
home agent, including the important case of passing a binding (a pairing
of a mobile with a care-of address) from the mobile to the home agent.
It is no help in authenticating the messages between mobile and foreign
agents that were necessary to establish the binding.  Sometimes there
will be methods outside of Mobile IP to increase the security of those
messages, such as the authentication protocols in recent wireless
standards.  If stronger security is essential, secret keys can be
manually configured between mobiles or home agents and the foreign
agents that they use.

(A clever scheme presented by John Zao (see mailing list Mobile IP 831)
offered a way of creating session keys, but could not fully authenticate
foreign agents.  It also perhaps increased the exposure of the shared
secret between home and mobile.  The consensus was to not use this
scheme in its present form.)

Here and throughout, public key certificates would allow easier
authentication of all parties in Mobile IP, and secure distribution of
shared session keys.  However, patent and export control issues are
delaying the creation of an Internet key management system.  The
consensus was that we needed a practical level of security now, with
provision for easy extension once a key management system is available.

The following list of points was suggested for Mobile IP security.  Most
items seemed to be generally acceptable, but the meeting did not
formally adopt the list.


  1. Algorithm-independent support for keyed cryptographic checksums or
     digital signatures for authentication.  This requires
     authentication fields in type/length/value format, where the type
     indicates algorithm.  For now, both the algorithm and key can be
     manually configured.  Later, a list of supported algorithms will
     need to be sent in an initial setup message, and negotiate the
     algorithm to be used.

  2. Mobile host and home agent must support at least MD5 with 128-bit
     keys using manual key distribution.  These keys must be supplied,
     but default values might be acceptable in some controlled
     environments.

  3. Foreign agents must support at least MD5 with 128-bit keys using
     manual key distribution.  Such keys are configured on a per-mobile
     basis.  Agents are allowed to serve mobiles with which they do not
     share a key.

  4. All registration messages must be authenticated whenever a shared
     key exists between the parties.  This implies that all messages
     between mobiles and their home agents must be authenticated.

  5. The sequence number field in existing messages should be extended
     to 64 bits to allow optional use of time stamps in NTPv3 format,
     for increased security against replay attacks.

  6. It would be helpful in the long term to add a ``home agent'' record
     to the Domain Name Service.  Today such records would not be
     believable, but with a future DNS that enforces authentication,
     they would be a handy way to get or check a mobile to home agent
     binding.

  7. Fields that must be covered by an authentication checksum include:
     type, op-code, addresses and address-lengths, service-life,
     binding-life, sequence number, and perhaps IP options.

  8. We need at least one new reply code:  ``Service Denied,
     Administratively Prohibited.''

  9. Because key management is harder for them, foreign agents should be
     lightweight.  They should take few actions on their own.  For
     example, they should never revoke a binding to a previous foreign
     agent on their own.  They may forward registrations or revocations
     from the mobile or the home agent, either of which might be able to
     authenticate the request.

 10. There should be only one binding lifetime, applying to both home
     and foreign agents.  A value of zero for any lifetime should mean
     that the binding is denied or revoked.  A value of all-one-bits
     should indicate an indefinite lifetime.

     (There was considerable discussion of how many binding lifetimes
     are needed.  Should a mobile's binding to a foreign agent have just
     one binding-lifetime at both home and foreign agents, or should it
     have two?  If there is only one lifetime, all (re)registrations
     must go to both the foreign and home agents.  That increases
     traffic, sometimes over a long path.  If there is one lifetime, the
     packet format, the protocol, and time-out handling are simpler.  As
     no clear resolution was reached, the provision for separate
     time-outs in the December draft will presumably be kept.)

 11. There may be situations where a mobile wishes to tunnel all of its
     outgoing packets back through the home agent, to conceal its
     location from outsiders.  The present protocol does not support
     reverse tunnels, but it would be easy to add later.


Routing Optimization

The meeting reluctantly agreed that:


   o The ``weak security'' model proposed in earlier drafts is
     unacceptable in the new, harsher Internet environment, and

   o Stronger security is impractical without a key distribution
     service.  All routing optimization will be removed from the base
     protocol.


Dave Johnson, Andrew Myles, and Charlie Perkins agreed to edit a
separate RFC defining experimental extensions to Mobile IP for routing
optimization.  They will include strong authentication for use where
suitable key distribution is available.  There will also be warnings of
the security risks involved in accepting unauthenticated routing
optimization messages.

Separating the routing optimization will make the base document shorter
and easier to read.  The optimization may or may not be folded in at a
later date.  Either way it is intended to become an official part of the
standard once Internet key management makes it practical to authenticate
routing messages.  Meanwhile the experimental protocol can be used in
safe isolated networks to gain experience.

[Comment that had to be preserved:  It is painful to have your packets
trapped in a route canal :-)]


Encapsulation

The encapsulation method for complete IP packets will be based on the
IMHP scheme, which adds only 12 bytes of header to each packet (only 8
bytes if the original sender is the tunnel source).  The header for
fragments will include full IP header information; this can probably be
treated as a variant of the IMHP encapsulation protocol rather than a
separate protocol.  Only IP packets are handled.

(A warning was given, based on experience, that multiple encapsulation
should be avoided.  It creates a risk of recursive encapsulation when a
routing loop occurs.  Based on this warning, it may not be a good idea
to re-encapsulate other protocols already tunnelled inside IP.)


Multiprotocol Encapsulation

Some people need to tunnel a protocol such as IPX or AppleTalk all the
way to a mobile host.  The foreign agent cannot be the end of the tunnel
because it does not know the other protocols (though it may be involved
for billing and beaconing), so the mobile must obtain a temporary IP
address using DHCP or some other means.  The encapsulation protocol
could be GRE or something equivalent.  The relationship between this
multiprotocol encapsulation and Mobile IP has not been worked out.


``Pop-ups''

Pop-ups are mobile hosts that ``pop up'' on a remote subnet that has no
foreign agent.  They obtain a temporary address by any available means
(such as DHCP or manual assignment) then act as their own foreign agent.
They use normal Mobile IP protocols to the home agent.  Because they
share a secret key with the home agent, their messages can be
authenticated.

(There would be advantages to eliminating foreign agents as tunnel
endpoints.  Protocols and authentication would be simpler, and it would
be easier to tunnel non-IP protocols.  However, a pool of available
mobility addresses would be needed for every subnet.  Foreign agents are
also essential for beaconing, and useful for packet redirection when
routing optimization is used.  In commercial networks they might be
involved in billing.  The consensus was that foreign agents as currently
defined are essential today to conserve address space, but their role
should be reconsidered after IPng is deployed.)


Ad-hoc Networking

Several mobile hosts (typically with wireless networking support) may be
near each other but not near a wired network.  A suggested solution is
to simply let a mobile host respond to an ARP request, without concern
for matching high order address bits, in that situation.


Multiple Agents

A mobile could potentially have multiple home agents if several routers
into its home subnet were capable of acting as home agents.  For greater
robustness the mobile might maintain a list of home agent addresses,
each with a secret key for authentication.  However, only one such agent
would normally be active at a time.  (This is a complex area needing
more design work.  For example, Mobile IP does not define any mechanisms
by which multiple home agents can properly synchronize their state.)

Since registration with a foreign agent and revoking a previous
registration are separate operations, a mobile could be served by more
than one foreign agent at a time.  This would allow softer handoff when
a mobile is moving from one wireless coverage area to another.  To
support this feature, the home agent would have to maintain a list of
active foreign agents for each mobile, and forward each packet to all of
them.  Existing higher layer protocols should be capable of eliminating
any duplicate or reordered packets that the mobile receives.


Agent Advertisement

It was agreed that the beaconing and solicitation parts of Mobile IP
would be modeled very closely on the existing router advertisement
protocol, including a name change from beaconing to advertisement.
However, the actual protocol will be new, because different information
is needed in the messages, and because we use UDP not ICMP.

Both home and foreign agents may advertise similarly.  If an agent has
multiple addresses, only one will be advertised.

(Some felt that home agents should not advertise.)


Returning Home

It was agreed that on returning to its home address, a mobile need not
specifically register with its home agent.  As soon as the mobile has
revoked all foreign registrations, the home agent should cease
forwarding packets addressed to the mobile, and should use a gratuitous
ARP on the mobile's behalf to clear obsolete ARP caches.


Higher Layers

There should be an appendix with hints for higher layer protocols in a
mobile environment; for example, there should be a way to configure
longer default time-outs.


Mobile Subnets

There was some discussion of the possibility that a registration might
represent the location of a whole subnet (where a subnet is the thing
you get by combining a netmask and an address) that moves together,
perhaps on an airplane or a ship.  It was suggested that we try to find
a good way to express this situation.  It may affect only registration
messages.


Detailed Study of Draft

All of Tuesday afternoon was spent on a section-by-section examination
of the existing draft, in the light of the earlier decisions.  With the
elimination of route optimization, many sections were dropped.  Since
the revised draft will be available shortly after these minutes, no
details are recorded here.


Attendees

Kannan Alagappan         [e-mail]
Randall Atkinson         [e-mail]
Stephen Deering          [e-mail]
Pierre Dupont            [e-mail]
Richard Fox              [e-mail]
Scott Hinnrichs          [e-mail]
David Johnson            [e-mail]
Phil Karn                [e-mail]
Charles Kunzinger        [e-mail]
Tony Li                  [e-mail]
Gabriel Montenegro       [e-mail]
Andrew Myles             [e-mail]
Sanjiv Nanda             [e-mail]
Steve Parker             [e-mail]
John Penners             [e-mail]
Charles Perkins          [e-mail]
Alan Quirt               [e-mail]
Joel Short               [e-mail]
William Simpson          [e-mail]
Jim Solomon              [e-mail]
Fumio Teraoka            [e-mail]
John White               [e-mail]
John Zao                 [e-mail]