Use of IPSec in Mobile IP

Transcription

1 Department of Electrical and Computer Engineering ELEG 777 Internet Engineering ( TERM PAPER ) Use of IPSec in Mobile IP DONE BY: SALEM ITANI ID #: SUBMITTED TO: Dr. AYMAN KAYSSI DATE: MAY 21, 2001

2 INTRODUCTION As mobile computing has become a reality, new technologies and protocols have been developed to provide to mobile users the services that already exist for non-mobile users. Mobile IP, one of these technologies, enables a node to change its point of attachment to an internet in a manner transparent to applications running on top of the protocol stack, since its IP address does not change. To provide this transparency, new elements are required: the home agent (HA), located in the home network, will forward all incoming packets addressed to the mobile node s (MN) new location. The foreign agent (FA) is responsible for providing a temporary address to the MN. The flexibility of communication through the Internet allows the existence of such protocols as Mobile IP. As much as this is true, it is as well the fact that every time new protocols or services are made available on the Internet, new security challenges arise. IPSec has been developed as a protocol to provide security at the IP layer. That is to say, using IPSec all communications on the Internet can be accomplished in a secure fashion. Providing security is not an easy task, since many situations have to be taken into account. The approach IPSec uses to address security is by managing two key concepts: privacy and authentication. In this paper, the MOBILE IPv4 & MOBILE IPv6 with the security considerations are introduced, after that the IPsec is explained, focusing on the IP Authentication Header and the IPsec Encapsulating Security Payload. Then the USE OF IPsec IN MOBILE IP part is treated, finally a performance analysis done in Carnegie Mellon University on IPsec usage in MOBILE IP on wireless environments is presented. MOBILE IPV4 The current Mobile IPv4 protocol is completely transparent to the transport and higher layers and does not require any changes to existing Internet hosts and routers. The Mobile IP protocol allows the MNs to retain their IP address regardless of their point of attachment to the network. This can be fulfilled by allowing the MN to use two IP addresses. The first one, called home address, is static and is mainly used to identify higher layer connections, e.g., TCP. The second IP address that can be used by a MN is the Care-of Address. While the mobile is roaming among different networks, the Care-of Address changes. The reason of this is that the Care-of Address has to identify the mobile s new point of attachment with respect to the network topology. In Mobile IPv4 the Care-of Address management is achieved by an entity called Foreign Agent. The Mobile Node, using its home address is appearing to be able to receive data on its home network, through a Home Agent. In the situation that the mobile roams into a foreign region, it will need to obtain, a new Care-of Address via the Foreign Agent. Note that, in this situation the Mobile Node can also obtain a new Care-of Address by contacting the Dynamic Host Configuration Protocol (DHCP) [RFC1541] or Point-to- Point Protocol (PPP) [RFC1661]. This new Care-of Address will be registered with its Home Agent. 1

3 The Correspondent Host (CH) starts a connection and at the moment that the Home Agent receives a packet that has to be send to the mobile, it delivers it from the home network to the mobile s Care-of Address. The delivery can take place only if the packet is redirected or tunneled, such that the Care-of Address appears as the destination IP address. The Home Agent tunnels the packet to the Foreign Agent. After receiving the packet, the Foreign Agent will have to apply the reverse transformation to decapsulate it, such that the packet will appear to have the mobile s home address as the destination IP address. After decapsulation, the packet is sent to the Mobile Node. Due to the fact that the packet arrives at the Mobile Node, being addressed to its home address, it will be processed properly by the upper protocol layers, e.g., TCP. The IP packets sent by the Mobile Node, are delivered by standard IP routing procedures, each to its destination. When the Mobile IP packet flow, follows a route similar to the one viewed in Figure, then the routing situation is typically called triangle routing, since the packet sent by the correspondent host follows the path 1,2 and 3, while the packet sent by the Mobile Node will follow routes 3 and 4. CHA MNHA HA Prot 4 or55 HAA COA 2 FA CHA MNHA 3 MN CHA MNHA Src Dest 1 CH 4 MNHA CHA Discovering the Care-of Address The Care-of address discovery procedure used in Mobile IP is based on the ICMP Router Advertisement standard protocol, specified in RFC 1256 [RFC1256]. In Mobile IPv4, the router advertisements are extended to also contain the required Care-of Address. These extended router advertisements are known as agent advertisements. Agent advertisements are typically broadcasted at regular intervals (e.g., once a second, or once every few seconds) and in a random fashion, by Home Agents and Foreign Agents. However, if a mobile needs to get a Care-of Address instantaneously, the Mobile Node can broadcast or multicast a solicitation that will be answered by any Foreign Agent or Home Agent that receives it. The functions performed by an agent advertisement are the following: - Allows the detection of Home Agents and Foreign Agents; - Lists one (or more available) care-of addresses; - Informs the Mobile Node about special features provided by Foreign Agents, e.g., alternative encapsulation techniques; - Permits Mobile Nodes to determine the network number and congestion status of their link to the Internet; - Lets the Mobile Node know, whether it is in its home network or in a foreign network by identifying whether the agent is a Home Agent, a Foreign Agent, or both. 2

