1. Project: Evaluating SNMP Application Level Gateway (SNMP ALG) Eyal Kessler 043127786 Alexander Shifrin 319432720 Dmitri Gorbenko 319352258

2. SNMP – What is it? SNMP is a simple protocol for remotely managing private network using an SNMP daemon. (On routers, web servers, etc.) Protocol consists of simple get / get-next / response / set / trap UDP packets. A packet of these types is simply a reference to an object (referred to as an OID – Object Identifier) in the MIB, a database shared by the management station and the managed host. (A trap packet is a triggered event) Contents of the response packet may contain various types of data: Integers, IP address, Strings, etc.

3. NAT - Network Address Translation: Performs translations of the addresses contained in the IP header of a packet, according to a given translation table. NAT may be useful when: 1.) Implementing a layer-4 proxy. The source address of incoming packets and the destination address of outgoing packets need to be changed from the proxy’s address to a different one. 2.) Private networks use non-certified internal IP addresses. In most cases it’s implemented by adding a software to an access router which scans IP headers of the incoming/outgoing packets and changes their destination/source IP addresses according to the rules. Hence, the use of externally illegal IP addresses is transparent to the outer world.

4. What is SNMP-ALG, and how does it relate to SNMP and NAT: SNMP-ALG is a parser which changes the IP addresses in the contents of a matching packet. For SNMP packets, SNMP-ALG continues NAT’s work where it finished translating the headers of the packet. It translates the payload of the SNMP packet.

5. And why is SNMP-ALG needed? For a company that offers network management, a managed network’s private IP addresses may collide with private addresses in the managing company’s network. For a similar company, several managed networks may have conflicting private address space.

6. SNMP-ALG parsing of a packet: Checks if the packet is an SNMP packet, if not so, it drops the packet and continues to the next packet. Searches the SNMP packet’s payload for IP addresses and OIDs (Object Identifiers) which match elements in its translation table. For each of the above matches, changes the contents of the packet to the translation specified in the translation table. Calculates the checksum difference between the original packet and the changed packet, and uses that value to change the header’s checksum to the new, correct one.

7. And where do we place this wonderful SNMP-ALG? Since it is computationally consuming, it is not recommended to place it on the access router (Linux implementation – since there it is the part of NAT). Instead, packets matching a rule (such as being SNMP packets and their source address matching a list of managed networks) can be encapsulated (IP in IP) and sent to a separate machine running SNMP- ALG (Lucent implementation). The packets would then be taken out of their encapsulation, processed and sent to their destination.

8. Placing of SNMP-ALG: Network 1 Network 2 Network 3 Network N

9. Basic SNMP-ALG: Translates only IPv4 addresses (fixed size - 4 bytes)  Handles only one out of the IP address representations (binary).  Limited transparency to the management application.  Quick and efficient. MIB independent  Easier to implement. Does not change overall packet length  does not increase network packet loss. Problematic with SNMPv3, which incorporates encryption.

10. Advanced SNMP-ALG: Translates both IP addresses and OIDs (Also when derived from octet strings  Handles all IP address representations) MIB aware  More difficult to implement. OIDs do not have a fixed size  May change overall packet size.  Lookup is computationally consuming. Problematic with SNMPv3, which incorporates encryption. Better transparency than the basic SNMP-ALG, but only for a known group of MIBs. May break lexicographical ordering when IP addresses are used as indexes.

11. Our testing of the Lucent implementation of SNMP-ALG consisted of 2 main stages:

12. The needed conditions have been achieved while processing of 10 6 packets sent at bursts of 200 packets per burst. A “burst” is defined as a number of packets sent immediately one after another. Then a certain sleep time (we used minimally allowed by the OS) and then another burst, until a total of 10 5 -10 6 packets is sent.

13. For the case where a “no losses” is the criteria, we increased the rate until 10,000 packets per second was reached. Any rate beyond 10,000 would cause a noticeable drop in the success rate from 99.5% to lower values (at most 80%). The average (averaged from dozens of tests) CPU time taken to process a maximal number of packets without losses (at a CPU usage which is about 25% kernel and 25% snmptrans.) is 50 seconds for 1,000,000 packets. Hence, the average actual time taken to process a maximal number of packets without losses is 100 seconds for 1,000,000 packets   10,000 packets per (actual) second.

14. The above results remain stable while changing different experiment parameters: number of successful lookups per packet, size of mapping file and position of matching row in it. We’ve not succeeded to achieve the stable rate of more than 10,000 packets/sec even by increasing the sending rate dramatically (up to ~40,000 packets/sec), probably due to network limitations (IP layer buffers etc.).

15. BurstActual timeCPU timePackets 25080458·10 5 /10 6 30066.6734665,000/10 6 40050255·10 5 /10 6 50040244·10 5 /10 6 6001610160,000/480,000 800129117,000/480,000 The correlation between the number of packets proceeded can be observed from the following table:

16. The Linux implementation does not seem to work: The module runs, but does nothing. All our efforts to configure iptables – the mapping rules declared to be used by both NAT and MPAT translations, have failed, even after referring to a 40 MB archive of a newsgroup discussing this module. The author of the module ip_nat_snmp_basic explained the sequence of commands so that we succeeded to make NAT translations of packets generated on the machine running the module, but it still refused to translate incoming/outgoing IP packets or parse SNMP packets.