Description Of A Tunnelling Protocol

Published Date: 02 Nov 2017

http://www.goodgoshalmighty.com/clipart-trojanhorse.gif

COMP09022

Tunnelling

An outline of reasons for its use, together with a discussion of several standard tunnelling protocols, the individual reasons they were developed and the circumstances in which a specific one may be favoured.

Word Count

Global

2562

Material

2102

B00240866

Contents

Table of Figures

Introduction

The tremendous expansion of the internet over the last twenty years has spawned, for various reasons, a need to ‘tunnel’. In this paper I will point up several reasons why tunnelling is employed prior to moving on to depict in a little more detail a number of benchmark tunnelling protocols. Further, I will go into some greater detail about why specific tunnelling protocols were developed in the first place – shining a light on the particular problem they overcame. The application areas in which one finds tunnelling protocols extensively used will be explained and I will discuss why one tunnelling protocol may be chosen when quite a few candidates are under contemplation.

Finally, I will compare and contrast the relative strengths and weaknesses of certain tunnelling protocols and touch on the links between tunnelling protocols per se and other non-tunnelling protocols.

Background to Tunnelling

In networking it is essential that it is possible to transmit PDUs from the source toward the destination. The media separating the two endpoints will, more often than not, be composed of varying networks with contrasting standards and policies outside the sender’s range of control. Equally, the native protocol from the source may be incompatible with the destination. So it follows it cannot be guaranteed that a PDU, just blindly sent, will be delivered in such circumstances where there are network incompatibilities relative to the protocols transmitted. Tunnelling was developed as a way to ‘push through’ variant protocols.

A reason for tunnelling

Security – An encrypted tunnel can be initiated between source and destination often on an ad-hoc basis, with the tunnel staying "up" for just as long as is needed before being dropped. Commonly this takes the form of a virtual private network (VPN).

Description of a Tunnelling Protocol

Point-to-Point tunnelling protocol (PPTP) is a tunnelling protocol developed by a group of companies. Its primary purpose is to allow the Point-To-Point (PPP) to be tunnelled across an Internet Protocol network (IP). PPPT, while still widely used, for VPN purposes, is being replaced by the more versatile Layer Two Transport Protocol (L2TP) partly because L2TP closely integrates with the encryption and security features of IPsec. Where PPTP is used, Generic Routing Encapsulation (GRE) is deployed too. The procedure for encapsulation is characterised thus:

The original data packet is processed by the PPTP utility which adds a header of its own.

The whole packet is now encrypted.

The resultant packet is handed over to GRE which attaches a header of its own and the packet now takes on the guise of a GRE packet.

The packet is now passed to the internet layer for transportation whereupon an IP header is attached – and so the packet now becomes ostensibly an IP packet and is able to pass across the internet. To the payload – encapsulation and tunnelling makes the journey appear as one hop.

At the destination the packet is decapsulated in a reversal of the encapsulation procedure

Figure . A PPTP packet

(Anon., 2011)

An outline of some further reasons for Tunnelling

Penetration – It can be useful to employ tunnelling to ‘sneak’ PDUs past the gaze of a firewall that is set to block them. The payload PDU is encapsulated within the delivery PDU and can therefore succeed in passing the scrutiny of the firewall.

Payload Delivery at a time of change – The internet is transitioning from IPv4 to IPv6 addressing. While the IPv6 system evolves – it is not complete yet; ‘islands’ of native IPv6 nodes have begun to take shape, necessitating transitional arrangements as these islands require to link to the outside across existing IPv4 infrastructure. Making use of IPv6-over-IPv4 tunnelling an IPv6 PDU can be encapsulated inside an IPv4 PDU at source and successfully reach its destination. (Nordmark, 1996)

6in4 Tunnelling Protocol

The 6in4 tunnelling protocol encapsulates IPv6 packets inside an IPv4 packet. Here the original IPv6 packet has an IPv4 header added at the start. This additional header contains the protocol number ‘41’ – a number indicative of IPv6 encapsulation. The 6in4 protocol adds a relatively small overhead addition to the process of tunnelling because the header added is only 20 bytes long. This small overhead has the welcome effect of allowing the transmission of native IPv6 packets which are 1480 bytes – with zero fragmentation as they fall within the Ethernet maximum transmission unit (MTU) which is set at 1500 bytes. On the other hand, 6in4 has problems when operating from behind a NAT and has the drawback of being a ‘configured’ protocol – that is to say both end points in the tunnel have to be set up. There is a solution, from an administrative stance, for the issue of configuring – a ‘Tunnel Broker’ can be engaged to take care of much of the configuration, tunnel management and negotiation on behalf of the local staff. (DURAND, 2001)

