Passport-pk

David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. Passport-PK: Network High Level Source Authentication Simulation and Design 1 David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. Table of Contents Terminology:........................................................................................................................................2 1. Abstract:...........................................................................................................................................2 2. Scopes: .............................................................................................................................................3 3. Passport-PK Designs. ......................................................................................................................4 3.1. Passport-PK header position:....................................................................................................4 3.1.1. Analysis of TCP Header Options:.....................................................................................4 3.1.2. Analysis of IPv6 extension headers..................................................................................4 3.2. Passport-PK header...................................................................................................................4 3.3. Stamping and verification:........................................................................................................5 4. Probability of checking.....................................................................................................................5 4.1. Initial analysis of the threat.......................................................................................................5 4.2. Methodology used to calculate this probability........................................................................5 4.3. Calculations made according to demanded probability............................................................6 5. Simulation scenario and possible simulation environments:............................................................7 5.1. Analysis of the scenario used:..................................................................................................7 5.2. Simulation environment: OMNET++.......................................................................................8 5.3. Initial work with OMNET++....................................................................................................9 6. Work being done in this moment...................................................................................................10 7. Next step work................................................................................................................................11 8. Conclusions....................................................................................................................................11 9. References......................................................................................................................................12 Table of Figures Figure 1: TCP Header...........................................................................................................................4 Figure 2: IPv6 Header..........................................................................................................................5 Figure 3: Graphical analysis of needed probability chance..................................................................7 Figure 4: Numerical analysis of needed probability chance................................................................7 Figure 5: Initial topology used in simulation.......................................................................................9 2 David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. Terminology: In this article, we name as Upgraded router to the border routers in each AS which uses Passport-PK. 1. Abstract: We present the report about the work made by David Muñoz Sanchez in November 2009. At the beginning, I explored some related literature and documents, such as Segment Layer Authentication[1], Passport[4] and Packet Level Authentication[3]. After a week we changed to Passport-PK[2] before continue working in SLA and try, if it was possible, to get some material related to PLA, which is the one SLA is based in, which will be helpful for our purposes. Passport-PK, based in Passport, is a system which evaluates the source addresses in the network through a public key based mechanism. One border router of sender's AS signs the packet with its private key and each upgraded router checks the source of the packet through its public key and , if this checking fails, discard the packet. This checking is done only in a percentage of the packets which passes through the router to allow to optimize the system. The main goal of this article is to show how to improve the performance of this protocol, try to demonstrate in some way that it is effective, show how will be the simulation of this protocol done, which could be the simulator to use and how will it be implemented. 2. Scopes: Assumption: We assume every network can prevent internal source spoofing problem through Ingress Filtering[6] or SAVA[7]. Threat model: Prevent IP spoofing based attacks, specially reflector DDoS[5]. Mitigate on-path and off-path replay attacks. 3 David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. Image from: http://en.wikipedia.org/wiki/Transmission_Control_Protocol (Modified by David Muñoz Sanchez) 3. Passport-PK Designs. 3.1. Passport-PK header position: Initially the Passport-PK header was though to be located in a TCP option or a shim layer between IP and transport layer. So The first work we did is to analyze these options and tried to get the best one for our purposes. 3.1.1. Analysis of TCP Header Options: The Options field in the TCP Header could be used for this purpose[8]. The problem in this case is hat the maximum Length of the options header is 40 bytes or 10 words of 32bits each. In Figure 1 we can see the TCP Header with its fields. 3.1.2. Analysis of IPv6 extension headers. In our case this one will be the option chosen. IPv6[9] allows to encapsulate another protocol's header inside Ipv6's header and define which kind of extension header it is carrying. In our case the best option would be “Hop by Hop” Option which makes this option to be examined in each hop inside the path. In Figure 2 we can see the IPv6 Header and its fields. 4 Figure 1: TCP Header David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. Image from: http://en.wikipedia.org/wiki/IPv6 (modified by David Muñoz Sanchez) 3.2. Passport-PK header It has three fields: Signature(326 bits), Network Prefix (Mask, 8 bits) and a Sequence Number(128 bits, used to prevent replay attacks). Total length of Passport-PK header: 462 bits. This is the reason we choose IPv6 extension header and not the TCP option one. 3.3. Stamping and verification: According to data obtained from PLA, one FPGA hardware accelerator could achieve 194,220 verifications per second. On the other hand, one FPGA could achieve 441.560 signatures per second. 4. Probability of checking. 4.1. Initial analysis of the threat. In networks, every packet pass through a path which has lots of routers. In our case some of this routers could be upgraded and some could be legacy ones. With this scenario it was useful to calculate a good end-to-end average to detect a spoofed packet. According to the path distribution used in Pi[10], we can calculate, if all routers contained in the path are upgraded, which probability do we need to guarantee that a high percentage of packets would be checked. 5 Figure 2: IPv6 Header David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. 4.2. Methodology used to calculate this probability. In this scenario, we consider the probability to check the packet of all routers a constant “p”. And so routers act independently, not influencing the rest, making possible the packet to be checked more than one time through the path or maybe none. So here is the demonstration about how to calculate it: Oposite event: The probability of one event to happen is equal to 1-Probability of the same event not to happen. --> P[E] == 1 - Not(P[E]). Intersection probability(independent events with the same probability) = product of probabilities. --> 1- (1-p)*(1-p)...*(1-p) = 1-(1-p)^n p : probability of each router to check one packet n : number of routers the packet pass through. So X = 1-(1-p)^n. X : End-to-End probability of each packet to be checked at least one time through the path. In this case we want to calculate 'p' to be maximum: X= 1-(1-p)^n --> (1-p)^n = 1-X --> 1-p = (1-X)^(1/n)--> Final formula used: p = 1-(1-X)^(1/n). 4.3. Calculations made according to demanded probability. Figure 3 shows the results of calculating this probabilities in a graphical way. In Figure 4 we can analyze the data more exactly. 6 David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. 7 Figure 3: Graphical analysis of needed probability chance. Figure 4: Numerical analysis of needed probability chance. David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. 5. Simulation scenario and possible simulation environments: 5.1. Analysis of the scenario used: In Figure 5 we can see the scenario used which is similar to the one used in Passport in order to compare the security between each other. We emulate scenarios in which hosts attacker “attacker”, “attacker1” and “attacker2” which are in legacy ASes , spoof the source address of a victim in an upgraded AS to launch reflector attacks against “victim” through some reflector Hosts “rh1”,...,”rh8”. In this topology we can see legacy routers without upgrading “r1”,...,”r11” and upgraded routers which use Passport-PK “ur1”,…, “ur5”. In order to compare the performance of Passport-PK and Passport, we also make the hosts rh1 to rh8 each send 100 files to the victim using TCP. These TCP traffic is used to measure how the reflector attacks affect the network performance. The size of each file is 20KB, and a file transfer aborts if it cannot finish in 10 seconds. We vary the attackers’ sending rate from 1% to 20% of the bottleneck link bandwidth and measure the file transfer time. In order to see how effective is Passport-PK, we want to know how many spoofed packets can be detected if only 30% of AS border routers have been upgraded. In future simulations we will use random generated topologies. 5.2. Simulation environment: OMNET++ After spending almost one week on analyzing OMNET++, NS2, GNS3 and NS3 we decided to use OMNET++ due to the high deployment which it has, the support given to IPv6 and because of its modular structure for simulating which could make easier to reuse modules programmed by other researchers and so will make future research about topics related to DDoS easier to simulate. 8 David Muñoz Sanchez Report Department of Computer Science and Engineering 5 December 2009 T-110.6100 Special Assignment in Datacommunications Software P 5 Cr. Helsinki University Of Technology. 5.3. Initial work with OMNET++ •Module Attacker: Will be the one sending UDP packets to the reflectorHost which will resend it to the “victim”. We need to define a new Module to be used by this host to do this. The next work in this module will be to add a “mark” in the UDP packet(I still have to decide how will it be done) to simulate the signature of the protocol, it should be not very difficult but I preffer to test the network first without special features. Only simulating the DDdoS first and obtaining the results of this test and comparing it with the scenario with our routers. In this case it will be a standardHost6 of omnetpp which will use the module “UDPSpoof” which is defined as follows: ◦Will need a special parameter “srcAddress” defined in omnetpp.ini, UDPSpoof.ned and UDPSpoof.h which will define for the attacker, which address will it spoof. ◦Additionally we will define a new sendToUDP method(inherited from UDPAppBase) which accepts as argument a source Address. This method should be programmed in UDPSpoof.cc too. 9 Figure 5: Initial topology used in simulation