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 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 .. 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.