Subject: (mobile-ip) Mobile IP minutes

From: Jim Solomon <[email-masked]>
Date: Wed, 07 Jan 1998 11:17:21 -0600

Minutes of the Mobile IP Working Group meeting at the 40th IETF,
December 8, 1997, Washington, DC

Minutes recorded by Yih-Chun Hu and Dave Maltz (CMU)
Edited by Dave Johnson (CMU) with minor edits by Jim Solomon (Motorola)

======================================================================

Overview:

The Mobile IP Working Group held one meeting during the week.  The
agenda was primarily devoted to Mobile IPv6, featuring a review of the
changes to the Mobile IPv6 draft by Dave Johnson.  Charlie Perkins
reviewed some changes made to the Route Optimization for Mobile IPv4
drafts.  Presentations proposing extensions to Mobile IP and future
work were also made on the topics of Rapid Authentication, a Tunnel
Establishment Protocol, and IPsec Tunneling for Mobile IP, by
Luis Sanchez, Charlie Perkins, and John Zao, respectively.

======================================================================

General Announcements and Status Information:

Gabriel Montenegro stated that the Reverse Tunneling draft is only
awaiting the assignment of an extension number from IANA, and then it
will go to Last Call.  See draft-ietf-mobileip-tunnel-reverse-04.txt.

Mobile IPv6 still needs some IANA assignments, too.  We need a
Home-Agents anycast address, as well as option type codes for the
Binding Update, Binding Request, Binding Acknowledgement, and Home
Address destination options.  Steve Deering is supposed to make this
happen, and we are supposed to bug him about it until he does.

Dave Johnson announced that MobiCom'98, The Fourth Annual ACM/IEEE
International Conference on Mobile Computing and Networking will be
held October 25-30, 1998, in Dallas, Texas.  Paper submissions are due
April 21, 1998.  For more information, see the MobiCom'98 web pages at
http://www.mobicom98.utdallas.edu/ .

======================================================================

Review of changes to Mobile IPv6
Presented by Dave Johnson <[email-masked]>

This presentation reviewed the changes in the Mobile IPv6 draft since
the previous version of the draft.  The changes are itemized in an
appendix of the draft and were discussed in the meeting.  The current
version of the draft is draft-ietf-mobileip-ipv6-04.txt.  Among the
meeting attendees, only the CMU Monarch Project has implemented Mobile
IPv6, and no attendees reported themselves as having an implementation
in progress.

This version of the draft introduced a new mechanism to allow a mobile
node to request its home agent to handle all home addresses for the
mobile node, based on each of the prefixes believed by the home agent
to be on-link.  The new draft specified this by use of a new ID Length
field in Binding Updates, but the consensus of the meeting was that
this should instead be represented by a Prefix Length field.  In an
unresolved issue, the Binding Update format allows a mobile node to
request forwarding for a single address, using a Prefix Length of 0,
or for all addresses for the mobile node on its home network with each
of the on-link network prefixes, using a nonzero Prefix Length.  Since
there can be only one Home Address extension per Binding Update, the
only way to indicate more addresses for the mobile node (such as those
acquired by DHCP, which differ in more than just the prefix bits) is
to send multiple Binding Updates.  There was no consensus on whether
or how Binding Updates should be changed to allow the listing of more
addresses as part of a single Binding Update.

Another issue that arose in the meeting was the exact rules for
forwarding to a mobile node packets addressed to its link-local
address or site-local address.  The new draft specifies that such
packets MUST NOT be forwarded, in order to avoid the confusion that
could otherwise arise when such packets are forwarded outside their
original scope.

On this point, Steve Deering noted that outside of the Mobile IP
Working Group, there is widespread misunderstanding about what service
Mobile IP is trying to provide.  Is Mobile IP attempting to give a
mobile node a virtual presence on the home network, or is it providing
a forwarding service?  The answer to many detail-oriented issues are
based on the answer to this question.  If Mobile IP attempts to give
virtual presence semantics, home agents would have to act like
bridges.  Any packet that a mobile node would hear if it was attached
to the home network must be forwarded to it.  On the other hand, if
Mobile IP attempts to give forwarding semantics, the home agent's
actions cannot be described simply and must be enumerated in the
drafts or refer explicitly to other IPv6 forwarding/encapsulation
drafts.

