Integrated Management of Network Address Translation, Mobility and Security on the Blockchain Control Plane

Currently, the dual use of IPv4 and IPv6 is becoming a problem. In particular, Network Address Translation (NAT) is an important issue to be solved because of traversal problems in end-to-end applications for lots of mobile IoT devices connected to different private networks. The vertical model is typically used to solve NAT, mobility and security issues for them. However, the existing vertical model has limitations because it handles NAT, mobility and security management one by one. This paper proposes a Blockchain-based Integrated Network Function Management (BINFM) scheme where the NAT, mobility, and security management are handled at once. The proposed scheme is advantageous in that by using blockchain and the Query/Reply mechanism, each peer can easily obtain the necessary parameters required to handle the NAT, mobility, and security management in a batch. In addition, this paper explains how our proposed scheme guarantees secure end-to-end data transfers with the use of one time session key. Finally, it is proved that the proposed scheme improves performance on latency from the viewpoints of mobility and security compared to the existing vertical model.


Introduction
One of the main reasons to extend the IP address space in IPv6 is to give Internet of Things (IoT) devices a platform to operate on for solving scalability issues [1][2][3]. The purported 400% increase in growth in the last five years sheds some light on how much exponential IoT growth we can expect to see in the next several decades [4]. However, its slow replacement of IPv4 can cause a problem especially for the demand to construct smart cities in a decade [5]. Recent smart cities need to allow IPv4 network-connected IoT devices to connect each other. As of now, Network Address Translation (NAT) solves connectivity issues for the IPv4 network-connected IoT devices [6][7][8]. NAT has one accessible public address which will be shared among End Nodes (ENs) inside the private network. NAT essentially extends internal addressing from the global IP addressing used over the Internet. NAT provides network resources to get over a shortage of the address space by mapping relatively public IP addresses to private IP addresses. However, the non-standardized characteristics of NAT cause traversal problems especially with the development of peer-to-peer applications for small IoT devices [9].
Considering that IPv6 allows IPv6 network-connected IoT devices to be uniquely addressable, despite the use of NAT and IPv4 private IP addresses, the mobile IoT devices, which enter private networks, must be allowed to solve a connectivity issue. Then, this enables increasing mobility for address-related and security-related information of the session responder just at the time when the initiator calls the responder. Jung et al. proposed a blockchain-based security management scheme to make a real-time packet key exchange perform better [22]. As a similar approach, for a certain end node, its security-related information are already stored and updated in the blockchain. Therefore, any end node, which wants to establish a new session to its peer, can obtain security parameters to derive the one time session key with the help of the blockchain while the vertical model requires the extra hand shaking procedure of key agreement in order to complete the security management.   The BINFM scheme uses one of the most innovative features of the blockchain, in which there is no central server running. It operates through the network of blockchain control plane that the super nodes (SNs) constitute. Here, the BINFM scheme includes Query/Reply mechanism from the viewpoints of ENs. Using the Query/Reply mechanism, the EN obtains the transport address-related information, which solve the NAT and mobility management, and security-related information from its nearest SN. Therefore, this idea of Integrated Management (IM) gives significantly advantageous effects on NAT, mobility and security controls by reducing the system complexity and latency taken for mobility and security controls. Furthermore, the use of one time session key makes data flow over BINFM system more secure.
The rest of this paper is organized as follows. Section 2 proposes the blockchain-based architecture for smart NAT management. In Section 3, this paper explains how to process a transaction to create a block and query/reply mechanism needed to access the transaction information from the blockchain. Section 4 describes the improvement effects of the proposed management system. This paper concludes in Section 5.