Application areas of 6in4 Tunnelling

The primary application area of 6in4 tunnelling is very specific. It is used to connect two IPv6 based networks (islands) across a gap, which is generally a contemporary IPv4 infrastructure. The ‘gap’ is not compatible with IPv6 and so encapsulation of IPv6 inside an IPv4 packet is the solution. So, in general, 6in4 is deployed when there is either an operational need or a personal preference to make use of IPv6 in the presence of an incompatible path between source and destination.

Point to Point over Ethernet (PPPoE)

PPPoE can be used as a form of tunnelling protocol. It is widely used by ISPs in their relationship with customers. Typically PPPoE is exploited to carry PPP packets from the client side modem (a router in the customer premises does the job of the PPPoE client) to the ISP via a DSLAM and on to the ISP router which fulfils the role of a PPPoE Server – all over Ethernet; hence the name PPP over Ethernet. ISPs like PPPoE because it supports billing on a per-host model, thereby maximising revenue stream from a given client base. PPPoE sits in the upper half of OSI layer 2 (Network layer on the DOD4 model).

Figure . Format of a PPPoE Packet

(Hangzhou H3C Technologies Co., Ltd., 2009)

Direction of EncapsulationThe diagram illustrates the encapsulation of a PPP packet into PPPoE which in turn is nested in an Ethernet frame. Demonstrably there is a significant overhead attached to PPPoE. (Around 15%)

There is a three stage negotiation process with PPPoE:

Discovery – client broadcasts a PPPoE Active Discovery Initiation (PADI) packet designed to advertise the service it requires and illicit a response from a PPPoE server. On a first-come-first-served basis, the client picks the first PPPoE Active Discovery Offer (PADO) that it receives and then transmits a unicast PPPoE Active Discovery Request (PADR) to the chosen PPPoE server which in turn generates a session identifier and sends a PPPoE Active Discovery Session-confirmation (PADS) packet

Session – After authentication and testing of the data link succeeds the PPPoE session fully opens and unicast data PPP packet delivery commences.

Terminate – Either party, at any time can end the session by sending a PPPoE Active Discovery Terminate (PADT) packet.

The ‘code’ field in the PPPoE packet holds the relative values for the differing discovery stages, depending on the purpose of the individual packet.

(Network Working Group, 1999)

Teredo Tunnelling

Teredo Tunnelling is a transitional technology, developed by Microsoft, for tunnelling IPv6. Its purpose is to deal with the problems encountered by other IPv6 tunnellers such as 6in4 described earlier, when they operate from behind an IPv4 based NAT. IPv4 Network address translators present a particular problem in that they generally cannot deal with IPv6 and so establishing IPv6 connectivity from behind the NAT is problematic. By encapsulating an IPv6 packet inside a UDP packet it is possible for IPv6 to traverse the NAT. Teredo addresses are the key to the connectivity and are constructed in the following five-component format:

Figure . Teredo Address Format

PREFIX

SERVER IPv4

FLAGS

PORT

CLIENT IPv4

The ‘hidden’ IPv4 address of the client

The ‘hidden’ details of the UDP port at the client side

Details of the address type and NAT

The Teredo servers IPv4 address

The 32-bit Teredo service prefix

This translates through to a colon hexadecimal notation teredo address such as 2001::CE49:7601:2CAD:DFFF:C0A8:0101 where, in this example, the teredo server is at IP 206.73.118.11 with a client external IP of 192.168.1.1.

The Teredo packet can be seen as a UDP IPv4 packet with a UDP header smoothing the NAT path followed by an IPv6 header which must incorporate at least one Teredo format address and finally the IPv6 payload (data) from a higher layer.

Figure . Teredo Packet Format

IPv4 HEADER

UDP HEADER

IPv6 HEADER

IPv6 PAYLOAD

20 BYTES

8 BYTES

