US20050135241A1 - Supporting mobile internet protocol in a correspondent node firewall - Google Patents
Supporting mobile internet protocol in a correspondent node firewall Download PDFInfo
- Publication number
- US20050135241A1 US20050135241A1 US10/860,574 US86057404A US2005135241A1 US 20050135241 A1 US20050135241 A1 US 20050135241A1 US 86057404 A US86057404 A US 86057404A US 2005135241 A1 US2005135241 A1 US 2005135241A1
- Authority
- US
- United States
- Prior art keywords
- network node
- address
- access blocking
- new address
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/34—Modification of an existing route
- H04W40/36—Modification of an existing route due to handover
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/02—Access restriction performed under specific conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
Definitions
- the invention relates to a method and a system for protecting a first network node (e.g., a correspondent node CN) by an access blocking function (e.g., a firewall).
- a first network node e.g., a correspondent node CN
- an access blocking function e.g., a firewall
- the invention relates in particular to mobile IP (Internet Protocol), wherein a second node having a connection to a first node is a mobile node (MN).
- MN mobile node
- Mobile IPv6 will be needed to support roaming across different access technologies, e.g. to augment 3 G (third generation) networks with Wireless Local Area Network (WLAN) hot spots.
- WLAN Wireless Local Area Network
- FW a firewall
- a mobile node is able to change its address.
- the firewall protects the correspondent node (CN) such that it allows only a link between the mobile node and the correspondent node wherein the link is identified by the addresses of the mobile node and the correspondent node (the link is referred to in the following a so-called “pinhole”). That is, in case the mobile node changes its address from an old CoA (care-of address) to a new CoA, the pinhole is no longer valid. Hence, it is necessary to newly set up the whole connection between the mobile node and the correspondent node again.
- BUs Binding Updates
- This object is solved by a method for protecting a network node by an access blocking function, wherein the access blocking function protects either a first or a second network node and allows access to the protected network node from the other network node via a link associated to an address of the first network node and an address of the second network node, wherein the second network node is adapted to change its address, the method comprising the step of,
- a network system comprising an access blocking function and at least a first network node and a second network node, wherein
- the existing link e.g., the pinhole
- the first network node e.g., the correspondent node
- the second network node e.g., the mobile node
- the old address e.g., old CoA
- the second network node e.g., the mobile node
- the old address e.g., old CoA
- the second network node may be protected.
- the new address inherits the pinhole(s) of the old address.
- a change of address of the second network node may be detected by detecting a binding update (BU) message from the second network node to the first network node, the binding update message comprising the new address of the second network node.
- BU binding update
- the new address of the second network node may be stored by the access blocking function without taking it into use. Then, it may be checked whether the new address of the second network node is valid, and, if the new address of the second network node is valid, the link associated to the old address of the second network node may be associated to the new address of the second network node.
- BA binding acknowledgement
- the binding acknowledgement message may be forwarded from the access blocking function to the second network node. Otherwise, in case the second network node does not request the binding acknowledgement message, the binding acknowledgement message may be discarded by the access blocking function.
- the new address may be waited for traffic destined to the new address of the second network node. Then, if traffic destined to the new address of the second network node is detected, the new address of the second network node may be interpreted as valid. Hence, the new address can be confirmed by checking whether the address is actually used in traffic.
- traffic transmitted between the first and the second network node may be blocked until it has been checked that the new address of the network node is valid.
- packets of the blocked traffic may be stored and forwarded to the first network node after it has been checked that the new address of the network node is valid.
- the binding update message described above may contain an identifier. Then, the binding update message may be blocked in case the identifier does not match with an expected identifier. In this way, a detection of an attack or a faulty packet can be easily performed.
- the identifier may be a sequence number of the binding update message which is increased every time a binding update message is sent from the second network node to the first network node, and the expected identifier may be a correspondingly sequence number of the previous binding update message.
- identifiers are possible, for example a Care-of Init Cookie included in a Care-of Test Init (CoTI) message used in a return routability (RR) test may be used.
- CoTI Care-of Test Init
- RR return routability
- the binding update message may comprise a timer limiting the lifetime of a binding. Then, the new address of the second network node may be discarded when the lifetime of the binding expires.
- a message e.g., a binding update (BU) message
- BU binding update
- the access blocking function may be a firewall.
- FIG. 1 shows a network layout as used according to the embodiments of the present invention
- FIG. 2 shows a message flow in a MIP handover according to the first embodiment of the present invention
- FIG. 3 a simplified block diagram of a firewall.
- CN Correspondent Node
- FW firewall
- MIP Mobile Internet Protocol
- BU Mobile Internet Protocol Binding Update
- MN Mobile Node
- CoA Care-of Address
- the CN is a server and the MN is a laptop or a communicator running client software.
- the FW handles an incoming BU in several phases:
- the FW keeps the old CoA and rejects the pending new CoA.
- FIGS. 1 and 2 Next, the embodiment is described in more detail by referring to FIGS. 1 and 2 .
- FIG. 1 shows a network layout and the location of the firewall (FW, indicated by reference numeral 13 ) in according to the present embodiment of the invention.
- FW firewall
- the FW 13 needs not protect the HA (Home Agent, indicated by reference numeral 12 ).
- the change of address of the MN 11 is indicated by moving of the MN (old connection state indicated by the dashed lines, new connection state indicated by the solid lines).
- FIG. 2 shows the messages in a MIP handover. It is noted that the FW 13 is not visible to the other elements. Therefore, the FW 13 is indicated by dashed lines. It is noted that in order to simplify the drawing, only those messages are shown which are necessary to describe the procedure according to the present embodiment.
- the handover starts with a BU message sent from the MN 11 to its HA 12 .
- MIP runs a “Return Routability” test.
- the FW 13 will pass the corresponding packets to the CN, unless there is some other reason (e.g., malformed content or forbidden address range) to drop them.
- the incoming test messages are not dangerous to the CN, and the outgoing responses will be filtered at the other end.
- the Return Routability procedure is a test by which it can be ensured that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. This test is performed by testing whether packets addressed to the two claimed addresses are routed to the mobile node.
- a so-called Home Test Init (HOTI) message and a Care-of Test Init (COTI) message are sent at the same time from the MN to the CN.
- HOTI Home Test Init
- COTI Care-of Test Init
- the HoTI message is sent via the Home Agent (HA)
- the CoTI message is sent directly (i.e., without involving the HA) to the CN.
- the CN replies with a Home Test (HoT) message sent via the HA and a Care-of Test (CoT) message sent to the MN.
- HoT Home Test
- CoT Care-of Test
- the HoTI message comprises as its source address the home address of the MN and as its destination address the CN address.
- a home init cookie is included which is a random number. This home init cookie has to be returned by the CN later and serves to give some assurance for the MN.
- the CoTI message is similar, only that the source address is the care-of address of the mobile node, and that a parameter is a Care-of Init Cookie similar to the home init cookie described above.
- the HoT message sent in response to the HoTI message comprises as its source address the CN address, and as its destination address the MN home address.
- the home init cookie and further parameters e.g., home keygen token and home nonce index, described in detail in the document mentioned above which a allow an improved security.
- the CoT message sent in response to the CoTI message is similar to the HoT message. That is, the CoT message comprises as its source address the CN address, as its destination address the MN care-of address and several parameters such as the Care-of Init Cookie and further parameters such as a care-of keygen token and care-of nonce index.
- the header of all messages described above contains (among other items) a Mobility Header (MH) Type.
- the MH Type is an 8-bit selector and identifies the particular mobility message in question. For example, for a CN proper values are 1, 2 or 5. In case the CN should be mobile itself, it needs to receive 0, 3 or 4.
- the HotI message uses the NH Type value 1
- the CoTI message uses the MH Type value 2.
- the HoT message uses the NH Type value 3
- the CoT message uses the NH Type value 4.
- the FW passes the messages necessary for the RR test. That is, packets with mobility headers are passed, if the MH type is appropriate. Moreover, if the FW protects a network that has its own HA, some other types sent to the HA must also be accepted.
- the RR test can also be carried out through a firewall.
- the firewall may also check the validity of the messages sent during the RR test. That is, the firewall can pick the Care-of Init Cookie from the CoTI and compare it to the Care-of Init Cookie included in the CoT message of the CN. In case both cookies do not match, the FW may drop the CoT message.
- the CN will accept a BU only from a node that passes the Return Routability test.
- the CN should then send a BA to the MN, which the FW can detect and treat as a confirmation of the CoA. Note that the message must be analyzed, because it may be sent also as an error report to a failing BU. Any errors will cause the FW to reject the pending CoA. If the MN didn't request a BA in the BU, the FW will drop it after confirming the CoA.
- the CN need not send a BA, unless the MN explicitly requests it. In this case the FW has to wait for some other packet going to the pending CoA.
- the waiting time should be a configuration parameter.
- the CN sends a BA, as shown in FIG. 2 .
- the FW forwards the BA to the MN (as indicated in FIG. 2 by the dashed arrow). Otherwise, the BA may be dropped, such that the BA is only used in order that the FW can confirm the correct CoA.
- Packets arriving from the new CoA will be stopped by the FW until the new CoA has been confirmed. For smooth service they should be stored temporarily instead of dropping them immediately. They can then be forwarded later when the CoA is confirmed. However, this increases the FWs vulnerability to DoS (Denial of Service) attacks by flooding, and should be a configuration option. To expedite the transition from ‘pending’ to ‘confirmed’ is another reason why the CN should send a BA for each BU.
- DoS Delivery of Service
- the FW is adapted to drop any BU's which have not been preceded by a CoTI.
- each transmission of a CoTI message may be stored, such that on receiving a BU it can be checked whether a CoTI message was transmitted between the two network nodes involved. If there is not CoTI message (or a transmission of a CoTI message) stored in the FW, the BU is dropped.
- the FW should also check those MIP details that can be checked by reading the messages, in order to increase security.
- the above mentioned required message formats may include the following rules:
- the checksum of packet should be verified.
- the checksum is a field in the Mobility Header (MH) and contains the checksum of the MH.
- the MH comprises the MH Type field described above, and the MH Type field must have a known value.
- the MH also comprises a Payload Proto field which is an 8-bit selector and identifies the type of header immediately following the Mobility Header.
- the Payload Proto field must be IPPROTO_NONE ( 59 decimal) which is a predetermined value defined for the MH.
- a Header Len field of the Mobility Header should be less than the length specified for this particular type of message.
- the BU contains a sequence number.
- the FW should drop out-of-sequence BUs before they reach a CN. That is, for each new BU, the sequence number is increased, so that the FW can expect a certain sequence number for a new BU by referring to an old BU. Hence, if the expected sequence number does not coincident with the actual sequence number of the BU, the BU is discarded.
- the BU may comprise some other kind of identifier, which should be known to the FW. If the detected identifier of a BU does not coincide with an expected identifier, the BU is discarded. The identifier may be changed in a way know to the FW, similar to the sequence number described above.
- the Care-of Init Cookie may be used. This requires that the MN includes the Care-of Init Cookie also into the BU and that the FW stores the Care-of Init Cookie during the RR test.
- this measure may be combined with the variation of the embodiment described above according to which the Care-of Init Cookies of the CoTI and COT messages are compared during the RR test.
- the BU contains a timer that limits the lifetime of a binding.
- the FW should check this timer and discard a CoA when its binding expires. This will also flush old pinholes out of the FWs memory.
- the invention works without changes to existing protocols, MNs, CNs, or HAs. Hence, it the invention can easily be implemented as an addition to existing elements.
- the FW does not participate in trust relationships or key management.
- the FW does not perform cryptographic computations.
- the invention is not restricted to firewalls, but may be applied to any kind of access blocking functions which fulfill a similar function.
- the invention is not limited to MIP but can be applied to any transport protocols in which one of the node involved in a connection may change its address.
- the protected node i.e., the CN
- the CN may be a mobile node and may changes its address. That is, for example, only the protected node may change its address wherein the other node may use a fixed address.
- the access blocking function may protect a plurality of network nodes, i.e., a cluster of correspondent nodes (CNs).
- CNs correspondent nodes
- the access blocking function (e.g., the firewall) may be implemented by software. It can be integrated in the software running at the CN, for example, or may be part of another network element (base station or the like). Alternatively, the access blocking function may be implemented as hardware, for example, as a stand-alone network element.
- the access blocking function or device may comprise a processing means 1 and two interfaces 2 and 3 .
- Each of the interfaces establishes a connection to a network element (e.g., MN and CN in the above examples).
- the processing means 1 is adapted to carry out the procedures according to the present invention. That is, the processing means 1 controls whether a connection (and in which direction) between the two network nodes is allowed or not.
- the interfaces 2 and 3 are logical interfaces. That is, the number of physical interfaces does not have to match the number of logical interfaces.
- the logical interfaces are mapped on the physical interfaces.
- the number of interfaces (logical and physical interfaces) of the access blocking function (firewall) is not limited to two interfaces.
- a firewall comprising three interfaces is possible which separates Intranet, Extranet and the Internet.
- also more interfaces are possible.
- a firewall with only one interface is possible. This is connected to a switch that sends all in- or outbound packets to a FW (and other elements such as NAT (Network Address Translator), VPN (Virtual Private Network) and virus scanner, for example), independent of the destination, and forward all packets coming from the firewall to the destination address.
- FW Network Address Translator
- VPN Virtual Private Network
- virus scanner for example
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- 1. Field of the Invention
- The invention relates to a method and a system for protecting a first network node (e.g., a correspondent node CN) by an access blocking function (e.g., a firewall).
- 2. Description of the Prior Art
- The invention relates in particular to mobile IP (Internet Protocol), wherein a second node having a connection to a first node is a mobile node (MN).
- Mobile IPv6 (MIP) will be needed to support roaming across different access technologies, e.g. to augment 3G (third generation) networks with Wireless Local Area Network (WLAN) hot spots. On the other hand, a firewall (FW) is needed to protect a node against malicious packets. However, existing stateful FWs will interfere with MIP route optimization.
- Namely, a mobile node is able to change its address. The firewall protects the correspondent node (CN) such that it allows only a link between the mobile node and the correspondent node wherein the link is identified by the addresses of the mobile node and the correspondent node (the link is referred to in the following a so-called “pinhole”). That is, in case the mobile node changes its address from an old CoA (care-of address) to a new CoA, the pinhole is no longer valid. Hence, it is necessary to newly set up the whole connection between the mobile node and the correspondent node again.
- This causes an interruption in the traffic between the two nodes, which is annoying for the users. That is, current firewalls do not support mobile IP.
- If the FW ignores Binding Updates (BUs) (i.e., avoiding changes in the CoA), MIP route optimization won't work. Many packets coming from the new CoA will be dropped, because they have no matching pinhole. All sessions have to be re-initiated from the new address. Smooth handovers are possible only if all packets are routed via the Home Agent (HA). This, however, means that no route optimization is possible.
- Hence, it is an object of the present invention to allow support of mobile IP also within firewalls.
- This object is solved by a method for protecting a network node by an access blocking function, wherein the access blocking function protects either a first or a second network node and allows access to the protected network node from the other network node via a link associated to an address of the first network node and an address of the second network node, wherein the second network node is adapted to change its address, the method comprising the step of,
-
- when the second network node changes its address, associating the link associated to the old address of the second network node to the new address of the second network node.
- Alternatively, the above object is solved by a network system comprising an access blocking function and at least a first network node and a second network node, wherein
-
- the access blocking function is adapted to protect either the first network node or the second network node by allowing access to the protected node from the other node via a link associated to an address of the first network node and an address of the second network node,
- the second network node is adapted to change its address, and,
- the access blocking function is adapted to, when the second network node changes its address, associate the link associated to the old address of the second network node to the new address of the second network node.
- Furthermore, the above object is solved by an access blocking device, wherein
-
- the access blocking device is adapted to protect either a first network node or a second network node by allowing access to the protected node from the other node via a link associated to an address of the first network node and an address of the second network node,
- to, when the second network node changes its address, associate the link associated to the old address of the second network node to the new address of the second network node.
- Hence, according to the invention the existing link (e.g., the pinhole) between the first network node (e.g., the correspondent node) and the second network node (e.g., the mobile node) which was associated to the old address (e.g., old CoA) of the second network node is associated to the new address of the second network node. It is noted that either the first or the second network node may be protected.
- In other words, according to the invention, the new address (new CoA) inherits the pinhole(s) of the old address.
- Thus, no new setup is required, and the traffic between the two nodes can continue smoothly.
- A change of address of the second network node may be detected by detecting a binding update (BU) message from the second network node to the first network node, the binding update message comprising the new address of the second network node.
- The new address of the second network node may be stored by the access blocking function without taking it into use. Then, it may be checked whether the new address of the second network node is valid, and, if the new address of the second network node is valid, the link associated to the old address of the second network node may be associated to the new address of the second network node.
- During checking whether the new address of the second network node is valid, it may be waited for a binding acknowledgement (BA) message from the first network node to the second network node transmitted in response of a binding update message comprising the new address of the second network node. Then, if the binding acknowledgement message is received, the new address of the second network node can be interpreted as valid. Thus, the check whether the new address is valid (i.e., confirmation of the new address) can be performed by waiting on a BA message.
- In case the second network node requests the binding acknowledgement message, the binding acknowledgement message may be forwarded from the access blocking function to the second network node. Otherwise, in case the second network node does not request the binding acknowledgement message, the binding acknowledgement message may be discarded by the access blocking function.
- During checking whether the new address is valid, it may be waited for traffic destined to the new address of the second network node. Then, if traffic destined to the new address of the second network node is detected, the new address of the second network node may be interpreted as valid. Hence, the new address can be confirmed by checking whether the address is actually used in traffic.
- Furthermore, traffic transmitted between the first and the second network node may be blocked until it has been checked that the new address of the network node is valid.
- During this blocking, packets of the blocked traffic may be stored and forwarded to the first network node after it has been checked that the new address of the network node is valid.
- Moreover, the binding update message described above may contain an identifier. Then, the binding update message may be blocked in case the identifier does not match with an expected identifier. In this way, a detection of an attack or a faulty packet can be easily performed.
- The identifier may be a sequence number of the binding update message which is increased every time a binding update message is sent from the second network node to the first network node, and the expected identifier may be a correspondingly sequence number of the previous binding update message.
- Also other kinds of identifiers are possible, for example a Care-of Init Cookie included in a Care-of Test Init (CoTI) message used in a return routability (RR) test may be used.
- The binding update message may comprise a timer limiting the lifetime of a binding. Then, the new address of the second network node may be discarded when the lifetime of the binding expires.
- Moreover, it may be required that the messages between the first and the second network node fulfil certain message formats. Then, a message (e.g., a binding update (BU) message) may be discarded in case it does not fulfil a required message format.
- The access blocking function may be a firewall.
- The invention is described in the following by referring to the attached drawings in which:
-
FIG. 1 shows a network layout as used according to the embodiments of the present invention; -
FIG. 2 shows a message flow in a MIP handover according to the first embodiment of the present invention, and -
FIG. 3 a simplified block diagram of a firewall. - In the following, a preferred embodiment of the invention is described.
- In the embodiment of the invention a case is described in which a Correspondent Node (CN) is protected by a firewall (FW), and receives a MIP (Mobile Internet Protocol) Binding Update (BU) from a Mobile Node (MN) that has moved to a new Care-of Address (CoA). In a typical scenario, the CN is a server and the MN is a laptop or a communicator running client software.
- In the following, the embodiment of the present invention is shortly summarized:
- The FW handles an incoming BU in several phases:
- 1. The FW detects the BU to a CN, and stores temporarily the suggested CoA without taking it into use (‘pending’).
- 2. The FW forwards the packet to the CN. The CN performs the usual validity checks and responds to the MN with a Binding Acknowledgement (BA) using the new CoA.
- 3. The FW detects the BA, and interprets it as a confirmation of the new CoA. The new CoA inherits the pinholes previously associated with the old CoA.
- 4. The FW drops or forwards the BA, depending on if the MN requested it in the BU.
- If there is no acceptable response within a reasonable time, the FW keeps the old CoA and rejects the pending new CoA.
- Next, the embodiment is described in more detail by referring to
FIGS. 1 and 2 . -
FIG. 1 shows a network layout and the location of the firewall (FW, indicated by reference numeral 13) in according to the present embodiment of the invention. There are no “enemies” (entities which possibly may attack the CN, indicated by reference numeral 14) between theFW 13 and the CN (or CNs, if a server cluster is protected by the same FW), because they are in the same security domain. Note that theFW 13 needs not protect the HA (Home Agent, indicated by reference numeral 12). InFIG. 1 , the change of address of theMN 11 is indicated by moving of the MN (old connection state indicated by the dashed lines, new connection state indicated by the solid lines). -
FIG. 2 shows the messages in a MIP handover. It is noted that theFW 13 is not visible to the other elements. Therefore, theFW 13 is indicated by dashed lines. It is noted that in order to simplify the drawing, only those messages are shown which are necessary to describe the procedure according to the present embodiment. - The handover starts with a BU message sent from the
MN 11 to itsHA 12. - As a preparation for a BU, MIP runs a “Return Routability” test. The
FW 13 will pass the corresponding packets to the CN, unless there is some other reason (e.g., malformed content or forbidden address range) to drop them. The incoming test messages are not dangerous to the CN, and the outgoing responses will be filtered at the other end. - In the following, the Return Routability (RR) test and in particular the messages involved are described in some more detail.
- In short, the Return Routability procedure is a test by which it can be ensured that the mobile node is in fact addressable at its claimed care-of address as well as at its home address. This test is performed by testing whether packets addressed to the two claimed addresses are routed to the mobile node.
- In particular, a so-called Home Test Init (HOTI) message and a Care-of Test Init (COTI) message are sent at the same time from the MN to the CN. It is noted that the HoTI message is sent via the Home Agent (HA), whereas the CoTI message is sent directly (i.e., without involving the HA) to the CN. In case of a successful test, the CN replies with a Home Test (HoT) message sent via the HA and a Care-of Test (CoT) message sent to the MN. These messages forming the Return Routability test are also illustrated in
FIG. 2 . - The HoTI message comprises as its source address the home address of the MN and as its destination address the CN address. As a parameter, a home init cookie is included which is a random number. This home init cookie has to be returned by the CN later and serves to give some assurance for the MN.
- The CoTI message is similar, only that the source address is the care-of address of the mobile node, and that a parameter is a Care-of Init Cookie similar to the home init cookie described above.
- The HoT message sent in response to the HoTI message comprises as its source address the CN address, and as its destination address the MN home address. As parameters, the home init cookie and further parameters (e.g., home keygen token and home nonce index, described in detail in the document mentioned above) which a allow an improved security.
- The CoT message sent in response to the CoTI message is similar to the HoT message. That is, the CoT message comprises as its source address the CN address, as its destination address the MN care-of address and several parameters such as the Care-of Init Cookie and further parameters such as a care-of keygen token and care-of nonce index.
- Moreover, the header of all messages described above (i.e., HoTI, CoTI, HoT and CoT) contains (among other items) a Mobility Header (MH) Type. The MH Type is an 8-bit selector and identifies the particular mobility message in question. For example, for a CN proper values are 1, 2 or 5. In case the CN should be mobile itself, it needs to receive 0, 3 or 4.
- With respect to the above-described RR messages, the HotI message uses the
NH Type value 1, and the CoTI message uses theMH Type value 2. On the other hand, the HoT message uses theNH Type value 3, and the CoT message uses the NH Type value 4. - As described earlier, it is necessary that the FW passes the messages necessary for the RR test. That is, packets with mobility headers are passed, if the MH type is appropriate. Moreover, if the FW protects a network that has its own HA, some other types sent to the HA must also be accepted.
- Hence, in this way the RR test can also be carried out through a firewall.
- According to a variation of the present embodiment, the firewall may also check the validity of the messages sent during the RR test. That is, the firewall can pick the Care-of Init Cookie from the CoTI and compare it to the Care-of Init Cookie included in the CoT message of the CN. In case both cookies do not match, the FW may drop the CoT message.
- The CN will accept a BU only from a node that passes the Return Routability test. The CN should then send a BA to the MN, which the FW can detect and treat as a confirmation of the CoA. Note that the message must be analyzed, because it may be sent also as an error report to a failing BU. Any errors will cause the FW to reject the pending CoA. If the MN didn't request a BA in the BU, the FW will drop it after confirming the CoA.
- However, according to the standard the CN need not send a BA, unless the MN explicitly requests it. In this case the FW has to wait for some other packet going to the pending CoA. The waiting time should be a configuration parameter.
- Namely, it can be assumed that there will be traffic very soon, or the MN wouldn't have sent a BU. This opens a possibility for a “pinhole hijack” attack: the attacker sends a fake BU with a CoA of a node that the CN communicates with for other reasons. In this case the FW accepts the wrong CoA as confirmed, because it sees traffic to the “new” CoA, and associates the pinholes of the MN with it.
- Requiring that the response to the new CoA must be a BA can prevent this attack. Note that the CN won't be fooled in the “pinhole hijack” attack (the fake BU fails the security check) but the FW just doesn't know it. The damage is limited to minor annoyance, because in the typical scenario the MN will refresh the sessions, reopening the needed pinholes. Protocols like TCP do it automatically.
- Nevertheless, according to a preferred variation of the first embodiment, it should be mandatory that the CN sends a BA, as shown in
FIG. 2 . In case the MN has explicitly requested a BA in the BU, the FW forwards the BA to the MN (as indicated inFIG. 2 by the dashed arrow). Otherwise, the BA may be dropped, such that the BA is only used in order that the FW can confirm the correct CoA. - Packets arriving from the new CoA will be stopped by the FW until the new CoA has been confirmed. For smooth service they should be stored temporarily instead of dropping them immediately. They can then be forwarded later when the CoA is confirmed. However, this increases the FWs vulnerability to DoS (Denial of Service) attacks by flooding, and should be a configuration option. To expedite the transition from ‘pending’ to ‘confirmed’ is another reason why the CN should send a BA for each BU.
- According to a variation of the embodiment, also another countermeasure against the “pinhole hijack” attack (the attacker sends a fake BU with a CoA of a node that the CN communicates with for other reasons) is possible. In detail, according to this variation, the FW is adapted to drop any BU's which have not been preceded by a CoTI.
- That is, each transmission of a CoTI message may be stored, such that on receiving a BU it can be checked whether a CoTI message was transmitted between the two network nodes involved. If there is not CoTI message (or a transmission of a CoTI message) stored in the FW, the BU is dropped.
- The embodiment and its variations according to the present invention can be implemented as a straightforward addition to existing FWs.
- As a further preferred variation of the embodiment described above, the FW should also check those MIP details that can be checked by reading the messages, in order to increase security.
- For example:
- In the MIP standards, certain required message formats are defined. In this way, invalid packets can be recognized by the FW, so that the FW may drop packets that fail to fulfill the required message formats. The FW can test most of them, offloading the checks from the CN.
- The above mentioned required message formats may include the following rules:
- The checksum of packet should be verified. The checksum is a field in the Mobility Header (MH) and contains the checksum of the MH.
- Furthermore, the MH comprises the MH Type field described above, and the MH Type field must have a known value.
- The MH also comprises a Payload Proto field which is an 8-bit selector and identifies the type of header immediately following the Mobility Header. The Payload Proto field must be IPPROTO_NONE (59 decimal) which is a predetermined value defined for the MH.
- A Header Len field of the Mobility Header should be less than the length specified for this particular type of message.
- Further MIP details that the FW can check by reading the messages, may include the following:
- The BU contains a sequence number. The FW should drop out-of-sequence BUs before they reach a CN. That is, for each new BU, the sequence number is increased, so that the FW can expect a certain sequence number for a new BU by referring to an old BU. Hence, if the expected sequence number does not coincident with the actual sequence number of the BU, the BU is discarded.
- As a further alternative, the BU may comprise some other kind of identifier, which should be known to the FW. If the detected identifier of a BU does not coincide with an expected identifier, the BU is discarded. The identifier may be changed in a way know to the FW, similar to the sequence number described above.
- For example, as the identifier described above also the Care-of Init Cookie may be used. This requires that the MN includes the Care-of Init Cookie also into the BU and that the FW stores the Care-of Init Cookie during the RR test. Thus, preferably this measure may be combined with the variation of the embodiment described above according to which the Care-of Init Cookies of the CoTI and COT messages are compared during the RR test.
- The BU contains a timer that limits the lifetime of a binding. The FW should check this timer and discard a CoA when its binding expires. This will also flush old pinholes out of the FWs memory.
- The invention as described above with respect to the preferred embodiment and its variations achieves the following advantages:
- The invention works without changes to existing protocols, MNs, CNs, or HAs. Hence, it the invention can easily be implemented as an addition to existing elements.
- The FW does not participate in trust relationships or key management.
- The FW does not perform cryptographic computations.
- The above description and accompanying drawings only illustrate the present invention by way of example. Thus, the embodiment and its variations may vary within the scope of the attached claims.
- For example, the invention is not restricted to firewalls, but may be applied to any kind of access blocking functions which fulfill a similar function.
- Moreover, the invention is not limited to MIP but can be applied to any transport protocols in which one of the node involved in a connection may change its address.
- Furthermore, in the above-described embodiment the protected node, i.e., the CN, has a fixed address. However, also the CN may be a mobile node and may changes its address. That is, for example, only the protected node may change its address wherein the other node may use a fixed address.
- Moreover, the access blocking function may protect a plurality of network nodes, i.e., a cluster of correspondent nodes (CNs).
- The access blocking function (e.g., the firewall) may be implemented by software. It can be integrated in the software running at the CN, for example, or may be part of another network element (base station or the like). Alternatively, the access blocking function may be implemented as hardware, for example, as a stand-alone network element.
- As illustrated in
FIG. 3 , the access blocking function or device may comprise a processing means 1 and twointerfaces - The
interfaces - That is, that the number of interfaces (logical and physical interfaces) of the access blocking function (firewall) is not limited to two interfaces. For example, a firewall comprising three interfaces is possible which separates Intranet, Extranet and the Internet. Furthermore, also more interfaces are possible.
- On the other hand, also a firewall with only one interface is possible. This is connected to a switch that sends all in- or outbound packets to a FW (and other elements such as NAT (Network Address Translator), VPN (Virtual Private Network) and virus scanner, for example), independent of the destination, and forward all packets coming from the firewall to the destination address. In this way, each packet that deals with the outside world passes twice through the switch and is handled in the firewall between the passes.
- In addition, the embodiment and its variations may be arbitrarily combined. That is, different kind of protection mechanisms may be combined in order to enhance security.
Claims (46)
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/860,574 US7620979B2 (en) | 2003-12-22 | 2004-06-04 | Supporting mobile internet protocol in a correspondent node firewall |
CN2004800382015A CN101073236B (en) | 2003-12-22 | 2004-10-21 | Supporting mobile internet protocol in a correspondent node firewall |
PCT/IB2004/003447 WO2005064888A1 (en) | 2003-12-22 | 2004-10-21 | Supporting mobile internet protocol in a correspondent node firewall |
EP04791726.5A EP1698140B1 (en) | 2003-12-22 | 2004-10-21 | Supporting mobile internet protocol in a correspondent node firewall |
KR1020067012185A KR100831088B1 (en) | 2003-12-22 | 2004-10-21 | Supporting mobile internet protocol in a correspondent node firewall |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP03029552.1 | 2003-12-22 | ||
EP03029552 | 2003-12-22 | ||
US10/860,574 US7620979B2 (en) | 2003-12-22 | 2004-06-04 | Supporting mobile internet protocol in a correspondent node firewall |
Publications (2)
Publication Number | Publication Date |
---|---|
US20050135241A1 true US20050135241A1 (en) | 2005-06-23 |
US7620979B2 US7620979B2 (en) | 2009-11-17 |
Family
ID=34740650
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/860,574 Active 2026-03-04 US7620979B2 (en) | 2003-12-22 | 2004-06-04 | Supporting mobile internet protocol in a correspondent node firewall |
Country Status (5)
Country | Link |
---|---|
US (1) | US7620979B2 (en) |
EP (1) | EP1698140B1 (en) |
KR (1) | KR100831088B1 (en) |
CN (1) | CN101073236B (en) |
WO (1) | WO2005064888A1 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080069030A1 (en) * | 2004-05-31 | 2008-03-20 | Matsushita Electric Industrial Co., Ltd. | Mobile Terminal Managing Device, Mobile Terminal, and Communication System |
US20080107124A1 (en) * | 2006-11-06 | 2008-05-08 | Jordi Ros-Giralt | System and method for supporting mobility and multipath packet delivery in ip communications and computer networks across nat and firewall boxes |
EP1971101A1 (en) * | 2007-03-12 | 2008-09-17 | Siemens Networks GmbH & Co. KG | A method , a device for configuring at least one firewall and a system comprising such device |
KR100922939B1 (en) | 2006-08-22 | 2009-10-22 | 삼성전자주식회사 | Packet filltering apparatus and method in network system using mobile ip network |
US20100027474A1 (en) * | 2007-03-16 | 2010-02-04 | Panasonic Corporation | Packet Communication Device |
US20100046558A1 (en) * | 2007-01-18 | 2010-02-25 | Panasonic Corporation | Header reduction of data packets by route optimization procedure |
US20100208706A1 (en) * | 2007-09-19 | 2010-08-19 | Jun Hirano | Network node and mobile terminal |
CN112152989A (en) * | 2019-06-26 | 2020-12-29 | 黑莓有限公司 | Method and system for updating application layers for third party telecommunications providers |
US11044652B2 (en) * | 2017-01-25 | 2021-06-22 | Huawei Technologies Co., Ltd. | Handover method and apparatus |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8171120B1 (en) | 2006-11-22 | 2012-05-01 | Rockstar Bidco Lp | Mobile IPv6 route optimization authorization |
US9516495B2 (en) * | 2007-03-01 | 2016-12-06 | Futurewei Technologies, Inc. | Apparatus and methods of PMIPv6 route optimization protocol |
EP3001647B1 (en) * | 2014-09-23 | 2017-11-01 | Siemens Aktiengesellschaft | Method for setting up a secure communication link, communication device and connection control unit |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020147820A1 (en) * | 2001-04-06 | 2002-10-10 | Docomo Communications Laboratories Usa, Inc. | Method for implementing IP security in mobile IP networks |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4201466B2 (en) | 2000-07-26 | 2008-12-24 | 富士通株式会社 | VPN system and VPN setting method in mobile IP network |
US7333482B2 (en) | 2000-12-22 | 2008-02-19 | Interactive People Unplugged Ab | Route optimization technique for mobile IP |
WO2003065682A1 (en) | 2002-01-29 | 2003-08-07 | Koninklijke Philips Electronics N.V. | A method and system for connecting mobile client devices to the internet |
US7756073B2 (en) | 2002-09-20 | 2010-07-13 | Franck Le | Method for updating a routing entry |
DE60305869T2 (en) | 2003-03-27 | 2006-10-05 | Motorola, Inc., Schaumburg | Communication between a private network and a mobile device |
-
2004
- 2004-06-04 US US10/860,574 patent/US7620979B2/en active Active
- 2004-10-21 CN CN2004800382015A patent/CN101073236B/en not_active Expired - Fee Related
- 2004-10-21 KR KR1020067012185A patent/KR100831088B1/en not_active IP Right Cessation
- 2004-10-21 EP EP04791726.5A patent/EP1698140B1/en not_active Not-in-force
- 2004-10-21 WO PCT/IB2004/003447 patent/WO2005064888A1/en not_active Application Discontinuation
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020147820A1 (en) * | 2001-04-06 | 2002-10-10 | Docomo Communications Laboratories Usa, Inc. | Method for implementing IP security in mobile IP networks |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080069030A1 (en) * | 2004-05-31 | 2008-03-20 | Matsushita Electric Industrial Co., Ltd. | Mobile Terminal Managing Device, Mobile Terminal, and Communication System |
US8036232B2 (en) | 2006-08-22 | 2011-10-11 | Samsung Electronics Co., Ltd | Apparatus and method for filtering packet in a network system using mobile IP |
KR100922939B1 (en) | 2006-08-22 | 2009-10-22 | 삼성전자주식회사 | Packet filltering apparatus and method in network system using mobile ip network |
US20080107124A1 (en) * | 2006-11-06 | 2008-05-08 | Jordi Ros-Giralt | System and method for supporting mobility and multipath packet delivery in ip communications and computer networks across nat and firewall boxes |
US20100046558A1 (en) * | 2007-01-18 | 2010-02-25 | Panasonic Corporation | Header reduction of data packets by route optimization procedure |
US20080229088A1 (en) * | 2007-03-12 | 2008-09-18 | Nokia Siemens Networks Gmbh & Co. Kg | Method, a device for configuring at least one firewall and a system comprising such device |
EP1971101A1 (en) * | 2007-03-12 | 2008-09-17 | Siemens Networks GmbH & Co. KG | A method , a device for configuring at least one firewall and a system comprising such device |
US8046442B2 (en) | 2007-03-12 | 2011-10-25 | Nokia Siemens Networks Gmbh & Co. | Method, a device for configuring at least one firewall and a system comprising such device |
US20100027474A1 (en) * | 2007-03-16 | 2010-02-04 | Panasonic Corporation | Packet Communication Device |
US20100208706A1 (en) * | 2007-09-19 | 2010-08-19 | Jun Hirano | Network node and mobile terminal |
US11044652B2 (en) * | 2017-01-25 | 2021-06-22 | Huawei Technologies Co., Ltd. | Handover method and apparatus |
CN112152989A (en) * | 2019-06-26 | 2020-12-29 | 黑莓有限公司 | Method and system for updating application layers for third party telecommunications providers |
EP3758328A1 (en) * | 2019-06-26 | 2020-12-30 | BlackBerry Limited | Method and system for updating of a firewall for a third-party telematics provider |
US11258762B2 (en) | 2019-06-26 | 2022-02-22 | Blackberry Limited | Method and system for updating of an application layer for a third-party telematics provider |
US11750565B2 (en) | 2019-06-26 | 2023-09-05 | Blackberry Limited | Method and system for updating of an application layer for a third-party telematics provider |
Also Published As
Publication number | Publication date |
---|---|
US7620979B2 (en) | 2009-11-17 |
EP1698140B1 (en) | 2014-05-14 |
CN101073236A (en) | 2007-11-14 |
EP1698140A1 (en) | 2006-09-06 |
WO2005064888A1 (en) | 2005-07-14 |
KR20060103925A (en) | 2006-10-04 |
CN101073236B (en) | 2010-10-27 |
KR100831088B1 (en) | 2008-05-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7436804B2 (en) | Methods and apparatus for using a Care of Address option | |
EP1636964B1 (en) | Ip mobility | |
KR101262405B1 (en) | Method, system and apparatus for providing security in an unlicensed mobile access network or a generic access network | |
Perkins | Rfc3344: Ip mobility support for ipv4 | |
EP2074799B1 (en) | Method and apparatus for mobile ip route optimization | |
US8413243B2 (en) | Method and apparatus for use in a communications network | |
US20030110274A1 (en) | Protecting against distributed denial of service attacks | |
JP2010507301A (en) | Method in mixed network-based and host-based mobility management | |
US7620979B2 (en) | Supporting mobile internet protocol in a correspondent node firewall | |
KR20070110864A (en) | Method, apparatus and computer program product enabling negotiation of firewall features by endpoints | |
US8015603B2 (en) | Method and mobile node for packet transmission in mobile internet protocol network | |
Perkins | RFC3220: IP Mobility Support for IPv4 | |
US20050175002A1 (en) | Alternative method to the return routability test to send binding updates to correspondent nodes behind firewalls | |
US20100275253A1 (en) | Communication method, communication system, mobile node, and communication node | |
US8036232B2 (en) | Apparatus and method for filtering packet in a network system using mobile IP | |
US20100189000A1 (en) | Prefix information check device and communication device | |
Arkko | IETF Mobile IP Working Group D. Johnson Internet-Draft Rice University Obsoletes: 3775 (if approved) C. Perkins (Ed.) Expires: January 14, 2010 WiChorus Inc. | |
Arkko | IETF Mobile IP Working Group David B. Johnson INTERNET-DRAFT Rice University Charles E. Perkins Nokia Research Center |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NOKIA CORPORATION, FINLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HIPPELAINEN, LASSI;REEL/FRAME:015445/0507 Effective date: 20040527 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: NOKIA TECHNOLOGIES OY, FINLAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NOKIA CORPORATION;REEL/FRAME:035443/0009 Effective date: 20150116 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |