Saturday, June 21, 2014

How to integrate GNS3 and Mininet.

Before we dive into the configuration first lets review the components needed to build the lab.


  1. GNS3 is a software suite that simulates complex networks, providing an intuitive graphical user interface to design and configure virtual networks.
  2. Virtualbox is a virtualization software package for x86 and AMD64/Intel64-based computers from Oracle Corporation. It can be integrated into the GNS3 software suite.
  3. MiniNet is an OpenFlow testing platform consisting of a realistic virtual network, running real kernel, switch and application code, with a single command prompt.

Virtualbox / Mininet 

Download Virtualbox HERE, and install (default settings are fine in most cases). Download Mininet HERE. After installing Virtualbox, and downloading Mininet. 

Now create the Mininet VM in Virtualbox. To do this select NEW button from the toolbar and go through the wizard to install the Mininet VM. At step one select the name and operating system. Type is Linux and Version is Ubuntu. Click NEXT through the memory size configuration. At the Hard drive selection option, select 'Use an existing virtual hard drive file' and add the mininet vmdk file. Now click CREATE.


The Mininet VM is created. Now we need to add extra network adapters to Virtualbox. To do this open the File -> Preferences... menu item, and open the NETWORK tab. Within the NETWORK tab, select the 'Host-only Adapter' tab and click 'Add host-only network' icon, until there are at least three 'VirtualBox Host-Only Adapter's', then click OK.


Now we need to configure the Mininet VM with the newly created virtual ethernet adapters. To do this open the SETTINGS button, and open the NETWORK tab. Select the 'Host-only Adapter', choose the first 'Virtual Host-Only Ethernet Adapter'. And open the Advanced settings of the adapter, and uncheck the 'Cable Connected' option. Add Adapter 2 and Adapter 3 in the same way. And click OK.


Virtualbox is now configured.


GNS3

In GNS3 click Edit -> Preferences... and open the VirtualBox tab. Select the 'VirtualBox Guest' sub tab. Now select the 'Mininet' VM from the 'VM List' drop down list. Set the 'Number of NICs' to 3, and check the 'Reserve first NIC for VirtualBox NAT to host OS', the 'Enable Console Support', and the 'Enable Console Server' checkboxes. Add an 'Identifier name', I choose Mininet, click SAVE button and then click OK button.




Now we are ready the to build our first lab.

The lab

For demonstration purposes the lab will consist of two routers connected to the Mininet VM. The Mininet VM will be started in the standard configuration: one Openflow switch, one controller, and two virtual hosts.












After which I manually attached both the interfaces eth1 and eth2, to the switch s1.

Both routers are configured with in the IP range 10.0.0.0/24. The .1 and .2 are used by the two virtual hosts.

The result of a ping from R1 to R2, from the perspective of R2.

R2#
*Mar  1 00:07:24.155: IP ARP: rcvd req src 10.0.0.3 c00d.2440.0000, dst 10.0.0.4 FastEthernet0/0
*Mar  1 00:07:24.155: IP ARP: sent rep src 10.0.0.4 c00e.2440.0000,
                 dst 10.0.0.3 c00d.2440.0000 FastEthernet0/0
*Mar  1 00:07:24.159: IP ARP: rcvd rep src 10.0.0.3 c00d.2440.0000, dst 10.0.0.3 FastEthernet0/0
R2#
*Mar  1 00:07:42.775: ICMP: echo reply sent, src 10.0.0.4, dst 10.0.0.3
*Mar  1 00:07:42.823: ICMP: echo reply sent, src 10.0.0.4, dst 10.0.0.3
*Mar  1 00:07:42.847: ICMP: echo reply sent, src 10.0.0.4, dst 10.0.0.3
*Mar  1 00:07:42.867: ICMP: echo reply sent, src 10.0.0.4, dst 10.0.0.3

*Mar  1 00:07:42.887: ICMP: echo reply sent, src 10.0.0.4, dst 10.0.0.3

Conclusion

Mininet provides a great tool to experiment with Software-defined networking (SDN), while providing an software switching platform within the GNS3 environment. Non of the routers available in the GNS3 (officially) support Openflow. Limiting the experimentation with Openflow to switching only.


References

Saturday, June 7, 2014

Browser Battle: the 5 most popular Android browsers benchmarked.

Normally I write about Cisco and network engineering related stuff. But today I decided, I'll do something different for a change.

Benchmarking a mobile browser is not a straightforward as it sounds. The developers behind the browser and/or components used in the browsers, develop their software to perform exceptionally well on their own benchmark. 


The five most popular browsers on Android, see table below:


