WO2006021156A1 - Procede destine a assurer la mobilite d'un hote reseau et une fonction multi-localite - Google Patents

Procede destine a assurer la mobilite d'un hote reseau et une fonction multi-localite Download PDF

Info

Publication number
WO2006021156A1
WO2006021156A1 PCT/CN2005/001327 CN2005001327W WO2006021156A1 WO 2006021156 A1 WO2006021156 A1 WO 2006021156A1 CN 2005001327 W CN2005001327 W CN 2005001327W WO 2006021156 A1 WO2006021156 A1 WO 2006021156A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
host
network host
network
communication peer
Prior art date
Application number
PCT/CN2005/001327
Other languages
English (en)
French (fr)
Inventor
Fuyou Miao
Hongke Zhang
Sidong Zhang
Yan Ren
Wei Su
Shen Yang
He Yang
Zuzhou Zheng
Jian Chen
Jianglin Wang
Ying Liu
Shuai Gao
Yajuan Qin
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2006021156A1 publication Critical patent/WO2006021156A1/zh

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to network communication technologies, and more particularly to a method for implementing host mobility and multiple home functions. Background of the invention
  • IP addresses represent both the physical location in the network and the network interface.
  • the physical location represented by the IP address can help the network entity to complete the routing function, and the network entity can also connect to the network through the network interface represented by the IP address, so that the IP address can also represent an entity identity.
  • DNS Domain Name Servers
  • the plurality of townships include a plurality of host towns and a plurality of townships, and the plurality of townships and the likes, wherein the host includes an interface having a plurality of global IP addresses. Since there are multiple high-level ISP sites in the network, or the ISP site can provide multiple addresses for the host at the same time, such as IPv4 and IPv6 addresses, it is easy to have multiple sites in the site.
  • the above situation requires entities in the network, especially security gateways, to have the characteristics of multiple towns.
  • the security multiple townships are requirements for realizing the mobility of the network host and a plurality of township functions from a security perspective, such as preventing man-in-the-middle attacks and DoS attacks against target addresses in the mobile network.
  • the method of representing the physical location and interface by IP address inevitably leads to a system such as address management and the original network security protocol cannot work effectively. Column problem.
  • Method 1 Mobile IPv6 is proposed as a mobile recommendation in mobile IP technology.
  • Figure 1 shows a basic mobile IPv6 composition.
  • the mobile node is a multi-master address node that has both a care-of address and a home address, which are bound together.
  • the care-of address is used to route the IP packet, and the address is temporary. It must be checked for a return route capability before it can use the care-of address to participate in the communication.
  • the home address is used to identify the mobile node, and the data packet can be forwarded to the mobile node through the home address regardless of which link the mobile node is currently located on.
  • An "IPSec reverse tunnel” is established between the mobile node and its home network to bind the home address to the care-of address to protect the data packets sent by the home network to the mobile node.
  • the method of establishing "IPSec reverse tunnel” is as follows: Establish the security association (SA) of the above tunnel using the home address and the care-of address, and use the home address as the traffic selector.
  • SA security association
  • the node registers the current care-of address on the router acting as the home agent to complete the binding of the home address and the care-of address.
  • the router that acts as the home agent is referred to as the home agent.
  • the node that communicates with the mobile node is referred to as the "communication peer", which can be mobile or fixed.
  • the mobile node provides its own current location information to the communication peer through the "binding registration" process, and the communication peer responds with a return routable test message to confirm the establishment of the binding to the mobile node.
  • FIG. 2 shows the return routable test process.
  • the Home Initial Test (HoT) message 201 and the Transfer Initial Test (CoTI) message 202 are simultaneously transmitted from the mobile node. After the communication peer performs a small amount of processing on the HoT message 201 and the CoTI message 202, it quickly returns to the home test (HoT) ⁇ 203 and the transfer test (CoT) message 204.
  • the mobile node and the communication peer can communicate in two different modes, namely a bidirectional tunnel mode and a route optimization mode.
  • the system structure of the bidirectional tunnel mode is shown in FIG. 3, and this mode does not require the communication peer to support mobile IPv6.
  • the system structure of the route optimization mode is as shown in FIG. 4, and this mode needs to bind the care-of address of the mobile node on the communication peer.
  • Mobile IPv6 technology enforces the use of the Network Security Protocol (IPSec) between the mobile node and the home network, and establishes an Encapsulated Security Payload Security Alliance (ESP SA) using IKEvl or IKEv2 key exchange protocol to protect the mobile node and The binding registration between the home agent and the communication data passed by the two-way tunnel mode.
  • IPSec Network Security Protocol
  • ESP SA Encapsulated Security Payload Security Alliance
  • the home network mainly the home agent
  • the home agent also needs to change the location, in addition to the above-mentioned problems caused by the re-movement of the mobile node, the normal end-to-end IKE exchange connection between the home network and the mobile node will not be completed.
  • the current mobile IP technology is less flexible in security design.
  • the address change problem caused by host mobility cannot be solved well.
  • mobile IP technology still has many problems when used in conjunction with the IPSec protocol at the network layer.
  • mobile IP technology does not have much consideration for multiple home issues in network entities.
  • an IP address is used at the transport layer to identify a host.
  • the main mechanism of the HIP protocol is to add a host identifier (HI) layer between the transport layer and the network layer, and bind the transport layer to the host that marks the host identity by host identity tag (HIT) or local scope identifier (LST).
  • HIT host identity tag
  • LST local scope identifier
  • the binding diagram is shown in Figure 5. In this way, the Socket socket used in the HIP protocol is no longer combined with the IP address, thereby facilitating address changes and multiple township issues.
  • an efficient and reliable key exchange protocol needs to be set between the HIP exchange initiator and the responder.
  • the basic exchange is defined in the HIP protocol to achieve the above purpose. After the basic exchange is completed, an IPSec SA can be generated to protect the subsequent IPSec ESP communication.
  • the basic exchange process is shown in FIG. 6. In the process of exchanging messages between the two parties, the ⁇ HITi, HITr> pair always uses the public HIT key tag indicating the identity of both parties. The two parties that generate the HIT also need to save their own private keys, and the basic key exchange protocol is used to complete the identity authentication. .
  • a host identity security content HISC is established, which contains the security association of the IPSec ESP.
  • Figure 7 shows the ESP packet structure without being added to the HIP layer.
  • Figure 8 shows the ESP packet structure after adding the HIP layer.
  • HbH Hop-by-Hop
  • RH the routing header
  • DO the destination option header.
  • the method of using the HIP protocol to complete mobility and multiple township functions is as follows:
  • the mapping of IP addresses extends from static one-to-one to dynamic one-to-many to complete the movement of the network host and support of multiple townships, and allows the network host to update the address set related to the communication peer.
  • the address update is implemented by the HIP REA parameter, which allows the host to exchange address information about the IP address, interface, and the like.
  • the logical structure established by the HIP REA parameters is shown in Figure 9, which includes the host, the IPSec SA indexed by the SPI, and the host address.
  • host 1 and host 2 negotiate to establish two unidirectional IPSec SAs. Each SA records the addresses of host 1 and host 2, and selects the SPI value for its own inbound SA.
  • the address la and the address 2a are the source addresses used by the corresponding host in the basic HIP exchange, and the inbound SPI can be reached through the source address regardless of which interface the data is sent to the host.
  • the format of the HIP REA parameter is as shown in FIG. 10, including a type field 1001, a length field 1002, an SPI field 1003, an address lifetime domain 1004, a P domain 1005, a reserved domain 1006, and an address domain 1007.
  • the network host can freely introduce a new SPI by defining the SPI field 1003.
  • all the addresses assigned to the old SPI work normally, and the new address in the HIP REA parameter is associated with the new SPI.
  • the P field 1005 defines the preferred address. If the first address in the HIP REA parameter is the new preferred address, the field is set to 1, otherwise it is set to 0.
  • the initiator when the initiator discovers that the IP address changes, it performs address grouping and SH address allocation, and establishes a HIP REA parameter for each packet. Only the first address in the REA parameter can be specified as the preferred address. If there are multiple REA parameters, these parameters should be sorted and the new preferred address is in the first REA parameter. Then, the initiator sends all the HIP REA parameters established through the basic exchange HIP message shown in FIG. 6 to the responding end.
  • the responder when it receives a REA parameter, it checks whether the SPI listed in the REA parameter is new. If it is, it establishes an SPI without an address, otherwise it adds the new address carried in the REA parameter to the existing SPI. .
  • the HIP technology is based on the public key as the host name, so it is easy to solve the identity authentication problem, but the basic HIP exchange can provide a single security function and the flexibility is not very good.
  • the existing HIP protocol simply proposes to use IPSec ESP to protect communication content, but does not propose how to generate SA definitions.
  • the HIP technology is only applicable to the ESP transmission mode between end-to-end, but cannot support the tunnel mode and the authentication header (AH) protocol.
  • the method is characterized in that the method comprises the following steps:
  • the Internet host exchange protocol is used between the network host and the network host as its communication peer to establish a pair of Internet Protocol security associations with the addresses of the two parties as their own addresses, and bind the above security association to the network host and It communicates with the host identifier of the peer network host;
  • the network host changes its own communication address, it sends the updated address to the communication peer, and modifies its own SA address to the updated address.
  • the communication peer receives the updated address sent by the network host, finds the corresponding security association according to the host identifier from the network host, modifies its own security association address to the updated address, and then uses the updated address to secure the communication peer.
  • the federation communicates with the network host.
  • the method for establishing an Internet Protocol security association in step A is to perform an IKE_SA-INIT exchange and an IKE_AUTH exchange between the network host and the communication peer.
  • the IKE-AS-INIT exchange includes a first request message and a first response message; and the IKE-AUTH exchange includes a second request message and a second response message.
  • the process of the IKE-SA-INIT exchange is specifically as follows:
  • the network host sends a first request to the communication peer to send a message, and the communication peer receives the first request message, and then responds to the first response message to the network host, and generates a key seed;
  • the network host receives the first response packet and generates a key seed.
  • the network host and the communication peer respectively generate the SAS key of the Internet Key Exchange Protocol Alliance by using the key seed generated by itself.
  • Both the first request message and the first response message include the following payloads: a header payload, a security association payload, a key exchange payload, and a Nonce payload;
  • Both the second request message and the second response message include the following payloads: header payload, identity payload, and authentication payload.
  • the security association key includes an encryption key and an integrity protection key, and the first request message, the first response message, the second request message, and the second response message, except for the header payload Other than the payload is encrypted with the Security Association key.
  • the method for the network host to send the updated address to the communication peer is as follows: The network host initiates an INFORMATIONAL exchange, and sends the updated address to the communication peer.
  • the process of the INFORMATIONAL exchange is specifically: the network host sends a fourth request message to the communication peer; after receiving the fourth request message, the communication peer replies with the fourth response message to the network host.
  • Both the fourth request message and the fourth response message include the following loads: a head load and an announcement load.
  • the advertisement payload includes the following domains: a protocol ID field, an SPI size field, an advertisement message type field, a security parameter index field, and an advertisement data field;
  • the advertisement data field is set with a HIP_NOTIFY-REA parameter.
  • the method for the network host to send the updated address to the communication peer is as follows:
  • the network host records its own host identifier and new in the HIP_ NOTIFY-REA parameter of the fourth request message.
  • step C the communication peer updates the SA address by: the communication peer uses the new IP address extracted from the fourth request packet as the updated SA address.
  • the HIP_NOTIF-REA parameter further records: an SPI associated with the new IP address, an address lifetime, and whether the new address is a preferred address identifier;
  • step C the method for the communication peer to find the security association further includes: determining the security association according to the received SPI.
  • the network host records its own interface and IP address in the HIP_ NOTIFY-REA parameter of the fourth request message and marks the preferred interface, and then sends the fourth request message to the communication peer end;
  • step C the communication peer updates the SA address by using the preferred interface and IP address extracted from the fourth request packet as the updated SA address.
  • the method for the network host to send the updated address to the communication peer in step B is as follows:
  • the network host records the IP address currently used by the interface in the HIP_NOTIFY_REA parameter of the fourth request message, and sends the fourth request message to the communication peer end; in step C, the communication peer end updates the SA address.
  • the method is: the communication peer uses the IP address currently used by the network host extracted from the fourth request message as the updated security association address.
  • the network host and/or communication peer includes a security gateway.
  • the method for implementing host mobility and multiple township functions of the present invention does not need to re-establish a security association (SA) when the address of any one of the two parties changes, and only needs to update the security association address.
  • SA security association
  • Security federation with a new address can be used to secure end-to-end communications so that both communicating parties continue to communicate.
  • the method of the invention can better support communication scenarios such as general mobility, multiple hometowns, multiple townships, and network renumbering.
  • 1 is a basic mobile IPv6 component structure in the prior art
  • FIG. 2 is a return routable test process in the prior art
  • FIG. 5 is a schematic diagram of joining a host identifier layer and binding at a transport layer and a network layer in the prior art
  • Figure 10 is a format of a HIP REA parameter in the prior art
  • FIG. 11 is a flowchart of implementing host mobility and multiple township functions in the present invention
  • FIG. 12 is a flowchart of establishing a security alliance by using the IKE protocol according to a preferred embodiment of the present invention
  • FIG. 14 is a process of an INFORMATIONAL exchange in a preferred embodiment of the present invention
  • FIG. 15 is a format of an announcement payload in a preferred embodiment of the present invention
  • FIG. 17 is a schematic diagram showing the relationship between hosts in multiple townships, IPSec SAs indexed by SPI, and addresses in a preferred embodiment of the present invention. Mode for carrying out the invention
  • FIG. 11 is a flowchart of implementing host mobility and multiple township functions according to the present invention, which specifically includes the following steps:
  • Step a adding a host identifier layer between the transport layer and the network layer, setting a host identifier (HI) for each network host in the mobile network, and binding the transport layer by a host identity tag HIT or a local scope identifier LST Go to HI.
  • HI host identifier
  • This step is the same as the existing HIP protocol, and is not described here.
  • Step b The network host and the network host as its communication peer use an Internet Key Exchange Protocol (IKE) to establish an Internet Protocol security association with the address of the communication party as its own address, and bind the security association to the security association.
  • IKE Internet Key Exchange Protocol
  • the network host and the communication peer refer to a pair of network entities that communicate, and the network host or the communication peer may be a security gateway, and the process of establishing an SA (Security Association) by using the IKE protocol As shown in FIG. 12, the process is completed by performing a plurality of sets of exchanges, which refer to a pair of request and response messages sent between the originating end and the responding end.
  • SA Security Association
  • Step 1201 The originating end sends a first request message to the responding end, where the first request message includes the following payloads: a head load (HDR), a security association payload (SAil), a key exchange payload (KEi), and Nonce load (Ni).
  • HDR head load
  • SAil security association payload
  • KEi key exchange payload
  • Ni Nonce load
  • Step 1202 After receiving the first request message, the responding end sends a first response message to the initiator, where the first response message includes the following loads, namely HDR, SArl payload, KEr payload, and Nr payload.
  • the responder selects a set of encryption algorithms from the options provided by the SAil payload. And inform the initiator to inform the initiator through the SArl payload.
  • the above steps 1201 ⁇ 1202 perform IKE_SA-INIT exchange, and the two parties exchange the parameter values such as encryption algorithm, Nonces and DH exchange through the group exchange.
  • the network host and the communication peer can be the initiator of the IKE-SA-INIT exchange.
  • Step 1203 The initiator sends a second request message to the responding end, where the message carries an identity payload (IDi) and an authentication payload (AUTH).
  • IDi identity payload
  • AUTH authentication payload
  • the IDi payload is used to declare its identity
  • the AUTH payload is used to prove the secret information related to the IDi payload and to protect the content integrity of the second request message.
  • the second request message optionally carries an IDr payload, so that the originating end can specify the identity of the responding end.
  • Step 1204 The responding end uses the received SAi2 payload to start negotiating the IPSec SA, and returns a second response packet to the initiator, where the packet carries the IDr payload and the AUTH payload, and the IPSec SA negotiation is completed.
  • the IDr payload is used to declare the identity of the responder, and the AUTH payload is used to authenticate the identity and protect the integrity of the second response message.
  • the above steps 1203 ⁇ 1204 perform IKE-AUTH exchange, which is used for authentication messages, exchange of identities and certificates.
  • both the initiator and the responder After the steps 1201 ⁇ 1202, both the initiator and the responder generate a key seed (SKEYSEED) and use SKEYSEED to generate the SA key of the IKE SA.
  • the security association key includes a completion encryption (SK-e) key and integrity protection (SK_a) key.
  • SK-e completion encryption
  • SK_a integrity protection
  • an encryption material (SK_d) key can be generated as needed to generate the required cryptographic material in the subsequent IPSec SA phase.
  • SK ⁇ ... ⁇ in the second request message and the second response message indicate that the load in the parentheses uses the SK-e and 81 (_ respectively) encryption and integrity protection in this direction.
  • SKEYEED prf(Ni
  • prf+ is used to generate pseudo-random numbers, and the execution of prf+ ( ) is determined by SK_d, SK_ai, SK-ar, SK— Ei, SK_er, SK-pi and SK-pr are connected in series.
  • an IKE_SA- ⁇ exchange and an IKE-AUTH exchange can be performed to establish an Internet Protocol Security Association (SA) between the network host and the communication peer. Therefore, the process shown in Figure 12 is called initial exchange.
  • SA Internet Protocol Security Association
  • the IKE protocol also defines CREATE-IPSEC-SA exchange, which is used to establish future IPSec SAs. This group exchange is not mandatory. After the initial exchange is completed, the CREATE_IPSEC_SA exchange can be initiated by either end of the communication. The specific process is shown in Figure 13:
  • the originating end sends a third request message to the responding end, the message carrying a head load, an SA load, a Ni load, a KEi payload, a TSi and a TSr payload, and the like.
  • the SA payload is used to send the SA offer;
  • the Ni payload is used to send the Nonce;
  • the KEi payload is optional for transmitting the Diffie-Hellman value;
  • the TSi and TSr payloads are also optional for transmitting the traffic selector.
  • the content of the message after the header payload is encrypted with the security association key.
  • Step c When the network host changes its own communication address, the network host sends the updated address to the communication peer, and modifies its own SA address to the updated address.
  • the network host sends the updated address to the communication peer, so that when the network host switches between different IP addresses, Ability to maintain normal communication with the communication peer.
  • the process of INFORMATIONAL exchange is shown in Figure 14, which includes the following steps:
  • the network host sends a fourth request message to the communication peer end, where the message carries a header payload, an advertisement payload, and the like. At this point, the network host becomes the initiator of the INFORMATIONAL exchange process.
  • the format of the notification payload (N) carried in the fourth request packet is as shown in FIG. 15, and the payload includes the following fields:
  • Protocol ID (1 byte). If this notification is about an existing SA, this field is used to indicate the SA type. For IKE-SA notifications, this field is 1. For IPSec SA advertisements, the domain is 2 when it represents AH, and when the domain is 3, it represents ESP. For advertisements that are not associated with an existing SA, this field must be set to 0 and ignored on reception. Other values for this field are reserved and may be allocated by IANA in the future.
  • SPI size (1 byte), in bytes, or 0 if there is no SPI. When the advertisement is an announcement about an IKE SA, the SPI size must be 0. (3) Announcement message type (2 bytes). (4) Security parameter index SPI (variable length). (5) Announce data (variable length), the value of this field is related to the type.
  • the advertisement data in the advertisement payload may be an error message indicating that the SA cannot be established, or may be status information transmitted by the program managing the SADB to another program. Among them, the value of 0-16383 is used to report errors.
  • a new type of advertisement data is defined, which is used for exchanging address change information between network hosts.
  • the type name is HIP-NOTIFY-REA, the value is set to 40960, and the HIP-NOTIFY-REA notification data format is as shown in the figure. 16 is shown.
  • Attribute Type (7 bits), used to indicate the address type, is the unique identifier of the configuration attribute type; (3) length (2 bytes) in bytes; (4) address lifetime, in seconds; 5) Preferred address ⁇ , if the first address in HIP_ NOTIFY-REA is the new preferred address, the field is set to 1, otherwise it is set to 0; (6) Reserved, set to 1 when transmitting, and received ignored; 7) Address, which can be an IPv6 address or an IPv4 address in IPv4-in-IPv6 format; (8) A variable length value (0 or more bytes) for configuring the variable length value of the attribute.
  • Step d The communication peer receives the updated address sent by the network host, finds the corresponding security association according to the host identifier from the network host, and modifies its own security association address to the updated address, and then the communication peer uses the updated address.
  • the security association communicates with the network host and the process ends.
  • a network host has only one interface, and the interface has only one IP address.
  • a pair of SAs with opposite directions are established between the network host and the communication peer.
  • the host moves from the home network to other foreign networks when communicating with the communication peer, the host needs to use the address prefix of the foreign network, so the address bound to the host interface changes.
  • the network host In order to maintain the communication relationship with the communication peer, the network host initiates an INFORMATIONAL exchange, and informs the communication peer of the following information through the HIP_ NOTIFY-REA parameter of the fourth request message: host identifier (HI), new IP address, and new IP address. Address-related SPI, address lifetime, and whether the new IP address is the preferred address. At the same time, the network host updates its own pair of SAs with a new IP address.
  • the communication peer 27 Since the HI of the network host does not change during the mobile process, the communication peer 27
  • HI in the HIP_ NOTIFY_REA parameter a pair of security associations bound to the HI are found, and the original address of the security association is replaced by the new IP address. Thereafter, the updated security association communication is used between the network host and the communication peer to process the communication data sent between each other.
  • the two parameters of HI and SPI related to the new IP address may also be jointly searched.
  • the multiple homes of the host refer to the case where the network host has multiple interfaces, and each interface has an IP address.
  • the IP address of the network host changes because each interface corresponds to an IP address.
  • the network host can notify the communication peer of the interface and IP address through the HIP_ NOTIFY-REA parameter, and indicate the preferred interface and IP address.
  • the peer end After receiving the interface and IP address information of the network host, the peer end preferentially updates the corresponding SA address with the preferred interface and IP address. After that, both parties use the updated security association to process the communication data.
  • the multiple townships at the site refer to a network host that contains an interface with multiple IP addresses.
  • the network host can select an IP address to communicate according to the actual situation, and send the selected IP address to the communication peer through the HIP_NOTIFY-REA parameter.
  • the processing of this case is similar to general mobility and will not be described here.
  • the renumbering operation of the IPv6 network will be more frequent than other networks.
  • the IPv6 prefix change of the link advertisement, the reconnection of the PPP link, or the new DHCP allocation will cause the network to be renumbered.
  • all host addresses on the network change.
  • the network host needs to inform the communication peer of the address change through the HIP_NOTIFY_REA parameter. This process is similar to general mobility and will not be described in detail here.
  • IKE Internet Key Exchange Protocol
  • the method for implementing host mobility and multiple township functions through the IKE protocol in the present invention can be compatible with the IKEv2 key exchange protocol proposed by the IETF organization, and the detailed description of the IKEv2 key exchange protocol is not given here, and the IKEv2 protocol is not provided. Specific details can be found in the relevant agreement.
  • the method for implementing host mobility and multiple township functions of the present invention does not need to re-establish a security association (SA) when the address of any one of the two parties changes, and only needs to update the security association address.
  • SA security association
  • the existing security alliance can be used to ensure the security of end-to-end communication, so that the communication parties can continue to maintain communication, so that communication scenarios such as general mobility, multiple hometowns, multiple townships, and network renumbering can be well supported. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

一种实现主机移动性和多家乡功能的方法 技术领域
本发明涉及网络通信技术, 尤指一种实现主机移动性和多家乡功 能的方法。 发明背景
当前, Internet 网络在世界范围内存在两种名称空间, 分别是 IP 地址和域名服务器(DNS )。 实际使用中, IP地址既代表网络中的实 体位置, 也代表网络接口。 IP地址代表的实体位置可以帮助网络实体 完成路由功能, 而网络实体还能通过 IP地址代表的网络接口连接到 网络上, 从而使 IP地址还能代表一个实体身份。 当网络拓朴基本固 定的时候, 现有这种 IP地址的使用方法并没有太多的问题。
然而, 随着人们对移动性要求的日益增长, 网络中的移动节点不 断增加, 网络拓朴将无法保持固定不变。 同时, 随着网络设置日益复 杂, 许多网络实体还出现了多家乡现象。 所述多家乡包括主机多家乡 和站点多家乡等,其中站点多家乡指的是主机包含一个具有多个全球 IP地址的接口。 由于网络中存在多个高层 ISP站点, 或者 ISP站点能为 主机同时提供多个地址, 比如 IPv4和 IPv6地址, 就容易出现站点多家 乡的情况。
上述情况要求网络中的实体, 特别是安全网关, 需要具有安全多 家乡的特点。所述安全多家乡是从安全的角度对实现网络主机的移动 性和多家乡功能提出的要求,比如防止移动网络中出现中间人攻击和 针对目标地址的 DoS攻击等。 此时, 通过 IP地址代表实体位置和接口 的方法必然导致如地址管理、原有网络安全协议不能有效工作等一系 列问题。
为解决网络实体的移动性问题, 现有技术提出了两种实现方法。 方法一、 在移动 IP技术中提出移动 IPv6作为一种可用的移动建 议。
图 1所示的是一个基本的移动 IPv6組成。 其中, 移动节点是一个 多主机地址节点, 它同时拥有一个转交地址和一个家乡地址, 这两个 地址绑定在一起。 转交地址用来路由 IP包, 且该地址是临时的, 必须 要对它进行一个返回路由能力检查之后, 才能使用转交地址参与通 信。 家乡地址用来识别移动节点, 无论移动节点当前位于哪个链路, 都可以通过家乡地址将数据包转发给该移动节点。
移动节点和自身家乡网络之间会建立一个 "IPSec反向隧道" , 将家乡地址与转交地址绑定,以保护由家乡网络送达移动节点的数据 包。 建立 "IPSec反向隧道" 的方法为: 使用家乡地址和转交地址建 立上述隧道的安全联盟 ( SA ) , 并用家乡地址作为流量选择器。 当 移动节点在外地链路时,该节点会在作为家乡代理的路由器上注册当 前的转交地址, 以完成家乡地址与转交地址的绑定, 以下将作为家乡 代理的路由器简称为家乡代理。
在图 1中, 与移动节点通信的节点被称为 "通信对端" , 它可以 是移动或固定的。 移动节点通过 "绑定注册" 过程向通信对端提供自 身当前的位置信息, 通信对端会回复一个返回可路由测试报文, 来向 移动节点确认绑定的建立。
图 2所示的是返回可路由测试过程。 其中, 家乡初始测试(HoT ) 报文 201和转交初始测试( CoTI )报文 202同时从移动节点发送。 通信 对端对 HoT报文 201和 CoTI报文 202作少量处理后, 快速返回家乡测试 ( HoT ) ^艮文 203和转交测试(CoT )报文 204。 移动节点与通信对端之间可以采用两种不同的模式进行通信,分 別是双向隧道模式和路由最佳化模式。所述双向隧道模式的系统结构 如图 3所示, 这种模式不要求通信对端能支持移动 IPv6。 所述路由最 佳化模式的系统结构如图 4所示, 这种模式需要在通信对端上绑定移 动节点的转交地址。
在协议规定中, 移动 IPv6技术强制要求移动节点和家乡网络之 间使用网络安全协议 (IPSec ) , 并采用 IKEvl或者 IKEv2密钥交换 协议建立封装安全载荷安全联盟 (ESP SA ) , 来保护移动节点和家 乡代理之间的绑定注册和双向隧道模式传递的通信数据。
但是, 釆用移动 IPv6技术支持网络实体的移动性存在以下问题:
1、 当移动节点再次发生移动, 或者移动节点与家乡网络建立连 接的接口 IP地址发生改变时,原先用来保护通信的 ESP SA就不可用 了。 在这种情况下, 要想继续保护通信数据, 只能采用重建 SA的方 式。 然而, 重建 SA的过程需要的操作代价较大, 会给正常通信带来 延时, 并会由于过多占用无线信道带宽而造成网絡性能下降。
如果移动节点在网络中的位置 /地址不断变化, 就会给网络通信 造成 "通信流量风暴" , 并可能造成网络拥塞。
2、 当家乡网络, 主要是家乡代理, 也需要发生位置改变时, 除 了上述由于移动节点的再次移动引发的问题外,家乡网络和移动节点 之间将无法完成正常的端到端 IKE交换连接。
3、 移动节点和通信对端之间正常建立各种 IPSec连接后, 如果 双方之中任何一方或者双方都发生移动, 同样会出现以上所描述的情 况。尤其在通信双方都在移动时, 更容易发生 "通信流量风暴"和 "端 到端 IKE交换连接无法完成" 等情况。
综上所述, 目前这种移动 IP技术在安全设计上的灵活性较差, 还不能较好地解决主机移动带来的地址变化问题。 特别是, 移动 IP 技术在与网絡层的 IPSec协议共同使用时, 仍存在许多问题。 此外, 移动 IP技术对于网络实体的多家乡问题也没有太多地考虑。
方法二、 通过主机身份协议 (HIP ) 实现主机移动性和多家乡功
^匕
3匕。
传统的 TCP/IP协议中,在传输层使用 IP地址来标识一个主机。 HIP 协议的主要机制是在传输层和网络层之间加入一个主机标识符 ( HI ) 层, 并将传输层通过主机身份标记(HIT )或者本地范围标识(LST ) 绑定到标记主机身份的主机标识符 (HI ) 上, 绑定示意图见图 5。 这 样, HIP协议中使用的 Socket套接口不再和 IP地址结合, 从而为解决 地址变化以及多家乡等问题带来便利。
进一步地,为了在通信对端的对等体地址改变时保证 HIP协议端 到端通信的安全性,需要在 HIP交换发起端和响应端之间设置一种高 效、 可靠的密钥交换协议。 HIP协议中定义了 "基本交换" 来实现上 述目的, 完成基本交换后就能生成一个 IPSec SA来保护随后进行的 IPSec ESP通信, 所述基本交换过程如图 6所示。 在双方交换消息的 过程中, 始终采 <HITi, HITr>这对表示双方身份的公开 HIT 密钥 标记,产生 HIT的双方还需要各自保存自身的私有 钥, 由基本密钥 交换协议来完成身份认证。
HIP 协议基本交换完成之后, 就建立一个主机身份安全内容 HISC, 该内容中包含有 IPSec ESP的安全联盟。 图 7为未加入 HIP 层的 ESP报文结构, 图 8为加入 HIP层后的 ESP报文结构。 其中, HbH ( Hop-by-Hop ) 为逐跳选项头部, RH为路由头部, DO 为目的 选项头部。
使用 HIP协议来完成移动性和多家乡功能的方法如下: 将 HI到 IP地址的映射从静态的一对一扩展到动态的一对多,来完成对网络主 机的移动和多家乡的支持,并允许网络主机更新与通信对端相关的地 址集。 上述过程中, 地址更新由 HIP REA参数实现, 该参数允许主 机交换关于 IP地址、 接口等地址信息。
由 HIP REA参数建立的逻辑结构如图 9所示, 包括主机、 由 SPI 索引的 IPSec SA和主机地址。 在图 9中, 主机 1和主机 2通过协商 建立两个单向 IPSec SA, 每个 SA都记录有主机 1和主机 2的地址, 并分别为自身的入站 SA选择 SPI值。 地址 la和地址 2a是对应主机 在基本 HIP 交换中使用的源地址, 无论数据发送到主机的哪一个接 口, 都能通过源地址到达入站 SPI。
HIP REA参数的格式如图 10所示, 包括类型域 1001、 长度域 1002、 SPI域 1003、 地址生存期域 1004、 P域 1005、 保留域 1006和 地址域 1007。 网络主机可以通过定义 SPI域 1003 , 来随意引入新的 SPI。 一方面, 如果接收到的 HIP REA参数中有新的 SPI, 所有指定 给旧 SPI的地址正常工作, 同时令 HIP REA参数中的新地址与新 SPI 相关联。 另一方面, 如果接收到的 HIP REA参数中有一个网络主机 已知的 SPI,就用 HIP REA参数中的新地址取代网络主机上所有与这 个 SPI相关的地址。 P域 1005定义的是首选地址, 如果 HIP REA参 数中的第一个地址是新的首选地址, 则该域置 1 , 否则置 0。
根据上述定义, 通过发送和处理 HIP REA参数来完成地址更新 的过程如下:
首先、 发起端在发现 IP地址改变时, 进行地址分组和 SH地址 分配, 并为每个分組建立一个 HIP REA参数。 REA参数中只有第一 个地址可以被指定为首选地址。 如果有多个 REA参数, 这些参数应 该进行排序, 并使得新的首选地址在第一个 REA参数中。 然后、 发起端通过图 6所示的基本交换 HIP报文将建立的所有 HIP REA参数发送给响应端。
最后、 当响应端接收到一个 REA参数后, 检查该 REA参数中列 出的 SPI是否为新,如果是就建立一个没有地址的 SPI,否则就将 REA 参数中携带的新地址加入已存在的 SPI。
采用 HIP 协议支持网络实体的移动性和多家乡功能存在以下问 题:
1、 HIP 技术基于公钥做为端主机名称, 故容易解决身份认证问 题, 但是基本 HIP交换所能提供的安全性功能比较单一, 灵活性也不 是很好。
2、 现有 HIP协议只是简单地提出用 IPSec ESP来保护通信内容, 却没有提出如何生成 SA的定义。
3、 HIP技术只适用于端到端之间采用 ESP传输模式的情况, 却 不能支持隧道模式和认证头部 (AH ) 协议。
从上面提到的两种方法看出, 现有技术对于实现主机移动性和多 家乡功能还没有较好的解决方法。 发明内容
本发明的目的在于,提供一种实现主机移动性和多家乡功能的方 法, 在通信双方中的任一方地址发生变化时, 还能使用安全联盟来保 持通信。
为达到上述目的, 本发明的技术方案具体是这样实现的: 一种实现主机移动性和多家乡功能的方法,在移动网络的传输层 和网络层之间加入主机标识符层,并在所述主机标识符层为移动网络 中的每个网络主机设置主机标识符; 其特征在于, 该方法包括以下步骤:
A、 网络主机和作为其通信对端的网络主机之间使用互联网密钥 交换协议,建立一对以通信双方地址作为自身地址的互联网协议安全 联盟,并将上述安全联盟绑定到所述网络主机和其通信对端网络主机 的主机标识符上;
B、 网络主机在自身通信地址变化时, 将更新后地址发送至通信 对端, 并将自身安全联盟地址修改为更新后地址;
C、 通信对端接收到网络主机发送的更新后地址, 根据来自网络 主机的主机标识符查找到对应的安全联盟,将自身安全联盟地址修改 为更新后地址,然后通信对端使用更新地址的安全联盟与网络主机进 行通信。
步骤 A所述建立互联网协议安全联盟的方法为:在网络主机和通 信对端之间执行一次 IKE_SA— INIT交换和一次 IKE_AUTH交换。
所述 IKE一 SA—INIT交换包括第一请求报文和第一应答报文; 所述 IKE—AUTH交换包括第二请求报文和第二应答报文。
所述 IKE一 SA— INIT交换的过程具体为:
网络主机向通信对端发出第一请求才艮文 ,通信对端接收到第一请 求报文后回复第一应答报文给网络主机, 并生成密钥种子;
网絡主机收到第一应答报文, 生成密钥种子;
网络主机和通信对端分别利用自身生成的密钥种子,生成互联网 密钥交换协议联盟的安全联盟密钥。
所述第一请求报文和第一应答报文都包括以下载荷: 头部载荷、 安全联盟载荷、 密钥交换载荷和 Nonce载荷;
所迷第二请求报文和第二应答报文都包括以下载荷: 头部载荷、 身份载荷和认证载荷。 所述安全联盟密钥包括完成加密密钥和完整性保护密钥, 则所述 第一请求报文、 第一应答报文、 第二请求报文和第二应答报文中, 除 头部载荷之外的其它载荷都采用安全联盟密钥进行加密。
步骤 B所述网络主机发送更新后地址到通信对端的方法具体为: 网络主机发起一次 INFORMATIONAL交换, 将更新后地址发送到通 信对端。
所述 INFORMATIONAL交换的过程具体为: 网络主机向通信对 端发出第四请求报文; 通信对端接收到笫四请求报文后, 向网络主机 回复第四应答 文。
所述第四请求艮文和第四应答报文都包括以下载荷: 头部载荷和 通告载荷。
所述通告载荷包括以下域: 协议 ID域、 SPI 大小域、 通告报文 类型域、 安全参数索引域和通告数据域;
其中, 所述通告数据域设置有 HIP_NOTIFY一 REA参数。
当网络主机发生 IP地址切换时, 步骤 B所述网络主机发送更新 后地址到通信对端的方法具体为: 网络主机在第四请求报文的 HIP— NOTIFY— REA参数中记录自身主机标识符和新 IP地址, 并向通 信对端发出上述第四请求报文;
则步骤 C中, 通信对端更新安全联盟地址的方法为: 通信对端用 从第四请求报文中取出的新 IP地址作为更新后的所述安全联盟地址。
所述 HIP— NOTIFY—REA参数中进一步记录有:与新 IP地址相关 的 SPI、 地址生存期, 以及新地址是否为首选地址标识;
则步骤 C中, 通信对端查找安全联盟的方法进一步包括: 根据接 收到的 SPI确定安全联盟。
当网络主机具有一个以上接口,且所述网络主机改变与通信对端 的通信接口时,步骤 B所述网络主机发送更新后地址到通信对端的方 法具体为:
网络主机在第四请求报文的 HIP— NOTIFY—REA参数中记录自身 接口和 IP地址并标记首选接口, 然后向通信对端发出上述第四请求 报文;
则步骤 C中, 通信对端更新安全联盟地址的方法为: 通信对端用 从第四请求报文中取出的首选接口和 IP地址作为更新后的所述安全 联盟地址。
当网络主机包含一个具有一个以上 IP地址的接口, 且网络主机 在同一接口的 IP地址之间切换时, 步骤 B所述网络主机发送更新后 地址到通信对端的方法具体为:
网络主机在第四请求报文的 HIP_NOTIFY— REA参数中记录所述 接口当前使用的 IP地址, 并向通信对端发出上述第四请求报文; 则步骤 C中, 通信对端更新安全联盟地址的方法为: 通信对端用 从第四请求报文中取出的网络主机当前使用的 IP地址作为更新后的 所述安全联盟地址。
所述网络主机和 /或通信对端包括安全网关。
由上述技术方案可见,本发明的这种实现主机移动性和多家乡功 能的方法, 在通信双方中的任一方地址发生变化时, 无需重新建立安 全联盟 (SA ) , 仅需更新安全联盟地址, 就能使用具有新地址的安 全联盟来保证端到端通信的安全性, 使通信双方继续保持通信。
本发明所述的方法能较好地支持一般移动性、 主机多家乡、 站点 多家乡和网络重编号等通信场景。 图 1为现有技术中一个基本的移动 IPv6组成结构; 图 2为现有技术中返回可路由测试流程;
图 3为现有技术中双向隧道模式的系统结构;
图 4为现有技术中路由最佳化模式的系统结构;
图 5 为现有技术中在传输层和网络层加入主机标识符层并绑定 的示意图;
图 6为现有技术中 HIP协议的基本交换流程;
图 7为现有技术中未加入 HIP层的 ESP 艮文结构;
图 8为现有技术中加入 HIP层后的 ESP报文结构;
图 9为现有技术中 HIP REA参数建立的逻辑结构;
图 10为现有技术中 HIP REA参数的格式;
图 11为本发明中实现主机移动性和多家乡功能的流程; 图 12为本发明一较佳实施例中利用 IKE协议建立安全联盟的过 程;
图 13 为本发明一较佳实施例中 CREATE一 IPSEC—SA 交换的过 程;
图 14为本发明一较佳实施例中 INFORMATIONAL交换的过程; 图 15为本发明一较佳实施例中通告载荷的格式;
图 16为本发明一较佳实施例中 HIP— NOTIFY_REA参数的通告数 据格式;
图 17为本发明一较佳实施例中处于站点多家乡的主机、 由 SPI 索引的 IPSec SA、 及地址之间的关系示意图。 实施本发明的方式
为使本发明的目的、 技术方案及优点更加清楚明白, 以下参照附 图并举实施例, 对本发明进一步详细说明。
图 11 为本发明中实现主机移动性和多家乡功能的流程, 具体包 括以下步骤:
步骤 a、 在传输层和网络层之间加入主机标识符层, 为移动网络 中的每个网络主机设置主机标识符(HI ) , 并将传输层通过主机身份 标记 HIT或者本地范围标识 LST绑定到 HI上。
该步驟与现有 HIP协议相同, 此处不赘述。
步骤 b、 网络主机和作为其通信对端的网络主机之间使用互联网 密钥交换协议 (IKE ) , 建立一对以通信双方地址作为自身地址的互 联网协议安全联盟,并将上述安全联盟绑定到所述网絡主机和其通信 对端网络主机的主机标识符上。
该步骤中, 网络主机和通信对端指的是进行通信的一对网络实 体, 所述网络主机或通信对端可以是安全网关,二者利用 IKE协议建 立安全联盟(SA, Security Association )的过程如图 12所示, 该过程 通过执行多组交换来完成,所述一组交换指的是一对在发起端和响应 端之间发送的请求和应答报文。
步骤 1201、 发起端向响应端发出第一请求报文, 所述第一请求 报文包括以下载荷,分别是头部载荷( HDR )、安全联盟载荷( SAil )、 密钥交换载荷 (KEi ) 和 Nonce载荷 ( Ni ) 。
步骤 1202、 响应端接收到第一请求报文后, 向发起端回复第一 应答报文, 所述第一应答报文包括以下载荷, 分别是 HDR、 SArl载 荷、 KEr载荷和 Nr载荷。
该步驟中,响应端从 SAil载荷提供的选项中选择一套加密算法, 并将自身选择通过 SArl载荷告知发起端。
上述步骤 1201~1202执行的是 IKE_SA—INIT交换, 通信双方通 过该组交换来协商加密算法、 Nonces和 DH交换等参数值。 其中, 网 络主机和通信对端中的任一方都可以是 IKE— SA— INIT交换的发起端。
步骤 1203、 发起端向响应端发出第二请求报文, 该报文携带有 身份载荷 ( IDi ) 和认证载荷 ( AUTH ) 等。
其中, IDi载荷用于声明自身身份, AUTH载荷用于证明与 IDi 载荷相关的秘密信息和保护笫二请求报文的内容完整性。
另外, 由于响应端可能具有多个身份, 第二请求报文还可选地携 带有 IDr载荷, 使发起端能够指定响应端的身份。
步骤 1204、 响应端使用接收到的 SAi2载荷开始协商 IPSec SA, 并向发起端回复第二应答报文, 该报文携带 IDr载荷和 AUTH载荷, IPSec SA协商完成。 其中, IDr载荷用于声明响应端身份, AUTH载 荷用于认证身份和保护第二应答报文的完整性。
上述步骤 1203〜1204执行的是 IKE— AUTH交换, 该组交换用于 认证消息、 交换身份和证书。
经过步骤 1201~1202 后, 发起端和响应端都会生成密钥种子 ( SKEYSEED ) , 并利用 SKEYSEED生成 IKE SA的安全联盟密钥。 所述安全联盟密钥包括完成加密 (SK— e ) 密钥和完整性保护(SK— a ) 密钥。 步骤 1203~1204交互的所有报文中, 除头部载荷外, 其余载荷 都会被加密并受到完整性保护。 此外, 还可以根据需要生成加密材料 ( SK_d ) 密钥, 用于在后续 IPSec SA阶段产生所需的加密材料。 图 12中, 第二请求报文和第二应答报文中的 SK{...}表明括号内的载荷 使用本方向的 SK—e和 81(_ 分別进行加密和完整性保护。
SKEYEED及其派生值由公式 ( 1 ) 和公式 (2 ) 计算得出: SKEYSEED = prf(Ni | Nr, gAir) ( 1 )
{ SK_d| SK_ai| SK_ar| SK_ei| SK_er| SK_pi|SK_pr}=
prf+(SKEYSEED,Ni|Nr|SPIi|SPIr) ( 2 ) 公式(2 ) 中, prf+用来产生伪随机数, prf+ ( ) 的执行结杲为将 SK_d, SK— ai, SK— ar, SK— ei, SK_er, SK— pi和 SK— pr串联。
通常情况下, 执行一次 IKE_SA— ΙΝΙΤ交换和一次 IKE— AUTH交 换,就能在网络主机和通信对端之间建立互联网协议安全联盟( SA ) , 故将图 12所示的过程称为初始交换。
除此之外, IKE协议还定义有 CREATE— IPSEC—SA交换, 用来建 立以后的 IPSec SA, 该组交换不是必须进行的。 在初始交换完成后, CREATE_IPSEC_SA交换可以由通信双方的任意一端发起,具体过程 如图 13所示:
1 )发起端向响应端发出第三请求报文, 该报文携带头部载荷、 SA载荷、 Ni载荷、 KEi载荷、 TSi和 TSr载荷等。 所述 SA载荷用于 发送 SA提议; Ni载荷用于发送 Nonce; KEi载荷是可选的, 用于发 送 Diffie-Hellman值; TSi和 TSr载荷也是可选的, 用于发送流量选 择器。
同样地, 第三请求报文中, 头部载荷之后的报文内容用安全联盟 密钥进行加密。
2 ) 响应端向发起端回复第三响应报文, CREATE— IPSEC—S A交 换完成。
步骤 c、 网絡主机在自身通信地址变化时, 将更新后地址发送至 通信对端, 并将自身安全联盟地址修改为更新后地址。
该步骤中, 通过执行 INFORMATION交换, 网络主机将更新后 地址发送至通信对端, 从而使网络主机在不同 IP地址之间切换时, 能够和通信对端保持正常通信。 INFORMATIONAL 交换的过程如图 14所示, 包括以下步骤:
1 ) 网络主机在地址发生变化时, 向通信对端发出第四请求报文, 所述报文中携带头部载荷、 通告载荷等。 此时, 网络主机成为 INFORMATIONAL交换过程的发起端。
2 ) 通信对端接收到第四请求 艮文后, 回复第四应答报文, INFORMATIONAL交换完成。
其中, 第四请求报文中携带的通告载荷(N ) 的格式定义如图 15 所示, 该载荷包括以下域:
( 1 ) 协议 ID ( 1字节) 。 如果这个通告是关于一个现存的 SA, 该域用于指出 SA类型。对于 IKE一 SA通告,该域是 1。对于 IPSec SA 通告, 该域是 2时代表 AH, 该域是 3时代表 ESP。 对于与现存 SA 无关的通告, 这个域必须设置为 0, 并在接收时忽略。 这个域的其它 值保留, 并可在将来由 IANA分配。 (2 ) SPI大小 ( 1字节) , 以字 节为单位, 或在没有 SPI时设置为 0。 当所述通告是关于 IKE SA的 通告时, SPI大小必须为 0。 ( 3 )通告报文类型 (2 字节) 。 (4 ) 安全参数索引 SPI (变长) 。 (5 ) 通告数据 (变长) , 这个域的取 值与类型相关。
通告载荷中的通告数据可以是表明 SA 不能建立原因的差错报 文,也可以是管理 SADB的程序向另一个程序传输的状态信息。其中, 0-16383的类型取值用于报告差错。
本发明中, 新定义一种通告数据类型, 用于网络主机之间交换地 址更改信息, 该类型名称为 HIP—NOTIFY— REA, 取值设置为 40960, HIP一 NOTIFY— REA的通告数据格式如图 16所示。
( 1 )保留 (1 比特) , 在发送时清 0, 接收时忽略; (2 ) 属性 类型(7比特), 用于表明地址类型, 是配置属性类型的唯一识别符; ( 3 ) 长度(2字节) , 以字节为单位; (4 )地址生存期, 以秒为单 位; ( 5 )首选地址 Ρ, 如果 HIP— NOTIFY— REA中的第一个地址是新 的首选地址, 则该域置为 1 , 否则置 0; ( 6 )保留, 在发送时置 1 , 接收忽略; ( 7 )地址, 可以是 IPv6地址或 IPv4-in-IPv6格式的 IPv4 地址; (8 ) 变长值 (0或多字节) , 用于配置属性的变长值。
步骤 d、 通信对端接收到网络主机发送的更新后地址, 根据来自 网络主机的主机标识符查找到对应的安全联盟,将自身安全联盟地址 修改为更新后地址,然后通信对端使用更新地址的安全联盟与网络主 机进行通信, 流程结束。
在图 11 所述流程的基础上, 下面将结合实际通信场景, 说明如 何利用本发明的方法实现主机移动性和多家乡功能。
一、 一般移动性。
假设某网络主机只有一个接口, 且该接口只有一个 IP地址, 网 络主机和通信对端之间已经建立有一对方向相反的 SA。 所述网络主 机在与通信对端进行通信时, 从家乡网络移动到其它外地网络, 那么 该主机需要使用外地网络的地址前缀, 因此绑定到主机接口的地址就 发生变化。
为 了 保持与通信对端 的 通信关 系 , 网 络主机发起 INFORMATIONAL 交换, 通过第四请求报文的 HIP— NOTIFY— REA 参数, 告知通信对端如下信息: 主机标识符 (HI ) 、 新 IP地址、 与 新 IP地址相关的 SPI、 地址生存期, 以及新 IP地址是否为首选地址 等。 同时, 网络主机用新 IP地址对自身保存的一对安全联盟地址进 行更新。
由于移动过程中, 网络主机的 HI不会发生变化, 所以通信对端 27
根据 HIP— NOTIFY_REA参数中的 HI, 查找到绑定在所述 HI上的一 对安全联盟, 并用新 IP地址替换安全联盟原有地址。 之后, 网络主 机和通信对端之间使用更新后的安全联盟通信,来处理相互之间发送 的通信数据。
其中, 在通信对端查找与网络主机相关的一对 SA时, 也可以采 用 HI和与新 IP地址相关的 SPI这两个参数联合进行查找。
二、 主机多家乡。
所述主机多家乡指的是网络主机具有多个接口,每个接口有一个 IP地址的情况。
网络主机使用的接口发生变化时, 由于每个接口对应一个 IP地 址, 所以网络主机的 IP 地址发生变化。 此时, 网络主机可以通过 HIP— NOTIFY— REA参数将接口和 IP地址通知通信对端, 并指明首选 接口和 IP地址。
通信对端接收到网络主机的接口和 IP地址信息后, 优先使用首 选接口和 IP地址更新相应安全联盟地址。 之后, 通信双方使用更新 后的安全联盟处理通信数据。
三、 站点多家乡。
所述站点多家乡指的是网络主机包含一个具有多个 IP地址的接 口。 此时, 网絡主机可以根据实际情况选择一个 IP地址进行通信, 并将选中的 IP地址通过 HIP_NOTIFY—REA参数发送给通信对端。这 种情况的处理过程与一般移动性类似, 此处不赘述。
当通信双方的网络主机都属于站点多家乡情况时,处理过程与单 个站点多家乡类似。如图 17所示,主机 1需要为自身添加地址 lb时, 就向位于地址 2a的主机 2发送 HIP— NOTIFY_REA参数,从而在主机 1和主机 2之间加入一組新的 SPI, 即 SPIlb和 SPI2b。 同样地, 主机 2需要添加地址 2b时, 由于主机 1具有两个地址, 主机 2可以选择 向地址 la、 地址 lb, 或同时向两者发送 HIP— NOTIFY一 REA参数。
四、 网络重编号。
根据 IPv6 自身的使用机制, IPv6网絡的重编号操作会比其它网 络更为频繁, 比如链路通告的 IPv6前缀改变、 PPP链路的重连接, 或新 DHCP分配等都会导致网络重编号。 出现网络重编号情况时, 位 于该网络的所有主机地址都会发生改变。 网络主机需要通过 HIP_NOTIFY_REA参数将地址变化情况告知通信对端, 该处理过程 与一般移动性类似, 此处不再详加描述。
由于本发明的方法通过互联网密钥交换协议 (IKE ) 实现, 所以 可以适用于终端主机和包括终端主机在内的安全网关等不同的场所。
此外, 本发明中通过 IKE协议实现主机移动性和多家乡功能的方 法, 可以与 IETF组织提出的 IKEv2密钥交换协议兼容, 此处不再给出 IKEv2密钥交换协议的详细说明, 关于 IKEv2协议的具体细节可以参 阅相关协议。
由上述的实施例可见,本发明的这种实现主机移动性和多家乡功 能的方法, 在通信双方中的任一方地址发生变化时, 无需重新建立安 全联盟 (SA ) , 仅需更新安全联盟地址, 就能利用已有的安全联盟 来保证端到端通信的安全性, 使通信双方继续保持通信, 从而能很好 地支持一般移动性、 主机多家乡、 站点多家乡和网络重编号等通信场 景。

Claims

权利要求书
1、 一种实现主机移动性和多家乡功能的方法, 在移动网络的传 输层和网络层之间加入主机标识符层,并在所述主机标识符层为移动 网络中的每个网络主机设置主机标识符;
其特征在于, 该方法包括以下步驟:
A、 网络主机和作为其通信对端的网络主机之间使用互联网密钥 交换协议,建立一对以通信双方地址作为自身地址的互联网协议安全 联盟,并将上述安全联盟绑定到所述网络主机和其通信对端网络主机 的主机标识符上;
B、 网络主机在自身通信地址变化时, 将更新后地址发送至通信 对端, 并将自身安全联盟地址修改为更新后地址;
C、 通信对端接收到网络主机发送的更新后地址, 根据来自网络 主机的主机标识符查找到对应的安全联盟,将自身安全联盟地址修改 为更新后地址,然后通信对端使用更新地址的安全联盟与网络主机进 行通信。
2、 根据权利要求 1所述的方法, 其特征在于, 步骤 A所述建立 互联网协议安全联盟的方法为:在网络主机和通信对端之间执行一次 IKE一 SA一 INIT交换和一次 IKE— AUTH交换。
3、根据权利要求 2所述的方法,其特征在于,所述 IKE— SA一 INIT 交换包括第一请求报文和第一应答报文;
所述 IKE— AUTH交换包括第二请求报文和第二应答报文。
4、根据权利要求 3所述的方法,其特征在于,所述 IKE— SA— INIT 交换的过程具体为:
网络主机向通信对端发出第一请求报文,通信对端接收到第一请 求报文后回复第一应答报文给网络主机, 并生成密钥种子;
网络主机收到第一应答>¾文, 生成密钥种子;
网络主机和通信对端分别利用自身生成的密钥种子,生成互联网 密钥交换协议联盟的安全联盟密钥。
5、 根据权利要求 4所述的方法, 其特征在于, 所述第一请求报 文和第一应答报文都包括以下载荷: 头部载荷、 安全联盟载荷、 密钥 交换载荷和 Nonce载荷;
所述第二请求报文和第二应答报文都包括以下载荷: 头部载荷、 身份载荷和认证载荷。
6、 根据权利要求 5所述的方法, 其特征在于, 所述安全联盟密 钥包括完成加密密钥和完整性保护密钥, 则所述第一请求报文、 第一 应答报文、 第二请求报文和第二应答报文中, 除头部载荷之外的其它 载荷都采用安全联盟密钥进行加密。
7、 根据杈利要求 1所述的方法, 其特征在于, 步骤 B所述网络 主机发送更新后地址到通信对端的方法具体为: 网络主机发起一次 INFORMATIONAL交换, 将更新后地址发送到通信对端。
8、 根据权利要求 7 所述的方法, 其特征在于, 所述 INFORMATIONAL 交换的过程具体为: 网络主机向通信对端发出第 四请求报文; 通信对端接收到第四请求报文后, 向网络主机回复第四 应答报文。
9、 根据权利要求 8所述的方法, 其特征在于, 所述第四请求报 文和第四应答报文都包括以下载荷: 头部载荷和通告载荷。
10、 根据权利要求 9所述的方法, 其特征在于, 所述通告载荷包 括以下域: 协议 ID域、 SPI 大小域、 通告报文类型域、 安全参数索 引域和通告数据域; 其中, 所述通告数据域设置有 HIP—NOTIFY—REA参数。
11、 才艮据权利要求 10所述的方法, 其特征在于, 当网络主机发 生 IP地址切换时, 步骤 B所述网络主机发送更新后地址到通信对端 的方法具体为: 网络主机在第四请求报文的 HIP— NOTIFY— REA参数 中记录自身主机标识符和新 IP地址, 并向通信对端发出上述第四请 求报文;
则步骤 C中, 通信对端更新安全联盟地址的方法为: 通信对端用 从第四请求报文中取出的新 IP地址作为更新后的所述安全联盟地址。
12、 根据权利要求 11 所述的方法, 其特征在于, 所述 HIP— NOTIFY—REA参数中进一步记录有: 与新 IP地址相关的 SPI、 地址生存期, 以及新地址是否为首选地址标识;
则步驟 C中, 通信对端查找安全联盟的方法进一步包括: 根据接 收到的 SPI确定安全联盟。
13、 根据权利要求 10所述的方法, 其特征在于, 当网络主机具 有一个以上接口, 且所述网络主机改变与通信对端的通信接口时, 步 骤 B所述网络主机发送更新后地址到通信对端的方法具体为:
网络主机在第四请求报文的 HIP— NOTIFY— REA参数中记录自身 接口和 IP地址并标记首选接口, 然后向通信对端发出上述第四请求 报文;
则步骤 C中, 通信对端更新安全联盟地址的方法为: 通信对端用 从第四请求报文中取出的首选接口和 IP地址作为更新后的所述安全 联盟地址。
14、 根据权利要求 10所述的方法, 其特征在于, 当网络主机包 含一个具有一个以上 ip地址的接口, 且网络主机在同一接口的 IP地 址之间切换时,步驟 B所述网络主机发送更新后地址到通信对端的方 法具体为:
网络主机在第四请求报文的 HIP_NOTIFY—REA参数中记录所述 接口当前使用的 IP地址, 并向通信对端发出上述第四请求报文; 则步驟 C中, 通信对端更新安全联盟地址的方法为: 通信对端用 从第四请求 4艮文中取出的网络主机当前使用的 IP地址作为更新后的 所述安全联盟地址。
15、 根据权利要求 1所述的方法, 其特征在于, 所述网络主机和 /或通信对端包括安全网关。
PCT/CN2005/001327 2004-08-25 2005-08-25 Procede destine a assurer la mobilite d'un hote reseau et une fonction multi-localite WO2006021156A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN 200410057052 CN1741523B (zh) 2004-08-25 2004-08-25 一种实现主机移动性和多家乡功能的密钥交换协议方法
CN200410057052.9 2004-08-25