4 In Mobile IP, the changes in the set of available mobility agents are detected by using ICMP router solicitations (agent solicitation) procedures defined in [RFC1256]. If the Mobile Node does not anymore receive agent solicitation advertisements from a Foreign Agent, it will presume that this Foreign Agent is not anymore within the range of its network interface. Registering the Care-of Address After the Mobile Node gets the Care-of Address it will have to inform the Home Agent about it. The Mobile Node sends a registration request (using the User Datagram Protocol (UDP)) with the Care-of Address information. This information is received by the Home Agent and normally, if the request is approved it adds the necessary information to its routing table and sends a registration reply back to the Mobile Node through the foreign agent. MN requests service FA relays request to MN MN FA HA FA relays status to MN HA accepts or denies The flags and parameters required to characterise the tunnel, through which the Home Agent will deliver packets to the Care-of Address, are contained in the registration request message. After accepting a registration request, the Home Agent begins to associate the home address of the Mobile Node with the Care-of Address for a prespecified time duration, called registration lifetime. The group that contains the home address, Care-of Address, and registration lifetime is called a binding for the Mobile Node. This binding is updated by the Mobile Node at regular intervals, sending a registration request to the Home Agent. During the registration procedure, there is a need to authenticate the registration information. The reason is that a malicious node could cause the Home Agent to alter its routing table with erroneous Care-of Address information, and then the Mobile Node would be unreachable. Therefore, each Mobile Node and Home Agent must share a security association. Tunnelling to the Care-of Address The tunnelling to the Care-of Address is accomplished by using encapsulation mechanisms. All mobility agents, i.e., Home Agents and Foreign Agents, using Mobile IPv4 must be able to use a default encapsulation mechanism included in the IP within IP protocol [RFC2003]. By using this protocol, the source of the tunnel, i.e., Home Agent, inserts an IP tunnel header, in front of the header of any original IP packet addressed to 3

5 the Mobile Node s home address. The destination of this tunnel is the Mobile Node s Care-of Address. In IP within IP [RFC2003] there is a way to indicate that the next protocol header is again an IP header. This is accomplished by indicating in the tunnel header that the higher level protocol number is 4. The entire original IP header is preserved as the first part of the payload of the packet. By eliminating the tunnel header the original packet can be recovered. Proxy and gratuitous Address Resolution Protocol (ARP) The IP nodes located in the home network of a Mobile Node are able to communicate with the Mobile Node while it is at home, by using ARP [RFC826] cache entries for this Mobile Node. When the Mobile Node moves to another subnetwork, the Home Agent will have to inform all IP nodes in the home network that the Mobile Node moved away. This is accomplished, by sending gratuitous ARP messages. These messages will update all ARP caches of each node in the home network. After that moment the packets sent by these IP nodes, to the Mobile Node will be intercepted by the Home Agent by using proxy ARP. The intercepted packets are then tunnelled to the care of address. Route Optimisation in Mobile IP The operation of the base Mobile IP protocol is extended to allow for more efficient routing procedures, such that IP packets can be routed from a correspondent host to a Mobile Node without going to the Home Agent first. These extensions are referred to as route optimisation, where in new methods for IP nodes, e.g., correspondent hosts, are provided. The correspondent host receives a binding 1 update message from the mobile s node Home Agent, that contains the Mobile Node s Care-of Address. This binding is then stored by the correspondent host and is used to tunnel its own IP packets directly to the care-of address indicated in that binding, bypassing the Mobile Node's Home Agent. In this way, the triangular routing situation, explained previously is eliminated. However, in the initiation phase, the IP packets sent by the correspondent host still use the triangle routing until the moment that the binding update message sent by the Mobile Node s Home Agent, is received by the correspondent host. Extensions are also provided, to allow IP packets sent by a correspondent host with an out-of-date stored binding, or in transit, to be forwarded directly to the Mobile Node's new care-of address. All operation of route optimisation that changes the routing of IP packets to the Mobile Node is authenticated using the same type of mechanisms also used in the base Mobile IP protocol. This authentication generally relies on a mobility security association established in advance between the sender and receiver of such messages. The route optimisation protocol operates four steps: - A binding warning control message is usually sent by a node (e.g., Mobile Node or Correspondent Host), to the Home Agent (i.e., recipient), indicating that a 1 Binding: The association of the home address of a Mobile Node with a care-of address for that Mobile Node, along with the remaining lifetime of that association. 4

