A Mobile-IP Implementation based on rfc 2002 -------------------------------------------- Summer '98 Release for FreeBSD 2.2.1. Jim Binkley, John McHugh, Sarah Mocas, David Reeder, Bill Trost, Zhong Chen, Bjorn Chambless, Jennifer Ye Portland State University Computer Science Dept. - Summer, 1998 email: mobileip@guinness.cs.pdx.edu -------------------------------------------------------------- Introduction Please see the file README for the main documentation. This README.summer98 file only covers new features in the latest release. Thus README.summer98 is a supplement. README discusses how to install the basic release. In general the work here represents student work done on the Secure Mobile Network project by M.S. students at PSU. This release represents a feature upgrade for our release of summer 97. It mostly adds only functionality, some of it experimental, to the previous integrated IPSEC-Mobile-IP system. A lot of the work here uses architectural features resident in the code from summer 97 and is built on top of it. The contents of the original README are still important and it should be read first. Then read this README.summer97 for more information. this release is still based on the FreeBSD 2.2.1 kernel, but we hope to make a minor release based on the latest FreeBSD kernel RSN. New features for summer 98 include master degree student work and some features added in late summer 98. The main features which will be discussed briefly here are: 0. an internal improvement in mnd and mipd so that they use the route(4) socket as opposed to route(8) and arp(8) calls. Thus they are much more efficient. We still supply modified route(8) and arp(8) binaries and source, as they can be used to manually setup Virtual Private Network connections along with IPSEC. Given that these improvements are internal, there will be no further documentation on this particular feature. 1. Jennifer Ye implemented a network-layer experimental ad hoc routing protocol called MADRP, for "Multicast Adhoc Demand Routing Protocol". The code is included in mnd and mipd but it is NOT compiled in by default (#ifdef MADRP). Functionally MADRP assumes that the previous ADHOC mode (ADHOC version ARP) is used for link-layer mobile communication. It allows Mobile Nodes that are separate from either Mobile-IP agents or other Mobile Nodes to set up host routes between them; i.e., packets are automatically forwarded across Mobile Nodes themselves. Connectivity between MNs and agents is also established; hence if a Mobile Node is separated from the wired infrastructure by other Mobile Nodes it can still find a routing path to Mobile-IP agents (and its own HA). See the MADRP section below for more information. 2. Zhong Chen has added DHCP capability for Mobile Nodes which may or may not be combined with the pre-existing IPSEC tunnel functionality between Mobile Node and Home Agent. DHCP is basically viewed as another link mode. We assume that DHCP servers are available on a link (and that ARP is used ...), thus Foreign Agents are not available on a link. This feature applies only to the mnd daemon. See the DHCP section below for more information. 3. IPSEC integration with Mobile-IP code. There are two features worthy of note. IPSEC AH and ESP may be used simultaneously for the route binding. Also IPSEC AH may be used with manual keys between Home Agents and "same security domain" Foreign Agents; i.e., instead of IPIP tunnels between HAs and FAs, one may use IPAHIP tunnels. There will be a brief discussion of this feature set below. 4. Bjorn Chambless (PSU CS/MS student) has implemented and released HARP, the Home Agent Redundancy Protocol. HARP allows for Mobile-IP Home Agent redundancy; i.e., one can have TWO Home Agents without the rest of the Mobile-IP systems (MNs/FAs) having to change or being aware of the co-HAs. The co-HAs cause no changes in the MIP protocol itself. They use the HARP protocol between themselves to communicate MIP routing information (where MNs are registered). See the HARP section below for a high level description, and configuration information. Please note that for the supplied binaries and the source in mip.src, HARP, and DHCP are compiled in and turned on. The source for MADRP is included, but MADRP is experimental and the Makefile in mip.src has MADRP left out at this point. The MADRP code is not in the supplied binaries but of course they can be recompiled if you wish to experiment with it. It should be possible to modify the Makefile and leave those #ifdef values in/out to produce binaries that have or do not have that functionality. Minimally we strongly urge that HARP and DHCP be left in the feature sets however. MADRP is interesting but is experimental. ---------------------------------------------------------------- 1. MADRP - Jennifer Ye (programmer) and Xu Hao (designer) MADRP is an experimental high-level ad hoc routing protocol. It may be viewed as an Interior Gateway Protocol. It allows Mobile Nodes to route packets over other Mobile Nodes which act as routers. It is very roughly based on or inspired by work done by Dave Johnson and Scott Corson in the distant past. MADRP contains certain design elements though of interest that include: 1. integration with Mobile-IP; i.e., Mobile Nodes that are more than one hop away from an agent can still use Mobile-IP to retain Internet connectivity. 2. the subnet-less nature of the previous link-layer ad hoc mechanism is still used; i.e., cooperating MNs do not assume they can only talk to other MNs of the same subnet. 3. MADRP hosts set up end to end host routes to other hosts they are talking to. Given that our IPSEC implementation is tied to routes in the routing table, this allows us to do end to end IPSEC between two participating laptops in so-called "tunnel mode". Given that the Mobile Nodes are not gateways, such IPSEC tunnels are not subject to proposed plaintext attacks. For good or bad, all of the packets sent between the hosts would be covered by the same IPSEC security association. This is an interesting but experimental notion. Note that MADRP assumes our link-level ad hoc scheme. It does not work with ARP. By definition, it uses any kernel routing mechanism involved with the link-level ad hoc scheme on which it is built. The protocol itself does not assume simple ad hoc or ARP, but the implementation certainly does. Functionally MADRP uses UDP port 1066 and 224.0.0.11 as a multicast address. Given MADRP's experimental nature, these numbers are not cast in concrete and can be changed if desired (but at this time they are compiled in). See mip.src/sr_config.c for these and other configurable constants. The protocol is actually fairly simple. If the kernel discovers that a route to a particular host does not exist (or mnd decides that a MADRP discovery protocol packet should be sent), e.g., due to a kernel route(4) socket upcall to the daemon ... mnd will send a MADRP multicast discovery packet. Participating hosts or agents may or may not forward the query decrementing the ttl (this depends on the limited flooding algorithm). Agents do not forward the query on internal (wired infrastructure) ports, but do forward it on wireless ports where the ad hoc link layer is used. The correct ip destination returns an answer (which may be multicast or unicast depending on configuration). Agents always return an answer (and thus in a sense act as a possible default route). Intermediate routing systems (other Mobile Nodes) setup host routes themselves typically back to the sender as MADRP queries (or multicast replies) are sent out and forwarded. As a result a routing path is setup. One interesting trick is that Mobile-IP works simply because the mnd tries to find a host route to its Home Agent. If any agent can be found (possibly across intermediate mobile nodes), Internet access will thus be available. Another trick relies on TCP (the protocol) as an optimization. If TCP discovers that a round-trip "host route" fails due to the other end failing to return TCP ACKs, mnd is notified, and it will reinitiate the end host discovery mechanism. MADRP at this time lacks much needed configuration and runtime status information. Further MADRP documentation can be found in three places. The original ASCII specification as written by Xu Hao can be found in the papers directory. Jennifer Ye wrote a term paper on the implementation. Various descriptions of the protocol can be found in our project reports at http://www.cs.pdx.edu/research/SMN. MADRP can only be compiled in or compiled out in the current implementation. See mip.src/Makefile and insert #ifdef MADRP as appropriate and recompile everything to add it. ---------------------------------------------------------------- 2. DHCP/IPSEC - Zhong Chen The DHCP mode causes mnd (the Mobile Node daemon) to be DHCP aware as well as Foreign Agent aware. This functionality only affects the Mobile Node, not Agents. DHCP is compiled in to the source base (#ifdef DHCP), but is not configured on by default. One and only one configuration line is necessary in /etc/mnd.conf in order to make mnd DHCP-aware. dhcp mvif0 [lease-period-in-seconds] The mvif device is used for "pushing" the Mobile-IP fixed node address (the home IP address) when a mnd system is resident at a DHCP server link. The lease-period-in-seconds value is optional. It defaults to 10 seconds. The MN will use the renewal period to try and detect movement; i.e., it will ask any local DHCP server for an address, and if the address is different, it will assume movement. A period of 60 seconds might be reasonable for casual mobility. Note that we assume that Foreign Agents are slightly better than DHCP-servers; i.e., if we don't have a FA, we will try and use DHCP (MN will make a DHCP query). We should point out that the ISOC DHCP implementation was used on the servers and was of assistance in the creation of our DHCP code. In addition to stock DHCP usage, mnd can also be IPSEC aware and tunnel packets to/from the Home Agent. When at a non-home (foreign) subnet, the security policy as specified with the mnd.conf line: ipsec_mn bypass_fa ... etc can be used; i.e., the MN will send IPSEC'ified packets to the Home Agent. The external IP header will use the DHCP local address as its IP source. The internal IP datagram will be shielded with ESP, hence the MN can send packets to/from home sans IP spoof filtering problems at nearby routers. HA IPSEC functionality is of course unchanged from the Foreign Agent (non-DHCP) IPSEC case). As a security note, it should be pointed out that this mechanism solves one of the so-called Mobile-IP firewall security problems; i.e., it allows Mobile-IP to work in the presence of ip-spoof filtering firewalls. It does *not* of course solve the problem of protecting ones own security enclave from alien and presumed hostile mobile nodes. ---------------------------------------------------------------- 3. New IPSEC integration functionality (David Reeder) 3.1 two IPSEC bindings at once (combined AH/ESP) Either route(8) or mnd may use combined AH+ESP headers (note: we have no support for the newer form of ESP, just the older separate forms) as opposed to (the older) ESP by itself. For use with route(8), please see the IPSEC-related modified man page on route (in our distribution tree, this is found at ../sbin/route/route.8). nroff -man route.8 | more. Note that route add can be used to add the first IPSEC association, and route change is used to add a second IPSEC association. One must a priori have two IPSEC associations (one for ESP and one for AH) in /etc/keys which have been loaded with keyadmin(8), and then one uses route(8) to tell the kernel to bind the IPSEC associations to the routes in the routing table. Packets sent through the routes will thus have the IPSEC modifications made to them. This functionality may also be used with our Mobile-IP daemons. As before, one must first setup /etc/keys and use keyadmin(8) to load IPSEC associations into the kernel. The routing daemons (mipd) will then use this information when routes are setup or torn down automatically as Mobile-IP is used. See the mnd.conf(5) man page for more details. The basic idea is that e.g., with the mnd.conf configuration file line: ipsec_mn at_ha ha_ip_address ipsec-protocol SPI-pairs [off] instead of using ONLY esp, ah for the ipsec-protocol, one can also specify ah+esp for the combined form. An additional SPI-pair is needed here in the configuration line. See the mnd.conf(5) man page for mnd functionality. See mipd.conf(5) for the related HA-side functionality (again ah+esp is used). Note that functionality may also be used with ipsec tunnels. Please see the mnd.conf and mipd.conf man pages for more details. 3.2 IPSEC HA/FA tunnels We have worked out the kernel details so that it was possible to combine IPIP tunnels directly with IPSEC attributes. This can be done manually with the route(8) command. We also integrated this functionality directly with the mipd Mobile-IP daemon. Of course, we still assume manual IPSEC keys (although there is no reason a more general policy description could exist that would allow ISAKMP (IKE) to automatically setup tunnels). The basic idea is that if a priori configuration exists in both (IPSEC spis) /etc/keys loaded at boot, and mipd.conf (control for MIPD), then mipd will install per Mobile Node IPIP tunnels so that a AH security association exists between a Home Agent and a Foreign Agent. As a security PRO, this means that Foreign Agents can be configured to 1. not accept plain IPIP packets and hence only accept IPAHIP packets from hosts with which they share a security assocation. (see the sysctl net.inet.ip.ipsecforwarding switch description in the README file) As a criticism, in truth, this feature sadly needs ISAKMP and some one to centralize key storage in order to make the IPAHIP tunnels dynamic in terms of configuration. With only manual keys and a few agents, there are too many manual keys to keep straight. We assume that the net.inet.ip.ipsecforwarding switch is used at agents to prevent the acceptance of plain IPIP packets. 2. Configure IPAHIP tunnels as opposed to IPIP tunnels between agents (or HA/MNs acting as their own FAs). In order to configure a "ipsec_tun" tunnel which is a one way tunnel between a HA and a FA, one does the following: 2.1 add an AH association in /etc/keys . in both HA and FA files add a one-way AH association between the two in /etc/keys and of course make sure that is loaded with keyadmin(8). 2.2 /etc/mipd.conf ipsec_tun switch In mipd.conf files make sure that relevant ipsec_tun ha (at the HA) and ipsec_tun fa (at the FA) lines exist so that mipd knows to use the security association. As a consequence IPIP packets will be replaced with IPAHIP packets between the HA and FA. See mipd.conf(5) for more details ------------------------------------------------------------- 4. HARP - Bjorn Chambless. Overview: The Home Agent Redundancy Protocol allows Mobile IP to maintain Mobile Node (MN) connectivity in the event that a Home Agent (HA) fails or some forms of network partition appear between the Home Agent and the current care-of-address of a MN. The protocol operates by extending Mobile IP so as to allow multiple Home Agents to service a given set of MNs, thereby ensuring that the loss of a single HA does not lead to loss of network connectivity. Cooperating Home Agents share registration information so that either HA may forward packets at any time to a Mobile Node's current care-of-address at any time. The protocol is fairly simple. HARP uses three kinds of messages: 1. HARP registration forwarding. A Mobile Node registration at either HARP co-HA is internally forwarded as a HARP message from one co-HA to the other. As a result, they setup tunnels as necessary in parallel so that any received datagrams for the MN will be forwarded from either co-HA. This mechanism uses the HARP UDP port 1588 (look for HARP-PORT in mipconfig.h). 2. a boot time, HARP uses a TCP connection to exchange any internal MIP registration info with the other co-HA. This is an optimization and servers to speed up registration if one co-HA reboots due a local failure. 3. a HARP internal "ping" is used. Periodically one HARP co-HA will use the UDP HARP channel to determine if the other co-HA exists. Actions taken on failure may include: 1. a page of a local network admin OR 2. bringing up a local interface to act as a HOME for MNs if desired. HARP is viewed as an Interior Gateway Protocol that ideally acts in conjunction with another IGP like OSPF or RIPv2. It may be used as static routes. Topologically we view co-HAs architected as follows: Internet | OSPF router1 ------------- OSPF router2 | exterior link | exterior link HA1 HA2 | mobile-IP subnet ....... | co-HAs must have two (possibly virtual) interfaces. E.g., one could use an Ethernet and wireless interface. Or one might use a single ethernet i/f with two ip addresses. We assume that the co-HAs somehow share ONE Mobile-IP subnet address, but that they also MUST have a separate unique IP address. Calls these two ip addresses: 1. the exterior (unique) IP address 2. the MIP (shared) IP address From the IGP (exterior) point of view, the co-HAs can function as routers. They simply somehow inject the existance of the MIP subnet into the local IGP routing domain. In our implementation, we currently lack a dynamic routing daemon on FreeBSD (although we have some experimental routed code included that is insufficiently tested, but does show signs of co-existance with mipd). We recommend that the "real" router/s simply use static routes for now. If one co-HA fails, the static route path can be changed. Ideally however the co-HAs would be part of an OSPF system and Mobile-IP traffic could be load-balanced as appropriate through the routing infrastructure. From the Mobile-IP subnet point of view, one has a number of topological possibilities. For example, one must act whether the interior Mobile-IP subnet (home) is partitioned or not. We recommend a partitioned subnet (ideal for wireless), but the system should work with a normal non-partitioned link (e.g., with ethernet). Keep in mind that the Mobile-IP subnet IP at the Home Agents (for the HAs themselves) must be the same. As a result, Mobile-IP does not change as a protocol and the MNs do not need to know about "two" HAs. The internal Mobile-IP link topology is important. Ironically as HARP is an IGP, we *could* claim that how we deal with that is not important (it has little to do with HARP as a routing protocol). However it is important in practical terms. Thus we support two possible internal Mobile-IP link topologies. 1. partitioned (the HAs can NOT reach each other on the Mobile-IP link) 2. non-partitioned (the HAs can reach each other on the Mobile-IP link) At PSU we have two co-HAs deployed. Each has a wireless and ethernet interface. The Mobile-IP subnet is bound to the wireless interface. The co-HAs can NOT hear each other on the wireless interfaces. Other topologies are possible (e.g., two ethernet i/fs per HA or one ethernet i/f with two ip addresses). Setup: This implementation of HARP only allows for the deployment of two Home Agents. ie. A co-HA pair. HA locations should be chosen so as to be as far separated as possible, both geographically and in terms of network topology. This is in order to avoid the loss of both Home Agents due to some localized disturbance like a power loss or a local router outage. This may not be possible, but it is good if it can be done. At this point in time, we have experimented with a modified BSD routed on freebsd to make it coexist with mipd. This routing daemon would allow the FreeBSD systems to be part of a dynamic (but RIPv2) IGP infrastructure. Thus the infrastructure itself could determine if the interior routing path to the Mobile-IP subnet had gone down. The experimental version of routed can be found in the usr.sbin/routed directory. We verified that it could work in conjunction with mipd using RIPv2. We do not feel that routed has been tested enough to be seriously deployed however and do not have the resources at the moment to do more testing. Those wanting to actually use HARP can resort to static routes in local routers (e.g., Ciscos). We have tested changing static routes in neighborhood routers to make sure that HARP works; i.e., we take down one co-HA host to simulate loss of a Home Agent, and then change the Mobile-IP subnet route in a nearby Cisco by hand to point out the other HARP system to make sure HARP works. Although this is not the best model in terms of dynamic routing, it does provide proof of concept. Re HARP configuration, first of all note that (almost) exactly the same mipd.conf file must appear on both HAs; i.e., /etc/mipd.conf. In general, key lines (e.g., for mip/mns) will most likely be the same. Of course other lines like coas/co-ha ip will be different. There are three HARP config lines that can appear in /etc/mipd.conf 1. coha ... REQUIRED 2. harp_tunnel ... (optional) 3. harp2_arp_disable ... (optional) (In addition there is an extra possible HARP protocol authentication line, which we will briefly discuss below.) 1. coha ip_address Designates the IP address of the OTHER home agent in a co-HA pair. This line must be present for HARP to function. It must be present in both co-HAs and the IP address must be the "interior" (non-Mobile-IP) address that is unique per co-HA. 2. harp_tunnel < yes | no > This configuration line applies to one of the two possible Mobile-IP link topologies. By default "no" is used (i.e., it is off). If a partitioned Mobile-IP link is desired, and you want Mobile Nodes to be able to be present at both Homes, set this value to "yes". As a result, the co-HA receiving packets for a MN present at the other co-HA will tunnels those packets to the other co-HA. 3. harp2_arp_disable This line should be used only when one desires to use a non-partitioned Mobile-IP home link. If used, harp_tunnel should be set to no (the default). It should only be set at one co-HA (not both). It causes that co-HA to dynamically enable ARP on the interface in question if and only if by using the HARP ping, that co-HA determines that the other co-HA is down. Hence confusion due to ARP and shared ip addresses will not occur. HARP protocol authentication: In terms of the implementation there are two possible mechanisms for HA to HA HARP protocol authentication. IPSEC AH at the application level may be used and in fact we assume that is available. mipd will simply try and use it with the current codebase. This means that an IPSEC/AH association must exist between the two Home Agent systems. An optional mechanism that is like the Mobile-IP md5 authentication mechanism may be compiled into the code (this is not discussed in the HARP IETF draft). In order to use this, mipd must be recompiled. This form of authentication is compiled in with #ifdef MIPSEC for HARP. if IPSEC is not defined, then MIPSEC is compiled in by default and the haha_key item is used. haha_key xxx.xxx.xxx.xxx md5 SPI Key Again, haha_key must be compiled in and is only used as a stopgap so that some form of authentication always exists. Additional documentation on HARP can be found in the ./papers directory. There is a student term paper written by Bjorn and an Internet draft authored by Bjorn and Jim Binkley. Final configuration note: In our current implementation for HARP in /etc/mipd.conf we actually use: co_ha harp_tunnel yes This is because our agents are configured with two real physical interfaces (ethernet and wireless). Thus it is possible for our Mobile Nodes to be home in two places as well as take advantage of the redundancy provided by HARP. ----------------------------------------------------------------- In Conclusion: Again see the README for the main installation details. This release only adds functionality (and fixes a bug or two). As a reminder, see our web page: http://www.cs.pdx.edu/research/SMN for DARPA reports, which document the protocol and architectural aspects of a lot of this work. In general project documentation consists of: 1. README* in this release 2. papers/ ... various papers generated at various times during the project that have bearing on particular parts of the project. Some of them are simply student reports and others are rough draft of either IETF documents or academic papers. 3. man/ ... man pages. Note that ps versions are supplied as well. 4. http://www.cs.pdx.edu/research/SMN