Publications (1)

Publication Number Publication Date
WO2006021156A1 true WO2006021156A1 (fr) 2006-03-02

Family

ID=35967167

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001327 WO2006021156A1 (fr) 2004-08-25 2005-08-25 Procede destine a assurer la mobilite d'un hote reseau et une fonction multi-localite

Country Status (2)

Country Link
CN (1) CN1741523B (zh)
WO (1) WO2006021156A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102752171A (zh) * 2012-07-04 2012-10-24 汉柏科技有限公司 Ipsec协商测试方法

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047945B (zh) * 2006-03-28 2012-05-30 华为技术有限公司 移动通信系统及用户临时身份分发方法
EP2022229B1 (en) * 2006-05-24 2009-11-04 OY LM Ericsson AB Delegation based mobility management
CN101247299B (zh) * 2007-02-14 2010-11-17 华为技术有限公司 一种实现多归属网络接入的方法和多归属网络系统
CN101335747B (zh) * 2007-07-01 2012-10-03 华为技术有限公司 通信地址通知、探索及通信检测、恢复方法及其装置
CN101626374B (zh) * 2008-07-11 2013-08-28 成都市华为赛门铁克科技有限公司 IPv6网络中协商SA的方法、系统和设备
JP4623177B2 (ja) * 2008-09-17 2011-02-02 富士ゼロックス株式会社 情報処理システム
US8619995B2 (en) * 2009-01-28 2013-12-31 Qualcomm Incorporated Methods and apparatus related to address generation, communication and/or validation
CN101931611B (zh) * 2009-06-19 2015-04-01 中兴通讯股份有限公司 基于主机身份协议实现用户移动性的方法和系统
CN102025700B (zh) * 2009-09-23 2013-11-06 华为技术有限公司 面向用户的通信方法和路由注册方法及设备及通信系统
CN101848164B (zh) * 2010-05-27 2013-05-29 北京邮电大学 基于多家乡主机扩展协议hip实现流分配和流重定向的方法
WO2012026855A1 (en) * 2010-08-25 2012-03-01 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for secure communication over an ip network
CN102457510B (zh) * 2010-11-02 2016-02-10 中兴通讯股份有限公司 一种hap切换的方法和系统
CN103595823B (zh) * 2012-08-17 2018-05-11 华为技术有限公司 数据传输的方法、终端及系统
US10250578B2 (en) * 2015-11-03 2019-04-02 Qualcomm Incorporated Internet key exchange (IKE) for secure association between devices
CN106169952B (zh) * 2016-09-06 2019-05-07 杭州迪普科技股份有限公司 一种英特网密钥管理协议重协商的认证方法及装置
US10609008B2 (en) 2017-06-08 2020-03-31 Nxp Usa, Inc. Securing an electronically transmitted communication
CN110958209B (zh) * 2018-09-27 2022-06-24 广东国盾量子科技有限公司 基于共享密钥的双向认证方法及系统、终端
CN114268473B (zh) * 2021-12-10 2023-07-11 北京天融信网络安全技术有限公司 IKEv1协议主模式抵御DDOS攻击的方法、系统、终端及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998026550A1 (en) * 1996-12-09 1998-06-18 Sun Microsystems, Inc. Secure dhcp server
WO2002098062A1 (en) * 2001-05-24 2002-12-05 British Telecommunications Public Limited Company Method for providing network access to a mobile terminal and corresponding network
US20040130322A1 (en) * 2002-12-19 2004-07-08 Crouzen Paulus Carolus Nicolaas Monitoring wall thickness

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998026550A1 (en) * 1996-12-09 1998-06-18 Sun Microsystems, Inc. Secure dhcp server
WO2002098062A1 (en) * 2001-05-24 2002-12-05 British Telecommunications Public Limited Company Method for providing network access to a mobile terminal and corresponding network
US20040130322A1 (en) * 2002-12-19 2004-07-08 Crouzen Paulus Carolus Nicolaas Monitoring wall thickness

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102752171A (zh) * 2012-07-04 2012-10-24 汉柏科技有限公司 Ipsec协商测试方法
CN102752171B (zh) * 2012-07-04 2015-03-25 汉柏科技有限公司 Ipsec协商测试方法