Proposed Network Architecture for Blockchain Control Plane
The blockchain keeps the database associating with the current transport address-related information for every mobile ENs from the NAT and mobility management viewpoints. For a specific application in the EN A behind the private network, a set of transport address-related information is assigned, that is, [private IP address, private source port number, NATed public IP address, NATed port number] = [IP_EN A _Pri, Port_EN A _Pri, IP_EN A _N AT ED , Port_EN A _N AT ED ]. For the corresponding EN B behind the different private network, the transport address-related information of [IP_EN B _Pri, Port_EN B _Pri, IP_EN B _N AT ED , Port_EN B _N AT ED ] are assigned. The role of the blockchain network is to enable both of session initiator and session responder to understand the transport address-related information for each other via the blockchain network. Query(to Blockchain)/Reply (from Blockchain) mechanism enables the EN to obtain information necessary for integrated management. In order to give an answer for this Query, the blockchain network requires to support the registration process that the EN's latest state information enter the blockchain. Figure 2 shows the BINFM network architecture, which can be explained as follows: 1. The EN is identified by the hash address derived from the public part of a public-private cryptographic key. The private part of the key is under the control of the EN. 2. The EN is responsible to update its Integrated Management (IM)-related information by pushing it into the blockchain. When an EN changes its private network, it sends a new registration transaction, that is, ToALL Tx, to the nearest super node (SN). After an SN receive the transaction message, it broadcasts the message to all SNs. Each transaction message contains several data fields for NAT, mobility and security management, which will be described in the next section. 3. The SN collects new ToALL Txs into a block and performs on solving the proof-of-work for its block. When an SN finds a proof-of-work for the ToALL Tx, it broadcasts the resultant block to all SNs. SNs imply their acceptance of the block by working on creating the next necessary block in the chain, using the hash of the accepted block as the previous hash. SNs will always keep working on extending it. The latency to extend a new block in the blockchain is closely related to the latency that takes the registration process to be completed. Therefore, this latency needs to be reduced as much as possible. Therefore, in this paper, it is assumed that next necessary block is created every 1 second on average and extended to the existing blockchain. This assumption is based on our experimental results using our blockchain testbed. 4. The EN uses the Query/Reply mechanism to obtain the peer's IM-related information from the blockchain. When an EN initiates to setup a session to its peer EN, it needs the peer EN's ToALL Tx information. To obtain this Tx information, it sends a query message to the nearest SN to gather the peer EN's transport address to reach there. Then, the SN searches the Tx Search Table (TST) and finds the corresponding transaction data from its blockchain. Then, it returns the requested transaction information to the EN.