40 BYTES

n

Potentially UDP has a maximum size of 65507 bytes – far in excess of the recommended MTU for IPv6 of 1280 Bytes. Consequently the Teredo tunnel should advertise to routers an MTU of no less than 1280 Bytes.

(RFC 2460, 1998)

Comparison of Tunnelling Protocols – 6IN4 AND TEREDO (strengths and weaknesses)

The 6in4 tunnelling protocol is very similar in its objective to that of Teredo – that is provide a viable transitioning solution in the migration from IPv4 based systems to IPv6.

6in4

It is understood by a greater number of network engineers because there are more people on the ground configuring this protocol.

It is relatively simple and deterministic.

Easier to debug than Teredo – because of the self configuration required

The manual configuration required can add costs

Teredo

Auto configuration

Can bypass more firewalls than 6in4

More able to negotiate the NAT hurdle than 6in4

Enabled by default in later versions of windows and an option in some earlier versions

More complicated than 6in4 – so debugging is more involved

Further Tunnelling Protocol

IPinIP

IPinIP tunnelling is a protocol belonging to the TCP/IP suite. Its principal role is to allow IP routing for mobile hosts – as opposed to the up-till-now more usual static node-node arrangement. The general rule of encapsulation and decapsulation is followed and this takes place at the tunnel endpoints. In IPinIP the outer header simply identifies the end points of the tunnel and, importantly, once the IPinIP packet reaches the endpoint the outer header is stripped off and the inner header then determines the true destination. A typical application area is mobile-ip arrangements. Mobile devices, by definition do not generally stay connected to one network all the time – they move around. IPinIP allows packets that are headed to the ‘usual’ IP address, to be encapsulated with a second header and instead make their way to an intermediate destination before arriving at the final destination which is configurable by the recipient – almost like a dynamic postal service mail redirection.

(RFC 2003, 1996)

Position of Tunnelling Protocols in Hierarchy and how it is used (links between them)

When one thinks of Tunnelling per se in the computer networking sense we are primarily concerned with the movement of frames and packets at the data link, network and transport layers of OSI (Layers two, three and four respectively). Flexibility is enhanced by relationships between tunnelling protocols, the marriage of L2TP with IPsec is a good example of this. IPsec, operating at the network layer is often used to encrypt the payload of a lower layer packet (Eg L2TP) or, as in IPsec tunnel mode, encrypt the whole packet and then encapsulate it inside a new IP packet. Tunnel mode is commonly used to create a VPN as it is the best way to establish a secure tunnel over a medium that is not trusted – like the internet. IPsec also offers ‘Transport Mode’ where it secures the connection by simply encapsulating the IP payload – in contrast to tunnel mode (SURMAN, 2002)

Existence of Multiple tunnelling standards and a critical discussion of x + y or a + b or x + b

There are many tunnelling standards. In fact, as a guide, Wikipedia lists in the region of thirty seven articles on the diverse tunnelling protocols and their inter-dependencies. Each one has been created to deal with a problem. By far the greatest numbers of tunnelling protocols exist to ‘bridge’ a network gap and seek to eliminate a particular problem. 6in4 simply offers its services as a transitional technology. On the other hand, others, in the vein of L2TP/IPsec endeavour to encrypt frames (as packets) over a higher layer providing a security role. So the existence of multiple tunnelling standards can be explained by the existence of multiple requirements for tunnelling to come about.

Conclusion

From my research into tunnelling protocols it is clear that they are a versatile and evolving technological problem solver. Whether it is an authentication/encryption purpose or a compatibility issue like for example IPv6/IPv4 there is (usually) a tunnelling protocol to assist. Equally, care has to be taken when choosing a tunnelling protocol for making the wrong choice can create vulnerabilities where there were none. For example using LT2P without IPsec could, in an un-trusted environment, be considered foolish. So tunnelling is of tremendous value. Notwithstanding, there is a ‘cost’ to be borne with tunnelling. There are overheads to consider and also training staff. Decisions may have to be made about tunnel brokers and software acquisition. On the other hand, tunnelling can be a cost saver. A VPN can save a company a lot of money – compared to a leased line. On reflection, tunnelling protocols look like they are here to stay in one form or another and promise to evolve to tackle as yet unknown tasks.