BrowserLayout engineJavaScrip engine
ChromeBlink, WebKit forkV8
DolphineDolphine engine, WebKit forkUnknown
FirefoxGeckoSpiderMonkey
OperaBlink, WebKit forkV8
UC BrowserU3, WebKit forkUnknown

As you can see both Chrome and Opera rely on the same layout engine and JavaScript engine, with only minor differences in versions, and proprietary patches. Since similar technologies produce similar results, it is reasonable to expect similar benchmark results.

Firefox is the only browser that uses a layout engine not forked from WebKit.

Both UC Browser and Dolphine, use their own WebKit fork. It is not public how much they have diverged from the original code. This means we only can make inferences based upon variations in benchmark results.

Benchmark methodology 

All test where done on a Sony Xperia Z: model C6603, running Android 4.4.2. All power management features where disabled and before every test the phone was power-cycled. For data only a stable WiFi connection was used. All browsers cloud based web acceleration options where turned off. The test page was loaded, and the cache was cleared, after which the test was done. All browser versions used where the latest at the time of writing.

The main three parameters tested are JavaScript performance, HTML5 performance, and CSS/HTML5 conformance.

Because of the before mentioned bias of any one particular test JavaScript performance was tested using three benchmarks: WebKit Sunspider 1.0.2 (originally developed, by Apple Inc), Mozilla Kraken 1.1 (developed by the Mozilla Foundation), and Google Octane 2.0.

HTML5 performance was tested using Futuremark Peacekeeper, and Rightware Browsermark 2.1. These test also use HTML feature conformance as part of their compound score metric. So to provide an insight into the CSS/HTML feature conformance as a standalone metric, Facebook's Ringmark 1.4.0 scores are also measured.





JavaScript Benchmark Results

The WebKit Sunspider benchmark metric is measured in milliseconds, lower is better. The original developer of this benchmark is Apple Inc. Apple's browser Safari uses Nitro as its JavaScript engine. Since non of the browsers tested use this JavaScript engine (as far as I am aware). It's result is reasonably unbiased, though somewhat synthetic. Since the executed test are separate pieces of JavaScript specifically developed for this benchmark. Also difference between the fastest and slowest browsers is just 115.3ms. Or to put it in other words UC Browser is only 8.7% slower, than Dolphine Browser. Not a noticeable difference for the user.



As with the previous benchmark, the metric is milliseconds, and lower is better. Also, it is not unexpected that the Mozilla browser obtains the best score on a Mozilla benchmark. The difference between the fastest and slowest browser is almost 2.5 seconds or 18.2% a pretty significant difference. 



The Google Octane 2.0 benchmark uses an entirely different metric, a Geometric Mean, as opposed to the previous two. Here, higher is better. Again we see that browser of the company behind the benchmark achieves the best score. 



JavaScript Benchmark Conclusion

As was expected the performance of  Chrome and Opera's are very similar in all tests. The results of the Kraken 1.1 and Octane 2.0 benchmarks are weighted two times heavier than the results of the Sunspider 1.0.2 benchmark. 

The browser overall JavaScript results:

  1. Dolphine Browser 11.1.1
  2. Firefox 29.0.1
  3. Chrome 35.0.1916.138
  4. Opera 21.0.1437.74904
  5. UCBrowser v9.8.0.435 



HTML5 benchmark results

The Futuremark Peacekeeper seems heavily weighted toward fast rendering. Other components tested include: DOM operations, and text parsing. Notably Firefox scored highest in the categories HTML5 canvas drawing, DOM operations, and text parsing. But only was able to produce a rendering at an average speed 8.59 frames a second, and therefor the slowest at rendering of all browsers. UCBrowser the slowest browser overall, was able to produce 13.87 fps, and Chrome was fastest at 20.17 fps.

The highest speed at which HTML5 canvas drawing was done by Firefox at 4.02 fps, and the slowest was UCBrowser with 3.03 fps. On the desktop platform, the performance is at +30 frames, for most systems and ready to be applied on nextgen websites. On mobile however we are still some time away before the performance is good enough on a large enough portion of the platform, to be a useful addition to mobile websites.



Rightware's Browsermark 2.1 is more of a black box when it comes to understanding how it arrives at its score. But HTML5 canvas drawing and HTML5 conformity seem to be the major factors. As with the previous benchmark, a higher score is better. 

The best two browsers, Chrome and Opera have the same HTML5 conformity score of 81%, Firefox comes in at 74% and both Dolphine Browser and UCBrowser score 66%.



Facebook's Ringmark only examines the support for web standards like CSS and HTML5. It does not benchmark the speed of the browsers. All browsers, passed all the rings. This means that they support enough features to deliver a full web experience on nextgen websites.