6 Correspondent Host (i.e., target) seems unaware of the Mobile Node s new Care-of Address; - A binding request message is sent by a Correspondent Host to the Home Agent at the moment it determines that its binding should be refreshed; -Typically an authenticated binding update message is sent by the Home Agent to all the Correspondent Hosts that need them, containing the Mobile Node s current Care-of Address; -A binding acknowledgement message can be requested by a Mobile Node from a Correspondent Host that has had received the binding update message. Security issues The security open issues that are related to Mobile IPv4 are listed below: Ingress filtering: In an ISP any border router, may discard packets that contain a source IP address, that is not being configured for one of the ISP s internal network. This issue is called ingress filtering. In Mobile IPv4 the Mobile Nodes that are away from home, i.e., in a foreign ISP use their home address as the source IP address, that is different than the IP addresses configured in the ISP s internal network. Minimise the number of required trusted entities: Security may be enhanced, if the number of the required trusted entities, i.e., Home Agent, Foreign Agent, in a Mobile IP scenario is decreased. Authentication: The recipient of a message should be able to determine who the actual (real) originator of the message is. Therefore authentication procedures between mobile agents and Mobile Nodes should be provided. The Mobile IPv4 authentication techniques between Mobile Nodes and Foreign Agents are not reliable enough. Authorisation: An organisation that owns or operates a network would need to decide who may attach to this network and what network resources may be used by the attaching node. Non-repudiation: In the future wireless Internet, a recipient of a message should have the opportunity, to prove that a message has been originated by a sender. In other words, the sender of a message should not be able to falsely deny that it originated a message at a later time. Encryption key distribution: The authentication, integrity and non-repudiation can only be accurately provided (inforced) by using some form of cryptography which requires the distribution/exchange of encryption key information amongst message senders and receivers. In other words key management procedures should be supported by Mobile IP. Two methods can be used for this purpose. One method for distributing the key information is to manually load it into each node. For a small number of nodes this is possible but it runs into administrative problems. Another method to distribute the key information is dynamical, using basic IETF security protocols. Location privacy: A sender of a message should able to control which, if any, receivers know the location of the sender s current physical attachment to the network. Location privacy is concerned with hiding the location of a Mobile Node from Correspondent Hosts. 5

