Internet Engineering Task Force Bjorn Chambless INTERNET DRAFT Portland State University Jim Binkley Oregon Graduate Institute October 27, 1997 HARP - "Home Agent Redundancy Protocol" Status of This Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document presents a protocol called the Home Agent Redundancy Protocol or HARP. HARP is an optional extension to Mobile-IP [RFC- 2002]. Mobile-IP includes the notion of a Home Agent which is a host located on the home IP subnet for Mobile Nodes. Home Agents forward packets to Mobile Nodes that are away from home. Since Mobile Nodes are dependent on the Home Agent for connectivity when away from home, the Home Agent represents a possible single source of failure for the Mobile IP system. HARP is a protocol which allows a pair (or set) of Home Agents to cooperate and share Mobile-IP Mobile Node registration information. If one of the HARP peers should fail, the Mobile-IP system will not necessarily fail, hence HARP introduces Home Agent redundancy into the Mobile-IP system. Mobile Nodes are not aware that HARP exists, so HARP requires no changes to Mobile-IP as a protocol. In this document, we present the HARP architecture and protocol. Chambless & Binkley Expires March 25 1998 [Page 1] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 Table of Contents 1. Introduction 1.1. Design Goals 1.2. Terminology 2. Protocol Overview 2.1 Assumptions 2.2 Protocol Overview 2.3 Redundancy Considerations 3. Mobile-IP Home Link Considerations 3.1 Non-partitioned Home Subnet 3.2 Partitioned Home Subnet 4. HARP Protocol 4.1. Message Types and Functions 4.2. Message Formats 4.2.1. HARP Registration Forward (HARP_FORWARD) 4.2.2. HARP Ping (HARP_PING) 4.2.3. HARP Ping Acknowledge (HARP_ACK) 4.2.4. HARP Registration Dump Request (HARP_DUMP_REQ) 4.2.5. HARP Registration Dump (HARP_REG_DUMP) 5. Security Considerations References......................................................... Contacts........................................................... Chambless & Binkley Expires March 25 1998 [Page 2] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 1. Introduction Mobile-IP is designed to allow a Mobile Node (MN) to change its point of IP subnet attachment in the Internet at the network or IP layer. The MN is always identified by it home IP address regardless of its current network location. Its mobility is not limited by conventional IP network boundaries. The Mobile-IP system consists of Mobile Nodes, and two kinds of agents, known as Home Agents (HA), and Foreign Agents (FA). Home Agents remain "home" and when the Mobile Node is not home, forward packets sent to the conventional IP subnet of the Mobile Node to a possibly distant point of attachment. The remote address is called a Care Of Address (COA), and may be at a Foreign Agent or a co-located Mobile Node. As a Mobile Node travels from one IP link to another, it determines possible COAs and uses the Mobile-IP registration protocol to inform the Home Agent of its current location. The Home Agent then forwards packets addressed to the Mobile Node at its home network to the its current location. In Mobile-IP, as currently specified, a single HA services an MN. The MN is reliant on this Home Agent for its connectivity. Thus the HA represents the possibility of a single point of failure for Mobile-IP. A Home Agent may be responsible for multiple Mobile Nodes on multiple home subnets. The failure of a single HA may then result in the loss of connectivity for numerous Mobile-IP Mobile Nodes located throughout the Internet. Thus the Home Agent and Mobile Node taken together have a shared fate. A Mobile Node cannot afford the loss of its Home Agent. This vulnerability is inconsistent with the fault tolerant nature of the Internet. Additionally redundancy is needed. We have developed the Home Agent Redundancy Protocol (HARP) as an optional extension to Mobile-IP to address this problem. HARP is a simple protocol based on the notion of one or more HARP peers that act as a single shared Home Agent. Each HARP peer is configured with information about its HARP peers and forwards any Mobile-IP registration messages it receives to its peers. HARP peers act in parallel to create or delete tunnels [RFC 2003] to the Mobile Node's remote COA according to the last registration message received. Although we speak of HARP peers as a set, in general, there will probably be only two cooperating systems in the HARP sub-system. There are three major types of messages, 1. HARP TCP DUMP, 2. HARP UDP FORWARD., and 3. HARP UDP PING. At boot, a TCP connection may optionally be made to a remote HARP peer to exchange mobile routing information. At runtime, HARP UDP PING messages are exchanged to determine if remote HARP peers are up. At runtime, HARP UDP FORWARD messages are used to forward Mobile-IP registration messages from the receiving HARP agent to its HARP peers. Chambless & Binkley Expires March 25 1998 [Page 3] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 HARP assumes no changes to Mobile-IP proper; i.e., the existence of one or more HARP peers is kept hidden from Mobile Nodes. Therefore HARP will interoperate with existing Mobile-IP implementations. In routing terms, one may think of the HARP peers as advertising the existence of a common IP subnet into an interior routing domain. Externally, a MN's Mobile-IP authentication message is routed to the nearest ( according to local routing metrics ) HARP peer which, in turn, informs other HARP peers about the MN's location via a HARP FORWARD message. Packets are routed to HARP peer Home Agents via conventional routing, and since each HARP peer maintains Mobile Node COA information, packets are forwarded to the MN. 1.1 Design Goals The Home Agent Redundancy Protocol (HARP) aims to remove the Home Agent as a single point of failure for Mobile-IP. The protocol is implemented entirely through the enhancement of Home Agent functionality. There are no additional responsibilities or modifications required of either Mobile Nodes or Foreign Agents. Mobile Nodes and Foreign Agents have no knowledge of HARP and Mobile-IP will interoperate with HARP capable Home Agents. The Home Agent Redundancy Protocol will be made secure, minimally with authentication, and optionally with authentication and privacy mechanisms. Home Agent Redundancy makes no assumptions about the physical media utilized by the Mobile-IP environment. Therefore HARP does not limit the physical implementation of Mobile-IP. The number of Mobile Nodes is not limited by HARP. 1.2 Terminology Home Agent Redundancy Protocol terminology uses and expands on the Mobile-IP terminology presented in RFC 2002. The following terms are specific to the Home Agent Redundancy protocol: HARP peers - co-HAs - co-Home Agents - A set of Home Agents acting in concert to provide connectivity to one or more Mobile Nodes. These hosts share an IP address on the Home Subnet but each has a uniquely identified interface outside of the Home Network. Co-HAs, a priori, know about a small set of cooperating Home Agents and exchange registration information regarding Mobile Nodes and periodically test peer co-HA reachability. One may assume that there are only two Home Agents in a set of co-HAs, but there is no inherent limit to the number of peers in a Co-HA set. Chambless & Binkley Expires March 25 1998 [Page 4] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 Primary-HA, Primary - The Home Agent of a co-HA set which is currently receiving registration information directly from a MN. The Primary Home Agent shares this information with its co-HAs (Secondaries) by forwarding registration packets to the peers. A HA is primary because the IP routing infrastructure is currently routing the Mobile-IP registration packet to it. Secondary-HA, Secondary - A Home Agent of a HARP set which is receiving registration information about a given MN indirectly through its co-Home Agent which is acting as the Primary. HARP - Home Agent Redundancy Protocol. HARP PORT - The HARP port number which is the same for both the TCP and UDP ports. This port has not yet been allocated yet. Home Network - Home Subnet - The subnet containing both Home Agents and the home addresses of the Mobile Nodes they are serving. This subnet may be partitioned in terms of the co-HAs or the co-HAs may be physically present on the same link. Partitioned Subnet - A physically divided Home Subnet. Home Agents in a co-HA pair may be thought of as existing on a virtual subnet. Physically divided means that the co-HAs cannot use that link to communicate directly. Note that this is not a requirement of HARP, but an aspect of network design. We will discuss the network design aspects of HARP below. AWAY(Mobile-IP state) - The state of a Mobile Node, with respect to its Home Agent(s), in which datagrams addressed to the MN arrive at its Home-Subnet and are tunneled to the MN's Care Of Address by one of the Mobile Node's Home Agents. AT HOME (Mobile-IP state) - The state of a Mobile Node with respect to a Home Agent in which the MN's current point of attachment in the Internet is consistent with its IP address. In this state, the Mobile Node will receive packets directly. At CoHA(Mobile-IP state) - The state of of Mobile Node, with respect to a Home Agent, in which the MN's home subnet is partitioned and a packet arrives for the MN at another link of the partitioned network. In this case, packets addressed to the home subnet may arrive on a portion of the home subnet to which the Mobile Node has no link layer attachment. These packets must then be forwarded (tunneled) by one HARP peer to another. Chambless & Binkley Expires March 25 1998 [Page 5] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 2. Protocol Overview This section provides a protocol overview of HARP. We discuss HARP from a routing topological point of view, and provide a short discussion of redundancy issues. 2.1 Assumptions The following are fundamental assumptions about the design of a HARP redundant agent network: 1. So that Mobile-IP and Mobile Nodes need not know about the HARP sub-system, we assume that the HARP peers share a single IP subnet and a single IP network address. 2. Due to assumption 1, and because the HARP agents must communicate amongst themselves, we assume they are multi-homed in the sense that there exist on one node at least two IP addresses. We will call them the "Mobile-IP subnet" address, and the "HARP peer" address. The former is shared. The latter is not shared. The HARP peer address is unique and is used by HARP systems to communicate amongst themselves. Note that this does not rule out an agent with only one physical interface. 3. We assume that the HARP peers exist within an interior routing domain that runs a IP interior routing protocol such as RIPv2 [RFC-1721], or OSPF [RFC-2178]. Thus packets addressed to the Mobile-IP subnet, including Mobile-IP authentication packets, are routed to the HARP peers according to the local metrics of the interior routing protocols. At any given time, any packet bound for a Mobile Host at HOME, will go to exactly one HARP peer. Ideally, if an interior link fails, an interior routing protocol will switch Mobile-IP packets to the other HARP system. This does not rule out the possibility of HARP being used with static routes in interior routers. External routes to the Mobile-IP subnet may always be changed by hand in the event of HARP agent failure. Finally, it is NOT assumed that the HARP Mobile-IP subnet is partitioned. Partitioning may add useful redundancy attributes. But the subnet need not be partitioned. How this is handled is implementation and site specific and will be discussed more in the next section. Chambless & Binkley Expires March 25 1998 [Page 6] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 2.2 Protocol Overview Diagram 1: MN or CH | | MN/CH path | Internet | | | ------------------------ R1 interior path R2 | | H1 H2 | | ----- Mobile-IP subnet ------ Please refer to diagram 1 for the following discussion. Assume we have a Mobile Node that is away from home. Assume that at home we have two routers R1, and R2, which are using a local interior routing protocol (for example, OSPF, or static routes). Behind them are two HARP peers which advertise a Mobile-IP subnet to the routers and to the network. Along with the Mobile Node on the exterior Internet, there exists a Correspondent Host (CH). The latter is any host interested in sending packets to the Mobile Node. The Mobile Node is unaware of Home Agent redundancy and sends registration information only once to the shared HA address located on the Home Subnet. Due to the nature of unicast routing, this information may be received by either Home Agent, but is likely to be received by only one. Packets sent from the CH to the Mobile Node will likewise be routed to one or the other Home Agent (whichever is "closer", according to the metrics of the interior routing system). Note that any of these datagrams (Mobile-IP authentication or ordinary datagrams) may at any time go to either Home Agent. When a Mobile-IP registration packet is received by a co-HA, it will encapsulate that registration packet and forward it to another co-HA via the HARP UDP port. Thus the peer co-HA will know that the other HA directly received the registration, and will also know the current MN Care Of Address; i.e., the forwarding address for CH packets. Chambless & Binkley Expires March 25 1998 [Page 7] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 Each HARP peer takes the same internal action whether it receives a Mobile-IP registration packet directly from a MN or whether it receives it from a HARP peer. For example, in parallel, the Mobile-IP vlist entry is created or refreshed, and tunnels are setup (if needed) from the Home Agent to the Care Of Address. In Mobile-IP terms, the Home Agents act in parallel. Mobile-IP authentication (MN to HA, FA to HA, etc.) is performed once at the primary co-HA system. The secondary is expected to perform a separate HARP protocol authentication (HA to HA) on packets forwarded to it by the primary via the HARP UDP (or TCP in the case of table exchanges) ports. If one Home Agent should fail, the interior routing structure should notice that it has failed as a router, and normal routing convergence will remove that path to the Mobile-IP subnet. Convergence may take manual route manipulation in some cases where static routes are used. As a result, the Mobile-IP system should be able to survive the loss of a Home Agent as packets will be routed to a surviving Home Agent. HARP consists of three major packets type sent from one HARP peer to other HARP peers. (Note that some of the types have acknowledgements). We have already mentioned the HARP UDP FORWARD, which is a simple repackaging of the Mobile-IP registration packet itself. In addition there are two other kinds of messages used in the HARP system. There is a HARP PING and a HARP boottime table exchange. The former uses UDP and the later uses TCP. The UDP HARP PING is used to determine if other HARP peers are up. If a PING fails (say 3 out of 5), a HARP agent knows that either its peer has failed or the path to it has been partitioned. It may then take implementation-specific actions which should include ways to attempt to notify local administrators that critical interior links or systems have failed. Other implementation actions may be taken as well if needed. For example, a dormant local link interface might be enabled. HARP provides an optional boot protocol which uses TCP to exchange all HARP information in one connection. Thus if one HARP system reboots after failure, it can acquire Mobile-IP state information from another HARP peer. At boot, a HARP Home Agent will attempt to establish a TCP connections with its co-HAs at their respective TCP HARP PORTs. If successful, these connections are used to pass all current Mobile Node registration information from a running HA to a booting co-HA. When all relevant information has been passed, and the booting Home Agent is synchronized with respect to MN Registrations, the TCP connections are closed. If the peer system is not available, the sending system will timeout and proceed as the peer may be unavailable or rebooting. Chambless & Binkley Expires March 25 1998 [Page 8] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 2.3 Redundancy Considerations There are a number of redundancy considerations regarding HARP that have driven its design which we will present in this section. The failure of one HARP agent, or a network interface on that agent, or possibly a path to that agent should not necessarily cause the Mobile-IP network to fail. This is, of course, the goal of the protocol itself. In addition to simple node redundancy, redundancy may be possible if a path from the MN (CH) in question exists to another HARP agent even when an interior (or exterior) router (or associated interface) fails. Thus HARP may sometimes be able to take advantage of dynamic interior routing. On the other hand, the interior path between the HARP agents should not be allowed to fail. If it does, it is possible that the Mobile-IP registration packets might go one way and datagram packets from a given CH might go another, thus leading to a (bizarre) partition. This is one of the reasons for the HARP PING protocol. Lack of connectivity between the agents should lead to a local management alert. Of course, fundamentally, an interior path failure might cut the Mobile Node off from important local services and should be taken seriously in any case. As part of the overview, we should justify why we have chosen UDP for internal HARP forwarding as opposed to say TCP connections between HARP agents. We felt that the HARP protocol should internally match the design of Mobile-IP. Registration for Mobile Nodes while away from home is driven by Mobile-IP/UDP based packets. Since the Mobile Node drives the registration, we felt that forwarding these packets internally over presumably shorter channels (with higher bandwidth) was reasonable. As a result, Mobile-IP registration also drives the HARP sub-system. We also felt that given the goal of producing a reliable server with reliable software it made more sense to use a simple protocol without the enhanced complexity of a TCP state machine to deal with possible protocol errors. Thus agent-side implementation should be simpler. As a final point, even though the number of HARP peers in a HARP set is likely to be very small, at some future time, one might consider experimentally replacing the unicast UDP HARP (re)registration with reliable multicast registration. Of course, TCP lacks multicast capability. Redundancy considerations for the Mobile-IP home link itself are discussed in the next section. Chambless & Binkley Expires March 25 1998 [Page 9] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 3. Mobile-IP Home Link Considerations One might claim that the impact of HARP on the actual Mobile-IP home subnet link could be regarded as implementation dependent. This is because Mobile-IP itself is aimed not so much at dealing with how mobile nodes interact at the home subnet, but how they can take a home subnet IP address, move to other subnets, and retain connectivity. Thus HARP primarily seeks to address the problem of what might happen if the home forwarding agent is lost. Still, the issue of redundancy on the Mobile-IP home link exists and there is a small amount of protocol impact on HARP. In a very simple sense, having two possible "home" links can aid redundancy as well. If one home fails, a second home might be available. In this section, we will discuss this issue and make implementation suggestions. In the end local network management must decide what they want, according to available local resources and local tradeoffs. Therefore we suggest that implementations remain flexible where home subnet design is concerned. The Home Mobile-IP subnet may be either: 1. not partitioned; i.e., the HARP Home Agents could reside on the same link and would be able to reach each other on that link. 2. partitioned; i.e., the HARP Agents might reside on different links, and would NOT be able to reach each other on that link. 3.1 Non-Partitioned Home Subnet If the link is not-partitioned, the HARP Home Agents can reach each other directly. It is not advisable to have both HARP IP interfaces (which by definition share the same IP interface) active as confusion with nodes on the shared subnet might result. If the systems act as routers only (and not as end systems), one might claim that it would not matter, but there is no point in having both systems race to answer ARP [RFC-826] requests. Worse, any node that attempted to directly connect to the shared HARP subnet IP address with a transport protocol may experience failure due to ARP cache overwrites. Thus it is reasonable to assume an implementation might provide a way to shut down one HARP interior IP interface and dynamically bring another up if failure of the other HARP node is detected. This can be done by the normal method of designated router election. A set of HARP peers exchanging HARP PING messages Chambless & Binkley Expires March 25 1998 [Page 10] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 may choose the HARP peer with the highest IP address to be the only active peer on the interface. We assume that the PINGS are done over the non-Mobile-IP (and non-shared) IP address. If PINGS fail from that interface, (say after N failures, where N is configured in), the remaining HARP peers would again elect a designated router which will take over the "live" ARP function. 3.2 Partitioned Home Subnet If HARP peers exist on the same link, it is possible that the failure of an interior router or router interface could lead to the loss of all HARP agents. Thus one may have replaced the Mobile-IP single point of failure mode with a more elaborate single failure mode. We suggest that if practicable (and this ultimately depends on per site network resources), it may be better to partition the home mobile link. In other words, the internal path to the HARP agents would still be an interior routing path, but the agents themselves might best be in widely dispersed locations. For example, HARP peers would be placed behind different interior routers, possibly in different buildings. Such a partitioned network is not ideal for non-Mobile nodes, as IP subnet reachability problems would result if non-Mobile nodes were placed on the Mobile subnet. As a result, one might choose to only place Mobile-IP nodes on such partitioned links. Where a partitioned scheme is used, it is necessary for the Home Agents to install tunnels between themselves. This mechanism is directly analogous to the Mobile-IP tunnel from the Home Agent to the Foreign Agent. A packet sent to a co-HA where the MN is not resident, would be forwarded to the other co-HA. Note that HA tunneling is not strictly necessary when the Mobile subnet is not partitioned, unless the Home Agents are only speaking one at a time to the home link. A simple and less elegant solution would be to disable Mobile-IP router advertisements for Home Agents where actual physical residence is not desired. A dynamic scheme for election here could be used, or this function could be done manually. For example, one might choose to have only one Mobile-IP home subnet from the interior point of view. The other home might reside on a virtual interface that is not directly accessible except in the exterior routing sense. Mobile Nodes in such a system might never be able to directly visit the second home. In summary, where interior router resources exist, partitioning may provide greater surviveablity. Chambless & Binkley Expires March 25 1998 [Page 11] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 4.1 Message Types and Functions The Home Agent Redundancy Protocol has five messages: HARP_FORWARD - This message consists of an encapsulated Mobile Node registration message which is tunneled from the receiving Home Agent to its co-HA. This information is used to update the co-HA's registration tables. This message type uses UDP and is sent to the HARP UDP PORT. HARP_PING - This message is sent at configurable intervals from one co-HA to another to confirm connectivity. If the Home Agent receives no response from its co-HA peer, the co-HA is assumed to be unreachable. This message type uses UDP and is sent to the HARP UDP PORT. HARP_ACK - Sent in response to a HARP_PING to acknowledge that the PING message has been received. This message type uses UDP and is sent to the HARP UDP PORT. HARP_REG_REQ - A message requesting all Mobile Node registration information. This is the first message sent upon establishment of an inter-co-HA TCP connection. This message type utilizes TCP. HARP_REG_DUMP - TCP message which contains Mobile Node registration information maintained by a Home Agent. This message is sent in response to a HARP_REG_REQ. Note that more than one DUMP message may be sent, but each DUMP message may contain more than one Mobile-IP node registration. 4.2. Message Formats All HARP messages are structured in a Tag, Length, Value format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type and Length occupy one unsigned short and are 16-bit values. They are assumed to be in network byte order. Messages are sent to either the HARP UDP or TCP PORT. Chambless & Binkley Expires March 25 1998 [Page 12] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 4.2.1. HARP Registration Forward (HARP_FORWARD) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=HARP_FORWARD | size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile-IP registration packet ... | | | type: HARP_FORWARD = 1 size: in bytes of the value field. value: Mobile-IP registration packet. HARP Registration Forward messages are used to encapsulate and forward registration updates received from a Mobile Node. They are sent between co-HAs. The message consists of two bytes of type followed by two bytes indicating the length in bytes of a Mobile-IP registration packet. The Data field is a Mobile-IP registration packet of the size indicated by the size field. The registration packet has the same format as used with Mobile-IP. Optional (TLV) elements may be present and should be processed. However it is expected that the receiving Home Agent deals with all MN/HA and MN/FA authentication and may remove those elements from the registration packet. 4.2.2 HARP Ping (HARP_PING) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=HARP_PING | size=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HARP peer IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type: HARP_PING = 2 size: 4 value: (reachable) IP address of HARP sender HARP_PING messages are sent between all the members of a HARP co-HA set. They are sent with a configured periodicity and are sent within a configured mechanism for determining the loss of an interior routing path. For example, one might send one message a minute, and retry N times. If the sending agent determines that another agent is down, it may initiate implementation-dependent mechanisms including SNMP alerts, paging a network administrator, and/or taking up or down a local interface. We include the HARP peer IP address in order to limit possible problems caused by multi-homing. Chambless & Binkley Expires March 25 1998 [Page 13] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 4.2.3. HARP Ping Acknowledge (HARP_ACK) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=HARP_ACK | size=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HARP peer IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type: HARP_ACK = 3 size: 4 value: HARP peer IP address A HARP Ping Acknowledge message is sent in response to a HARP Ping. The peer IP address belongs to the sender of the acknowledgement. 4.2.4 HARP Dump Request (HARP_DUMP_REQ) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=HARP_DUMP_REQ | size=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type: HARP_DUMP_REQ = 4 size: 0 The HARP Dump Request message consists of two bytes of type followed by two bytes giving the size of the data field, which is always zero. A HARP_DUMP_REQ is passed from a Home Agent in Initializing State to its co-HA through the inter-co-HA TCP connection. If the receiving co-HA does not receive this message, it should shut down the connection and log an error. If the client's connection fails or no DUMP appears within a configured timeout interval, the client should disconnect and log an error. Chambless & Binkley Expires March 25 1998 [Page 14] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 4.2.5 HARP Registration Dump (HARP_REG_DUMP) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type=HARP_REG_DUMP | size=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Registrations | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Size of Registrations | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile-IP registration field ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile-IP registration field ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | etc. | | type: HARP_REG_DUMP = 5 size: 8 value: Number of Registrations: a 32-bit unsigned integer in network byte order Size of Registrations: a 32-bit unsigned integer in network byte order. This field contains the size of all the Mobile-IP registration sections which must all have the same size. Some number of Mobile-IP registration requests. A HARP Registration Dump message is sent in response to a TCP connect and HARP Dump Request. It contains current registration information for all Mobile Nodes serviced by a given Home Agent. "The number of registrations" field tells the receiver how many registration messages are being sent. The size of the registration message gives the size of each Mobile-IP registration message which as before, is assumed to be the same format as is used with Mobile-IP. Note we assume that all message sub-fields are of the same length. Also note that a Home Agent need not write all of the information with the same TCP write. Nor does the responding peer need to send all Mobile-IP registration messages in one DUMP message. Multiple DUMP messages may be sent over the same connection. The channel must be closed by the receiver when it has written all of the messages. Chambless & Binkley Expires March 25 1998 [Page 15] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 5. Security Considerations In this section, we briefly consider the security of the HARP protocol itself. Security might also be taken to mean "survivability" and we will discuss that notion first, and then return to HARP protocol network security. In terms of survivability, HARP primarily addresses the problem that a Mobile-IP system, serving a given number of Mobile Nodes may fail due to the loss of a single Home Agent. Home Agent redundancy reduces the odds of a total Mobile-IP system outage due to failure of a Home Agent node, a network adapter on that node, or possibly an internal routing path to that node. Given that we may have multiple Home Agents that cooperate to emulate a single home agent there may also be additional security benefits. For example, a denial of service attack against one Home Agent may not apply to the other (perhaps if they are not on the same link). Hence the Mobile-IP network might continue to function. For protocol security of HARP itself, we require the use of IP layer security [RFC 1825] between any given HARP pair in a set of HARP peers. The HARP pair may use a TCP connection between them at boot for route synchronization, and will use UDP to forward Mobile-IP registration packets. It is required that all of these end to end TCP and UDP channels be protected by at least IPSEC authentication [RFC 1826], and optionally by authentication and encryption [RFC 1827]. Authentication is a requirement. Thus security will be end to end for the HARP protocol between HARP peers. Chambless & Binkley Expires March 25 1998 [Page 16] INTERNET DRAFT Home Agent Redundancy Protocol October 1997 References [RFC-826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware", STD 37, November 1982. [RFC-1721] Malkin, G., "RIP Version 2 Protocol Analysis", November 1994. [RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", Naval Research Laboratory, July 1995. [RFC-1826] Atkinson, R., "IP Authentication Header", August 1995. [RFC-1827] Atkinson, R., "IP Encapsulated Security Payload", August 1995. [RFC-2002] Perkins, C., "IP Mobility Support", October 1996. [RFC-2003] Perkins, C., "IP Encapsulation within IP", October 1996. [RFC-2178] Moy, J., "OSPF Version 2", July 1997. Chambless & Binkley Expires March 25 1998 [Page 17] ^L INTERNET DRAFT October 27, 1997 Expires April 1997 Contacts Bjorn Chambless Computer Science Department Portland State University Email: bjorn@cs.px.edu Jim Binkley Computer Science and Engineering Department Oregon Graduate Institute Email: jrb@cse.ogi.edu Chambless & Binkley Expires March 25 1998 [Page 18]