The only difference between Opera and Chrome was that Opera supports the Ring 1 feature ''multiple audio playback'' and Chrome does not.

HTML5 Benchmark Conclusion

Since all browser had a passing score on Ringmark, and it does not measure performance, both Peacekeeper's and Browsermark's results will be weighted two times heavier.

HTML5 overall benchmark results:

  1. Chrome 35.0.1916.138
  2. Opera 21.0.1437.74904
  3. Firefox 29.0.1
  4. Dolphine 11.1.1
  5. UCBrowser v9.8.0.435



Overall Conclusion

As expected Chrome and Opera performed very similar. Also the browsers seem to be optimized for their own benchmarks.

Since Google is most heavily invested in HTML5 technology, to replace Adobe Flash on the desktop and mobile. It is not unexpected that Google Chrome performs best. Only Firefox and UCBrowser still support Flash.

Since the reliance on HTML5 for mobile websites and even on most desktop websites is minimal, the JavaScript performance is weight twice as heavy.


Dolphine is the winner, followed by Chrome and Firefox on a shared second place. The performance difference is between first and second place is only minor. Opera comes in at third, and UCBrowser is last.

Monday, March 10, 2014

Cisco IOS URL filter

An URL filter is a mechanism to restrict or control access to any website. The URL filter determines what content will be available or perhaps more often what content will be blocked.

Cisco IOS provides us with many different ways to accomplish an URL filter implementation. I'll discuss various techniques and present example configurations.

To perform the HTTP content filtering, the first three methods classify traffic use Cisco's Modular QoS CLI feature. Where after various ways can be applied to filter out the MQC marked traffic.  

With both the Context-Based Access Control and Zone Based Firewall method the decision which URLs to filter can be made by the router itself or by a content filtering server. In this post I will only show examples of locally configured URL filtering.


Access Control List content filter

This method uses an ACL on the output interface to drop the packets marked by MQC. The packets - containing the website requests - are marked on the interface from which the websites are requested. 


!
class-map match-any URL_BLOCK
 match protocol http host "example.com"
!
policy-map MARK_URL
 class URL_BLOCK
  set ip dscp 1
!
interface FastEthernet0/0
 description WAN interface
 ip access-group 100 out
!
access-list 100 deny   ip any any dscp 1 log
access-list 100 permit ip any any
!
interface FastEthernet0/1
 description LAN interface
 service-policy input MARK_URL

considerations

  • Disable sending IP unreachable messages with the no ip unreachable interface-level command to avoid causing the router to expend excessive resources.
  • Does NOT inform users, that the website is blocked and why.
  • IOS allows only one ACL per direction, per protocol, per interface. So it may not be practical.

Class-Based Policy content filter

The Class-Based Method, requires even less configuration. It uses the policy-map to drop the marked packets - containing the website requests. 

!
class-map match-any URL_BLOCK
 match protocol http host "example.com"
!
policy-map MARK_URL
 class URL_BLOCK
  drop
!
interface FastEthernet0/0
 description WAN interface
!
interface FastEthernet0/1
 description LAN interface
 service-policy input MARK_URL

considerations

  • Disable sending IP unreachable messages with the no ip unreachable interface-level command to avoid causing the router to expend excessive resources.
  • Does NOT inform users, that the website is blocked and why.

Policy-Based Routing (PBR) content filter

This method, actually gives us two options, either route the to the Null interface, to just drop the website requests for the blocked URLs. Or route the websites marked by MQC, to a local web-server that is configured to reply with a standard page to inform users that their web request is blocked.

!
class-map match-any URL_BLOCK
 match protocol http host "example.com"
!
policy-map MARK_URL
 class URL_BLOCK
  set ip dscp 1
!
access-list 100 deny   ip any any dscp 1 log
access-list 100 permit ip any any
!
route-map test URL_REDIRECT 10
 match ip address 100
 set ip next-hop 192.168.100.100
!
!
interface FastEthernet0/0
 description WAN interface
 ip policy route-map URL_REDIRECT
!
interface FastEthernet0/1
 description LAN interface
 service-policy input MARK_URL


considerations

  • If the route-map forwards filtered traffic to interface Null0, disable sending IP unreachable messages with the no ip unreachable interface-level command to avoid causing the router to expend excessive resources, 
  • If the route-map forwards traffic to interface Null0, users are NOT informed that the website is blocked and why.
  • If the route-map forwards the filtered traffic to a web server, to present an information page to the users, it must be configured as a catch all server. This means that a default virtual host needs to be configured. And it requires that the destination IP address of the HTTP requests are rewritten to the IP address of the server (e.i. destination NAT).