7 Use one single subscription for all service types: In RFC 2468 [RFC2468] the Network Access Identifier (NAI) is defined, it is used to identify ISP subscribers during roaming operations. Regarding second and third generation cellular networks, an interesting approach for cellular service providers would be to evolve their home cellular networks to provide second and third generation cellular services, IP packet data services and so on with a single subscription using NAIs. Mobile IPv4 does not provide solutions to this issue. Firewall support in Mobile IP: If a Mobile Node has to enter a private Internet network (Intranet) that is securely protected by a firewall, then Mobile IP aware support at this firewall is required. In Mobile IP this support is not provided. MOBILE IPV6 Comparison with Mobile IPv4 Mobile IPv6 shares many features with Mobile IPv4, but the protocol provides many improvements over Mobile IPv4. The major differences between Mobile IPv4 and Mobile IPv6 are: - Support for "Route Optimisation". This feature is now built in as a fundamental part of the Mobile IPv6 protocol. In Mobile Ipv4 the route optimisation feature is being added on as an optional set of extensions that may not be supported by all IP nodes. - In Mobile IPv6 (also integrated in the IPv6) a new feature is specified that allows Mobile Nodes and Mobile IP to coexist efficiently with routers that perform "ingress filtering".the packets sent by a Mobile Node can pass normally through ingress filtering routers. This can be accomplished due to the fact that the care-of address is used as the Source Address in each packet s IP header. Moreover, the Mobile Node s home address is carried in the packet in a Home Address destination option. This allows the use of the care-of address in the packet to be transparent above the IP layer, e.g., TCP. - By using the care-of address as the Source Address in each packet's IP header the routing of multicast packets sent by a Mobile Node is simplified. In Mobile IPv6 the Mobile Node will not anymore have to tunnel multicast packets, as in Mobile IPv4, to its Home Agent Moreover, the use of the Home Address option allows the home address to be used but still be compatible with multicast routing that is based in part, on the packet's Source Address. -In Mobile IPv6 the functionality of the Foreign Agents can be accomplished by IPv6 enhanced features, such as Neighbour Discovery, [RFC1970] and Address Autoconfiguration, [RFC1971]. Therefore, there is no need to deploy Foreign Agents in Mobile IPv6. -The Mobile IPv6, unlike Mobile IPv4, uses IPsec for all security requirements such as sender authentication, data integrity protection, and replay protection for Binding Updates (which serve the role of both registration and Route Optimisation in Mobile 6

8 IPv4). In Mobile IPv4 the security requirements are provided by its own security mechanisms for each function, based on statically configured mobility security associations. - In mobile IPv6 a mechanism is provided to support bidirectional (i.e., packets that the router sends are reaching the Mobile Node, and packets that the Mobile Node sends are reaching the router) confirmation of a Mobile Node's ability to communicate with its default router in its current location. This bidirectional confirmation can be used to detect the black hole situation, where the link to the router does not work equally well in both directions. In contrast, Mobile IPv4 does not support bidirectional confirmation, but only the forward direction (packets from the router are reaching the Mobile Node) is confirmed, and therefore the black hole situation may not be detected. - Mobile IPv6 and IPv6 use the source routing feature. This feature makes it possible for a Correspondent Host to send packets to a Mobile Node while it is away from its home network using an IPv6 Routing header rather than IP encapsulation, whereas Mobile IPv4 must use encapsulation for all packets. However, in Mobile IPv6 the Home Agents are allowed to use encapsulation for tunnelling. This is required, during the initiation phase of the binding update procedure. -In Mobile IPv6 the packets which arrive at the home network and are destined for a Mobile Node that is away from home, are intercepted by the Mobile Node s Home Agent using IPv6 Neighbour Discovery,[RFC1970] rather than ARP [RFC826] as is used in Mobile IPv4. - The source routing (routing header) feature in Mobile IPv6 removes the need to manage "tunnel soft state", which was required in Mobile IPv4 due to limitations in ICMP error procedure for IPv4. In Mobile IPv4 an ICMP error message that is created due to a failure of delivering an IP packet to the Care-of Address, will be returned to the home network, but will may not contain the IP address of the original source of the tunnelled IP packet. This is solved in the Home Agent by storing the tunnelling information, i.e., which IP packets have been tunnelled to which Care-of Address, called tunnelling soft state. - In IPv6 a new routing procedure is defined called anycast. This feature is used in Mobile IPv6 for the dynamic Home Agent address discovery mechanism. This mechanism returns one single reply to the Mobile Node, rather than the corresponding Mobile IPv4 mechanism that used IPv4 directed broadcast and returned a separate reply from each Home Agent on the Mobile Node's home subnetwork. The Mobile IPv6 mechanism is more efficient and more reliable. This is due to the fact that only one packet need to be replied to the Mobile Node. - In Mobile IPv6 an Advertisement Interval option on Router Advertisements (equivalent to Agent Advertisements in Mobile IPv4) is defined, that allows a Mobile Node to decide for itself how many Router Advertisements (Agent Advertisements) it is tolerating to miss before declaring its current router unreachable. - All Mobile Ipv6 control traffic can be piggybacked on any existing IPv6 packets. This can be accomplished by using the IPv6 destination options. In contrary, for Mobile IPv4 and its Route Optimisation extensions, separate UDP packets were required for each control message. 7

9 Security Considerations Binding Updates, Acknowledgements, and Requests The Binding Update option will result in packets addressed to a mobile node being delivered instead to its care-of address. This ability to change the routing of these packets could be a significant vulnerability if any packet containing a Binding Update option was not authenticated. Such use of "remote redirection", for instance as performed by the Binding Update option, is widely understood to be a security problem in the current Internet if not authenticated. The Binding Acknowledgement option also requires authentication, since, for example, an attacker could otherwise trick a mobile node into believing a different outcome from a registration attempt with its home agent. No authentication is required for the Binding Request option, since the use of this option does not modify or create any state in either the sender or the receiver. The Binding Request option does open some issues with binding privacy, but those issues can be dealt with either through existing IPsec encryption mechanisms or through use of firewalls. The existing IPsec replay protection mechanisms allow a "replay protection window" to support receiving packets out of order. Although appropriate for many forms of communication, Binding Updates must be applied only in the order sent. The Binding Update option thus includes a Sequence Number field to provide this necessary sequencing. The use of this Sequence Number together with Ipsec replay protection is similar in many ways, for example, to the sequence number in TCP. IPsec provides strong replay protection but no ordering, and the sequence number provides ordering but need not worry about replay protection such as through the sequence number wrapping around. Home Address Option No special authentication of the Home Address option is required, except that if the IPv6 header of a packet is covered by authentication, then that authentication must also cover the Home Address option; this coverage is achieved automatically by the definition of the Option Type code for the Home Address option since it indicates that the option is included in the authentication computation. Thus, even when authentication is used in the IPv6 header, the security of the Source Address field in the IPv6 header is not compromised by the presence of a Home Address option. Without authentication of the packet, then any field in the IPv6 header, including the Source Address field, and any other parts of the packet, including the Home Address option, can be forged or modified in transit. In this case, the contents of the Home Address option is no more suspect than any other part of the packet. The use of the Home Address option allows packets sent by a mobile node to pass normally through routers implementing ingress filtering. Since the care-of address used 8