Also Published As

Publication number Publication date
CN1741523B (zh) 2010-05-12
CN1741523A (zh) 2006-03-01

Similar Documents

Publication Publication Date Title
WO2006021156A1 (fr) Procede destine a assurer la mobilite d&#39;un hote reseau et une fonction multi-localite
Perkins Mobile ip
Le et al. A review of mobility support paradigms for the internet.
Henderson Host mobility for IP networks: a comparison
JP5502905B2 (ja) モバイル・ネットワークにおけるセキュア・ネットワークベースのルート最適化のための方法
JP4909357B2 (ja) イーサネット伝送プロトコルを基礎とするデータパケットを少なくとも1つのモバイル通信ユニットと通信システムとの間において伝送する方法
US7849195B2 (en) Host identity protocol method and apparatus
US20070204150A1 (en) Identification method and apparatus for establising host identity protocol (hip) connections between legacy and hip nodes
JP2000022758A (ja) ネットワークにおけるインターワーキング機能選択システム
JPH11275156A (ja) ピア・ツー・ピア プロトコルサーバを用いた通信
JPH11252183A (ja) イーサネット(登録商標)フレームにおけるポイント・ツー・ポイント・プロトコルのカプセル化
JPH11331276A (ja) ネットワークのための登録方法
JPH11289353A (ja) ネットワークにおける会計システム
JPH11275155A (ja) ネットワークにおけるメッセージおよび通信システム
JPH11275154A (ja) メッセージ配信シーケンス
JP2008530948A (ja) ホスト・アイデンティティ・プロトコルの方法および装置
JP4938891B2 (ja) ネットワークベース・ローカル移動管理
JP5147995B2 (ja) ホスト・アイデンティティ・プロトコル・サーバ・アドレス構成
US20120271965A1 (en) Provisioning mobility services to legacy terminals
Bless et al. The underlay abstraction in the spontaneous virtual networks (SpoVNet) architecture
US20090106831A1 (en) IPsec GRE TUNNEL IN SPLIT ASN-CSN SCENARIO
US20090300217A1 (en) Method and apparatus for dynamically assigning unique addresses to endpoints
KR100737140B1 (ko) 이동통신에서의 인터넷 프로토콜 가상 사설망 서비스처리장치 및 방법
Kavitha et al. A secure route optimization protocol in mobile IPv6
Haresh Comparison and Analysis of IP and IKEv2 Mobility Extensions

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase