An in-band signaling method that enables secure updates of a care-of-ip address for a mobile host that roams between access networks. In the illustrative embodiment described herein, a mobile host includes an intelligent interface that handles ip networking functions and tunnels ip packets between the mobile host and the mobile host's home agent/remote access server (HA/RAS) transparently, as if the mobile host established a connection to a communicating or destination host (DST) from the home network (where the HA/RAS resides). In accordance with an aspect of the invention, there is provided an in-band signaling method that employs encrypted three-way handshake signaling messages that are embedded in encapsulated ip packets to enable care-of ip address updates. This method can effectively protect mobile hosts from denial-of-service attacks and is transparent to NAT/NAPT firewalls. The signaling messages are communicated between the home agent and the mobile host, in a manner transparent to any NAT/NAPT firewall in the network.
|
11. A method comprising:
responsive to a mobile host departing from a first access network and being granted access to a second access network, sending, to a home agent, a care-of address confirmation message in outbound ip packets to the home agent after a care-of address acknowledgment message is received, the care-of address confirmation message comprising a same sequence number as a sequence number in the care-of address acknowledgment message, the care-of address confirmation message sent responsive to a determination that the sequence number in the care-of address acknowledgment message is greater than or equal to a sequence number in a care-of address request message, the care-of address acknowledgment message adapted to acknowledge update of a care-of ip address for the mobile host by the home agent.
10. A method comprising:
responsive to a mobile host departing from a first access network and being granted access to a second access network, receiving, at a home agent, an embedded ip-in-ip packet comprising a care-of address confirmation message, the embedded ip-in-ip packet received responsive to a care-of address acknowledgment message, the care-of address confirmation message comprising a same sequence number as a sequence number in the care-of address acknowledgment message, the care-of address acknowledgment message sent responsive to a determination that the sequence number in the care-of address request message is greater than or equal to a sequence number in a most recent care-of address request message register, the care-of address acknowledgment message adapted to acknowledge update of a care-of ip address for the mobile host to the home agent by the mobile host.
1. A method comprising:
responsive to a mobile host departing from a first access network and being granted access to a second access network, the first and second access networks each comprising firewalls and the mobile host assigned an inside and an outside care-of ip address on each of the first access network and the second access network, responsive to a receipt of a care-of address status message from the mobile host, the care-of address status message comprising a same sequence number as a sequence number in a most recently received care-of address request message, storing an outside ip address for the mobile host in a CURRENT_CARE-OF_ADDRESS register, the outside ip address recognized as a new care-of ip address for the mobile host, the sequence number of the most recently received care-of address request message identical to a sequence number of a sent care-of address acknowledgment message, the care-of address acknowledgment message sent in an embedded ip-in-ip packet, the outside ip address a care-of ip address for the mobile host.
2. The method of
storing the sequence number from the most recently received care-of address request message.
3. The method of
receiving a new care-of address request message from the mobile host, the new care-of address request message comprising a sequence number in an embedded ip-in-ip packet that comprises a destination address of a communicating host, the ip-in-ip packet further comprising the outside ip address assigned to the mobile host by the second access network that corresponds to the care-of ip address assigned to the mobile host by the second access network.
4. The method of
checking whether a sequence number contained in a new care-of address request message is less than or equal to the sequence number of the most recently received care-of address request message.
5. The method of
checking whether a sequence number contained in a new care-of address request message is less than or equal to the sequence number of the most recently received care-of address request message, and if so;
storing the outside ip address for the mobile host on the second access network in a CANDIDATE_CARE-OF_ADDRESS register.
6. The method of
checking whether a sequence number contained in a new care-of address request message is less than or equal to the sequence number of the most recently received care-of address request message, and if so;
bicasting packets to the mobile host at the outside care-of ip address for the mobile host on the second access network, and the outside care-of ip address for the mobile host on the first access network.
7. The method of
checking whether a sequence number contained in a new care-of address request message is less than or equal to the sequence number of the most recently received care-of address request message, and if so;
terminating a bicast of packets to the first and second access networks.
8. The method of
checking whether a sequence number contained in a new care-of address request message is less than or equal to the sequence number of the most recently received care-of address request message, and if so;
storing the outside ip address for the mobile host on the second access network in a CANDIDATE_CARE-OF_ADDRESS register;
bicasting packets to the mobile host at the outside care-of ip address for the mobile host on the second access network, and the outside care-of ip address for the mobile host on the first access network; and
terminating the bicasting of packets to the first and second access networks.
9. The method of
bicasting packets to the mobile host at the outside care-of ip address for the mobile host on the second access network, and the outside care-of ip address for the mobile host on the first access network;
terminating the bicasting of packets to the first and second access networks after a BI_CASTING timer expires.
12. The method of
sending the care-of address request message at the home agent in an embedded ip-in-ip packet containing a destination address of a communicating host.
13. The method of
receiving an embedded ip-in-ip packet comprising the care-of address acknowledgment message from the second access network.
14. The method of
checking whether the sequence number in the care-of address acknowledgment message is greater than or equal to the sequence number in the care-of address request message.
15. The method of
16. The method of
17. The method of
18. The method of
19. The method of
|
|||||||||||||||||||||||||||||
This application is a continuation of, claims priority to, and incorporates by reference herein in its entirety, U.S. patent application Ser. No. 10/298,406 (now U.S. Pat. No. 7,146,428), filed 18 Nov. 2002, which claims priority to Provisional Application Serial No. 60/339,953 entitled “A SECURE IN-BAND SIGNALING METHOD FOR MOBILITY MANAGEMENT CROSSING FIREWALLS” filed on Dec. 12, 2001, the content of which is incorporated by reference herein.
The present invention relates generally to mobile networking, and more particularly, to method for securely updating a care-of-IP address across a NAT (network address translation)/NAPT (network address-port translation) firewall without the need to coordinate the update with the firewall.
Mobile IP is a protocol that enables a mobile host to roam from one access network to another without loss of IP connectivity. In Mobile IP, a special entity referred to as a home agent, is deployed on the Internet to track the location of mobile computers (hosts) and to route IP packets to them irrespective of their physical locations. A mobile host owns a fixed IP address that belongs to the subnet of the home agent. Any application programs running on the mobile host use this fixed IP address as the source IP address during network communications. Whenever the mobile computer attaches to a subnet, a care-of IP address belonging to the subnet is reported to the home agent, so that the home agent can route inbound IP packets to the mobile host's current location using an IP tunnel. If a foreign agent is deployed on the subnet, the foreign agent's IP address is the mobile's care-of IP address. If there is no foreign agent, the mobile must have a built-in foreign agent, and it needs to apply an IP address from the subnet for this built-in foreign agent.
All IP packets destined for the mobile host are intercepted by the home agent when they arrive at the home agent's subnet. The home agent encapsulates these packets into new IP packets with the home agent's IP address as source IP address and the care-of IP address as destination IP address. When they arrive at the foreign agent, the encapsulated packets are decapsulated, and the inner IP packets are delivered to the TCP/IP stack of the mobile host. IP packets that are communicated from the mobile host to a destination host are encapsulated into new IP packets by the foreign agent. The outer source IP address is the care-of IP address, and the outer destination IP address is the home agent's IP address.
Due to security concerns and the insufficiency of IPv4 address, many Internet Service Providers (ISPs) and corporate networks use NAT/NAPT technologies in their firewall gateways. This makes mobility management very difficult because it affects the conventional update signaling of care-of IP addressing. According to current methods, either the mobile host cannot securely update its own care-of IP address that is behind the firewall with its mobility router outside of firewall, or complicated signaling methods are needed to coordinate communications between the mobile host, the firewall gateway, and the mobility router. Neither is a satisfactory solution. Accordingly, there exists a need for a new in-band signaling method for mobility management, which assures secure updates of care-of IP addresses across a firewall and which does not require coordination with the firewall.
In accordance with an aspect of the invention, there is provided an in-band signaling method that employs encrypted three-way handshake signaling messages that are embedded in encapsulated IP packets to enable care-of IP address updates. This method can effectively protect mobile hosts from denial-of-service attacks and is transparent to NAT/NAPT firewalls. The signaling messages are communicated between the home agent and the mobile host, in a manner transparent to any NAT/NAPT firewall in the network.
Referring now to the several views of the drawings, there is provided an in-band signaling method that enables secure updates of a care-of-IP address for a mobile host that roams between access networks. In the illustrative embodiment shown and described herein, a mobile host includes an intelligent interface that handles IP networking functions and tunnels IP packets between the mobile host and the mobile host's home agent/remote access server (HA/RAS) transparently, as if the mobile host established a connection to a communicating or destination host (DST) from the home network (where the HA/RAS resides). The details of the intelligent interface are disclosed in commonly owned copending U.S. patent application Ser. No. 10/026,589, filed Dec. 19, 2001, the disclosure of which is hereby incorporated by reference.
Referring now to
In the first group of examples, the Dynamic Host Configuration Protocol (DHCP) is utilized to configure the network address. See R. Droms, “Dynamic Host Configuration Protocol,” IETF Network Working Group, RFC 2131 (March 1997); S. Alexander, R. Droms, “DHCP Options and BOOTP Vendor Extensions,” IETF Network Working Group, RFC 2132 (March 1997); which are incorporated by reference herein.
Referring now to
For the purpose of illustration, it is assumed that the intelligent interface has established a security association with the HA/RAS. In other words, the mobile host has been authenticated to the HA/RAS and all encapsulated IP packets transmitted in the tunnel between the intelligent interface and the HA/RAS are encrypted using a key shared in the security association (See IPsec RFC for the definition of Security Association).
The mobile host is in the middle of a vertical handoff procedure (i.e., handoff between two different networks). In this regard, the mobile host is departing from a first access network (AN1, for example, a cellular network) and arriving at a second access network (AN2, for example, a WLAN).
Both access networks run NAT/NAPT at their firewalls to allow IP tunnels as long as the tunnel traffic is initiated from hosts on the subnet. The care-of IP address assigned to the mobile host by AN1 is IPiAN1. Its corresponding outside IP address is IPeAN1. The care-of IP address assigned to the mobile host by AN2 is IPiAN2. Its corresponding outside IP address is IPeAN2.
The intelligent interface only knows IPiAN1 and IPiAN2, but does not know about IPeAN1 and IPeAN2. The mobile host doesn't even know the existence of IPeAN1 and IPeAN2.
The intelligent interface has a CURRENT_CA_REQ register, a KEEP_REQUESTING timer, and a CONFIRM_LINGER timer. The HA/RAS has a CURRENT_CA_ACK register, a CURRENT_CARE-OF_ADDRESS register, a CANDIDATE_CARE-OF_ADDRESS, and a BI_CASTING timer for every mobile host it serves. These registers and timers are initialized to 0 except that the CURRENT_CARE-OF_ADDRESS register is IPeAN1.
Referring now to
At 400, immediately after the mobile host has been granted access to AN2, it sends an outbound IP packet to a destination host. The source IP address is IPSRC and the destination IP address is IPDST. If the mobile host does not generate any outbound IP packet at this moment, the intelligent interface will generate an empty IP packet and send out a CA_REQ message to the HA/RAS as soon as possible.
At 402, the intelligent interface embeds a CA_REQ message as an IP header in this IP packet, encapsulates it in a new IP packet with IPiAN2 and IPHA as the source and destination IP addresses respectively, and sends this IP-in-IP packet to the HA/RAS. The CA_REQ message signals the home agent to update the care-of IP address for the mobile host. IPHA is the IP address of the home agent. The CA_REQ message contains a sequence number, which is incremented by one whenever the mobile host wants to change to a new care-of IP address. The sequence number is stored in the CURRENT_CA_REQ register of the intelligent interface. The intelligent interface will keep inserting the same CA_REQ message into each subsequent outbound IP packet until a KEEP_REQUESTING timer expires or a corresponding CA_ACK message, which contains the same sequence number as that in the CURRENT_CA_REQ register, is received from the HA/RAS via AN2. After the KEEP_REQUESTING timer goes off, the intelligent interface aborts the care-of IP address update procedure and sticks with AN1.
At 404, when this IP-in-IP packet crosses the NAT/NAPT firewall of AN2, its source IP address is changed from IPiAN2 to IPeAN2. by the NAT/NAPT firewall. A NAT/NAPT box has two interfaces. Typically, the inner interface is a network interface, and assigns private IP addresses to any computer connected to it. The outer interface is a host interface. When a packet comes from inner interface to the outer interface, the NAT uses the IP address of its outer interface to replace the source IP address of the IP packet, which is a private IP address.
The IP-in-IP packet then arrives at the HA/RAS. After this packet is decapsulated, the HA/RAS finds the embedded CA_REQ message. It initially verifies the validity of this 1P-in-IP packet based on the security association of the IP tunnel between the intelligent interface and the HA/RAS. If the IP-in-IP packet is valid, so is the CA_REQ message and the inner IP packet is forwarded to the destination host at 406 after the CA_REQ message is removed. If the inner IP packet is an empty one, the HA/RAS will drop it. The HA/RAS then checks whether the sequence number of the CA_REQ is less than or equal to that of the most recently received CA_REQ message. If this is not the case, the CA_REQ message is ignored because it has been updated by another CA_REQ message that was sent later by the intelligent interface but arrived earlier at the HA/RAS. Otherwise, the HA/RAS saves IPeAN2 in the CANDIDATE_CARE-OF_ADDRESS register and at 408 starts bicasting inbound IP packets to the mobile host at both care-of IP addresses IPeAN1 and IPeAN2. For inbound IP packets tunneled to IPeAN2, at 410 a CA_ACK message is embedded as an IP header of the inner 1P packet, which contains the sequence number that was included in the CA_REQ message. The sequence number is also stored in a CURRENT_CA_ACK register at the HA/RAS. For inbound IP packets tunneled to IPeAN1 at 412 a no CA_ACK message is embedded. The bicasting operation will terminate after a corresponding CA_YES (or CA_NO) message, which contains the same sequence number as that in the CURRENT_CA_ACK register, is received from the mobile host or after a BI_CASTING timer expires. If the HA/RAS receives a CA_YES message that contains the same sequence number as the one contained in the CURRENT_CA_ACK register, the HA/RAS will recognize IPeAN2 as the new care-of IP address for the mobile host and saves it in the CURRENT_CARE-OF_ADDRESS register. In all other scenarios, the HA/RAS still considers IPeAN1 as the care-of IP address for the mobile host.
When the bi-cast IP-in-IP packets cross the firewalls of AN1 and AN2, at 414, 416 their destination IP addresses are changed from IPeAN1 to IPiAN1 and from IPeAN2 to IPiAN2, respectively.
The intelligent interface may receive the same inbound IP-in-IP packet from AN1 and AN2. After the packet is decapsulated, the intelligent interface finds the embedded CA_ACK message from the IP packet that is received from AN2. It first verifies the validity of this IP-in-IP packet based on the security association on the IP tunnel between the intelligent interface and the HA/RAS. If the IP-in-IP packet is valid, so is the CA_ACK message and the inner IP packet is submitted to the mobile host at 418 after the CA_ACK message is removed. The intelligent interface then checks whether the sequence number in the CA_ACK message is equal to the one stored in the CURRENT_CA_REQ register. If it is, the intelligent interface stops embedding CA_REQ messages in outbound IP packets received from the mobile host at 420. Instead, it clears the CURRENT_CA_REQ register and embeds a CA_YES message at 422, which contains the same sequence number as that in the CA_ACK message, in every subsequent outbound IP packet until the CONFIRM_LINGER timer expires. At this point, the intelligent interface may release network access to AN1. If the mobile host goes back to AN1 when the first CA_ACK message is received, which can happen if the mobile host stays at the boundary of AN2, the intelligent interface embeds a CA_NO message instead of CA_YES message.
When the IP-in-IP packet carrying the CA_YES message crosses the firewall of AN2 at 424, its source IP address is changed from IPiAN2 to IPeAN2. The IP-in-IP-packet carrying the CA_YES message arrives at the HA/RAS, where it is decapsulated, and the HA/RAS finds the embedded CA_YES message. It first verifies the validity of this IP-in-IP packet based on the security association on the IP tunnel between the intelligent interface and the HA/RAS. If the IP-in-IP packet is valid, so is the CA_YES message and the inner IP packet is submitted to the destination host after the CA_YES message is removed. The HA/RAS then checks whether the sequence number in the CA_YES message is equal to that in the CURRENT_CA_ACK register. If this is the case, the HA/RAS terminates the bicasting operation at 426, clears the CURRENT_CA_ACK register and the CANDIDATE_CARE-OF_ADDRESS register, and saves IPeAN2 in the CURRENT_CARE-OF_ADDRESS register. This completes the entire care-of IP address update process.
The above described in-band signaling method is resistant to denial-of-service attacks, assuming such attacks are implemented by either sending a fake CA_REQ message to the HA/RAS, or changing IPeAN2 to some other IP address.
The only way for a hacker to conduct a denial-of-service attack is to change the IPeAN2 to the IP address of the hacker's router and then to shut down the router after a few inbound IP packets have been forwarded to AN2 by the router. If this is the case, the hacker can be easily tracked down because his router's IP address is saved in the CURRENT_CARE-OF_ADDRESS register by the HA/RAS.
The present invention has been shown and described in what is considered to be the most practical and preferred embodiment. It is anticipated, however, that departures may be made therefrom and that obvious modifications will be implemented by those skilled in the art.
| Patent | Priority | Assignee | Title |
| 8447879, | Dec 12 2001 | AT&T Properties, LLC; AT&T INTELLECTUAL PROPERTY II, L P | Secure in-band signaling method for mobility management crossing firewalls |
| 9331980, | Dec 12 2001 | AT&T Properties, LLC; AT&T INTELLECTUAL PROPERTY II, L P | Secure in-band signaling method for mobility management crossing firewalls |
| 9680793, | Dec 12 2001 | AT&T Intellectual Property II, L.P. | Secure in-band signaling method for mobility management crossing firewalls |
| Patent | Priority | Assignee | Title |
| 6195705, | Jun 30 1998 | Cisco Technology, Inc. | Mobile IP mobility agent standby protocol |
| 6915325, | Mar 13 2000 | Apple Inc | Method and program code for communicating with a mobile node through tunnels |
| 6988146, | Jul 13 2000 | Alcatel | Simple multicast extension for mobile IP SMM |
| 7146428, | Dec 12 2001 | AT&T Properties, LLC; AT&T INTELLECTUAL PROPERTY II, L P | Secure in-band signaling method for mobility management crossing firewalls |
| 20030016655, | |||
| 20030158938, | |||
| 20040047348, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jan 20 2003 | LUO, HUI | AT&T Corp | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 062385 | /0374 | |
| Oct 26 2006 | AT&T Corporation | (assignment on the face of the patent) | / | |||
| Feb 15 2023 | AT&T Corp | AT&T Properties, LLC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 062723 | /0411 | |
| Feb 15 2023 | AT&T Properties, LLC | AT&T INTELLECTUAL PROPERTY II, L P | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 062724 | /0888 |
| Date | Maintenance Fee Events |
| Nov 14 2011 | REM: Maintenance Fee Reminder Mailed. |
| Apr 01 2012 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Apr 01 2011 | 4 years fee payment window open |
| Oct 01 2011 | 6 months grace period start (w surcharge) |
| Apr 01 2012 | patent expiry (for year 4) |
| Apr 01 2014 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Apr 01 2015 | 8 years fee payment window open |
| Oct 01 2015 | 6 months grace period start (w surcharge) |
| Apr 01 2016 | patent expiry (for year 8) |
| Apr 01 2018 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Apr 01 2019 | 12 years fee payment window open |
| Oct 01 2019 | 6 months grace period start (w surcharge) |
| Apr 01 2020 | patent expiry (for year 12) |
| Apr 01 2022 | 2 years to revive unintentionally abandoned end. (for year 12) |