10 in the Source Address field of the packet's IPv6 header is topologically correct for the sending location of the mobile node, ingress filtering can trace the location of the mobile node in the same way as can be done with any sender when ingress filtering is in use. However, if a node receiving a packet that includes a Home Address option implements the processing of this option by physically copying the Home Address field from the option into the IPv6 header, replacing the Source Address field there, then the ability to trace the true location of the sender is removed once this step in the processing is performed. This diminishing of the power of ingress filtering only occurs once the packet has been received at its ultimate destination, and does not affect the capability of ingress filtering while the packet is in transit. Furthermore, this diminishing can be entirely eliminated by appropriate implementation techniques in the receiving node. For example, the original contents of the Source Address field (the sending care-of address) could be saved elsewhere in memory with the packet, until all processing of the packet is completed. Introduction IPsec The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. It provides a set of security algorithms plus a general framework that allows a pair of communicating entities to use whichever algorithms provide security appropriate for the communication. The elements describing the set of IPsec protocols are divided into seven groups: There is the main Architecture, which broadly contain the general concepts, security requirements, definitions, and mechanisms defining IPsec technology. There is the ESP Protocol and an AH Protocol which contain the packet format and general issues regarding the respective protocols. The "Encryption Algorithm", describes how various encryption algorithms are used for ESP. The "Authentication Algorithm", describes how various authentication algorithms are used for both ESP and AH. The "Key Management ". The DOI contains values needed for the other elements to relate to each other. This includes for example encryption algorithms, authentication algorithms, and operational parameters such as key lifetimes. 9

11 In this part we will focus on the IP Authentication Header and the IPSec Encapsulating Security Payload as shown below. The IP Authentication Header The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams, and to provide protection against replays. The protocol header (IPv4, IPv6, or Extension) immediately preceding the AH header will contain the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field NEXT HEADER PAYLOAD LEN RESERVED SECURITY PARAMETERS INDEX SEQUENCE NUMBER AUTHENTICATION DATA (VARIABLE) Next Header: The Next Header is an 8-bit field that identifies the type of the next payload after the Authentication Header. Payload Length: This 8-bit field specifies the length of AH in 32-bit words (4-byte units), minus "2". AH is an IPv6 extension header. However, since its length is measured in 32- bit words, the "Payload Length" is calculated by subtracting 2 (32 bit words). In the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4". A "null" authentication algorithm may be used only for debugging purposes. Its use would result in a "1" value for this field foripv4 or a "2" for IPv6, as there would be no corresponding Authentication Data field. Reserved: This 16-bit field is reserved for future use. It must be set to "zero." Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that, in combination with the destination IP address and security protocol (AH), uniquely identifies the Security Association for this datagram. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system. Sequence Number: This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). It is obligatory and is always present even if the 10

12 receiver does not elect to enable the anti-replay service for a specific SA 2, when Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender must always transmit this field, but the receiver need not act upon it. The sender's counter and the receiver's counter are initialized to 0 when an SA is established and the first packet sent using a given SA will have a Sequence Number of 1. If anti-replay is enabled, the transmitted Sequence Number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter must be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA. Authentication Data: This is a variable-length field that contains the Integrity Check Value (ICV) for this packet. The field must be an integral multiple of 32 bits in length. This field may include explicit padding. This padding is included to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). The authentication algorithm specification must specify the length of the ICV and the comparison rules and processing steps for validation. Authentication Header Location AH may be employed in two ways: transport mode or tunnel mode. The former mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. In transport mode, AH is inserted after the IP header and before an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec headers that have already been inserted. The following diagram illustrates AH transport mode positioning for a typical IPv4 packet, on a "before and after" basis. IPv4 BEFORE APPLYING AH orig IP hdr TCP DATA IPv4 AFTER APPLYING AH orig IP hdr AH TCP DATA < authenticated In the IPv6 context, AH is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the AH header depending on the 2 To save space in the header, IPsec arranges for each receiver to collect all the details about a security scheme into an abstraction known as security association SA. Each SA is given a number, known as SECURITY PARAMETER INDEX, through which it is identified. 11