The Working Group consensus is that Mobile IP provides forwarding
semantics.  The home agent is just a router with a physical interface
and tunnels. The draft should make it clear that the home agent is not
a bridge, and is not exempt from normal rules of IPv6 forwarding.
Though some people want Mobile IP to provide virtual presence
semantics so it looks as if they're always at home, it looks like this
breaks too much of non-mobile IPv6's model.

Based on this consensus of the model provided by Mobile IP, we
returned to the specific question of whether or not to forward packets
addressed to a link-local or site-local address.  The issue rests
largely on the exact semantics of link-local and site-local addresses,
which have not yet be finalized by the IPng Working Group.  In
particular, it's not yet clear whether a home agent can even tell by
looking at an address whether or not the address belongs to the same
site as the mobile node (and the home agent).  A current IPng
proposal, though, says that if a node is communicating with another
node inside the same site it SHOULD use that node's site-local
address, if known.  If so, however, then the language in the current
Mobile IP draft saying that such packets MUST NOT be forwarded by the
home agent, will break any connections with a mobile node if it moves
away from home, if the connections were started while at home and
connect with another node in the mobile node's home site.  This issue
must be resolved between the Mobile IP and IPng Working Groups.

As at least an interim solution, the Mobile IP Working Group decided
that home agents MUST NOT forward packets sent to a link-local
address, and MUST NOT forward packets sent to a site-local address
unless the home agent is sure the mobile node's care-of address is
still inside the same site.

Jim Solomon asked if anyone had claims of IPR on the sequence number
in Binding Updates since the semantics border on that of nonces --
something which IBM has previously asserted relevance to existing
patents (cf RFC 2002).  Dave Johnson explained that the sequence
number is *only* a sequence number and is not involved in replay
protection.  It is only used in ordering Binding Updates, in exactly
the same way as any sequence number, and so should not be covered by
the patent.

The draft's description of the processing of the Home Address
destination option is now complete, and must be checked out with an
IPsec expert to make sure there are no conflicts.  The basic
end-to-end processing order is:

 TCP -> Mobile IP swap -> IPsec -> wire -> IPsec -> Mobile IP swap -> TCP

The processing of a received Home Address option in a packet is
described in the draft as a conceptual model.  As an implementation
issue, though, the CMU Monarch Project implementors reported that in
processing a received Home Address option, they found it useful to
physically swap the Source Address in the packet's IP header (the
care-of address) with the Home Address field in the Home Address
option, so that after the swap the Home Address option contains the
care-of address and the IP Source Address field contains the home
address.  This preserves any ingress filtering protection as the
packet travels up through protocol stack, since higher layers can
still check the care-of address for sanity should they want to.

The draft is currently silent on the topic of mobile networks.  There
are two kinds of mobile networks: fixed-on-mobile, where a mobile
router hides all mobility issues from a network of fixed hosts behind
it that use it as their default router; and mobile-on-mobile, where a
router, which is also a mobile node, provides router service to other
mobile nodes (who have a home network elsewhere).  The mechanisms
described in the current draft support mobile-on-mobile correctly,
without the draft specifically mentioning that it does so.  Supporting
fixed-on-mobile is harder.  The draft needs to either explain or
disclaim fixed-to-mobile networks.  Perhaps we can simply adopt what
is done in RFC 2002 for Mobile IPv4.  This issue needs further
consideration.

Receiving a packet containing a Home Address option MUST be supported
by all IPv6 nodes -- that is, not just mobile nodes or home agents or
routers, but ALL IPv6 nodes.  However, the the top two bits of the
Home Address option type code must still be set to indicate what
should happen if a node receives this option but doesn't recognize it.
The draft currently specifies that these bits are set to cause such a
receiver to return an ICMP "parameter problem" error to the sender (a
mobile node), but the draft doesn't say what the sender should do when
it receives such an ICMP error.  It is unclear whether the sender
should: (a) treat the destination as unreachable and log the error; or
(b) try to talk to the correspondent without the Home Address Option,
using its home address as the IPv6 Source Address, and realize that
its packets have some likelihood of being dropped by ingress-filtering
routers.

======================================================================

Rapid Authentication for Mobile IP
Presented by Luis Sanchez <[email-masked]>

The idea behind this presentation was to find a scalable approach to
authentication, since we may need to authenticate to nodes other than
the home agent.  If that happens, we need scalability. The only way to
authenticate to arbitrary nodes is to use public key methods, but such
methods have high computation cost.  If a mobile node is moving fast,
it can't do a public key exchange fast enough when moving into new
domains.  The approach described here is to do the public key exchange
once, and then to get tickets that allow you to move around the domain
without need of further public key exchanges.

