home *** CD-ROM | disk | FTP | other *** search
/ ftp.ee.pdx.edu / 2014.02.ftp.ee.pdx.edu.tar / ftp.ee.pdx.edu / pub / mobile / mip-summer98.README < prev    next >
Text File  |  1998-08-05  |  25KB  |  555 lines
  1.  
  2. A Mobile-IP Implementation based on rfc 2002
  3. --------------------------------------------
  4.  
  5. Summer '98 Release for FreeBSD 2.2.1.
  6.  
  7.             Jim Binkley, 
  8.             John McHugh,
  9.             Sarah Mocas,
  10.             David Reeder, 
  11.             Bill Trost,
  12.             Zhong Chen, 
  13.             Bjorn Chambless, 
  14.             Jennifer Ye
  15.  
  16.             Portland State University
  17.             Computer Science Dept.  - Summer, 1998
  18.  
  19.             email: mobileip@guinness.cs.pdx.edu
  20.  
  21. --------------------------------------------------------------
  22. Introduction
  23.  
  24. Please see the file README for the main documentation.  This 
  25. README.summer98 file only covers new features in the latest release.  
  26. Thus README.summer98 is a supplement.  README discusses how
  27. to install the basic release.
  28.  
  29. In general the work here represents student work done on
  30. the Secure Mobile Network project by M.S. students at PSU.
  31. This release represents a feature upgrade for our release of summer 97.
  32. It mostly adds only functionality, some of it experimental,
  33. to the previous integrated IPSEC-Mobile-IP system.
  34. A lot of the work here uses architectural features resident
  35. in the code from summer 97 and is built on top of it.
  36.  
  37. The contents of the original README are still important
  38. and it should be read first.  Then read this README.summer97
  39. for more information.  this release is still based on the 
  40. FreeBSD 2.2.1 kernel, but we hope to make a minor release
  41. based on the latest FreeBSD kernel RSN.
  42.  
  43. New features for summer 98 include master degree student 
  44. work and some features added in late summer 98.  The main
  45. features which will be discussed briefly here are:
  46.  
  47. 0. an internal improvement in mnd and mipd so that they use
  48. the route(4) socket as opposed to route(8) and arp(8) calls.
  49. Thus they are much more efficient.  We still supply modified 
  50. route(8) and arp(8) binaries and source, as they can be used to 
  51. manually setup Virtual Private Network connections along with IPSEC.  
  52. Given that these improvements are internal, there will be no further 
  53. documentation on this particular feature.
  54.  
  55. 1. Jennifer Ye implemented a network-layer experimental ad hoc
  56. routing protocol called MADRP, for "Multicast Adhoc Demand Routing
  57. Protocol".  The code is included in mnd and mipd but it is NOT
  58. compiled in by default (#ifdef MADRP).   Functionally
  59. MADRP assumes that the previous ADHOC mode (ADHOC version ARP)
  60. is used for link-layer mobile communication.  It allows Mobile
  61. Nodes that are separate from either Mobile-IP agents or other
  62. Mobile Nodes to set up host routes between them; i.e., packets
  63. are automatically forwarded across Mobile Nodes themselves.  
  64. Connectivity between MNs and agents is also established; hence
  65. if a Mobile Node is separated from the wired infrastructure
  66. by other Mobile Nodes it can still find a routing path to
  67. Mobile-IP agents (and its own HA).  See the MADRP section below 
  68. for more information.
  69.  
  70. 2. Zhong Chen has added DHCP capability for Mobile Nodes which may
  71. or may not be combined with the pre-existing IPSEC tunnel functionality
  72. between Mobile Node and Home Agent.  DHCP is basically viewed as
  73. another link mode.  We assume that DHCP servers are available on
  74. a link (and that ARP is used ...), thus Foreign Agents are not
  75. available on a link.  This feature applies only to the mnd daemon.
  76. See the DHCP section below for more information.
  77.  
  78. 3. IPSEC integration with Mobile-IP code.  There are two
  79. features worthy of note.  IPSEC AH and ESP may be used simultaneously
  80. for the route binding.  Also IPSEC AH may be used with manual keys
  81. between Home Agents and "same security domain" Foreign Agents; i.e.,
  82. instead of IPIP tunnels between HAs and FAs, one may use IPAHIP
  83. tunnels.  There will be a brief discussion of this feature set
  84. below.
  85.  
  86. 4. Bjorn Chambless (PSU CS/MS student) has implemented and released
  87. HARP, the Home Agent Redundancy Protocol.  HARP allows for Mobile-IP
  88. Home Agent redundancy; i.e., one can have TWO Home Agents without
  89. the rest of the Mobile-IP systems (MNs/FAs) having to change or
  90. being aware of the co-HAs.  The co-HAs cause no changes in the MIP
  91. protocol itself.  They use the HARP protocol between themselves to
  92. communicate MIP routing information (where MNs are registered).
  93. See the HARP section below for a high level description, and
  94. configuration information.
  95.  
  96. Please note that for the supplied binaries and the source
  97. in mip.src, HARP, and DHCP are compiled in and turned on.
  98. The source for MADRP is included, but MADRP is experimental
  99. and the Makefile in mip.src has MADRP left out at this point.
  100. The MADRP code is not in the supplied binaries but of course
  101. they can be recompiled if you wish to experiment with it.
  102.  
  103. It should be possible to modify the Makefile and leave those
  104. #ifdef values in/out to produce binaries that have or do not have 
  105. that functionality.  Minimally we strongly urge that HARP and DHCP
  106. be left in the feature sets however.  MADRP is interesting but
  107. is experimental.
  108.  
  109. ---------------------------------------------------------------- 
  110. 1. MADRP - Jennifer Ye (programmer) and Xu Hao (designer)
  111.  
  112. MADRP is an experimental high-level ad hoc routing protocol.
  113. It may be viewed as an Interior Gateway Protocol.  It allows 
  114. Mobile Nodes to route packets over other Mobile Nodes
  115. which act as routers.  It is very roughly based on or inspired
  116. by work done by Dave Johnson and Scott Corson in the distant past.
  117. MADRP contains certain design elements though of interest that include:
  118.  
  119.     1. integration with Mobile-IP; i.e., Mobile Nodes that
  120.     are more than one hop away from an agent can still use
  121.     Mobile-IP to retain Internet connectivity.
  122.  
  123.     2. the subnet-less nature of the previous link-layer
  124.     ad hoc mechanism is still used; i.e., cooperating MNs
  125.     do not assume they can only talk to other MNs of the same
  126.     subnet.  
  127.  
  128.     3. MADRP hosts set up end to end host routes
  129.     to other hosts they are talking to.  Given that our IPSEC
  130.     implementation is tied to routes in the routing table, this
  131.     allows us to do end to end IPSEC between two participating
  132.     laptops in so-called "tunnel mode".
  133.  
  134.     Given that the Mobile Nodes are not gateways, such IPSEC
  135.     tunnels are not subject to proposed plaintext attacks.
  136.     For good or bad, all of the packets sent between the hosts
  137.     would be covered by the same IPSEC security association.
  138.     This is an interesting but experimental notion.
  139.  
  140. Note that MADRP assumes our link-level ad hoc scheme. It does not
  141. work with ARP.  By definition, it uses any kernel routing mechanism
  142. involved with the link-level ad hoc scheme on which it is built.
  143. The protocol itself does not assume simple ad hoc or ARP, but the
  144. implementation certainly does.
  145.  
  146. Functionally MADRP uses UDP port 1066 and 224.0.0.11 as a multicast address.
  147. Given MADRP's experimental nature, these numbers are not cast in concrete
  148. and can be changed if desired (but at this time they are compiled in).
  149. See mip.src/sr_config.c for these and other configurable constants.
  150.  
  151. The protocol is actually fairly simple.  If the kernel discovers
  152. that a route to a particular host does not exist (or mnd decides
  153. that a MADRP discovery protocol packet should be sent), e.g., due
  154. to a kernel route(4) socket upcall to the daemon ... mnd will send
  155. a MADRP multicast discovery packet.  Participating hosts or agents
  156. may or may not forward the query decrementing the ttl (this depends 
  157. on the limited flooding algorithm).  Agents do not forward the query 
  158. on internal (wired infrastructure) ports, but do forward it on wireless
  159. ports where the ad hoc link layer is used.  The correct ip destination 
  160. returns an answer (which may be multicast or unicast depending on 
  161. configuration).  Agents always return an answer (and thus in a sense 
  162. act as a possible default route).  Intermediate routing systems 
  163. (other Mobile Nodes) setup host routes themselves typically
  164. back to the sender as MADRP queries (or multicast replies) are sent out 
  165. and forwarded.  As a result a routing path is setup.   
  166.  
  167. One interesting trick is that Mobile-IP works simply because the
  168. mnd tries to find a host route to its Home Agent.  If any agent
  169. can be found (possibly across intermediate mobile nodes), Internet
  170. access will thus be available.  Another trick relies on TCP (the
  171. protocol) as an optimization.  If TCP discovers that a round-trip
  172. "host route" fails due to the other end failing to return TCP ACKs,
  173. mnd is notified, and it will reinitiate the end host discovery
  174. mechanism.
  175.  
  176. MADRP at this time lacks much needed configuration and runtime status
  177. information.  
  178.  
  179. Further MADRP documentation can be found in three places.  
  180. The original ASCII specification as written by Xu Hao can
  181. be found in the papers directory.   Jennifer Ye wrote a term
  182. paper on the implementation.  Various descriptions of the protocol
  183. can be found in our project reports at http://www.cs.pdx.edu/research/SMN.
  184.  
  185. MADRP can only be compiled in or compiled out in the current implementation.
  186. See mip.src/Makefile and insert #ifdef MADRP as appropriate
  187. and recompile everything to add it.
  188.  
  189. ---------------------------------------------------------------- 
  190. 2. DHCP/IPSEC - Zhong Chen
  191.  
  192. The DHCP mode causes mnd (the Mobile Node daemon) to be DHCP
  193. aware as well as Foreign Agent aware.  This functionality
  194. only affects the Mobile Node, not Agents.  DHCP
  195. is compiled in to the source base (#ifdef DHCP), but is not 
  196. configured on by default.  One and only one configuration line is 
  197. necessary in /etc/mnd.conf in order to make mnd DHCP-aware.  
  198.  
  199. dhcp mvif0 [lease-period-in-seconds]
  200.  
  201. The mvif device is used for "pushing" the Mobile-IP fixed 
  202. node address (the home IP address) when a mnd system is resident
  203. at a DHCP server link.  The lease-period-in-seconds
  204. value is optional.  It defaults to 10 seconds.  The MN will use
  205. the renewal period to try and detect movement; i.e., it will
  206. ask any local DHCP server for an address, and if the address 
  207. is different, it will assume movement.  A period of 60 seconds
  208. might be reasonable for casual mobility.  Note that we assume
  209. that Foreign Agents are slightly better than DHCP-servers; i.e.,
  210. if we don't have a FA, we will try and use DHCP (MN will make
  211. a DHCP query).
  212.  
  213. We should point out that the ISOC DHCP implementation was
  214. used on the servers and was of assistance in the creation
  215. of our DHCP code.
  216.  
  217. In addition to stock DHCP usage, mnd can also be IPSEC
  218. aware and tunnel packets to/from the Home Agent.  When at
  219. a non-home (foreign) subnet, the security policy as specified with
  220. the mnd.conf line:
  221.  
  222. ipsec_mn bypass_fa ... etc
  223.  
  224. can be used; i.e., the MN will send IPSEC'ified packets
  225. to the Home Agent.  The external IP header will use the DHCP
  226. local address as its IP source.  The internal IP datagram will
  227. be shielded with ESP, hence the MN can send packets to/from
  228. home sans IP spoof filtering problems at nearby routers.
  229. HA IPSEC functionality is of course unchanged from the
  230. Foreign Agent (non-DHCP) IPSEC case).
  231.  
  232. As a security note, it should be pointed out that this mechanism
  233. solves one of the so-called Mobile-IP firewall security problems;
  234. i.e., it allows Mobile-IP to work in the presence of ip-spoof
  235. filtering firewalls.  It does *not* of course solve the problem
  236. of protecting ones own security enclave from alien and presumed
  237. hostile mobile nodes.
  238.  
  239. ---------------------------------------------------------------- 
  240. 3. New IPSEC integration functionality (David Reeder)
  241.  
  242. 3.1 two IPSEC bindings at once (combined AH/ESP)
  243.  
  244. Either route(8) or mnd may use combined AH+ESP headers 
  245. (note: we have no support for the newer form of ESP, just the older 
  246. separate forms) as opposed to (the older) ESP by itself.
  247. For use with route(8), please see the IPSEC-related
  248. modified man page on route (in our distribution tree, this
  249. is found at ../sbin/route/route.8). nroff -man route.8 | more.
  250. Note that route add can be used to add the first IPSEC association,
  251. and route change is used to add a second IPSEC association.  
  252. One must a priori have two IPSEC associations (one for ESP
  253. and one for AH) in /etc/keys which have been loaded with keyadmin(8),
  254. and then one uses route(8) to tell the kernel to bind the IPSEC
  255. associations to the routes in the routing table.  Packets sent
  256. through the routes will thus have the IPSEC modifications made to them.
  257.  
  258. This functionality may also be used with our Mobile-IP daemons.  
  259. As before, one must first setup /etc/keys and use keyadmin(8) to
  260. load IPSEC associations into the kernel.  The routing daemons (mipd)
  261. will then use this information when routes are setup or torn down
  262. automatically as Mobile-IP is used.
  263.  
  264. See the mnd.conf(5) man page for more details.  The basic idea
  265. is that e.g., with the mnd.conf configuration file line:
  266.  
  267. ipsec_mn at_ha ha_ip_address ipsec-protocol SPI-pairs [off]
  268.  
  269. instead of using ONLY esp, ah for the ipsec-protocol, one can
  270. also specify ah+esp for the combined form.  An additional SPI-pair
  271. is needed here in the configuration line.  See the mnd.conf(5)
  272. man page for mnd functionality.  See mipd.conf(5) for the related
  273. HA-side functionality (again ah+esp is used).  Note that functionality
  274. may also be used with ipsec tunnels.  Please see the mnd.conf
  275. and mipd.conf man pages for more details.
  276.  
  277. 3.2 IPSEC HA/FA tunnels
  278.  
  279. We have worked out the kernel details so that it was possible to
  280. combine IPIP tunnels directly with IPSEC attributes.   This
  281. can be done manually with the route(8) command.  We also
  282. integrated this functionality directly with the mipd Mobile-IP
  283. daemon.  Of course, we still assume manual IPSEC keys (although
  284. there is no reason a more general policy description could exist
  285. that would allow ISAKMP (IKE) to automatically setup tunnels).  The basic
  286. idea is that if a priori configuration exists in both 
  287. (IPSEC spis) /etc/keys loaded at boot, and mipd.conf (control
  288. for MIPD), then mipd will install per Mobile Node IPIP tunnels
  289. so that a AH security association exists between a Home Agent
  290. and a Foreign Agent.  As a security PRO, this means that Foreign Agents
  291. can be configured to 
  292.     1. not accept plain IPIP packets and hence only
  293. accept IPAHIP packets from hosts with which they share a security assocation.
  294. (see the sysctl net.inet.ip.ipsecforwarding switch description in the README file) 
  295.  
  296. As a criticism, in truth, this feature sadly needs ISAKMP and 
  297. some one to centralize key storage in order to make the
  298. IPAHIP tunnels dynamic in terms of configuration.  With only manual
  299. keys and a few agents, there are too many manual keys to keep straight.
  300.  
  301. We assume that the net.inet.ip.ipsecforwarding switch is used at
  302. agents to prevent the acceptance of plain IPIP packets.  
  303.  
  304.     2. Configure IPAHIP tunnels as opposed to IPIP tunnels
  305.     between agents (or HA/MNs acting as their own FAs).
  306.  
  307.     In order to configure a "ipsec_tun" tunnel which is a one 
  308.     way tunnel between a HA and a FA, one does the following:
  309.  
  310.     2.1 add an AH association in /etc/keys . 
  311.     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).
  312.  
  313.     2.2 /etc/mipd.conf ipsec_tun switch
  314.  
  315.     In mipd.conf files make sure that relevant ipsec_tun ha (at the HA)
  316.     and ipsec_tun fa (at the FA) lines exist so that mipd knows to
  317.     use the security association.  As a consequence IPIP packets will
  318.     be replaced with IPAHIP packets between the HA and FA.
  319.     See mipd.conf(5) for more details
  320.  
  321. -------------------------------------------------------------
  322. 4. HARP - Bjorn Chambless.
  323.  
  324. Overview:
  325.  
  326. The Home Agent Redundancy Protocol allows Mobile IP to maintain
  327. Mobile Node (MN) connectivity in the event that a Home Agent (HA)
  328. fails or some forms of network partition appear between the Home
  329. Agent and the current care-of-address of a MN.
  330.  
  331. The protocol operates by extending Mobile IP so as to allow
  332. multiple Home Agents to service a given set of MNs, thereby ensuring 
  333. that the loss of a single HA does not lead to loss of network connectivity. 
  334.  
  335. Cooperating Home Agents share registration information so that either
  336. HA may forward packets at any time to a Mobile Node's current 
  337. care-of-address at any time.  
  338.  
  339. The protocol is fairly simple.  HARP uses three kinds of messages:
  340. 1. HARP registration forwarding.  A Mobile Node registration
  341. at either HARP co-HA is internally forwarded as a HARP message
  342. from one co-HA to the other.  As a result, they setup tunnels
  343. as necessary in parallel so that any received datagrams for the MN
  344. will be forwarded from either co-HA.  This mechanism uses the
  345. HARP UDP port 1588 (look for HARP-PORT in mipconfig.h).
  346.  
  347. 2. a boot time, HARP uses a TCP connection to exchange any
  348. internal MIP registration info with the other co-HA.  This is
  349. an optimization and servers to speed up registration if one
  350. co-HA reboots due a local failure.
  351.  
  352. 3. a HARP internal "ping" is used.  Periodically one HARP
  353. co-HA will use the UDP HARP channel to determine if the other
  354. co-HA exists.  Actions taken on failure may include:
  355.     1. a page of a local network admin OR
  356.     2. bringing up a local interface to act as a HOME
  357.     for MNs if desired.
  358.  
  359.  
  360. HARP is viewed as an Interior Gateway Protocol that ideally
  361. acts in conjunction with another IGP like OSPF or RIPv2.  It
  362. may be used as static routes.  Topologically we view co-HAs
  363. architected as follows:
  364.  
  365.  
  366. Internet
  367. |
  368. OSPF router1 -------------  OSPF router2
  369.   | exterior link             | exterior link
  370. HA1                HA2
  371.   | mobile-IP subnet .......     |  
  372.  
  373. co-HAs must have two (possibly virtual) interfaces.  E.g.,
  374. one could use an Ethernet and wireless interface.  Or one
  375. might use a single ethernet i/f with two ip addresses.
  376. We assume that the co-HAs somehow share ONE Mobile-IP subnet
  377. address, but that they also MUST have a separate unique IP
  378. address.  Calls these two ip addresses:
  379.  
  380.     1. the exterior (unique) IP address
  381.     2. the MIP (shared) IP address
  382.  
  383. From the IGP (exterior) point of view, the co-HAs can function
  384. as routers.  They simply somehow inject the existance of the MIP
  385. subnet into the local IGP routing domain.  In our implementation,
  386. we currently lack a dynamic routing daemon on FreeBSD (although
  387. we have some experimental routed code included that is insufficiently
  388. tested, but does show signs of co-existance with mipd).  We recommend
  389. that the "real" router/s simply use static routes for now.  If
  390. one co-HA fails, the static route path can be changed.  Ideally
  391. however the co-HAs would be part of an OSPF system and Mobile-IP
  392. traffic could be load-balanced as appropriate through the routing
  393. infrastructure.
  394.  
  395. From the Mobile-IP subnet point of view, one has a number of
  396. topological possibilities.  For example, one must act
  397. whether the interior Mobile-IP subnet (home) is partitioned
  398. or not.  We recommend a partitioned subnet (ideal for wireless),
  399. but the system should work with a normal non-partitioned link
  400. (e.g., with ethernet).  Keep in mind that the Mobile-IP subnet IP
  401. at the Home Agents (for the HAs themselves) must be the same.
  402. As a result, Mobile-IP does not change as a protocol and the MNs
  403. do not need to know about "two" HAs.  
  404.  
  405. The internal Mobile-IP link topology is important.  Ironically
  406. as HARP is an IGP, we *could* claim that how we deal with that
  407. is not important (it has little to do with HARP as a routing
  408. protocol).  However it is important in practical terms.  Thus
  409. we support two possible internal Mobile-IP link topologies.
  410.     1. partitioned (the HAs can NOT reach each other
  411.     on the Mobile-IP link)
  412.     2. non-partitioned (the HAs can reach each other
  413.     on the Mobile-IP link)
  414.  
  415. At PSU we have two co-HAs deployed.  Each has a wireless
  416. and ethernet interface.  The Mobile-IP subnet is bound
  417. to the wireless interface.  The co-HAs can NOT hear each
  418. other on the wireless interfaces.  Other topologies are possible
  419. (e.g., two ethernet i/fs per HA or one ethernet i/f with two
  420. ip addresses).
  421.  
  422. Setup:
  423.  
  424. This implementation of HARP only allows for the deployment of two
  425. Home Agents. ie. A co-HA pair.  
  426.  
  427. HA locations should be chosen so as to be as far separated as
  428. possible, both geographically and in terms of network topology.
  429. This is in order to avoid the loss of both Home Agents due to some
  430. localized disturbance like a power loss or a local router outage.
  431. This may not be possible, but it is good if it can be done.
  432.  
  433. At this point in time, we have experimented with
  434. a modified BSD routed on freebsd to make it coexist with mipd.
  435. This routing daemon would allow the FreeBSD systems to be part
  436. of a dynamic (but RIPv2) IGP infrastructure.  Thus the infrastructure
  437. itself could determine if the interior routing path to the Mobile-IP
  438. subnet had gone down.
  439.  
  440. The experimental version of routed can be found in the usr.sbin/routed
  441. directory.  We verified that it could work in conjunction with
  442. mipd using RIPv2.  We do not feel that routed has been tested enough
  443. to be seriously deployed however and do not have the resources at
  444. the moment to do more testing.
  445.  
  446. Those wanting to actually use HARP can resort to static routes in
  447. local routers (e.g., Ciscos).  We have tested changing static routes
  448. in neighborhood routers to make sure that HARP works; i.e., we take
  449. down one co-HA host to simulate loss of a Home Agent, and then
  450. change the Mobile-IP subnet route in a nearby Cisco by hand to point
  451. out the other HARP system to make sure HARP works.  Although this
  452. is not the best model in terms of dynamic routing, it does provide
  453. proof of concept.
  454.  
  455. Re HARP configuration, first of all note that (almost) exactly the same
  456. mipd.conf file must appear on both HAs; i.e., /etc/mipd.conf.
  457. In general, key lines (e.g., for mip/mns) will most likely be the same.
  458. Of course other lines like coas/co-ha ip will be different.
  459.  
  460. There are three HARP config lines that can appear in /etc/mipd.conf
  461.  
  462. 1. coha ...  REQUIRED
  463. 2. harp_tunnel ... (optional)
  464. 3. harp2_arp_disable ... (optional)
  465.  
  466. (In addition there is an extra possible HARP protocol authentication
  467. line, which we will briefly discuss below.)
  468.  
  469. 1.  coha ip_address 
  470.  
  471. Designates the IP address of the OTHER home
  472. agent in a co-HA pair.   This line must be present for HARP
  473. to function.  It must be present in both co-HAs and the IP
  474. address must be the "interior" (non-Mobile-IP) address that
  475. is unique per co-HA.
  476.  
  477. 2.  harp_tunnel < yes | no >   
  478.  
  479. This configuration line applies to one of the two possible
  480. Mobile-IP link topologies.  By default "no" is used (i.e., it is
  481. off).    If a partitioned Mobile-IP link is desired, and
  482. you want Mobile Nodes to be able to be present at both Homes,
  483. set this value to "yes".  As a result, the co-HA receiving packets
  484. for a MN present at the other co-HA will tunnels those packets
  485. to the other co-HA.
  486.  
  487. 3.  harp2_arp_disable  <if_name>
  488.  
  489. This line should be used only when one desires to use
  490. a non-partitioned Mobile-IP home link.  If used, harp_tunnel
  491. should be set to no (the default).  It should only be set
  492. at one co-HA (not both).  It causes that co-HA to dynamically
  493. enable ARP on the interface in question if and only if by using
  494. the HARP ping, that co-HA determines that the other co-HA is down.
  495. Hence confusion due to ARP and shared ip addresses will not occur.
  496.  
  497. HARP protocol authentication:  
  498.  
  499. In terms of the implementation there are two possible mechanisms
  500. for HA to HA HARP protocol authentication.  IPSEC AH at the application
  501. level may be used and in fact we assume that is available.  mipd
  502. will simply try and use it with the current codebase.  This means
  503. that an IPSEC/AH association must exist between the two Home Agent
  504. systems.  
  505.  
  506. An optional mechanism that is like the Mobile-IP md5 authentication
  507. mechanism may be compiled into the code (this is not discussed
  508. in the HARP IETF draft).   In order to use this, mipd must be recompiled.
  509. This form of authentication is compiled in with #ifdef MIPSEC for HARP.
  510. if IPSEC is not defined, then MIPSEC is compiled in by default
  511. and the haha_key item is used.
  512.  
  513.     haha_key xxx.xxx.xxx.xxx md5 SPI Key
  514.  
  515. Again, haha_key must be compiled in and is only used as a stopgap 
  516. so that some form of authentication always exists.
  517.  
  518. Additional documentation on HARP can be found in the ./papers
  519. directory.  There is a student term paper written by Bjorn 
  520. and an Internet draft authored by Bjorn and Jim Binkley.
  521.  
  522. Final configuration note:
  523.  
  524. In our current implementation for HARP in /etc/mipd.conf we actually use:
  525.  
  526. co_ha <other ip address>
  527. harp_tunnel yes  
  528.  
  529. This is because our agents are configured with two real physical
  530. interfaces (ethernet and wireless).  Thus it is possible for
  531. our Mobile Nodes to be home in two places as well as take advantage
  532. of the redundancy provided by HARP.
  533.  
  534. -----------------------------------------------------------------
  535. In Conclusion:
  536.  
  537. Again see the README for the main installation details.  This
  538. release only adds functionality (and fixes a bug or two).
  539.  
  540. As a reminder, see our web page: http://www.cs.pdx.edu/research/SMN
  541. for DARPA reports, which document the protocol and architectural aspects
  542. of a lot of this work.
  543.  
  544. In general project documentation consists of:
  545.  
  546.         1. README* in this release
  547.         2. papers/ ... various papers generated at various
  548.         times during the project that have bearing on
  549.         particular parts of the project.  Some of them
  550.         are simply student reports and others are rough
  551.         draft of either IETF documents or academic papers.
  552.         3. man/ ... man pages.  Note that ps versions are supplied
  553.         as well.
  554.         4. http://www.cs.pdx.edu/research/SMN
  555.