Context-Based Access Control (CBAC) content filter

This method relies on the CBAC Deep Packet Inspection (DPI) to decide which web requests are allowed or denied. The configuration is only a couple of lines. 

!
ip inspect name URL_FILTER http urlfilter
ip urlfilter allow-mode on
ip urlfilter exclusive-domain deny example.com
ip urlfilter audit-trail
!
interface FastEthernet0/0
 description WAN interface
!
interface FastEthernet0/1
 description LAN interface
 ip inspect URL_FILTER in

considerations

  • Users are informed that their website request was denied via a 'HTTP 403 - Forbidden' error page.
  • Only provides the ability to filter on domain names. It does NOT provide the ability to filter on other variables, like file names, or particular directories of the allowed or denied domains.

Zone Based Firewall (ZBF) content filter

With this method DPI analyses the traffic between (security) zones and the ZBF decides based on a policy map if the traffic is allowed.

!
parameter-map type urlfpolicy local URL_FILTER
 block-page message "You do NOT have permission to view this page"
!
parameter-map type urlf-glob EXAMPLE
 pattern example.com
parameter-map type urlf-glob ALLOW
 pattern *
!
class-map type urlfilter match-any BLOCK
 match  server-domain urlf-glob EXAMPLE
class-map type urlfilter match-any ALLOW
 match  server-domain urlf-glob ALLOW
!
class-map type inspect match-any HTTP
 match protocol http
class-map type inspect match-any HTTPS
 match protocol https
class-map type inspect match-any DNS
 match protocol dns
!
policy-map type inspect urlfilter URL_FILTER
 parameter type urlfpolicy local URL_FILTER
 class type urlfilter BLOCK
  log
  reset
 class type urlfilter ALLOW
  allow
!
policy-map type inspect URLs
 class type inspect HTTP
  inspect
  service-policy urlfilter URL_FILTER
 class type inspect HTTPS
  inspect
 class type inspect DNS
  inspect
 class class-default
  drop
!
zone security LAN
zone security WAN
!
zone-pair security LAN_OUT source LAN destination WAN
 service-policy type inspect URLs
!
interface FastEthernet0/0
 description WAN interface
 zone-member security WAN
!
interface FastEthernet0/1
 description LAN interface

 zone-member security LAN


considerations


  • Users are informed that their website request was denied via a customizable error page. 
  • Requires complete configuration of Zone Based Firewall, for all security policies.

Conclusion

As we have seen there are many different ways to configure an URL filter, also known as a content filter, on a router. Some considerations which should be made before choosing a method. Do you want to inform users, that they are violating company policy? What type of other security measures are in place, or are planned in the near future. Except domain names, what other criteria do you want to filter. 

Thursday, March 6, 2014

Everything you need to know about Ping, and more

Ping is one of - or maybe it is - the first network diagnostic tools invented, and usually the first used in the analyses network issues. 


How does it work

Ping makes use of timed IP/ICMP Echo and Echo Reply messages, as defined by RFC 792 to probe a network host.
















Network reachability

An Echo message is simply called a 'ping'. The Echo Reply message is the 'ping reply'. A few simple pings will show if the 2 hosts have their TCP/IP stacks configured correctly and if there are any problems with the routes packets are taking in order to get to the other side, and back (e.i. reachability).

On the right we can look inside such an Echo message before it is send. We see the IP header, which is 20 bytes. It indicates, the source and destination IP addresses, and that it carries an ICMP packet.

Next we see the ICMP header, which is 8 bytes. The ICMP header includes the type information, an Echo Request.

And lastly we see the payload portion, which is indicated as Raw. I'll come back to it later.

On the left we see the ICMP Echo Reply message. Again the first 20 bytes is the IP header, containing the source and destination addresses. Which are now reversed.

Next, the ICMP header, again 8 bytes long, indicating that the message type is an Echo Reply. After the ICMP type field, there is a ICMP code field. The error code, or the type of error. (0<= Code <= 16).



On the right, you see an example of the use of the ICMP code field. In this example I pinged google.com again, but set the Time To Live to 5. Which means that the IP packet is allowed to jump 5 layer-3 hops. Google.com is further away than 5 hops. 

The router 5 hops away who was the last to receive the ICMP Echo packet, responds to indicated, to the sender that it was not able to send the ping to the intended destination. In the IP header, we see the source address of that router.

In he ICMP header contains a ICMP type 11 Time Exceeded message. And it includes the ICMP type code 0: "time to live exceeded in transit". 

