- Email: [email protected]
Design and implementation of a Secure Bandwidth Broker Discovery Protocol
Computer Standards & Interfaces 34 (2012) 231–237
Contents lists available at SciVerse ScienceDirect
Computer Standards & Interfaces journal homepage: www.elsevier.com/locate/csi
Design and implementation of a Secure Bandwidth Broker Discovery Protocol Ibrahim Taner Okumus a,⁎, Sezgin Cekerekli b a b
Mugla University, Faculty of Engineering, Computer Engineering Department, Kotekli Kampusu, 48000, Mugla, Turkey Mugla University, Graduate School of Sciences, Kotekli Kampusu, 48000, Mugla, Turkey
a r t i c l e
i n f o
Article history: Received 25 February 2011 Received in revised form 28 June 2011 Accepted 10 August 2011 Available online 16 September 2011 Keywords: Bandwidth Broker Discovery IP QoS Diffserv Bandwidth Broker SIBBS
a b s t r a c t Differentiated Services architecture definition lacks control level functionalities. One of the solutions proposed to fill this gap is Bandwidth Brokers (BB). Bandwidth Brokers are autonomous entities inside a network which is responsible for bandwidth management of the network along with other tasks. There is a lack of protocol for Bandwidth Brokers to discover other Bandwidth Brokers automatically. This study introduces a new Secure Bandwidth Broker Discovery Protocol (BBDP), which allows Bandwidth Brokers to automatically discover other Bandwidth Brokers. In this paper design principles, protocol details, working scenarios and implementation details of the BBDP protocol are presented. © 2011 Elsevier B.V. All rights reserved.
1. Introduction Providing quality of service on computer communication networks is an important issue and much effort is spent by researchers to find a scalable solution that can work on the global Internet [1,2,3]. Differentiated Services (Diffserv) architecture [3] is one of these solutions and is seen as the most viable solution because of its simplicity and scalability. Diffserv is designed to work both with IPv4 and IPv6. Deployment of IPv6 enhanced the importance of providing QoS. Diffserv is tested on IPv6 networks [4,5,6,7,8]. Diffserv defines limited number of QoS classes called Per Hop Behaviors (PHB) [9] and every router is only responsible to provide QoS classes defined with these PHBs. Diffserv architecture defines data level functionalities to provide a scalable QoS. However control level functionalities are not included in the architectural definition. Providing control level functionalities intrigued many researchers and there are various studies on this subject. One of the solutions is named Bandwidth Broker (BB) [10]. Bandwidth Broker is a logical entity and works as a resource manager inside a network. There are various BB architectures [11,12] proposed by researchers. A BB can be a centralized agent or it can be designed to work in a distributed fashion. Regardless of the architecture, every domain is controlled by a BB. A survey of Bandwidth Brokers can be found in [13].
⁎ Corresponding author. Tel.:+90 252 2111723; fax: + 90 252 2111702. E-mail address: [email protected] (I.T. Okumus). URL: http://ceng.mugla.edu.tr/~okumus/ (I.T. Okumus). 0920-5489/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2011.08.003
Main duty of a BB is to manage bandwidth inside a network by performing appropriate actions. BB works with requests. When a QoS request arrives to a BB, BB analyzes this request and then first finds an appropriate QoS path to the destination. Destination can be an internal node inside the domain or it can be a node residing in another domain. After finding an appropriate path, BB polls all the routers on the path to get the latest QoS state of each node along the path. Next step is to allocate resources, so that actual traffic can get promised QoS from the network. In order to provide end-to-end (e2e) QoS, BBs need to perform the tasks defined above from source to destination. As we mentioned before, destination can be on the same domain as the BB, or it can be in another domain. If traffic needs to traverse multiple domains, a single BB by itself cannot provide e2e QoS, because BBs are autonomous just like the domains (autonomous systems (AS)) they serve. If the source and destination reside in different ASS, each AS's BB needs to get the request and take action to provide the requested QoS. This requires BB to BB communication to relay the request toward the destination. Simple Inter-Bandwidth Broker Signaling (SIBBS) Protocol is designed for inter-BB communication [14]. SIBBS Protocol mainly works with two message types. Resource Allocation Request (RAR) message and Resource Allocation Answer (RAA) message. When a node needs a QoS resource allocation from a network, node constructs an RAR message and sends that to the BB of the domain. Upon receiving the RAR message, BB determines a path on its domain toward the destination of the request. If the destination is not on BB's domain, BB determines the next domain to reach the destination by checking BGP information. After determining the next domain BB checks neighbor database to find the address of the next domain's
232
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
BB. Then RAR request is forwarded to the next domain's BB. This procedure is repeated by each BB until the request reaches the destination. Internet consists of interconnected networks. These networks are called autonomous system (AS). ASs are considered to be neighbors if they have BGP neighbor relationship. Number of ASs on the Internet is increasing day by day. Inter-AS connectivity has a dynamic nature due to the customer–provider relationship among them. ASs can change service providers or peers and this will change the neighbor relationship. Some ASs become passive and new ASs appear frequently. This dynamic nature of the interconnected network makes it hard to keep track of neighborship information. During the design of the SIBBS protocol, it is assumed that BBs already know all neighboring BB addresses. This information is kept in neighbor database. Because of the dynamic nature of the Internet, an automated BB discovery mechanism is needed to fill in the neighbor database and if necessary update the information in the neighbor database automatically. To the best of our knowledge, only protocol that is close to automatic discovery of BBs is Path and Oracle discovery Protocol (PODP) [15]. However, this protocol is designed for path discovery and passive BB discovery. Although, PODP is designed for a centralized BB, it is not clear and not discussed how it relates to the authorization, authentication and resource management duties of a BB. PODP works with the underlying routing protocol to relay messages. BB later learns the path taken by those messages. BB is mainly used as a resource manager. Before making reservations and accepting QoS requests, BB needs to decide about the availability of the resources and which path to allocate for the request. Another issue with the PODP is that security and reliability is not considered in the protocol design. A BB is an important entity in a domain which needs to work securely when allocating resources. In this study we present a new secure protocol for neighbor BB discovery. This protocol is called Bandwidth Broker Discovery Protocol (BBDP). Apart from automated discovery of neighbor BBs, BBDP also helps with the security and reliability of BB communication. Previous studies on BB security show that inter-BB communication can be secured by using a certificate based system. In that system, each BB will have a certificate. These certificates are distributed among BBs. Nature of distribution is also an open issue. BBDP is also used for certificate distribution among BBs. In this sense, BBDP itself is designed securely and also will lay the foundation of interBB communication security by coordinating certificate exchange among BBs. The rest of this paper is organized as follows. Section 2 shows the overall system and how BBDP fits into the architecture. Section 3 gives the details of the design of the BBDP. In Section 4 we provide implementation details and different working scenarios for BBDP. Section 5 gives the concluding remarks and future work.
2. System architecture In this study, Differentiated Services (Diffserv) is used as the QoS technology. On top of Diffserv, BB is employed as inter and intra-domain resource manager inside a domain. SIBBS protocol is used as the signaling protocol for inter-BB communication. BBDP protocol is used for neighbor BB discovery purposes. Fig. 1 shows a sample network with above mentioned protocols and components working together. If a host wants to request certain QoS to a destination, host needs to contact the BB of its domain. This communication takes place via SIBBS protocol. Host uses Resource Allocation Request (RAR) message to indicate the properties of the requested QoS to the BB. BB receives the RAR and checks the requested QoS. BB performs authentication and authorization to verify the identity of the host and to determine the level of QoS that host can request. All these details are pre-agreed via Service Level Agreements (SLA). If these controls succeed, BB determines if the destination is in its own domain or in another domain. If the destination is in BB's own domain, then the BB determines a path to the destination that satisfies the requested QoS. QoS path can be found using a QoS routing protocol employed in the network, such as OSPF-TE [16]. When a BB determines the ingress router that the flow will enter the network, then the BB can communicate with the ingress router to find a QoS path to the destination. If a path is available that satisfies the requested QoS, BB returns a positive Resource Allocation Answer (RAA) back. BB also communicates with the routers along the path to configure them for the requested QoS. This requires a BB to be able to communicate with all the routers in its domain. Also all the routers in a domain knows the identity of the BB. In case the destination is in another domain, the BB needs to determine the egress router that is connected to the next domain toward the destination. A BB can get the autonomous system (AS) level path to the destination from BGP routers. This will show a series of AS numbers from source domain to destination domain. Next, the BB determines a QoS path from the ingress router to the egress router. If that path is available, that means QoS can be satisfied in BB's own domain. Then, BB needs to communicate with the downstream domain's BB to relay the RAR request. This is achieved via SIBBS protocol. Next domain's BB repeats the same steps as the source domain BB and forwards the RAR to the next domain's BB. This will continue until RAR reaches the destination. If every domain's BB on the path to the destination accepts the QoS request, a positive RAA will be relayed back to the host following the reverse path. In order for inter-BB communication to take place, BB keeps a database containing the identities (basically IP addresses) of neighbor BBs. This database contains entries consisting of BB IP address, AS number, and edge router IP for that AS (BB IP, ASN, ER IP). Every BB needs to know the AS number and edge router (ingress router) of a neighboring domain. In the concept of Diffserv and BB, neighboring
Fig. 1. A sample network.
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
means two neighbor domains having a Service Level Agreement between them. SIBBS protocol is designed to work in a sequential manner. If a QoS request traverses more than one domain, every BB communicates with its upstream/downstream immediate neighbor only. So this requires every BB to know the identity of all BBs in neighboring domains in order to initiate a SIBBS communication. There is a need for an automated BB discovery mechanism to fill in the neighbor BB database. We are proposing Bandwidth Broker Discovery Protocol to fill this gap. Using BBDP, BBs discover neighbor BBs and learn their identity for future communication. 3. Bandwidth Broker Discovery Protocol (BBDP) Design principle for the BBDP protocol is that it has to be lightweight and it also has to be secure. Lightweight means minimum number of messages should be exchanged. Security is another important aspect. Only valid BBs should be discovered and communicated afterwards, for valuable resource usage. We designed the BBDP protocol considering these two principles. BBDP protocol works as part of a BB implementation. BBDP uses common BB databases. BBDP works after BB boots up and periodically runs to keep the information fresh. Basic operation of BBDP is as follows. When BBDP runs, it first controls the neighbor database neighbor_db of the BB. Neighbor database keeps AS number, edge router address and associated BB address for each neighboring domain. Table 1 shows a sample BB neighbor database state. BBDP checks whether every neighbor domain has a BB IP associated with it. If all neighbor domains have an associated BB address, then BBDP moves on to the waiting state. If a BB address is missing in the neighbor database, then a BBDP Discovery Request Message (DRM) is prepared. This DRM is sent to the edge router of the related domain. There can be a situation where two neighboring domains connected through two different edge routers. In this case DRM is sent to both edge routers. When a router receives a BBDP DRM destined to it, router forwards that message to its own BB, if one exists. Upon receiving the BBDP DRM, BB first checks the message to ensure that the message is authentic and comes from a valid BB. If a message fails in authentication and authorization checks, message is simply discarded. After clearing the security checks, target BB learns the IP address of the requesting BB and updates its own neighbor database with the information included in the DRM. Since the IP address of the requesting BB is known by the target BB, target BB can directly communicate with the requesting BB. Target BB prepares a BBDP Discovery Answer Message (DAM) and sends it back to the requesting BB. DAM also goes through the same security checks and if DAM passes security checks, BB updates its neighbor database with the IP address of the neighbor domain BB. Fig. 2 shows the message exchange sequence of BBDP. In this figure, BB1 is discovering its neighbor BB in Domain 2 (BB2). Line 1 represents BBDP Discovery Request Message. Line 2 shows that the request is forwarded by the edge router to BB2. Line 3 represents BBDP Discovery Answer Message sent back to BB1. 3.1. Security of the protocol There are previous works discussing the possibilities of securing BB. Security mechanism of the BBDP follows the same principles as previous Table 1 A sample bandwidth broker neighbor database state. BB neighbor database AS number
Edge router address
BB address
AS1 AS2 …
AS1_ER_IP AS2_ER_IP …
AS1_BB_IP AS2_BB_IP …
233
inter-BB secure communication works follow [17,18,19,20,21]. Security of the communication requires Bandwidth Brokers to have a secret key. Using PKI [22], a bandwidth broker possesses a public key/private key pair. Digital certificates (DC) ensure authenticity of the keys and are issued by Certificate Authorities (CA). Inter-BB security is provided using a PKI. This system requires each BB to have DC of other BBs to verify the identity of other BBs. It is not clearly specified in earlier works how these certificates can be distributed. BBDP also solves the problem of distribution of DCs to other BBs. Digital signature is the common method to ensure the integrity of the message and also to identify the owner of the message. BBDP uses digital signature to sign messages. Each message of BBDP is partially digitally signed using private key of the source BB. Certificate of the source BB is included in the message. When destination BB (dBB) receives the message, it first controls the authenticity of the DC through a CA. After authenticating the BB, then dBB controls the authenticity of the message. These control sequences ensure that the CA belongs to a valid trusted BB and the message is signed by that BB and not tampered on the way. 3.2. Message structure of BBDP There are two basic message types used by BBDP. These are Discovery Request Message and Discovery Answer Message. Message structure of both message types is the same. Fig. 3 shows the message structure. Message structure is prepared according to the IPv4 and 16-bit AS number system. It can easily be adapted to IPv6 and 32bit AS number. • • • • • •
Message Type: 1 for Request, 2 for Answer. Message Length: Includes all the fields in the message. BB Identity: IP address of the source BB. Sequence Number: Randomly generated integer. AS Number: Autonomous System number of the domain. Digitally Signed Message Hash: Hash value of Message Type, Message Length, BB Identity, and Sequence number is calculated and signed with private key of the source BB. • Digital Certificate: DC of source BB. • Checksum: 16-bit checksum for error control. 3.3. BBDP message processing BBDP contains two processes for message processing. First process sends BBDP DRM and receives and processes incoming DAM. Second process answers incoming BBDP DRM with a DAM. 3.3.1. Sending a discovery request message Fig. 4 shows the message processing sequence for sending DRM and receiving a DAM. When BBDP Request process is started, it controls the neighbor db. Every entry in the database is checked to see if there is a missing (neighbor AS–BB IP) pair. If all neighbor ASs have an associated BB IP, then process ends and waits for the refresh. Otherwise, for every neighboring autonomous system (AS) that has a missing BB IP, a DRM is prepared. Message type is set as 1. BBs own IP address is put into the BB identity field. A randomly generated 32-bit sequence number is inserted into the sequence number field of the message. Then, domain's AS number is written in the AS number field and also DC is inserted into the message. Next, the hash value of the message type, message length, BB identity and sequence number fields is calculated. This hash value is digitally signed using BBs own private key and inserted into the message. As the last step, checksum is calculated and added to the message. This DRM is sent to the border router of the neighboring domain. Identity of the neighboring domain border router can be obtained through BGP and this information is already available in the neighbor_db.
234
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
Fig. 2. BBDP message exchange.
After sending the message, a BBDP Discovery Answer Message (DAM) is expected. When a DAM is received, BBDP goes into the response check state. Upon receiving a response, first the integrity of the message is controlled by calculating the message checksum and comparing this value with the one arrived in the message. If this check fails, that means message is corrupted on the way. Since the BB sending the DAM does not have any means to know that the message is corrupted, source BB needs to resend the DRM. If the message is not corrupted, then security check is performed. At this stage, identity of the sending BB needs to be verified. Receiving BB extracts the DC of the sending BB from the message and verifies the identity of the BB through a CA. If the DC is not a valid BB certificate, then the message is not a valid DAM and it is simply discarded. If DC belongs to a valid BB, receiving BB stores DC in the database, and extracts the public key of the sending BB from the DC. This key is used to check the digitally signed part of the message. Stored DC will also be used for future SIBBS transactions. Receiving BB calculates the hash value of the fields mentioned before and then decrypts the digitally signed hash value using the public key of the sending BB. In order to determine whether the message is tampered by a third party on transit, receiving BB compares these two hash values. If these values do not match, then the message is tampered. Receiving BB treats this message as a corrupted message and resends a DRM. If these values match, that means incoming message is a valid DAM. Receiving BB extracts the IP address of the sending BB from the message and updates the neighbor db database with this value. There can be a case where the incoming DAM is a totally invalid message. The reasons can be that DC is not valid or DAM is not coming from one of the BBs that were sent a request etc. In this case, receiving BB discards the message, returns to the message waiting state and waits for the next DAM.
We implemented a timeout mechanism into the protocol. After a DRM is sent, BB starts a timer. If a response message is not received within the timeout duration, BB resends a DRM. This process is repeated 3 times. If a DAM is not received after sending 3 DRMs, this means either destination BB is not reachable or there is no BB in the neighboring domain. BB stops trying and will not send another message to the same neighbor domain until the next refresh period. 3.3.2. Receiving a discovery request message Second process of BBDP listens to a specified port for incoming DRM. These messages can only come from one of the edge routers in the BBs domain. Fig. 5 shows message processing sequence of receiving a DRM. Upon receiving a DRM, first the integrity of the message is checked by checksum control. If the message is corrupted, it is simply discarded. If the message is not corrupted, then the DC of the sending BB is extracted from the message and validity of the DC is checked. If DC is not valid, then the message is discarded. Otherwise message integrity check is performed. Hash value of the message type, message length, BB identity, and sequence number fields is calculated. Public key of the sending BB is extracted from the DC and the digitally signed hash value in the message is decrypted. If these two hash values are the same, that means message is authentic. Neighbor db is updated with the sending BB IP address. The DC of the sending BB is also stored in the database to be used in future transactions. Receiving a valid DRM requires responding with a valid DAM. Message structure of a DAM is the same as the message structure of a DRM which is shown in Fig. 3. When preparing a DAM, message type is set as 2. Receiving BB IP address is written into the BB identity field. Sequence number is copied from the incoming DRM and embedded into the sequence number field of the DAM. AS number of the receiving domain is inserted into the message. Hash values of the fields mentioned before is calculated and this hash value is signed
Fig. 3. BBDP message structure.
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
235
Fig. 4. Sending DRM and receiving DAM.
with the private key of the receiving BB. This signed hash value is inserted into the message. DC is also inserted. Then the checksum is calculated and written at the end of the message. Since the IP address of the sending BB is extracted from the incoming DRM, DAM is sent directly to the sending BB. A refresh mechanism is implemented into the protocol. After identifying the missing BB IP addresses, BBDP sends DRM messages to those domains and receives DAMs if a BB is residing in the corresponding domain. After receiving all the DAMs, BBDP goes into the waiting mode through a refresh period. Refresh time can be in the order of hours or days. At the end of refresh period, regardless of whether a domain has a corresponding BB IP address or not, DRM is sent to all neighboring domains to verify the information kept in the database is still valid.
4. Implementation of the Bandwidth Broker Discovery Protocol BBDP is implemented using C language on Linux platform. Same program is tested and used on Windows platform using Cygwin environment. BBDP implementation is composed of three components. First component is responsible for sending DRM and processing incoming DAM. We will refer to this component as sender. Second process is responsible for listening for incoming DRM and sending back DAM, which we will refer as listener. Third component is a small program needed on routers. This program recognizes BBDP messages and forwards them to its own BB. Sender program runs when BB starts and controls the neighbor_db to determine the ASs that does not have a corresponding BB address in the database. After determining the missing BBs, program prepares DRMs for each of those ASs and sends those messages to the corresponding edge routers. After that, program waits for incoming DAMS. For each of the neighbor ASs that has missing BB IP address, program performs following actions to prepare a DRM:
• • • • •
Set message type: 1 Insert own BB IP address Generate and insert 32-bit random sequence number Insert own AS number Calculate and sign the hash: to calculate hash, MD5 [23] is used. To sign the calculated hash, openssl [24] is used. Following is the command structure to sign a hash using openssl: – openssl rsautl -sign -inkey private.pem -keyform PEM -in hash N signature • Calculate and insert the message length • Write the Digital Certificate into the message • Calculate and insert the checksum After completing all the fields, DRM is sent to the corresponding edge router. Process then waits for the incoming DAMs. Timeout duration is set to 20 s in the implementation. We are aware that this is a long duration in a networking environment. This duration can be adjusted according to the needs of the actual network. When a DAM is received, following actions are performed: • • • •
Calculate the checksum and verify that message is not corrupted. Control the sequence number and match the DAM with a DRM. Extract the Digital Certificate and verify the validity of the certificate. Extract the public key of the sending BB from the DC. This is accomplished using openssl: – openssl x509 -inform pem -in recv.cert -pubkey -noout N public.key • Extract the digitally signed part and store it into foo.ssl file. Using the public key, decrypt the signed hash value and store it. Openssl command to accomplish this task: – openssl rsautl -verify -inkey public.key -keyform PEM -pubin -in foo.ssl N recovered-hash • Calculate the hash value using MD5 and compare the result with the value stored in recovered-hash file. • If all the controls succeed, update neighbor_db with the incoming BB IP address.
Fig. 5. Receiving DRM and sending DAM.
236
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
In the implementation, each BB needs to have a Digital Certificate. These certificates are constructed using openssl. In theory, all DCs need to be verified by a CA. However in the implementation, we did not employ a CA and assumed the validity of the DCs inserted into the messages. In the implementation, self-signed DCs are created using openssl. Private Key is created using the following command: • openssl genrsa -out private.key 1024 Then, using the generated private key, DC is created: • openssl req -new -x509 -nodes -sha1 -days 365 -key private.key N host.cert This command creates a self-signed x509 [25] certificate valid for 365 days. Fig. 5 shows the message processing sequence of the listener. Listener is always running and listens to a specified port for incoming DRM. These messages may only be coming from one of the edge routers in the domain. When a DRM is received, listener first controls the checksum to determine whether message is corrupted or not. If it is a sound message, listener then extracts the DC from the message and verifies the authenticity of the DC through a CA. If the DC is authentic, listener calculates the hash value of the message fields. Then, using the public key from the DC, listener decrypts the signed hash message and compares the values of these two hashes. If values match, that means message is not tampered. The listener stores sending BB IP address into its neighbor_db and also stores DC of the sending BB for future transactions. Then, listener prepares a DAM to be sent to the owner of the DRM. Following actions are performed when preparing a DAM: • • • • •
Set message type:2 Insert own BB address Copy the sequence number from the DRM and insert into DAM Insert own AS number Calculate and sign the hash with own private key and insert into the message • Calculate and insert the message length • Write the Digital Certificate into the message • Calculate and insert the checksum This DAM message is sent directly to the IP address of the sender BB. Listener goes back to the listening mode and waits for other incoming DRMs. Third part is a small program running on the router. Since at the initial stage, when a BB tries to discover its neighbors, BB only knows the edge routers of the neighboring domains. DRM messages are sent to the edge routers. In the BB/Diffserv environment, every BB needs to be in contact with all the routers in its domain. So, if there is a BB running in a domain, all routers know the identity of the BB. When a router receives a DRM, router forwards the DRM to the BB. A small addition to the router software is needed so that routers recognize the BBDP message types and forward them to the
BB. If there is no BB running in the domain, routers ignore BBDP messages. 4.1. Testing the implementation In order to test the system, we designed a scenario and tested all the functionalities. Fig. 6 shows the topology used to test the system. In this topology, BB1 and BB2 are two neighbor Bandwidth Brokers and they do not know the IP address of each other. BB1 sends a DRM to ER2 to discover whether neighbor domain has a bandwidth broker or not. Upon receiving the BBDP DRM, ER2 recognizes protocol type and message type and forwards DRM to its own BB, which is BB2. BB2 processes the message, and if the message passes integrity and security checks, BB2 updates its neighbor db and sends back a BBDP DAM directly to BB1. If the DAM is received within the timeout duration, BB1 performs integrity and security controls on the message. If the controls succeed, BB1 updates its neighbor_db with the BB2 IP address. In the second scenario, we tested the situation where there is no BB on the second domain and BB1 tries to discover the IP address of the BB of Domain 2. Fig. 7 shows the topology used to test this scenario. In this case, BB1 prepares a BBDP DRM and sends it to ER2. However, ER2 discards the packet since there is no BB in the domain. BB1 will timeout and resend the message. This repeats 3 times. After third timeout, BB1 concludes that either Domain 2 does not have a BB or it is unreachable and stops sending DRM to that domain until the next refresh period. Refresh period is set as one day in the implementation. In our third scenario, we mimicked the situation where BB1 receives an invalid response message. We tested the case where BB1 receives a BBDP DAM without sending a DRM. Upon receiving the DAM, BB1 controls the message type. Seeing that message type is 2 and there is no previously sent matching DRM, BB1 discards the message. We also tested the situations of corrupt messages and messages with invalid DCs. Implementation works as expected in all the tested scenarios. 4.2. Message overhead of BBDP BBDP overhead depends on the size and the connectivity of the Autonomous System [26]. BBDP sends one DRM to each of the neighbor AS. As of June 2011, average connectivity degree of ASs is 3,0685. This means on average each AS sends approximately 3 DRM to neighbor ASs. There is an upper bound on the number of messages injected on the network by BBDP. This number is limited by the degree (number of neighbor ASs) of an AS. Due to the design of BBDP, in the normal operation actual number of messages will be less than the upper limit. When a BB receives a valid DRM, that BB learns the IP address of the sending BB and updates database automatically. This means receiving BB will not be sending a DRM later to the sending BB, because
Fig. 6. Test topology.
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
237
Fig. 7. Topology of the second scenario: domain2 without a BB.
IP address of the sending BB is already in the database. This functionality lowers the number of messages injected into the network. Another measure for the overhead is the size of the message. Fig. 3 shows the basic BBDP massage structure. Size of the message in number of bytes can be calculated from the figure. Total size of the fields Message Type, Message Length, BB Identity, Sequence Number, AS Number and Checksum is 16 Bytes. Size of the digitally signed hash message is 128 Bytes. Size of the Digital Certificate is 1281 Bytes. In total, the message size is 1425 Bytes. Without the DC, message size is 144 Bytes. Refresh period is another factor affecting the overhead of BBDP. If the Refresh period is too short, overhead will be high. Selecting the refresh period one day results in less overhead on the network. Since ISPs will be employing BBDP and there will be only one responsible BB for BBDP communication, overhead of the BBDP, compared to the overall network load, is negligible. 5. Conclusion In this study design and implementation of a Bandwidth Broker Discovery Protocol (BBDP) is introduced. With this protocol, BBs can discover each other automatically. BBDP provides the security features that were missing in the previous BB architectures. Using certificate authorities and digital certificates, BBDP securely exchanges messages and also exchanges DCs that will be used for future secure transactions by signaling protocol that works between Bandwidth Brokers. BBDP is implemented in a lab environment and tested under various scenarios. The protocol is designed to be lightweight and simple which means protocol does not keep valuable network resources busy and works unintrusively. We also intended to have a small message size for the protocol. However, for security purposes, message size got bigger because of the inclusion of the DC into the messages. This was necessary because, first inter-BB interaction takes place via BBDP. We assume DCs of BBs are not distributed by other means. If BBs have other means to obtain DCs of other BBs, than DC can be omitted from the message and the message size will be small. Even with the inclusion of DC into the messages, since protocol does not run very often, the load protocol brings to the network can be ignored. Designed protocol is running between neighboring ASs. This means the path length of the messages will be small and will not affect the network at large. Our lab tests show that protocol runs effectively and securely. Using this protocol, BBs that are not communicated before can discover and securely identify each other. BBDP uses the information gathered from the BGP protocol to identify the neighboring ASs and edge routers of the neighboring domains. Future work is to test the protocol under a fully implemented BB with SIBBS protocol to find out the working performance and possible compatibility issues with other protocols.
References [1] J. Wroclawski, The Use of RSVP with IETF Integrated Services, Request for Comments: RFC 2210, IETF Network Working Group, 1997. [2] R. Braden, et al., Resource Reservation Protocol (RSVP) — Version 1 Functional Specification, Request for Comments: RFC 2205, IETF Network Working Group, 1997. [3] S. Blake, et al., An Architecture for Differentiated Services, Request for Comments: RFC 2475, IETF Network Working Group, 1998. [4] H.Z. Abidin, N. Fisal, IP QoS enhancement using Diffserv in IPv6 network, Proc. The 9th Asia-Pacific Conference on Communications, 2003, pp. 183–186. [5] J. Zhou, Y. Wang, G. Hu, End-to-end performance measurement model on Diffserv domain in IPv6 network, Proc. Networked Computing and Advanced Information Management — NCM, 2010, pp. 203–206. [6] W.H. Hsu, Y.P. Shieh, Diffserv-based bandwidth-constrained anycast routing in a mobile IPv6 Network, International Journal of Communication Systems 24-2 (2011) 139–152. [7] T. Aziz, Performance evaluation of real-time applications over Diff-serv/MPLS in IPv4/IPv6 networks, Masters Thesis, Blekinge Institute of Technology, Dec. 2010. [8] A. Vallejo, A. Zaballos, J. Abella, G. Villegas, J.M. Selga, Evaluation of a policy-based QoS management architecture over an IPv6 Diff-serv testbed, Proc. 3rd International Conference on Testbeds and Research Infrastructure Development of Networks and Communities, 2007, pp. 1–9. [9] S. Brim, B. Carpenter, F. Le Faucheur, Per Hop Behaviour Identification Codes, Request for Comments: RFC 2836, IETF Network Working Group, 2000. [10] K. Nichols, V. Jacobson, L. Zhang, A Two-bit Differentiated Services Architecture for the Internet, Request for Comments: RFC 2638, IETF Network Working Group, 1999. [11] H.A. Mantar, T. Okumus, J. Hwang, S.J. Chapin, A scalable intra-domain resource management architecture for Diffserv networks, Journal of High Speed Network 15 (2006) 185–205. [12] C. Bouras, K. Stamos, An efficient architecture for bandwidth brokers in DiffServ networks, International Journal of Network Management 18-1 (2008) 27–46. [13] S. Sohail, S. Jha, The survey of bandwidth broker, Technical Report UNSW-CSE-TR0206, The University of New South Wales, 2002. [14] A. Adamson, et al., Qbone Signalling Design Team Final Report, http://qos.internet2. edu/wg/documents-informational/20020709-chimento-etal-qbone-signaling/ 2001. [15] T.M. Lim, B.S. Lee, C.K. Yeo, Path and oracle discovery protocol, Journal of Network and Systems Management 11–4 (2003) 447–467. [16] D. Katz, K. Kompella, D. Yeung, Traffic engineering extensions to OSPF version 2, request for comments: RFC 3630, IETF Network Working Group, 2003. [17] V. Sander, W.A. Adamson, I.T. Foster, A.J. Roy, End-to-end provision of policy information for network QoS, Proc. HPDC, 2001, pp. 115–126. [18] B.S. Lee, et al., Secure communications between bandwidth brokers, ACM SIGOPS, Operations Systems Reviews 38–1 (2004) 43–57. [19] C. Bouras, K. Stamos, Securing a bandwidth broker architecture, Processing International Conference on Interactions Composite (2005) 474–480. [20] M. Gunter, C. Matt, I. Khalil, H. Kneer, T. Braun, Security Analysis of the Broker Architecture, Deliverable ID: CATI-IAM-DE-P-003-1.2, 1999. [21] C. Bouras, K. Stamos, Security issues for multi-domain resource reservation, network security, administration, and management: advancing technologies and practices, IGI Global 2011, 2011 to appear. [22] C. Adams, S. Lloyd, Understanding PKI: Concepts, Standards, and Deployment Considerations, Second Ed, Addison-Wesley, 2002. [23] R. Rivest, The MD5 Message-Digest Algorithm, Request for Comments: RFC 1321, IETF Network Working Group, 1992. [24] Openssl Web site, http://www.openssl.org accessed June 2010. [25] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Infrastructure Certificate and CRL Profile, Request for Comments: RFC 2459, IETF Network Working Group, 1999. [26] AS Connectivity Report, http://bgp.potaroo.net/as2.0/bgp-active.html accessed June 2011.
Contents lists available at SciVerse ScienceDirect
Computer Standards & Interfaces journal homepage: www.elsevier.com/locate/csi
Design and implementation of a Secure Bandwidth Broker Discovery Protocol Ibrahim Taner Okumus a,⁎, Sezgin Cekerekli b a b
Mugla University, Faculty of Engineering, Computer Engineering Department, Kotekli Kampusu, 48000, Mugla, Turkey Mugla University, Graduate School of Sciences, Kotekli Kampusu, 48000, Mugla, Turkey
a r t i c l e
i n f o
Article history: Received 25 February 2011 Received in revised form 28 June 2011 Accepted 10 August 2011 Available online 16 September 2011 Keywords: Bandwidth Broker Discovery IP QoS Diffserv Bandwidth Broker SIBBS
a b s t r a c t Differentiated Services architecture definition lacks control level functionalities. One of the solutions proposed to fill this gap is Bandwidth Brokers (BB). Bandwidth Brokers are autonomous entities inside a network which is responsible for bandwidth management of the network along with other tasks. There is a lack of protocol for Bandwidth Brokers to discover other Bandwidth Brokers automatically. This study introduces a new Secure Bandwidth Broker Discovery Protocol (BBDP), which allows Bandwidth Brokers to automatically discover other Bandwidth Brokers. In this paper design principles, protocol details, working scenarios and implementation details of the BBDP protocol are presented. © 2011 Elsevier B.V. All rights reserved.
1. Introduction Providing quality of service on computer communication networks is an important issue and much effort is spent by researchers to find a scalable solution that can work on the global Internet [1,2,3]. Differentiated Services (Diffserv) architecture [3] is one of these solutions and is seen as the most viable solution because of its simplicity and scalability. Diffserv is designed to work both with IPv4 and IPv6. Deployment of IPv6 enhanced the importance of providing QoS. Diffserv is tested on IPv6 networks [4,5,6,7,8]. Diffserv defines limited number of QoS classes called Per Hop Behaviors (PHB) [9] and every router is only responsible to provide QoS classes defined with these PHBs. Diffserv architecture defines data level functionalities to provide a scalable QoS. However control level functionalities are not included in the architectural definition. Providing control level functionalities intrigued many researchers and there are various studies on this subject. One of the solutions is named Bandwidth Broker (BB) [10]. Bandwidth Broker is a logical entity and works as a resource manager inside a network. There are various BB architectures [11,12] proposed by researchers. A BB can be a centralized agent or it can be designed to work in a distributed fashion. Regardless of the architecture, every domain is controlled by a BB. A survey of Bandwidth Brokers can be found in [13].
⁎ Corresponding author. Tel.:+90 252 2111723; fax: + 90 252 2111702. E-mail address: [email protected] (I.T. Okumus). URL: http://ceng.mugla.edu.tr/~okumus/ (I.T. Okumus). 0920-5489/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2011.08.003
Main duty of a BB is to manage bandwidth inside a network by performing appropriate actions. BB works with requests. When a QoS request arrives to a BB, BB analyzes this request and then first finds an appropriate QoS path to the destination. Destination can be an internal node inside the domain or it can be a node residing in another domain. After finding an appropriate path, BB polls all the routers on the path to get the latest QoS state of each node along the path. Next step is to allocate resources, so that actual traffic can get promised QoS from the network. In order to provide end-to-end (e2e) QoS, BBs need to perform the tasks defined above from source to destination. As we mentioned before, destination can be on the same domain as the BB, or it can be in another domain. If traffic needs to traverse multiple domains, a single BB by itself cannot provide e2e QoS, because BBs are autonomous just like the domains (autonomous systems (AS)) they serve. If the source and destination reside in different ASS, each AS's BB needs to get the request and take action to provide the requested QoS. This requires BB to BB communication to relay the request toward the destination. Simple Inter-Bandwidth Broker Signaling (SIBBS) Protocol is designed for inter-BB communication [14]. SIBBS Protocol mainly works with two message types. Resource Allocation Request (RAR) message and Resource Allocation Answer (RAA) message. When a node needs a QoS resource allocation from a network, node constructs an RAR message and sends that to the BB of the domain. Upon receiving the RAR message, BB determines a path on its domain toward the destination of the request. If the destination is not on BB's domain, BB determines the next domain to reach the destination by checking BGP information. After determining the next domain BB checks neighbor database to find the address of the next domain's
232
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
BB. Then RAR request is forwarded to the next domain's BB. This procedure is repeated by each BB until the request reaches the destination. Internet consists of interconnected networks. These networks are called autonomous system (AS). ASs are considered to be neighbors if they have BGP neighbor relationship. Number of ASs on the Internet is increasing day by day. Inter-AS connectivity has a dynamic nature due to the customer–provider relationship among them. ASs can change service providers or peers and this will change the neighbor relationship. Some ASs become passive and new ASs appear frequently. This dynamic nature of the interconnected network makes it hard to keep track of neighborship information. During the design of the SIBBS protocol, it is assumed that BBs already know all neighboring BB addresses. This information is kept in neighbor database. Because of the dynamic nature of the Internet, an automated BB discovery mechanism is needed to fill in the neighbor database and if necessary update the information in the neighbor database automatically. To the best of our knowledge, only protocol that is close to automatic discovery of BBs is Path and Oracle discovery Protocol (PODP) [15]. However, this protocol is designed for path discovery and passive BB discovery. Although, PODP is designed for a centralized BB, it is not clear and not discussed how it relates to the authorization, authentication and resource management duties of a BB. PODP works with the underlying routing protocol to relay messages. BB later learns the path taken by those messages. BB is mainly used as a resource manager. Before making reservations and accepting QoS requests, BB needs to decide about the availability of the resources and which path to allocate for the request. Another issue with the PODP is that security and reliability is not considered in the protocol design. A BB is an important entity in a domain which needs to work securely when allocating resources. In this study we present a new secure protocol for neighbor BB discovery. This protocol is called Bandwidth Broker Discovery Protocol (BBDP). Apart from automated discovery of neighbor BBs, BBDP also helps with the security and reliability of BB communication. Previous studies on BB security show that inter-BB communication can be secured by using a certificate based system. In that system, each BB will have a certificate. These certificates are distributed among BBs. Nature of distribution is also an open issue. BBDP is also used for certificate distribution among BBs. In this sense, BBDP itself is designed securely and also will lay the foundation of interBB communication security by coordinating certificate exchange among BBs. The rest of this paper is organized as follows. Section 2 shows the overall system and how BBDP fits into the architecture. Section 3 gives the details of the design of the BBDP. In Section 4 we provide implementation details and different working scenarios for BBDP. Section 5 gives the concluding remarks and future work.
2. System architecture In this study, Differentiated Services (Diffserv) is used as the QoS technology. On top of Diffserv, BB is employed as inter and intra-domain resource manager inside a domain. SIBBS protocol is used as the signaling protocol for inter-BB communication. BBDP protocol is used for neighbor BB discovery purposes. Fig. 1 shows a sample network with above mentioned protocols and components working together. If a host wants to request certain QoS to a destination, host needs to contact the BB of its domain. This communication takes place via SIBBS protocol. Host uses Resource Allocation Request (RAR) message to indicate the properties of the requested QoS to the BB. BB receives the RAR and checks the requested QoS. BB performs authentication and authorization to verify the identity of the host and to determine the level of QoS that host can request. All these details are pre-agreed via Service Level Agreements (SLA). If these controls succeed, BB determines if the destination is in its own domain or in another domain. If the destination is in BB's own domain, then the BB determines a path to the destination that satisfies the requested QoS. QoS path can be found using a QoS routing protocol employed in the network, such as OSPF-TE [16]. When a BB determines the ingress router that the flow will enter the network, then the BB can communicate with the ingress router to find a QoS path to the destination. If a path is available that satisfies the requested QoS, BB returns a positive Resource Allocation Answer (RAA) back. BB also communicates with the routers along the path to configure them for the requested QoS. This requires a BB to be able to communicate with all the routers in its domain. Also all the routers in a domain knows the identity of the BB. In case the destination is in another domain, the BB needs to determine the egress router that is connected to the next domain toward the destination. A BB can get the autonomous system (AS) level path to the destination from BGP routers. This will show a series of AS numbers from source domain to destination domain. Next, the BB determines a QoS path from the ingress router to the egress router. If that path is available, that means QoS can be satisfied in BB's own domain. Then, BB needs to communicate with the downstream domain's BB to relay the RAR request. This is achieved via SIBBS protocol. Next domain's BB repeats the same steps as the source domain BB and forwards the RAR to the next domain's BB. This will continue until RAR reaches the destination. If every domain's BB on the path to the destination accepts the QoS request, a positive RAA will be relayed back to the host following the reverse path. In order for inter-BB communication to take place, BB keeps a database containing the identities (basically IP addresses) of neighbor BBs. This database contains entries consisting of BB IP address, AS number, and edge router IP for that AS (BB IP, ASN, ER IP). Every BB needs to know the AS number and edge router (ingress router) of a neighboring domain. In the concept of Diffserv and BB, neighboring
Fig. 1. A sample network.
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
means two neighbor domains having a Service Level Agreement between them. SIBBS protocol is designed to work in a sequential manner. If a QoS request traverses more than one domain, every BB communicates with its upstream/downstream immediate neighbor only. So this requires every BB to know the identity of all BBs in neighboring domains in order to initiate a SIBBS communication. There is a need for an automated BB discovery mechanism to fill in the neighbor BB database. We are proposing Bandwidth Broker Discovery Protocol to fill this gap. Using BBDP, BBs discover neighbor BBs and learn their identity for future communication. 3. Bandwidth Broker Discovery Protocol (BBDP) Design principle for the BBDP protocol is that it has to be lightweight and it also has to be secure. Lightweight means minimum number of messages should be exchanged. Security is another important aspect. Only valid BBs should be discovered and communicated afterwards, for valuable resource usage. We designed the BBDP protocol considering these two principles. BBDP protocol works as part of a BB implementation. BBDP uses common BB databases. BBDP works after BB boots up and periodically runs to keep the information fresh. Basic operation of BBDP is as follows. When BBDP runs, it first controls the neighbor database neighbor_db of the BB. Neighbor database keeps AS number, edge router address and associated BB address for each neighboring domain. Table 1 shows a sample BB neighbor database state. BBDP checks whether every neighbor domain has a BB IP associated with it. If all neighbor domains have an associated BB address, then BBDP moves on to the waiting state. If a BB address is missing in the neighbor database, then a BBDP Discovery Request Message (DRM) is prepared. This DRM is sent to the edge router of the related domain. There can be a situation where two neighboring domains connected through two different edge routers. In this case DRM is sent to both edge routers. When a router receives a BBDP DRM destined to it, router forwards that message to its own BB, if one exists. Upon receiving the BBDP DRM, BB first checks the message to ensure that the message is authentic and comes from a valid BB. If a message fails in authentication and authorization checks, message is simply discarded. After clearing the security checks, target BB learns the IP address of the requesting BB and updates its own neighbor database with the information included in the DRM. Since the IP address of the requesting BB is known by the target BB, target BB can directly communicate with the requesting BB. Target BB prepares a BBDP Discovery Answer Message (DAM) and sends it back to the requesting BB. DAM also goes through the same security checks and if DAM passes security checks, BB updates its neighbor database with the IP address of the neighbor domain BB. Fig. 2 shows the message exchange sequence of BBDP. In this figure, BB1 is discovering its neighbor BB in Domain 2 (BB2). Line 1 represents BBDP Discovery Request Message. Line 2 shows that the request is forwarded by the edge router to BB2. Line 3 represents BBDP Discovery Answer Message sent back to BB1. 3.1. Security of the protocol There are previous works discussing the possibilities of securing BB. Security mechanism of the BBDP follows the same principles as previous Table 1 A sample bandwidth broker neighbor database state. BB neighbor database AS number
Edge router address
BB address
AS1 AS2 …
AS1_ER_IP AS2_ER_IP …
AS1_BB_IP AS2_BB_IP …
233
inter-BB secure communication works follow [17,18,19,20,21]. Security of the communication requires Bandwidth Brokers to have a secret key. Using PKI [22], a bandwidth broker possesses a public key/private key pair. Digital certificates (DC) ensure authenticity of the keys and are issued by Certificate Authorities (CA). Inter-BB security is provided using a PKI. This system requires each BB to have DC of other BBs to verify the identity of other BBs. It is not clearly specified in earlier works how these certificates can be distributed. BBDP also solves the problem of distribution of DCs to other BBs. Digital signature is the common method to ensure the integrity of the message and also to identify the owner of the message. BBDP uses digital signature to sign messages. Each message of BBDP is partially digitally signed using private key of the source BB. Certificate of the source BB is included in the message. When destination BB (dBB) receives the message, it first controls the authenticity of the DC through a CA. After authenticating the BB, then dBB controls the authenticity of the message. These control sequences ensure that the CA belongs to a valid trusted BB and the message is signed by that BB and not tampered on the way. 3.2. Message structure of BBDP There are two basic message types used by BBDP. These are Discovery Request Message and Discovery Answer Message. Message structure of both message types is the same. Fig. 3 shows the message structure. Message structure is prepared according to the IPv4 and 16-bit AS number system. It can easily be adapted to IPv6 and 32bit AS number. • • • • • •
Message Type: 1 for Request, 2 for Answer. Message Length: Includes all the fields in the message. BB Identity: IP address of the source BB. Sequence Number: Randomly generated integer. AS Number: Autonomous System number of the domain. Digitally Signed Message Hash: Hash value of Message Type, Message Length, BB Identity, and Sequence number is calculated and signed with private key of the source BB. • Digital Certificate: DC of source BB. • Checksum: 16-bit checksum for error control. 3.3. BBDP message processing BBDP contains two processes for message processing. First process sends BBDP DRM and receives and processes incoming DAM. Second process answers incoming BBDP DRM with a DAM. 3.3.1. Sending a discovery request message Fig. 4 shows the message processing sequence for sending DRM and receiving a DAM. When BBDP Request process is started, it controls the neighbor db. Every entry in the database is checked to see if there is a missing (neighbor AS–BB IP) pair. If all neighbor ASs have an associated BB IP, then process ends and waits for the refresh. Otherwise, for every neighboring autonomous system (AS) that has a missing BB IP, a DRM is prepared. Message type is set as 1. BBs own IP address is put into the BB identity field. A randomly generated 32-bit sequence number is inserted into the sequence number field of the message. Then, domain's AS number is written in the AS number field and also DC is inserted into the message. Next, the hash value of the message type, message length, BB identity and sequence number fields is calculated. This hash value is digitally signed using BBs own private key and inserted into the message. As the last step, checksum is calculated and added to the message. This DRM is sent to the border router of the neighboring domain. Identity of the neighboring domain border router can be obtained through BGP and this information is already available in the neighbor_db.
234
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
Fig. 2. BBDP message exchange.
After sending the message, a BBDP Discovery Answer Message (DAM) is expected. When a DAM is received, BBDP goes into the response check state. Upon receiving a response, first the integrity of the message is controlled by calculating the message checksum and comparing this value with the one arrived in the message. If this check fails, that means message is corrupted on the way. Since the BB sending the DAM does not have any means to know that the message is corrupted, source BB needs to resend the DRM. If the message is not corrupted, then security check is performed. At this stage, identity of the sending BB needs to be verified. Receiving BB extracts the DC of the sending BB from the message and verifies the identity of the BB through a CA. If the DC is not a valid BB certificate, then the message is not a valid DAM and it is simply discarded. If DC belongs to a valid BB, receiving BB stores DC in the database, and extracts the public key of the sending BB from the DC. This key is used to check the digitally signed part of the message. Stored DC will also be used for future SIBBS transactions. Receiving BB calculates the hash value of the fields mentioned before and then decrypts the digitally signed hash value using the public key of the sending BB. In order to determine whether the message is tampered by a third party on transit, receiving BB compares these two hash values. If these values do not match, then the message is tampered. Receiving BB treats this message as a corrupted message and resends a DRM. If these values match, that means incoming message is a valid DAM. Receiving BB extracts the IP address of the sending BB from the message and updates the neighbor db database with this value. There can be a case where the incoming DAM is a totally invalid message. The reasons can be that DC is not valid or DAM is not coming from one of the BBs that were sent a request etc. In this case, receiving BB discards the message, returns to the message waiting state and waits for the next DAM.
We implemented a timeout mechanism into the protocol. After a DRM is sent, BB starts a timer. If a response message is not received within the timeout duration, BB resends a DRM. This process is repeated 3 times. If a DAM is not received after sending 3 DRMs, this means either destination BB is not reachable or there is no BB in the neighboring domain. BB stops trying and will not send another message to the same neighbor domain until the next refresh period. 3.3.2. Receiving a discovery request message Second process of BBDP listens to a specified port for incoming DRM. These messages can only come from one of the edge routers in the BBs domain. Fig. 5 shows message processing sequence of receiving a DRM. Upon receiving a DRM, first the integrity of the message is checked by checksum control. If the message is corrupted, it is simply discarded. If the message is not corrupted, then the DC of the sending BB is extracted from the message and validity of the DC is checked. If DC is not valid, then the message is discarded. Otherwise message integrity check is performed. Hash value of the message type, message length, BB identity, and sequence number fields is calculated. Public key of the sending BB is extracted from the DC and the digitally signed hash value in the message is decrypted. If these two hash values are the same, that means message is authentic. Neighbor db is updated with the sending BB IP address. The DC of the sending BB is also stored in the database to be used in future transactions. Receiving a valid DRM requires responding with a valid DAM. Message structure of a DAM is the same as the message structure of a DRM which is shown in Fig. 3. When preparing a DAM, message type is set as 2. Receiving BB IP address is written into the BB identity field. Sequence number is copied from the incoming DRM and embedded into the sequence number field of the DAM. AS number of the receiving domain is inserted into the message. Hash values of the fields mentioned before is calculated and this hash value is signed
Fig. 3. BBDP message structure.
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
235
Fig. 4. Sending DRM and receiving DAM.
with the private key of the receiving BB. This signed hash value is inserted into the message. DC is also inserted. Then the checksum is calculated and written at the end of the message. Since the IP address of the sending BB is extracted from the incoming DRM, DAM is sent directly to the sending BB. A refresh mechanism is implemented into the protocol. After identifying the missing BB IP addresses, BBDP sends DRM messages to those domains and receives DAMs if a BB is residing in the corresponding domain. After receiving all the DAMs, BBDP goes into the waiting mode through a refresh period. Refresh time can be in the order of hours or days. At the end of refresh period, regardless of whether a domain has a corresponding BB IP address or not, DRM is sent to all neighboring domains to verify the information kept in the database is still valid.
4. Implementation of the Bandwidth Broker Discovery Protocol BBDP is implemented using C language on Linux platform. Same program is tested and used on Windows platform using Cygwin environment. BBDP implementation is composed of three components. First component is responsible for sending DRM and processing incoming DAM. We will refer to this component as sender. Second process is responsible for listening for incoming DRM and sending back DAM, which we will refer as listener. Third component is a small program needed on routers. This program recognizes BBDP messages and forwards them to its own BB. Sender program runs when BB starts and controls the neighbor_db to determine the ASs that does not have a corresponding BB address in the database. After determining the missing BBs, program prepares DRMs for each of those ASs and sends those messages to the corresponding edge routers. After that, program waits for incoming DAMS. For each of the neighbor ASs that has missing BB IP address, program performs following actions to prepare a DRM:
• • • • •
Set message type: 1 Insert own BB IP address Generate and insert 32-bit random sequence number Insert own AS number Calculate and sign the hash: to calculate hash, MD5 [23] is used. To sign the calculated hash, openssl [24] is used. Following is the command structure to sign a hash using openssl: – openssl rsautl -sign -inkey private.pem -keyform PEM -in hash N signature • Calculate and insert the message length • Write the Digital Certificate into the message • Calculate and insert the checksum After completing all the fields, DRM is sent to the corresponding edge router. Process then waits for the incoming DAMs. Timeout duration is set to 20 s in the implementation. We are aware that this is a long duration in a networking environment. This duration can be adjusted according to the needs of the actual network. When a DAM is received, following actions are performed: • • • •
Calculate the checksum and verify that message is not corrupted. Control the sequence number and match the DAM with a DRM. Extract the Digital Certificate and verify the validity of the certificate. Extract the public key of the sending BB from the DC. This is accomplished using openssl: – openssl x509 -inform pem -in recv.cert -pubkey -noout N public.key • Extract the digitally signed part and store it into foo.ssl file. Using the public key, decrypt the signed hash value and store it. Openssl command to accomplish this task: – openssl rsautl -verify -inkey public.key -keyform PEM -pubin -in foo.ssl N recovered-hash • Calculate the hash value using MD5 and compare the result with the value stored in recovered-hash file. • If all the controls succeed, update neighbor_db with the incoming BB IP address.
Fig. 5. Receiving DRM and sending DAM.
236
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
In the implementation, each BB needs to have a Digital Certificate. These certificates are constructed using openssl. In theory, all DCs need to be verified by a CA. However in the implementation, we did not employ a CA and assumed the validity of the DCs inserted into the messages. In the implementation, self-signed DCs are created using openssl. Private Key is created using the following command: • openssl genrsa -out private.key 1024 Then, using the generated private key, DC is created: • openssl req -new -x509 -nodes -sha1 -days 365 -key private.key N host.cert This command creates a self-signed x509 [25] certificate valid for 365 days. Fig. 5 shows the message processing sequence of the listener. Listener is always running and listens to a specified port for incoming DRM. These messages may only be coming from one of the edge routers in the domain. When a DRM is received, listener first controls the checksum to determine whether message is corrupted or not. If it is a sound message, listener then extracts the DC from the message and verifies the authenticity of the DC through a CA. If the DC is authentic, listener calculates the hash value of the message fields. Then, using the public key from the DC, listener decrypts the signed hash message and compares the values of these two hashes. If values match, that means message is not tampered. The listener stores sending BB IP address into its neighbor_db and also stores DC of the sending BB for future transactions. Then, listener prepares a DAM to be sent to the owner of the DRM. Following actions are performed when preparing a DAM: • • • • •
Set message type:2 Insert own BB address Copy the sequence number from the DRM and insert into DAM Insert own AS number Calculate and sign the hash with own private key and insert into the message • Calculate and insert the message length • Write the Digital Certificate into the message • Calculate and insert the checksum This DAM message is sent directly to the IP address of the sender BB. Listener goes back to the listening mode and waits for other incoming DRMs. Third part is a small program running on the router. Since at the initial stage, when a BB tries to discover its neighbors, BB only knows the edge routers of the neighboring domains. DRM messages are sent to the edge routers. In the BB/Diffserv environment, every BB needs to be in contact with all the routers in its domain. So, if there is a BB running in a domain, all routers know the identity of the BB. When a router receives a DRM, router forwards the DRM to the BB. A small addition to the router software is needed so that routers recognize the BBDP message types and forward them to the
BB. If there is no BB running in the domain, routers ignore BBDP messages. 4.1. Testing the implementation In order to test the system, we designed a scenario and tested all the functionalities. Fig. 6 shows the topology used to test the system. In this topology, BB1 and BB2 are two neighbor Bandwidth Brokers and they do not know the IP address of each other. BB1 sends a DRM to ER2 to discover whether neighbor domain has a bandwidth broker or not. Upon receiving the BBDP DRM, ER2 recognizes protocol type and message type and forwards DRM to its own BB, which is BB2. BB2 processes the message, and if the message passes integrity and security checks, BB2 updates its neighbor db and sends back a BBDP DAM directly to BB1. If the DAM is received within the timeout duration, BB1 performs integrity and security controls on the message. If the controls succeed, BB1 updates its neighbor_db with the BB2 IP address. In the second scenario, we tested the situation where there is no BB on the second domain and BB1 tries to discover the IP address of the BB of Domain 2. Fig. 7 shows the topology used to test this scenario. In this case, BB1 prepares a BBDP DRM and sends it to ER2. However, ER2 discards the packet since there is no BB in the domain. BB1 will timeout and resend the message. This repeats 3 times. After third timeout, BB1 concludes that either Domain 2 does not have a BB or it is unreachable and stops sending DRM to that domain until the next refresh period. Refresh period is set as one day in the implementation. In our third scenario, we mimicked the situation where BB1 receives an invalid response message. We tested the case where BB1 receives a BBDP DAM without sending a DRM. Upon receiving the DAM, BB1 controls the message type. Seeing that message type is 2 and there is no previously sent matching DRM, BB1 discards the message. We also tested the situations of corrupt messages and messages with invalid DCs. Implementation works as expected in all the tested scenarios. 4.2. Message overhead of BBDP BBDP overhead depends on the size and the connectivity of the Autonomous System [26]. BBDP sends one DRM to each of the neighbor AS. As of June 2011, average connectivity degree of ASs is 3,0685. This means on average each AS sends approximately 3 DRM to neighbor ASs. There is an upper bound on the number of messages injected on the network by BBDP. This number is limited by the degree (number of neighbor ASs) of an AS. Due to the design of BBDP, in the normal operation actual number of messages will be less than the upper limit. When a BB receives a valid DRM, that BB learns the IP address of the sending BB and updates database automatically. This means receiving BB will not be sending a DRM later to the sending BB, because
Fig. 6. Test topology.
I.T. Okumus, S. Cekerekli / Computer Standards & Interfaces 34 (2012) 231–237
237
Fig. 7. Topology of the second scenario: domain2 without a BB.
IP address of the sending BB is already in the database. This functionality lowers the number of messages injected into the network. Another measure for the overhead is the size of the message. Fig. 3 shows the basic BBDP massage structure. Size of the message in number of bytes can be calculated from the figure. Total size of the fields Message Type, Message Length, BB Identity, Sequence Number, AS Number and Checksum is 16 Bytes. Size of the digitally signed hash message is 128 Bytes. Size of the Digital Certificate is 1281 Bytes. In total, the message size is 1425 Bytes. Without the DC, message size is 144 Bytes. Refresh period is another factor affecting the overhead of BBDP. If the Refresh period is too short, overhead will be high. Selecting the refresh period one day results in less overhead on the network. Since ISPs will be employing BBDP and there will be only one responsible BB for BBDP communication, overhead of the BBDP, compared to the overall network load, is negligible. 5. Conclusion In this study design and implementation of a Bandwidth Broker Discovery Protocol (BBDP) is introduced. With this protocol, BBs can discover each other automatically. BBDP provides the security features that were missing in the previous BB architectures. Using certificate authorities and digital certificates, BBDP securely exchanges messages and also exchanges DCs that will be used for future secure transactions by signaling protocol that works between Bandwidth Brokers. BBDP is implemented in a lab environment and tested under various scenarios. The protocol is designed to be lightweight and simple which means protocol does not keep valuable network resources busy and works unintrusively. We also intended to have a small message size for the protocol. However, for security purposes, message size got bigger because of the inclusion of the DC into the messages. This was necessary because, first inter-BB interaction takes place via BBDP. We assume DCs of BBs are not distributed by other means. If BBs have other means to obtain DCs of other BBs, than DC can be omitted from the message and the message size will be small. Even with the inclusion of DC into the messages, since protocol does not run very often, the load protocol brings to the network can be ignored. Designed protocol is running between neighboring ASs. This means the path length of the messages will be small and will not affect the network at large. Our lab tests show that protocol runs effectively and securely. Using this protocol, BBs that are not communicated before can discover and securely identify each other. BBDP uses the information gathered from the BGP protocol to identify the neighboring ASs and edge routers of the neighboring domains. Future work is to test the protocol under a fully implemented BB with SIBBS protocol to find out the working performance and possible compatibility issues with other protocols.
References [1] J. Wroclawski, The Use of RSVP with IETF Integrated Services, Request for Comments: RFC 2210, IETF Network Working Group, 1997. [2] R. Braden, et al., Resource Reservation Protocol (RSVP) — Version 1 Functional Specification, Request for Comments: RFC 2205, IETF Network Working Group, 1997. [3] S. Blake, et al., An Architecture for Differentiated Services, Request for Comments: RFC 2475, IETF Network Working Group, 1998. [4] H.Z. Abidin, N. Fisal, IP QoS enhancement using Diffserv in IPv6 network, Proc. The 9th Asia-Pacific Conference on Communications, 2003, pp. 183–186. [5] J. Zhou, Y. Wang, G. Hu, End-to-end performance measurement model on Diffserv domain in IPv6 network, Proc. Networked Computing and Advanced Information Management — NCM, 2010, pp. 203–206. [6] W.H. Hsu, Y.P. Shieh, Diffserv-based bandwidth-constrained anycast routing in a mobile IPv6 Network, International Journal of Communication Systems 24-2 (2011) 139–152. [7] T. Aziz, Performance evaluation of real-time applications over Diff-serv/MPLS in IPv4/IPv6 networks, Masters Thesis, Blekinge Institute of Technology, Dec. 2010. [8] A. Vallejo, A. Zaballos, J. Abella, G. Villegas, J.M. Selga, Evaluation of a policy-based QoS management architecture over an IPv6 Diff-serv testbed, Proc. 3rd International Conference on Testbeds and Research Infrastructure Development of Networks and Communities, 2007, pp. 1–9. [9] S. Brim, B. Carpenter, F. Le Faucheur, Per Hop Behaviour Identification Codes, Request for Comments: RFC 2836, IETF Network Working Group, 2000. [10] K. Nichols, V. Jacobson, L. Zhang, A Two-bit Differentiated Services Architecture for the Internet, Request for Comments: RFC 2638, IETF Network Working Group, 1999. [11] H.A. Mantar, T. Okumus, J. Hwang, S.J. Chapin, A scalable intra-domain resource management architecture for Diffserv networks, Journal of High Speed Network 15 (2006) 185–205. [12] C. Bouras, K. Stamos, An efficient architecture for bandwidth brokers in DiffServ networks, International Journal of Network Management 18-1 (2008) 27–46. [13] S. Sohail, S. Jha, The survey of bandwidth broker, Technical Report UNSW-CSE-TR0206, The University of New South Wales, 2002. [14] A. Adamson, et al., Qbone Signalling Design Team Final Report, http://qos.internet2. edu/wg/documents-informational/20020709-chimento-etal-qbone-signaling/ 2001. [15] T.M. Lim, B.S. Lee, C.K. Yeo, Path and oracle discovery protocol, Journal of Network and Systems Management 11–4 (2003) 447–467. [16] D. Katz, K. Kompella, D. Yeung, Traffic engineering extensions to OSPF version 2, request for comments: RFC 3630, IETF Network Working Group, 2003. [17] V. Sander, W.A. Adamson, I.T. Foster, A.J. Roy, End-to-end provision of policy information for network QoS, Proc. HPDC, 2001, pp. 115–126. [18] B.S. Lee, et al., Secure communications between bandwidth brokers, ACM SIGOPS, Operations Systems Reviews 38–1 (2004) 43–57. [19] C. Bouras, K. Stamos, Securing a bandwidth broker architecture, Processing International Conference on Interactions Composite (2005) 474–480. [20] M. Gunter, C. Matt, I. Khalil, H. Kneer, T. Braun, Security Analysis of the Broker Architecture, Deliverable ID: CATI-IAM-DE-P-003-1.2, 1999. [21] C. Bouras, K. Stamos, Security issues for multi-domain resource reservation, network security, administration, and management: advancing technologies and practices, IGI Global 2011, 2011 to appear. [22] C. Adams, S. Lloyd, Understanding PKI: Concepts, Standards, and Deployment Considerations, Second Ed, Addison-Wesley, 2002. [23] R. Rivest, The MD5 Message-Digest Algorithm, Request for Comments: RFC 1321, IETF Network Working Group, 1992. [24] Openssl Web site, http://www.openssl.org accessed June 2010. [25] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Infrastructure Certificate and CRL Profile, Request for Comments: RFC 2459, IETF Network Working Group, 1999. [26] AS Connectivity Report, http://bgp.potaroo.net/as2.0/bgp-active.html accessed June 2011.