Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mobileip/mobileip-minutes-96dec.txt

Text File | 1997-01-30 | 13KB | 324 lines

Editor's note:  These minutes have not been edited.



                         Minutes of 37th IETF
           IP Routing for Wireless/Mobile Hosts (mobileip)
                             Routing Area
             Reported By Frank Ciotti <[e-mail]>


I) Dec 10, 1996, 9:00am -- Mobile IPv4 Issues

Based on Scott Bradner's talk at Monday's Introduction, RFC 1264
indicates that before we can go the draft standard, all features,
required and optional, need to be implemented, and more
interoperability testing needs to be performed.

Steve Glass from FTP Software said that his company will hold another
Mobile IP connectathon as they did in the Fall of 1995.  They would
like to hold it a week or two prior to the Memphis IETF.

Problems with RFC2002:

 - Typos Fixed.

 - In response to SYN attacks, Organizations and ISP's have begun to
   use ingress filtering on their routers.  This breaks Mobile IP as
   the Mobile Node will no longer be able to inject packets directly
   into the routing fabric while visiting the Foreign Network.  We may
   need to make the support of reverse tunneling a MUST for all
   traffic types, not just multicast.  In addition, the MN->HA tunnel
   must be topologically correct - that is, the outer IP hdr src
   address must be that of the COA, not the MN's Home Addr.

 - Recent discoveries in MD5 weaknesses may be reason to change the
   RFC to state that some other authentication algorithm (e.g.,
   HMAC-MD5) is the default algorithm.

 - When an MN registers with a co-located COA, RFC2002 requires it to
   use that COA as the IPsrc address of its Registration.  Solomon
   wondered whether this was the correct IPsrc address to use in the
   case where the MN is registering that COA _via_ an FA (because the
   'R' bit was set).  The discussion found no compelling reason to
   change the IPsrc address from the co-located COA to the MN's home
   address.

 - Gabriel Montenegro indicated that RFC2002 was ambigous, or
   downright wrong, with respect to the inclusion of the SPI in the
   computation of the authenticator in the various authentication
   extensions.  The group unanimously agreed that the SPI MUST be
   included in the computation of the authenticator, and future
   revisions of the RFC will make this more clear.

 - Charlie Perkins voiced a concern regarding the use of ICMP for
   router advertisements - suggesting the use of UDP instead.

   ICMP Pros:
     If already using Router Discovery, less traffic than using a
     separate UDP packet.
   ICMP Cons:
     May be difficult for applications to implement if there is no raw
     ICMP access.

   Since there didn't seem to be anyone having a problem implementing
   the discovery/advertisement mechanism as it is currently w/ICMP,
   consensus was to use ICMP only, and not UDP.

 - Jim Solomon asked if anyone had implemented the Mobile IP MIB.  No
   responses.

Bi-Directional Tunnel presentation
Gabriel Montenegro - Sun Microsystems

 - Charlie Perkins proposed that the reverse tunnel mechanism as
   described by Gabriel be made mandatory to implement for all Foreign
   Agents.  There were no objections to this.

 - Joel Halpern (Routing Area Director) indicated that he will need an
   applicability statement along with technical specification (which
   can be folded into one document) in order for reverse tunneling to
   advance to Proposed Standard RFC.  It will also require
   implementation experience, such as at the FTP Software connectathon
   mentioned above.  When Mobile IP goes to Draft Standard, the two
   documents can be combined into one specification.

Firewall Support for Mobile IP presentation
Vipul Gupta - Sun Microsystems

 - If there is a key distribution mechanism in place at the firewall,
   a Foreign Agent can be used.  Otherwise, there can be no security
   association between the FA & FW.

 - IPSEC preferred over SOCKS.

 - Joel stated that we must comply with whatever the IPSEC group
   mandates for Internet Key Management.  If it works with SKIP, then
   great, but it MUST work with ISAKMP/Oakley.

 - The working group found this topic of significant importance to
   convene a mini-BOF on Thursday morning to draft a set of goals and
   requirements for the ability for Mobile Nodes to get packets past
   their firewalls when away from their protected intranet.  Minutes
   of this session are included below.

Mobile IP Gateway traversal using IPSEC
Atsushi Inoue - Toshiba

 - Charlie Perkins indicated that a failure to establish a security
   association with a gateway may not always result in a message
   returned to the source indicating the failure.

 - There were some concerns regarding the time required to negotiate
   the path to the secure gateway endpoint.

Proximity Proxies for Mobile Nodes and Agents
Yunzhou Li - National University of Singapore

 - Main benefit is that the MN does not need to re-register when it
   attaches to a new segment within the same Autonomous System, given
   that the original registration has not yet expired.

 - Not much time for questions.

Surrogate Registrations for Mobile IP
Gabriel Montenegro - Sun Microsystems

 - Typical use is where the surrogate FA is a PPP server or is on the
   same Ethernet Hub as the MN, where the FA registers on behalf of a
   mobile computer that has not implemented the Mobile Node function
   of Mobile IP.

 - Dave Johnson pointed out that the security association is between
   the FA and HA, not MN & HA.  This is particularly interesting when
   the FA and HA are owned by different entities.

Route Optimization in Mobile IP
Dave Johnson - CMU

 - Trying to merge IPv4 route optimization with the techniques devised
   for IPv6 mobility.

 - Charlie Perkins would like to perform interoperability testing at
   the FTP connectathon.

......................................................................

II) Dec 11, 1996, 7:30pm -- Mobile IPv6 Issues


Announcements:

There will be a firewall traversal mtg tomorrow morning (Dec 12)
9:00-11:30 in the restaurant on the 1st floor of the Fairmont.
Seating is limited - only those with contributions should attend.

Joel Halpern indicated that we need to indicate why we chose *not* to
use SOCKS for security.

Mobility Support in IPv6
Dave Johnson - CMU
========================

Announcement:  Please submit papers to Dave for:
ACM/IEEE Int'l Conference on Mobile Computing (MobiCom'97)
Sep '97
Budapest, Hungary

1. Changes to latest MIPv6 draft (02):
======================================
 - Binding Ack now sent as a dest option (same as Binding Update).
 - New Binding Request, also sent as a dest option.
 - Options now encoded to cause ICMP from nodes not
   implementing them.
 - ID in Binding Update & Binding Ack now only 32 bits.
 - New intro & overview.

2. Known typos & issues:
========================
 - Binding Ack len is 9 not 8
 - When MN recieves ICMP in response to Binding Update:
   - Stop rexmit Binding Updates (if waiting for ACK), and
   - Remember not to transmit more Binding Updates to that node.

3. Open Issues:
===============

 3.1 Misc:
 ---------
 - A one-time security association is needed between the MN and the
   MN's egress router on a foreign network so that when the MN moves
   to a new foreign network, it will be capable of sending an
   authenticated Binding Update to its previous egress router to have
   it forward all pkts to the new COA.

 - When sending binding updates, the same source addr filtering issues
   in Mobile IPv4 apply to MIPv6.

 3.2 Dynamic HA addr discovery
 -----------------------------
 - Since there are no directed broadcast pkts in ipv6, there is no
   mechanism for a MN to send a Registration Request (Binding Update)
   to an HA on its home network if it does not know the address of an
   HA.  The concern is what happens if an HA's IP addr is dynmically
   changed (i.e. dhcp)?  The MN no longer knows who his HA is and will
   not be able to find a new one.

 - One sugg was to tunnel a directed broadcast to the home network,
   but to whom?  Charlie suggested using an anycast as the outer
   header destination.

 - Dave's proposal is for all HA's on the same subnet to retain a list
   of all other HA's whose advertisements were heard on the link, and
   to indicate any new HA's to the MN in the Ack to the Binding Update
   Registration.

 - Someone in the audience suggested they may have a solution to allow
   directed broadcast in IPv6.

 - Joel suggested that the real problem to solve is what to do when we
   have *no* addr on the home net to send "reg req" to. (i.e. the MN
   was turned off for an extended period of time and all HA's it has
   in its list are no longer valid).

 - The consensus was to tunnel a multicast packet of scope=one to the
   "All Home Agents On This Link" address within an anycast packet of
   the form <home-network-prefix>.<anycast-address>.  The problem is
   to make sure that any router on the home network which receives
   this tunneled packet knows how to emit it on the correct interface.


 3.3 Relay protocol for binding updates
 --------------------------------------
 - Dave mentioned that the replay protection schemes for IPSEC's AH
   might not work for binding updates because AH accepts packets that
   are within a certain "window" of the expected sequence number.
   Mobile IP requires strictly in-order packets for replay protection.

 - Thus, our choices are:
   - do our own replay protection;
   - get IPSEC'S replay protection to let us FORCE in-order acceptance.
   - use IPSEC replay protection *and* our own sequence number.

 3.4 Binding cache refreshing
 ----------------------------
 - Dave raised the issue of how to delete a binding from a CH if it is
   no longer in use.  If the CH always refreshes its binding entry
   before the entry times out, binding will be permanent (as long as
   MN remains reachable).  A better refresh method may be to only
   update if we have data to send and the binding will expire soon.


 3.5 Discussion on source address filtering:
 -------------------------------------------
 - IPv6 routing header is not reversed unless the header is
   authenticated.

 - Joel found out that we *can* encapsulate a multicast within an
   anycast.  This way we could send a subnet-directed broadcast to the
   home network to find an HA.


 3.6 Spec issues
 ---------------
 - Jim Solomon recommended the addition of a MIPv4 vs. MIPv6 section.
   Dave said he would add it.

 - Due to source address filtering, the format of the Binding Update
   packet might need to change, making the source address the COA
   instead of the MN's home address.  Therefore, we MUST put the home
   address wtihin the Binding Update destination option.

 - Use loose or strict routing bits?  Text should be added to say one
   way or the other.  Some say it SHOULD be loose because strict may
   go away.


4. Misc:
========

 - A comment was made that the IP header compression draft was going
   to last call.  Review for MIPv4 & MIPv6 to ensure we need no
   changes.

 - Erik demonstrated a problem with binding caches between to wireless
   MN'S on the same router and the router dies.

 - Charlie presented solution for routing non-IP (IPX) using virtual
   tunneling.  Jim indicated that Tony Li wrote a draft some time ago
   to do this type of operation.

 - Charlie annouced a web site for a newly formed "mobile ad-hoc
   networking" group.  He hopes to have a BOF at Memphis IETF.  URL:
   http://tonnant.itd.nrl.navy.mil/manet_home.html

 - Charlie also proposed two new ICMP type msgs to allow the MN to
   learn why a firewall would not route its packet.  This would enable
   the MN to learn when the use of a reverse tunnel is necessary.  The
   two new ICMP messages are:

   - ICMP "wrong outgoing source address" (ingress routing).  Joel
     pointed out the problem with the router sending an ICMP message
     to an address which is invalid for that interface.

   - ICMP "wrong incoming source address".


5. 8+8 Mobility proposal
========================

 - Proposes a different method of addressing and binding which
   eliminates HA to MN tunnelling.  The mobileip wg will wait to see
   if this proposal is seriously considered in the ipngwg before
   worrying too much about it.


6. More Misc.
=============

 - Dave Johnson demonstrated a routing loop which could occur when the
   MN makes a loop when roaming due to the MN sending Binding Updates
   to its previous egress router.

 - Jim asked for implementation experience - none offered.