Next we see a block called IP in ICMP, this is part of the payload portion which I promised we would come back to. This contains the original IP header plus the first 64 bits or 8 byte of the original datagram's data. Since the ICMP header is 8 bytes, that is what is included in the block called ICMP in ICMP. This data is used by the original sender to match the message to the appropriate process.

In the example on the left we see an ICMP Destination Unreachable message, as a response to a ping that had the 'Do not Fragment' bit set, and exceeded the Maximum Transmission Unit.

Again the IP header contains the source and destination addresses. The source is the router that informs us, that it could not forward the original ICMP Echo message. 


The ICMP header contains the type 3 Destination Unreachable message. And includes the ICMP type code 4: "fragmentation needed and DF set"


And as in the previous example the IP in ICMP and ICMP in ICMP are the original IP and ICMP header.


These examples are obviously just a few of the many possible ICMP message types.


On Cisco routers, characters are used to indicate what type of ICMP reply message was sent back. In the table below you will find an overview of the characters and their description.




Network performance measurement

Apart from connectivity testing ping is also used to measure two types of network performance indicators, latency and bandwidth.

Latency

Latency is the delay data traveling over the network experiences, usually measured in milliseconds.

After the sender of ICMP Echo receives a ICMP Echo Reply message, it compares the time it sent the Echo to the time it received the Echo Reply, and calculates the time difference between the two. This is called the Round Trip Time, more commonly referred to as RTT.

R1#ping 192.168.100.100 size 1500 repeat 2 df-bit

Type escape sequence to abort.

Sending 2, 1500-byte ICMP Echos to 192.168.100.100, timeout is 2 seconds:
Packet sent with the DF bit set
!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 2/16/29 ms

NOTE: Routers make use of queues to store the electrical - or laser - pulses until enough of them are received to have enough information to analyse them. After which the data is sent from these queues to the processor of the router, which also make use of separate queues - commonly known as cache - to store data which it is analyzing. ICMP packets have a low priority. If the router is handling traffic near its capacity it will drop ICMP packet from its queues. 

Available bandwidth 

Ping can also be used to measure the available bandwidth per second. Which becomes less as the latency increases, this will become glaringly obvious from the following example where we will do a ping to IP 192.168.100.100, on a 54Mbit/s 802.11g connection.

54Mbit/s = 54000Kbit/s
(54000Kbit/s / 8bit) / 18 kbyte = 375 packets

R1#ping 192.168.100.100 size 18000 repeat 375

Type escape sequence to abort.
Sending 375, 18000-byte ICMP Echos to 192.168.100.100, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (375/375), round-trip min/avg/max = 12/20/256 ms

We calculate the available bandwidth by dividing the bandwidth by the latency, while compensating for the comma shift. Notice that the bandwidth will drop if packet loss occurs.


((18000 byte X 8 bit X 375 received packets) / 100) / 0.020 xseconds = 27Mbit/s

(54Mbit/s / 100) / 0.020 seconds = 27Mbit/s

0,54 / 0.020 seconds = 27Mbit/s


Size Matters

Keep in mind that there are differences between how different vendors handle the size option of the ping command.

On Cisco equipment the size option specifies the size of the total ping packet, that is IP header, ICMP header, and payload. 


R1#ping 192.168.100.100 size 1500 repeat 2 df-bit

Type escape sequence to abort.

Sending 2, 1500-byte ICMP Echos to 192.168.100.100, timeout is 2 seconds:
Packet sent with the DF bit set
!!

Success rate is 100 percent (2/2), round-trip min/avg/max = 2/16/29 ms


On Juniper equipment, the size option only specifies the payload. So when you want to ping with the DF bit set, at 1500 bytes use the following command:


root@olive> ping 192.168.100.100 size 1472 count 2 do-not-fragment   
PING 192.168.222.100 (192.168.100.100): 1472 data bytes
1480 bytes from 192.168.100.100: icmp_seq=0 ttl=255 time=27.549 ms
1480 bytes from 192.168.100.100: icmp_seq=1 ttl=255 time=34.765 ms

--- 192.168.100.100 ping statistics ---

2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 27.549/31.157/34.765/3.608 ms



Microsoft Windows follows that same logic. The size option only specifies the payload, as seen below:

C:\Users\>ping 192.168.100.100 -l 1472 -n 2 -f

Pinging 192.168.100.100 with 1472 bytes of data:

Reply from 192.168.100.100: bytes=1472 time=3ms TTL=255
Reply from 192.168.100.100: bytes=1472 time=29ms TTL=255

Ping statistics for 192.168.100.100:

    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:

    Minimum = 3ms, Maximum = 29ms, Average = 16ms


Linux agrees and the size option there also only applies to the payload, as seen below:

$ ping -c 2 -s 1472 -M do 192.168.100.100
PING 192.168.100.100 (192.168.100.100) 1472(1500) bytes of data.
1480 bytes from 192.168.100.100: icmp_seq=1 ttl=255 time=20.6 ms
1480 bytes from 192.168.100.100: icmp_seq=2 ttl=255 time=11.5 ms

--- 192.168.100.100 ping statistics ---

2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 11.566/16.133/20.661/4.549 ms


Ping of Death

The Ping of Death is a ICMP Echo that violates the maximum length of an IP packet as defined in RFC 791 to be 65,535 octets long, including the header. As discussed earlier a IP packet exceeding the MTU, will be fragmented. A lot of operating systems, did not process the IP packet until they had all fragments and then tried to reassemble it. This lead to the overflow of the 16-bit packet buffer, and thus to system crashes, reboots, and kernel panics.

Most operating systems after 1998 are hardened against Ping of Death attacks and even attempt to prevent you from sending one.

The only tool on Windows that allows you to send a Ping of Death packet is Scapy, which you can find here. From the CLI of Scapy you can send the 'special' ping with this command:

>>>send(fragment(IP(dst="192.168.100.100")/ICMP()/("F"*65530)))


Smurf Attack

The Smurf Attack, is an ICMP Echo messages to a broadcast address, with a spoofed source address. Basically burring the uplink of the victim with ping Echo Reply messages of all the hosts on that broadcast domain.

Today's computers, and network equipment is secured against this type of attack. Most operating systems by default, do not reply to ICMP messages directed to the network broadcast address. Also ISPs have taken steps to prevent their customers from sending traffic with an incorrect IP source address. Lastly, both the equipment manufacturers and ISPs are denying any traffic send to broadcast addresses. 

  

You can craft a Smurf Attack packet with Scapy, using the following command:


>>>send(IP(src="192.168.100.100", dst="192.168.100.255")/ICMP())

With Nping, use the following command:


nping --icmp -S 192.168.100.100 192.168.100.255


ICMP Nuke

An ICMP Nuke is denial of service attack, based on a spoofed ICMP Destination Unreachable message or a spoofed ICMP Time Exceeded message. The aim of this attack is that target system breaks communications with existing connection(s). Technically it is not a "ping", but was sometimes called a Ping Nuke.


An ICMP Nuke can require some brute-forcing depending on the communication protocol attacked. For both TCP and UDP protocols, the source port needs to be guessed. And for the TCP based protocols, the sequence number needs to be guessed.

This type was a very popular type of attack against IRC channel operators, where the hacker had the aim to takeover the the channel. On the right you see an example of such an ICMP Nuke packet directed at the host IP 192.168.100.100.


Today this type of attack is more difficult to perform, because most routers are rate-limiting ICMP Destination Unreachable, and ICMP Time Exceeded messages. And modern operating system also implement random sequence number generation, making it difficult to predict them accurately.


Ping Tunnel

A ping tunnel (also known as ICMPTX), is a tunneling where the payload portion of ping packets are used to carry TCP sessions, between a client and a proxy server. This is usually done to circumvent a firewall. You can find the original implementation of this protocol here.

Sunday, March 2, 2014

Transparent Ethernet over an IP network

In today's corporate networks the layer-2 domain is collapsed down to the access layer - at least it should be, in most cases -, and there is virtually no requirement for a contiguous layer-2 domain passed the access layer switches.

However there are corner cases where extending the layer-2 domain across a layer-3 network is a requirement. For example server visualization may require the storage network to be on the same layer-2 domain. Or when a layer-2 interconnect circuit is backed up by a cheap(er) layer-3 circuit. 

I'll discuss various technologies to accomplish transparent Ethernet over an IP network and present sample configurations, for them.

In the topology we will be using for the sample configurations are two routers (i.e R1 and R2) connected back-to-back. R1 will have a loopback interface configured with the IP 1.1.1.1 and R2 will have a loopback with the IP 2.2.2.2. The physical back-to-back interfaces are configured on the 10.0.0.0/30 subnet, R1 has the IP 10.0.0.1 and R2 - how surprising - has 10.0.0.2. The routing is done through a static route, pointing to the IP address of other router's physical interface.


GRE Tunnel

Generic Routing Encapsulation (GRE) is a mechanism for encapsulating any network layer protocol over any other network layer protocol, developed by Cisco. The general specification is described in RFC 2784 (obsoletes earlier RFC 1701 and RFC 1702). 

Configuration example:

R1:

!
bridge irb
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 bridge-group 1
!
interface Tunnel0
 no ip address
 tunnel source Loopback0
 tunnel destination 2.2.2.2
 bridge-group 1
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252
!
ip route 2.2.2.2 255.255.255.255 10.0.0.2
!