13 semantics desired. The following diagram illustrates AH transport mode positioning for a typical IPv6 packet. IPv6 BEFORE APPLYING AH orig IP hdr ext hdrs TCP Data IPv6 AFTER APPLYING AH orig IP hdr hop-by-hop, dest, routing, fragment. AH dest TCP Data < authenticated except for mutable fields > Tunnel mode AH may be employed in either hosts or security gateways. When AH is implemented in a security gateway (to protect transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header. The position of AH in tunnel mode, relative to the outer IP header, is the same as for AH in transport mode. The following diagram illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets. IPv4 new IP hdr AH orig IP hdr TCP Data <-authenticated except for mutable fields in the new IP hdr -> IPv6 new IP hdr ext hdrs AH orig IP hdr ext hdrs TCP Data authenticated except for mutable fields in new IP hdr > 12

14 IPsec Encapsulating Security Payload The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH), or in a nested fashion, e.g., through the use of tunnel mode. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association establishment and on the placement of the implementation. Confidentiality may be selected independent of all other services. Data origin authentication and connectionless integrity are joint services (here after referred to jointly as authentication) and are offered as an option in conjunction with confidentiality. The anti-replay service may be selected only if data origin authentication is selected, and its election is solely at the discretion of the receiver. Traffic flow confidentiality requires selection of tunnel mode, and is most effective if implemented at a security gateway, where traffic aggregation may be able to mask true source-destination patterns. The ESP header is inserted after the IP header and before the upper layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). For IPv4 a value of 50 in the PROTOCOL field of the datagram informs a receiver that the datagram carries ESP. The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis. Before: Ipv4 Header TCP Header TCP DATA After: IPv4 Head er ESP Header TCP Header authenticated encrypted TCP DATA As the figure shows, ESP adds three additional areas to the datagram. The ESP HEADER immediately follows the IP header and precedes the encrypted payload. The ESP TRAILER is encrypted along with the payload; a variable size ESP AUTH field follows the encrypted section. ESP Trailer ESP AUTH 13

15 In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could appear either before or after the ESP header depending on the semantics desired. However, since ESP protects only fields after the ESP header, it generally may be desirable to place the destination options header(s) after the ESP header. The following diagram illustrates ESP transport mode positioning for a typical IPv6 packet. Before: orig IP hdr ext hdrs if present TCP Data After: Orig IP hdr hxh, rtg, frag if present Dest opt ESP hdr Dest opt TCP Data ESP Trailer ESP Auth encrypted authenticated Tunnel mode ESP may be employed in either hosts or security gateways. When ESP is implemented in a security gateway (to protect subscriber transit traffic), tunnel mode must be used. In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header may contain distinct IP addresses, e.g., addresses of security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6 packets. IPv4: authenticated encrypted New ESP Ip hdr Header ESP Orig IP hdr TCP Data ESP Trailer ESP AUTH 14

16 IPv6: New IP hdr Ext hdrs ESP Orig. IP hdr Ext hdrs TCP Data ESP Trailer ESP Auth encrypted authenticated Encapsulating Security Payload Packet Format The ESP HEADER consists of 8 octets that identify the security parameters index and a sequence number SECURIY PARAMETERS INDEX SEQUENCE NUMBER The ESP TRAILER consists of optional padding, a padding length field, PAD LENGTH, and a NEXT HEADER field that is followed by a variable amount of authentication data OCTETS OF PADDING PAD LENGTH NEXT HEADER ESP AUTHENTICATION DATA (VARIABLE).. Obviously, the payload data is located between the header and trailer. Security Parameters Index: The SPI is an arbitrary 32-bit value that uniquely identifies the Security Association for this datagram, relative to the destination IP address contained in the IP header (with which this security header is associated) and relative to the security protocol employed. The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. It is ordinarily selected by the destination system upon establishment of an SA.(A zero value may be used within an ESP implementation for 15

17 local debugging purposes, but no ESP packets should be transmitted with a zero SPI value). Sequence Number: This unsigned 32-bit field contains a monotonically increasing counter value (sequence number). The counter is initialized to 1 when an SA is established. The Sequence Number must never be allowed to cycle; thus, it must be reset by establishing a new SA and thus a new key prior to the transmission of 2^32-1 packets on an SA. The Sequence Number is obligatory. It is always included in an ESP packet, to ensure alignment of the Payload field on an 8-byte boundary (in support of IPv6). Even if authentication is not selected as a security service for the SA, or if ESP is employed in an IPv4 environment, this field must be present. Processing of the Sequence Number field is at the discretion of the receiver, i.e., the sender must always transmit this field, but the receiver need not act upon it. Payload Data : Payload Data is a variable-length field containing data described by the Next Header field. The Payload Data field is mandatory and is an integral number of bytes in length. If the algorithm used to encrypt the payload requires cryptographic synchronization data, then this data may be carried explicitly in the Payload field. Any encryption algorithm that requires such explicit, per-packet synchronization data must indicate the length and any structure for such data. Padding (for Encryption): If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Pad Length and Next Header fields, as well as the Padding) to the size required by the algorithm. Any encryption algorithm used with ESP that requires padding must define its padding requirements in an RFC specifying how the algorithm is used with ESP. Padding also may be required, irrespective of algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary, i.e., the Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure. Finally, padding beyond that required for the algorithm or alignment reasons cited above, may be used to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality. However, inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care. The Padding field is optional, but all implementations must support generation and consumption of padding. Pad Length: The Pad Length field indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255, where a value of zero indicates that the byte immediately preceding the pad length field is the last byte of the payload. The Pad Length field is mandatory. Next Header :The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol 16