This rapid authentication scheme has three goals.  First, to be
compatible with the standards track Mobile IP protocols.  Second, to
improve the efficiency of mobile nodes to move around inside an
administrative domain; there is no intent to make the first
authentication faster.  Finally, rapid authentication avoids requiring
trust across boundaries.

The protocol uses an extra code in the foreign agent Advertisement to
indicate that the foreign agent supports rapid authentication and can
act as a Rapid Key Distribution Center for the mobile node while the
mobile is visiting the administrative domain.  The security
associations developed by the Rapid Authentication protocol are in a
separate PK_KEY class from standard IPsec security associations.

Source code for the system should be released soon.  Also, although
the slides in this presentation were marked "BBN confidential", the
speaker stated that they were in fact not confidential.

======================================================================

Tunnel Establishment Protocol (TEP)
Presented by Charlie Perkins <[email-masked]>

The idea of TEP is based on a tunnel protocol for Virtual Private
Networks (VPN).  Some people want multi-protocol tunneling, multilevel
security domains, VPNs, etc., and the IETF is generating many
tunneling protocols.  TEP's goal is be a general protocol to set up
all tunnels.  TEP is designed to allow a multi-protocol tunnel agent
(like a Mobile IPv4 foreign agent) to request a tunnel on behalf of
some node (like a Mobile IPv4 mobile node) that doesn't need to
participate in the protocol.  TEP is designed so that the constructed
tunnel is bidirectional.

The designers want to take the experience from Mobile IPv4 in RFC
2002, and add elements to obtain extra functionality.  They plan to
use the same ports and basic registration methods as Mobile IP, with
new extensions.

Some changes in terminology were suggested to make the protocol more
understandable.  The following terms map roughly into the given Mobile
IPv4 entities:

  targeted tunnel agent  == home agent
  requesting tunnel agent == foreign agent
  PDU receiver == mobile node

TEP also includes provisions for a hierarchy of foreign agents, in
order to reduce the number of packets that must travel to/from the
home agent when the mobile node is making local moves between foreign
agents which are in the same or nearby domains.

======================================================================

Route Optimization in Mobile IPv4
Presented by Charlie Perkins <[email-masked]>

This presentation described some of the changes made recently to the
Route Optimization extensions for Mobile IPv4.  The Route Optimization
draft has now been split into three separate drafts:

  - draft-ietf-mobileip-optim-07.txt: edited version of previous
      draft, with two sections (below) pulled out into their own drafts.
  - draft-ietf-mobileip-regkey-00.txt:  registration key establishment
  - draft-ietf-mobileip-spectun-00.txt:  special tunnels

Registration key establishment has little to do with the Binding
Cache, but has lots to do with establishing security associations.
This draft now needs feedback from security experts.

It was pointed out that during the editing changes, the drafts'
descriptions of when and how to send Binding Updates were removed, and
need to be added back.  Note also that the Route Optimization
extensions are being redesigned to more closely follow the protocol
model designed for Mobile IPv6, and these revised drafts do not yet
completely reflect that redesign.

======================================================================

IPsec Tunneling for Mobile IP
Presented by John Zao <[email-masked]>

Most of the previous work in this Working Group has dealt with how to
secure the control traffic of Mobile IP.  There is another part of the
Mobile IP traffic that may need to be secured --- the tunneled
packets.  The questions are should we protect the tunneled packets,
and if so, where should we add IPsec protection to do so?  IPsec needs
to be married to Mobile IP so it doesn't add an extra header, since
there's already a tunneling header used for Mobile IP.

This presentation proposed using IPsec at every tunnel, and
negotiating the tunnels via the normal Mobile IP control messages.  A
new IPsec tunnel extension would be added to the Registration Request
and Reply messages, and flags would be used to select tunnel
parameters, like is currently done for GRE and Minimal Encapsulation.

David Reeder noted that Portland State University already has an
implementation of Mobile IP that does most of this, except for
advertising the possibility of IPsec tunneling in its Agent
Advertisements.  See http://www.cs.pdx.edu/research/SMN/ .

======================================================================
-----------------------------------------------------------------------------
IETF Mobile IP Working Group Mailing List - Archives:  software.watson.ibm.com
Unsubscribe:	unsubscribe mobile-ip		(as message body, not subject)
Direct all administrative requests to [email-masked]