R2:

!
bridge irb
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 bridge-group 1
!
interface Tunnel0
 no ip address
 tunnel source Loopback0
 tunnel destination 1.1.1.1
 bridge-group 1
!
interface Serial0/0
 ip address 10.0.0.2 255.255.255.252
!
ip route 1.1.1.1 255.255.255.255 10.0.0.1
!


considerations

  • Supports Dot1Q, and ISL VLAN trunking, depending on the routing platform.
  • Integrated Routing and Bridging does NOT support transparent tunneling of CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD.
  • The MTU of the sending device may need to be adjusted, Integrated Routing and Bridging does NOT support fragmentation.
  • Native support for tunneling over an IPv6 network.
More information about Generic Routing Encapsulation on the Cisco website can be found here.


DLSw+ circuit

Data-Link Switching is an almost forgotten technology, originally developed to tunnel non-routable, non-IP based protocols such as IBM Systems Network Architecture (SNA) and NetBIOS/NetBEUI across IP networks, described in RFC 1434 (updated by RFC 2166). 

DLSw+ is Cisco's proprietary implementation of DLSw, with following extensions:

  • Choice of transport option, including TCP, FST (fast-sequenced transport), and direct encapsulation.
  • Scalability enhancements through: peer groups, on-demand peers, explorer firewalls, and location learning.
  • Media conversion between local and remote LANs and SDLC or Ethernet.

One of the more popular uses of DLSw+, was bridging Token ring networks over other media. 

DLSw+ is a flexible, though dated technology that can transport of Ethernet frames across an IP network.

Configuration example:


R1:

!
bridge irb
!
dlsw local-peer peer-id 1.1.1.1
dlsw remote-peer 0 tcp 2.2.2.2
dlsw bridge-group 1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 bridge-group 1
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252
!
ip route 2.2.2.2 255.255.255.255 10.0.0.2
!

R2:

!
bridge irb
!
dlsw local-peer peer-id 2.2.2.2
dlsw remote-peer 0 tcp 1.1.1.1
dlsw bridge-group 1
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 bridge-group 1
!
interface Serial0/0
 ip address 10.0.0.2 255.255.255.252
!
ip route 1.1.1.1 255.255.255.255 10.0.0.1
!

considerations

  • Supports Dot1Q, and ISL VLAN trunking, depending on the routing platform.
  • Integrated Routing and Bridging does NOT support transparent tunneling of CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD.
  • The MTU of the sending device may need to be adjusted, Integrated Routing and Bridging does NOT support fragmentation.
  • NO native support for tunneling over an IPv6 network.
  • DLSw+ is process switched.
  • NO support for DLSw+, on any Cisco IOS XE, IOS RX, or NX-OS platform.
  • Support for DLSw+ is only available on legacy Multi-Layer Switches, for example the CAT4500, and the CAT6000.
More information about Data-Link Switching (DLSw) and Data-Link Switching Plus (DLSw+) on the Cisco website can be found here.


L2TP Tunnel

Layer-2 Tunneling Protocol, described in RFC 2661, is based on primarily two older tunneling protocols for Point-to-Point communication: Cisco's Layer 2 Forwarding Protocol (L2F) and USRobotics Point-to-Point Tunneling Protocol (PPTP). The original L2TP implementation uses UDP for transport. The newer L2TP version 3, described in RFC 3931 (updated by RFC 5641), uses IP as transport - just like GRE -, that can be implemented on any IP-aware network. L2TPv3 has two 'modes' point-to-point and point-to-multipoint. We will be focusing exclusively on L2TPv3 point-to-point mode tunneling.

Configuration example:

R1:

!
pseudowire-class TEST
 encapsulation l2tpv3
 ip local interface Loopback0
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 no cdp enable
 xconnect 2.2.2.2 1 encapsulation l2tpv3 pw-class TEST
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252
!
ip route 2.2.2.2 255.255.255.255 10.0.0.2
!

R2:

!
pseudowire-class TEST
 encapsulation l2tpv3
 ip local interface Loopback0
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 no cdp enable
 xconnect 1.1.1.1 1 encapsulation l2tpv3 pw-class TEST
!
interface Serial0/0
 ip address 10.0.0.2 255.255.255.252
!
ip route 1.1.1.1 255.255.255.255 10.0.0.1
!


considerations

  • Cisco Express Forwarding must be enabled. The xconnect configuration mode is inaccessible until CEF is enabled.
  • Native support for tunneling over an IPv6 network.
  • The MTU of the sending device may need to be adjusted, to prevent fragmentation. The ingress router receives an Ethernet frame and encapsulates the packet by removing the preamble, the start of frame delimiter (SFD), and the frame check sequence (FCS), inserts the frame into a L2TPv3 packet and transmits the packet to its peer.
  • You may need to configure the l2protocol-tunnel command to enable or disable tunneling of Layer 2 protocols (e.i. CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD) depending on the platform. In my test environment (GNS3, c3725, IOS 124-15.T8) CDP was tunneled transparently.
More information about Layer Two Tunnel Protocol (L2TP) on the Cisco website can be found here.


EoMPLS over GRE Tunnel

Ethernet over Multi Protocol Label Switching is a mechanism to encapsulate and transport Ethernet Protocol Data Units (PDUs) over an MPLS network, and is described in RFC 4448 (updated by RFC 5462). Basically a frame is received on a switch, MPLS labels the frame, transportes it via MPLS labels over an IP routed network, and the receiving switch removes the MPLS label, and switches the frame out the appropriate port(s).

EoMPLS is the most common method Internet Service Providers use to implement Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS), on their networks.

MPLS requires every hop in the path to be an MPLS router. Here is where the GRE Tunnel comes in to play. We will use GRE to tunnel the MPLS traffic, end-to-end.

Configuration example:

R1:

!
ip cef
!
mpls ip 
!
interface Tunnel0
 ip address 172.16.1.1 255.255.255.252
 mpls ip
 tunnel source Serial1/0
 tunnel destination 192.168.100.4
!
interface FastEthernet0/0
 no ip address
 no cdp enable
 xconnect 172.16.1.2 1 encapsulation mpls
!
interface Serial1/0
 ip address 192.168.100.1 255.255.255.0
!
mpls ldp router-id Tunnel0 force
!

R2:

!
ip cef
!
mpls ip 
!
interface Tunnel0
 ip address 172.16.1.2 255.255.255.252
 mpls ip
 tunnel source Serial1/0
 tunnel destination 192.168.100.1
!
interface FastEthernet0/0
 no ip address
 no cdp enable
 xconnect 172.16.1.1 1 encapsulation mpls
!
interface Serial1/0
 ip address 192.168.100.4 255.255.255.0
!
mpls ldp router-id Tunnel0 force

!

NOTE: In the configuration above I used the 172.16.1.0/30 IP address range on the tunnel interface. Also the Tunnel interface on the platform used defaults to tunnel mode gre ip.

considerations

  • Cisco Express Forwarding must be enabled. The xconnect configuration mode is inaccessible until CEF is enabled.
  • Native support for tunneling over an IPv6 network.
  • The MTU of the sending device may need to be adjusted, to prevent fragmentation. The ingress router receives an Ethernet frame and encapsulates the packet by removing the preamble, the start of frame delimiter (SFD), and the frame check sequence (FCS), inserts the frame into a MPLS packet and transmits the packet to its peer.
  • You may need to configure the l2protocol-tunnel command to enable or disable tunneling of Layer 2 protocols (e.i. CDP, STP, VTP, LLDP, PAgP, LACP, and UDLD) depending on the platform. In my test environment (GNS3, c7200, IOS 150-1.M) CDP was tunneled transparently.
More information about Multi Protocol Label Switching (MPLS) on the Cisco website can be found here.


Conclusion

Both the 'vanilla' GRE Tunnel and the DLSw+ circuit use the Integrated Routing and Bridging feature to span the Ethernet across the layer-3 network. And therefore these two methods carry the same limitations as a single router bridging two layer-2 domains, using the IRB feature. You can either bridge a normal Ethernet connection, a single VLAN or a Trunk, per bridge group. Since the router is not a switch it does not support DTP or VTP, nor will it transparently carry those and other layer-2 protocols (e.g. CDP, STP) - since the router is a layer-2 hop, just like a switch.

For more information about Integrated Routing and Bridging (IRB) see the Cisco website here.

As mentioned earlier DLSw+ in not supported on any of the Cisco IOS XE, IOS RX, or NX-OS platforms. Also the protocol is process switched which may require extensive tuning, you can find an excellent post about tuning DLSw performance here, on the Packetpushers website.

Of all the methods described, L2TPv3 and EoMPLS over GRE are the most powerful and flexible, providing truly transparent Ethernet, allowing you to implement it as a trunk or per VLAN. The per VLAN method allows you to transport different VLANs to different endpoints, or even mix layer-2 and layer-3 features on a single port, using sub-interfaces. Big downsides are - yes, there are downsides - that It also may also tempt you as a network engineer to be too clever; creating a real unholy mess of layer-2 over layer-3 confusion, which is not fun to troubleshoot.