Requirements for the Proposed System
Private IP addresses must be configured automatically for new ENs that move from one network to another. Dynamic Host Configuration Protocol (DHCP) server maintains a pool of private IP addresses and leases an address to any DHCP-enabled EN when it starts up on the network. A DHCP-enabled EN, upon accepting a lease offer, receives a valid private IP address for the private network to which it is currently connecting. There are additional parameters that a DHCP server is configured to assign to ENs. In the proposed BINFM scheme, the NAT address (IP_EN_N AT ED , which is one accessible public address that will be shared among ENs inside the private network, is included in those parameters DHCP server offers. Figure 3 shows that the DHCP reply message contains the offered private address and the NAT address which will be used as the EN's source address when its packet enters the public network.  When EN sends a packet using its source private IP address and port number (IP_EN_Pri: Port_EN_Pri) to destination IP address and port number (IP_Dest: Port_Dest), the NAT creates a map for EN's private address and port number (IP_EN_Pri: Port_EN_Pri) by assigning public IP_EN_N AT ED and Port_EN_N AT ED as public address and port number, respectively. Therefore, incoming packets from [IP_Dest: Port_Dest] destined to [IP_EN_N AT ED : Port_EN_N AT ED ] are forwarded to [IP_EN_Pri: Port_EN_Pri]. As depicted in Figure 4, the BINFM scheme requires the important condition that Port_EN_N AT ED should be derived from the hash function of IP_EN_Pri and Port_EN_Pri. EN is aware that NAT devices use the NAT port assignment function of H16 where the first 16 bits are taken from the hash value.

EN NAT
NAT-mapped table

Smart Wallets for the End Nodes
ENs such as small IoT devices have smart wallets. As shown in Figure 5, smart wallet contains its own identity-related, transport address-related and security-related information. So the EN is responsible for registering this information with the blockchain maintained in the SNs. To obtain this information for the other side from the blockchain, the EN uses Query/Reply mechanism. Therefore, each side can easily obtain the necessary parameters of the other side required to handle the NAT, mobility and security management to establish and maintain a secure session between two peers which entered two different private networks. Here, 'smart' wallet means that the EN takes advantage of the blockchain's merits without maintaining the blockchain data structure.

Private Key (priKey_EN) Public Key (pubKey_EN) HashAddress (Hash_EN)
Identity-related information -private key (priKey_EN) -public key (pubKey_EN) -Hash address (Hash_EN) Transport address-related information -private IP address (IP_EN_Pri) -public NAT address (IP_EN_NAT ED ) Security-related information -q and : global parameters in the Diffie-Hellman key exchange -x : a secret value -Y : a blind key, using the equation of Y= x mod q Application-specific information

BINFM Transactions and Registration Procedure
Each EN's latest state information resides in its own wallet. however, all ENs' information are stored in a distributed database called the blockchain, which stores a secure list of all ToALL transactions sent by them. The BINFM transaction is defined as the EN's state record during the period of temporally assigned private IP address. Therefore, the transaction change rate is the same as the private IP address change rate. This means that EN sends its ToALL Tx to the network whenever it moves and obtains a new private IP address. When a handover occurs during a call session between two ENs, the EN, which changes its private IP address, also issues new ToALL Tx to the network. The transaction consists of Transaction Input (TxIn) and Transaction Output (TxOut). The TxIn contains the signature and the public key computed from the EN's private key which creates the transaction. The first field of TxOut contains the hash address that identifies the owner of this transaction. Figure 6 explains the ToALL Tx structure.       where D K B is any symmetrical key decryption algorithm with the key K B . As a result, bidirectional session traffic travel over the established secure sessions. Therefore, our blockchain-based scheme easily solves the problem of handling complex issues of NAT, mobility and security management. This advantage results from the fact that each peer can obtain the necessary parameters for peer-to-peer session establishment via a simple Query/Reply mechanism between an EN and its nearest SN.

Blockchain-Based Mid-Call Mobility Management Procedure
The mid-call mobility management is needed when either EN A or EN B changes its local private network during an on-going session. Figure 9 shows the mid-call mobility management operation for the case that EN A changes its network during the on-going session with EN B . When EN A confronts with IP handover, it first sends IP handover Request message to the EN B . This massage contains a new transport address-related information, that is, [IP _EN A _N AT ED and IP _EN A _Pri]. Next, a new ToALL Tx registration procedure starts to update EN A 's state information on the blockchain. When EN B receives the Request message, it immediately uses the updated transport address information for EN A . Then, both can keep on going the existing bidirectional session.  Figure 9. Blockchain-based mid-call mobility management procedure.

Key Renewal Process During a Session
From security management viewpoints, any side can initiate to change the one time session key even during an on-going session. Figure 10 shows the key change operation for the case that EN A needs to change its one time session key during the on-going session with EN B . As a key change initiator, EN A generates new secret value X A and computes Y A = α X A mod q. Also, EN A prepares new one time session key K A = Y B X A mod q. Then, EN A sends the Key Renewal Request message, which contains the blind key Y A , to EN B . Once EN B receives Y A , it computes the one time session key of K B using the equation of Y A X B mod q.
Now, EN A can encrypt its datagrams using the new session key which results in E K A [Audio Data]. Therefore, EN A sends the encrypted datagrams to EN B . When EN B receives the encrypted datagrams from EN A , it can decrypt those datagrams using the new session key K B which results in Because EN A changes its secret value, it needs to update its security-related information in the blockchain. EN A updates its state information including the security-related information by sending ToALL Tx to the SN.

Comparisons between the Existing Vertical Model and the Proposed BINFM Model for the Pre-Call
Mobility and Handover Management Figure 1 shows a series of steps, which correspond to the pre-call mobility management procedure in the vertical model, to complete a secure session set up between two ENs where they are located within the different private networks. Here, each EN changes its location dynamically. Figure 11 shows a series of steps to handle a mid-call mobility management between two ENs at the circumstance that one of them changes its private IP address.  Figure 11. Mid-call mobility management procedure in the vertical model. Figure 8 shows the proposed BINFM-based VoIP call setup procedure which corresponds to the pre-call mobility procedure in the proposed BINFM model. As shown in Figure 9, the mid-call mobility management in the proposed BINFM model is already described.
The following assumptions have been made to perform the comparative analysis with respect to total latency to complete the IM management. Three types of delay components exist, that is, where T I I = 5T I and T I I I = 10T I . This assumption is based on the blockchain network architecture where the unit delay of T I corresponds to the packet delay to travel from a certain EN to its nearest SN and the end-to-end path between two peers is longer by 5 times compared to the unit delay. Also, T I I I is assumed to be twice compared with the end-to-end path delay because the delay of T I I I includes delay components needed for searching processes in the distributed servers. Considering that with 4G networks, average latency is around 50 ms, the unit delay of T I is set to 40 ms. Table 1 compares the vertical model in Figure 1 with BINFM model in Figure 8. In the BINFM system, the Query/Reply procedures are only required to agree on necessary parameters to solve the issues relating to NAT, mobility and security management. As shown in Table 1, the pre-call mobility management latency requires 760 ms in the BINFM system compared to the vertical model, which needs the latency of 1440 ms for pre-call mobility management.  As shown in Table 2, the vertical model yields a latency of 280 ms for mid-call mobility management. In the BINFM model, a mid-call mobility management needs the latency of 200 ms.

Comparisons between the Existing Vertical Model and the Proposed BINFM Model for the Security Management
As shown in Table 3, the BINFM model needs the latency of 200 ms to complete a new key agreement procedure between two peers during a session. the vertical model yields a latency of at least 400 ms for the same key management.

Comparisons between the Existing Vertical Model and the Proposed BINFM Model for the Signaling Overhead
This subsection analyzes the signaling overhead that is imposed in the overall system. Without loss of generosity, three types of signaling overhead can be assumed,

•
S I : intra-domain signaling overhead caused in intra-domain links, • S I I : end-to-end signaling overhead caused in end-to-end path, • S I I I : signaling overhead caused to collaborate with the distributed servers, which are spread in inter-domain regions, where S I I = 5S I and S I I I = 10S I . This condition is based on the same assumption to obtain the results shown in Table 1. The unit signaling overhead of S I corresponds to the amount of signaling overhead for the Query message in Figure 8 to complete a mission. Inferring using the same method as Table 1, the overall signaling overhead requires 19S I in the BINFM system compared to the vertical model, which needs the overall signaling overhead of 36S I for completing the whole management to establish a secure session. It is found that the signaling overhead, which is imposed in the BINFM system, can be reduced to the level of 52% compared to the vertical model.

Complexity Analysis of the Proposed BINFM Model
If our BINFM approach can be implemented in real time or close to real time within a realistic networking environment, the complexity of the system can be explained in two ways. In the BINFM system, the role of the blockchain network is to enable two ENs as session initiator and session responder to agree on the mutual transport address-related and security-related information close to real-time. Therefore, blockchain information need to be updated as fast as possible when a certain EN issues a ToALL Tx. This latency is the same as the block creation period to extend a new block in the blockchain. Therefore, the latency to complete the registration process will be reduced as much as the block creation period decreases. In this paper, it is required to solve the complexity of the BINFM system in which the proof-of-work takes 1 second on average to succeed. Next, complexity is related to the Query/Reply mechanism. It starts to work by sending a Query Tx to the nearest SN. Then, the SN searches the corresponding transaction data from its blockchain with the Tx Search Table (TST)'s help and replies the searched transaction information. As the number of ENs increases and their movements increase, the complexity of finding information of the desired counterpart will increase. This complexity is closely related to the scalability of the system. It is beyond the scope of this paper.

Conclusions
Currently, the vertical model is typically used to solve Network Address Translation (NAT), mobility, and security issues for the mobile IoT devices where IPv4 and IPv6 are used together as a network layer protocol. However, the existing vertical model confronts with limitations in handling NAT, mobility and security management in batch. This paper proposed a Blockchain-based Integrated Management system where the the NAT and mobility management are handled together with the security management at once. This paper proved that our BINFM scheme is advantageous in terms of using the blockchain and Query/Reply mechanism, and each side can easily obtain the necessary parameters of the other side required to handle the NAT, mobility, and security management to establish and maintain a secure session between two peers which entered two different private networks. It was proved that the proposed scheme performs better from the viewpoints of pre-call mobility, mid-call mobility, pre-call security, and mid-call security control issues than the existing vertical model.