18 identifier. The value of this field is chosen from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is obligatory. Authentication Data : The Authentication Data is a variable-length field containing an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data. The length of the field depends upon the authentication function selected. The mandatory-to-implement authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit ICV's because of the truncation convention adopted for use in IPsec. The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question. USE OF IPsec IN MOBILE IP The use of IPSec ESP protocol in the Mobile IP packet redirection tunnels will protect the redirected packets against both passive and active attacks launched and aid these packets to traverse the firewalls surrounding both the home and the foreign subnets visited by the mobile nodes. Use of IPSec on Mobile IP Redirection Tunnels The IPSec protected Mobile IP tunnels (MIP_IPSec tunnels) offer message confidentiality and authentication (including data origin authentication and connectionless integrity) but not anti-replay services to the IP datagrams to and from the mobile nodes (MNs) passing through the mobility agents, i.e. home agents (HAs) and foreign agents (FAs). Selective use of these tunnels coupled with rule/identity based access control can provide the security services. The proposed scheme made certain assumptions on the architecture and implementation of this secure Mobile IP system. These assumptions are stated below: - In order to use the MIP-IPSec tunnels and the mobility agents for the best protection of the mobile Internet, both FAs and HAs should function as IPSec supporting security gateways capable of performing packet encryption/decryption and packet filtering based on strong authentication. - On a firewall protected foreign subnet, the FAs should be the firewalls closest to the mobile nodes (MNs). Other firewalls on the subnet should permit the IPSec protected packets to and from the FAs to pass through. Reverse tunneling must be used if INGRES source filtering is employed by the firewalls. 17

19 - The HAs should function as the innermost firewall guarding the home subnet. Similarly, other firewalls on the subnet should permit the IPSec protected packets to and from the HAs to pass through. - The IPSec implementation is expected to be integrated with the Mobile IP implementation. Such an approach allows the use of a single IP-IP encapsulation to be used for both IPSec protection and Mobile IP packet redirection (except when MN-HA IPSec tunnels are used). The approach is also consistent with the new roles of FAs and HAs as IPSec supporting security gateways. The MIP-IPSec tunnels running between MN-HA, HA-FA, FA-MN are the essential ones for fulfilling the security requirements. They will be examined individually in the following paragraphs. In addition, the end-to-end IPSec protection between MNs and CHs can be used in combination with the IPSec tunnels. Notice that Mobile IP tunnels do not run between CHs and HAs, and the tunnels running between CHs and FAs exist only in route-optimized Mobile IP. This is because corresponding hosts may be completely ignorant of Mobile IP, and may not know of the existence of FAs and HAs. MN-HA Tunnels The MN-HA MIP-IPSec tunnels can be used to provide data-origin authentication plus connectionless integrity and data confidentiality. They are most useful in providing a secure communication path between a MN and its home subnet as shown in the following diagram. H1* (Internet) SG2* ---- (Local Intranet) H2* admin. boundary The data-origin authentication and connectionless integrity can counter active attack while data confidentiality can frustrate eavesdropping. By using the tunnels in both directions, a MN should be allowed to enjoy same connectivity as it has at home. The MN-HA tunnels are, however, more expensive to establish since they are not one of the Mobile IP redirection tunnels, they must be established separately with the use of an additional IP header. 18

20 HA-FA Tunnels The MIP-IPSec tunnel going from a HA to a FA (and from a FA to a HA if reverse tunnel and FA Care-of Address are used) can be implemented by simply adding IPSec protection to the existing Mobile IP tunnels. The tunnels can also be used to support data-origin authentication plus connectionless integrity and data confidentiality. They establish virtual private network (VPN) connections between the home subnet of the MN and the foreign subnet currently visited by the MN as shown in the following diagram. H (Local Intranet) SG1* SG2* ---- (Local Intranet) H2 The main uses of the FA-HA tunnels are: (1) To frustrate passive and active attacks from the open Internet. (2) To traverse firewalls between FAs and HAs. Such a tunnel may allow the MN to access its home subnet only if it is coupled with strong authentication of the MN by the FA and system security of the FA. MN-FA Tunnels The MN-FA MIP-IPSec tunnels can be used in two ways if no link-layer protection has already provided the services: 1. Data confidentiality for MN over the foreign network and 2. Data origin authentication of MN-FA exchange. The MN-FA tunnels exist only if MN chooses to use an FA Care-of Address and they must be built by re-encapsulating the IP datagrams. Hence, these tunnels are expensive to use and should be replaced by MN-CH end-to-end IPSec protection or MN-HA IPSec tunnels whenever possible. Changes to Mobile IP Messages In order for the mobile nodes (MNs) and the mobility agents (FAs and HAs) to agree on the selection of MIP-IPSec tunnels, the FA and the MN should use the following two extensions (added to the mobility agent advertisement and the registration request) for proposing their choices. Upon reception of the registration request, the HA should decide 19

21 weather to accept and reject the proposal based on its security policy and then return its decision using the return codes in the registration reply. Extension to Mobility Agent Advertisement An FA IPSec Tunnel Extension is added to the mobility agent advertisement message, which conforms to the format of an ICMP router advertisement. The purpose of the extension is to carry FA's choice of MIP-IPSec tunnels. The type- length-value (TLV) format of the extension is shown below: Type Length F R reserved F R reserved MN Tunnel HA Tunnel FA IPSec Tunnel Extension Length : 2 bytes F : IPSec Protection for Forward Tunnels ( HA->FA, FA->MN ) R : IPSec Protection for Reverse Tunnels ( FA->HA, MN->FA ) reserved : ignored upon reception; must be set to zero during transmission Extension to Mobile IP Registration Request An MN IPSec Tunnel Extension is added to the registration request message. This extension indicates the choices of MIP-IPSec tunnels made by MN based on its own policy and its knowledge of FA's choices. The extension carries six flags, each when set indicates the use of IPSec on a possible tunnel. The extension format is shown in the Figure below. To simplify processing, the flags in the FA IPSec Tunnel Extensions remain in the same positions Type Length F R F R F R reserved FA HA HA MN Tunnel FA Tunnel MN IPSec Tunnel Extension 20

22 Length: 2 bytes F: IPSec Protection for Forward Tunnels (HA->FA, FA->MN, HA->MN) R: IPSec Protection for Reverse Tunnels (FA->HA, MN->FA, MN->HA) Reserved: ignored upon reception; must be set to zero during transmission. Procedure for MIP-IPSec Tunnel Establishment The process of establishing the MIP-IPSec tunnels can be divided in three steps: (1) Tunnel selection. (2) Security association negotiation. (3) Tunnel activation. Among them, tunnel selection happens concurrently with Mobile IP registration and tunnel activation occurs also in ordinary Mobile IP tunneling. The insertion of security association (SA) negotiation is a new step, and it introduces a new complexity to the process: owing to the possible failure of SA negotiation, a MIP-IPSec tunnel may need to be dismantled even after a successful Mobile IP registration. Format of Encapsulated Packets Outer IP Hdr IPSec Hdr Inner IP Hdr UDP / TCP Payload Ext Ext Tunnel, AH/ESP Src Dest The IPSec tunnel supports that packets are encapsulated in IP-in-IP encapsulation, and it is active when the packet is being delivered in a mobile route. When a packet travels in the mobile IP tunnel, an additional IPSec header with ESP header is inserted between mobile IP encapsulation header and the original IP packet. In the only case of MN-HA tunneling, an MN-HA IPSec tunnel must be embedded into outer Mobile IP (HA-FA, FA-MN) tunnels. Hence, an extra IP header will be inserted along with ESP header between the Mobile IP encapsulation and the original IP header. 21

23 Performance Analysis of IPSec For Mobile IP on Wireless Environments In this part a performance evaluation of the deployment of Mobile IP in combination with IPSec is presented. Three different scenarios are used to represent the most likely deployment configurations. The ns-2 network simulator is used to model the performance penalty of the IPSec protocol. The performance results are presented in terms of throughput and delay. INTRODUCTION In wireless environments, due to the intrinsic characteristics of the media, lower bandwidth and high error rates cause packet loss and retransmission among other effects. Mobile nodes using Mobile IP in wireless environments could be particularly affected more so than others due to the overhead already imposed by Mobile IP. Due to the nature of mobile computing in a wireless environment, it is very likely that nodes will move from one cell to another. Therefore, a scenario that needs special attention is the hand-off necessary to maintain normal communication flow. SCENARIOS Practical applications of Mobile IP are likely to occur in scenarios where a private network is extended over a public backbone (i.e. the Internet). In many cases these scenarios could imply that the FA belongs to a commercial entity that wishes to provide mobile services. Scenario 1: Basic. The basic authentication required by Mobile IP between the Home Agent (HA) and the Mobile Node (MN) is represented in this scenario. This process is simulated through the Authentication Header protocol in Transport Mode. The main reason for doing this is that this represents the least expensive computational authentication method provided by IPSec s protocols. ESP s fw h g f mn AH Basic scenario. 22