# Building Scalable and Secure Multicast Delivery Infrastructure in a Local Area Network
## 4 Core Based Multicast Tree
By the choice of these nodes, they can collaborate with each other's prime nodes in the network to create new pairs of keys and generate hash-polynomials. Reducing the depth of the CBT delivery tree may result in reduced end-to-end latency. The administrator wishes to select only powerful switches to be the core of the network. Switches that are not powerful enough may not be able to handle CBT tasks on top of the normal switching operations. **Step 2: Switches That Are One-Hop Away from Core Nodes**  
Let \(S\) be a switch that is directly connected with a core switch \(C\) through port \(P\). \(S\) wishes to join the CBT-delivery tree. \(S\) then broadcasts _CBT-join_ message to every switch connected with \(S\). There is a vendor-neutral standard called Link-Layer Discovery Protocol (LLDP) ratified as IEEE 802.1 AB. The primary purpose of this protocol is for devices to advertise their identity, capabilities and to discover neighbours in a Local Area Network (LAN). Information gathered through LLDP are stored in the device's Management Information Database (MIB). The join message from \(S\) contains the switches public identify. Switches that receive this message but are not a part of the CBT delivery tree yet will drop this message. In our case, the message is received by a core switch \(C\). The following steps are taken by \(C\) to authenticate \(S\) and add it to the CBT delivery tree:  
1. Based on \(S\)'s public identity, \(C\) will fetch its public-key \(Pub_{S}\). This is done through the hash polynomial by inputting the node's public identity. This polynomial will accept a node's public identity and outputs its public-key. 2. \(C\) creates a random challenge \(K\). This challenge is used as a session key during the authentication phase
3. Encrypt \(K\) with \(Pub_{S}\) (i.e., \(m=Pub_{S}(K)\) ) and send it to \(S\) through port \(P\). **Switch \(S\)'s Response for the Challenge \(m\)**  
1. \(S\) decrypts \(m\) using its private key, known only to \(S\); thus retrieving the plain-text challenge \(K\). If any other rouge switch impersonates \(S\)'s identity, it may not able to retrieve \(K\), as \(S\)'s private key is known only to \(S\). In a similar fashion, man-in-the-middle attack is also not possible. These are the unique features of our protocol. In a traditional public-key crypto-system, \(C\) may not know the public-key of \(S\). This may result in impersonation and man-in-the-middle attacks. To overcome these attacks, Public Key Infrastructure (PKI) may be installed in the network that contains the repository of all public keys. However, a PKI system may be a single point failure. 2. After retrieving the challenge, \(S\) creates a _CBT-join confirmation_ message, encrypt using the challenge \(K\) (_K(CBT-join confirmation)_ ) and send it to \(C\) through port \(P\). The switch \(S\) may be connected with multiple core nodes. In this case, it will receive multiple challenges. \(S\) will retrieve all the challenges; however, it will send _CBT-join confirmation_ to one core switch. To the rest of them, \(S\) will send _CBT-join reset_ message encrypted using their challenges. Even though this process consumes CPU and time, \(S\) informs other core switches implicitly that it is going to connect with other core nodes. 3. After receiving _K(CBT-join confirmation)_, \(C\) retrieves the _CBT-join confirmation_ message from \(S\). This process implicitly confirms that \(S\) is a legitimate switch with the claimed public identity. Let \(O\) be the ongoing session key in the CBT-multicast process. \(C\) sends \(K(O)\) to \(S\) and adds port \(P\) (as a forwarding port) and switches \(S\) to the CBT delivery tree. The switch \(S\) sets a reverse pointer to port \(P\) for the reverse path to its core node \(C\). Now, \(S\) has the knowledge of the ongoing session key \(O\) and the part of the CBT-delivery tree. The message flow diagram outlining this step is given in Figure 1.