Network Protocols

IPv6 Subnetting - How and Why to Subnet IPv6

2012-06-19T20:00:00+10:00

In the previous tutorials, I went through the need for IPv6, and followed it up by drawing out the salient features which overcomes issues with IPv4. We took the journey of looking inside the headers, the structure and purpose of each and every extension headers. By now I sincerely hope, as readers, you all have got a good grasp of what entails this new protocol.

In this tutorial, I will be talking about subnetting. Subnetting is one of the most talked about, practiced, and supposedly confusing topics encountered by network professionals. In retrospect, all I would say, and do take it as a personal opinion, subnetting is one of the easiest things that can be mastered. The question you might ask is, why do we need to do subnetting if IPv6 already caters to the need for an absurd amount of IP addresses? Yes, I would agree to it at first but because IPv6 does make itself and subnetting two very disjoint terms. I might say, subnetting decreases broadcast traffic, but then you can counter it by saying IPv6 doesn’t have broadcast traffic. It does become difficult to justify.

However if you see it logically, you will still need reduce unnecessary network traffic. Subnetting also will give you an element of security. You can force people to follow a certain route, or even go through a specific router, where you can apply security policies.

For network administrators, subnetting increases flexibility in designing networks, route summarisation becomes easy, routing itself becomes efficient and management of networks improves. If you are given a /48 subnet to work with, you will have more than enough spaces to work with i.e. you get 65536 subnets with 18,446,744,073,709,551,616 hosts per subnet. I think that’s more than enough.

So, in all, subnetting is necessary in IPv6, but not for the reasons why we did it with IPv4.

Before diving into subnetting IPv6, I'd like to present a diagram which illustrates the differences between the IPv4 & IPv6 header. This will help understand the major structural differences between the two protocols. Notice the additional addressing space provided in the IPv6 Source and Destination Address which is now 128bit long (each), compared to 32bits in IPv4:

Courtesy of ls-a.org

Now, let us all exercise our birthright to subnet, and dig deeper into how we go about doing it. I can bet you, there are more than thousands of ways you can do this, and perhaps a similar if not greater number of videos on the web, that teaches you to do this as well. What follows is my personal humble attempt of practicing the dark arts, in perhaps a simple way possible.

An IPv6 subnet mask is written in hexadecimal, but let's start by explaining that IPv6 uses 128 binary digits for each IP address, as opposed to IPv4's 32 binary digits, and those 128 binary digits are divided into eight 16-bit words (8 x 16 = 128), like this:

0000000000000000.0000000000000000.0000000000000000.0000000000000000.0000000000000000.0000000000000000.0000000000000000.0000000000000000

It would be a little difficult to use IPv4's old octet notation for 128 bits, which might look like this:
182.222.101.003.255.074.112.200.000.010.135.016.208.192.136

So, a hexadecimal representation is used instead, which makes a little bit easier. Hexadecimal is a 16-digit numbering system, as opposed to binary's 2-digit system and decimal's 10-digit system. The 16 digits of hexadecimal run from zero to nine, then use the letters A to F: {0123456789ABCDEF}.

One 4-digit hex word represents 16 binary digits, like this:
Bin 0000000000000000 = Hex 0000 (or just 0)
Bin 1111111111111111 = Hex FFFF
Bin 1101010011011011 = Hex D4DB

So, this 128-bit binary address:

1111111111111111.1111111111111111.1111111111111111.1111111111111111.1111111111111111.1111111111111111.1111111111111111.1111111111111111
...would be represented by 8 hex words, separated by colons:

FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

A full IPv6 subnet mask uses the same 8-hex-word format as an IPv6 address, although some tools allow you to specify only 1 hex word.

Like IPv4, an IPv6 address has a network portion and a device portion. Unlike IPv4, an IPv6 address has a dedicated subnetting portion. Next we show how the ranges are divided in IPv6.

Network Address Range

In IPv6, the first 48 bits are for Internet routing.

1111111111111111.1111111111111111.1111111111111111.0000000000000000.0000000000000000.0000000000000000.0000000000000000.0000000000000000

Subnetting Range

The 16 bits from the 49th to the 64th are for defining subnets.

0000000000000000.0000000000000000.0000000000000000.1111111111111111.0000000000000000.0000000000000000.0000000000000000.0000000000000000

Device (Interface) Range

The last 64 bits are for device (interface) ID's:

0000000000000000.0000000000000000.0000000000000000.0000000000000000.1111111111111111.1111111111111111.1111111111111111.1111111111111111

The diagram below depicts a Global Unicast IPv6 address which has the following characteristics:

Address format that enables aggregation upward to the ISP.
48-bit global routing prefix and a 16-bit subnet ID.
Allows for organizations to have up to 65535 individual subnets.

Courtesy of ls-a.org

Subnetting Example

Let's assume there is a requirement to break your corporate network into 64 subnets. The binary mask just for the subnetting range would be 1111110000000000 which translates to a hex value of FC00. Some IPv6 masking tools will work with just this one hex word, otherwise a full 128-bit hex mask would be FFFF:FFFF:FFFF:FC00:0:0:0:0.

If you play around with converting values in the Windows Calculator (in scientific mode), remember to convert between binary and hexadecimal, not decimal and hex.

Before you ask, yes, it is possible to use bits in the device range for additional subnet masking, but you shouldn't need it. The 16 binary digits dedicated to subnetting and 64 binary digits available for devices give 65,535 subnets with over 18 quintillion devices per subnet. In addition, if you use some of the 64 bits in the device range for subnetting, then you can't use autoconfiguration tools because they expect all of the 64 bits on the right side to be dedicated to devices. So don't use any of the device bits for subnetting if you need IPv6 Autoconfiguration and if you don't know whether or not you need autoconfiguration, assume you do. And even if you know you don't need autoconfiguration, it's a good standard to use a 64-64 split for network/lan vs. device.

Those interested in IP4v Subnetting can read through our extensive IPv4 Subnetting tutorial.

Hope the tutorial quenches your thirst for IPv6 subnetting.

About the Writer

Arani Mukherjee holds a Master’s degree in Distributed Computing Systems from the University of Greenwich, UK and works as network designer and innovator for remote management systems, for a major telecoms company in UK. He is an avid reader of anything related to networking and computing. Arani is a highly valued and respected member of Firewall.cx, offering knowledge and expertise to the global community since 2005.

IPv6 - Analysing the IPv6 Protocol Structure and IPv6 Header

2012-05-31T06:40:00+10:00

As discussed in the previous tutorial, we were made painfully aware that we were running out of IP address spaces and literally did in 2011. A new proposal or RFC was released for creation of a new addressing and network protocol that would improve this major issue and other issues that IPv4 couldn’t resolve.

RFC 1752, raised in the Toronto IETF meeting, explained the major changes that had to happen. It was adopted by IETF and IPv6 was established.

RFC 2460 was written specifically on IPv6 and we’ll follow it for study and analysis of the features. The features being discussed appear in similar order to those in the RFC. Let’s find out why IPv6 is being touted as the best thing since sliced bread.

Addressing Capability - Three Types of Addresses IPv6 Supports

Unicast

A unicast address identifies a single interface within the scope of the type of unicast address. With the appropriate unicast routing topology, packets addressed to a unicast address are delivered to a single interface. To accommodate load-balancing systems, it allows multiple interfaces to use the same address as long as they appear as a single interface to the IPv6 implementation on the host.

This in turn is further subdivided into the following types:

Unicast IPv6 addresses fall into one of five types:

Global unicast addresses (which are conventional, publicly routable address, just like conventional IPv4 publicly routable addresses.)
Link-local addresses (They are akin to the private, non-routable addresses in IPv4 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). They are not meant to be routed, but confined to a single network segment. Link-local addresses mean you can easily throw together a temporary LAN, such as for conferences or meetings, or set up a permanent small LAN the easy way.)
Site-local addresses (They are also meant for private addressing, with the addition of being unique, so that joining two subnets does not cause address collisions.)
Special addresses (They are loopback addresses, IPv4-address mapped spaces, and 6-to-4 addresses for crossing from an IPv4 network to an IPv6 network.)
Compatibility addresses (They are addresses to aid the migration of IPv4 to IPv6 and the coexistence of both types of hosts.)

Multicast

A multicast address identifies multiple interfaces. With the appropriate multicast routing topology, packets addressed to a multicast address are delivered to all interfaces that are identified by the address. A multicast address is used for one-to-many communication, with delivery to multiple interfaces.

In IPv6, multicast traffic operates in the same way that it does in IPv4. Arbitrarily located IPv6 nodes can listen for multicast traffic on arbitrary IPv6 multicast addresses. IPv6 nodes can listen to multiple multicast addresses at the same time. Nodes can join or leave a multicast group at any time.

IPv6 multicast addresses have the first 8 bits set to 1111 1111. An IPv6 address is easy to classify as multicast because it always begins with “FF.” Multicast addresses cannot be used as source addresses or as intermediate destinations in a Routing header. Beyond the first 8 bits, multicast addresses include additional structure to identify their flags, scope, and multicast group.

Anycast

An anycast address identifies multiple interfaces. With the appropriate routing topology, packets addressed to an anycast address are delivered to a single interface, the nearest interface that is identified by the address. The nearest interface is defined as being closest in terms of routing distance. An anycast address is used for one-to-one-of-many communication, with delivery to a single interface.

An anycast address is assigned to multiple interfaces. The routing infrastructure forwards packets that are addressed to an anycast address to the nearest interface to which the anycast address is assigned. To facilitate delivery, the routing infrastructure must track the interfaces that have been assigned anycast addresses and their distance in terms of routing metrics. At present, anycast addresses are used only as destination addresses and are assigned only to routers. Anycast addresses are assigned out of the unicast address space, and the scope of an anycast address is the scope of the type of unicast address from which the anycast address is assigned.

Simplification Of The Header Format

The header format has been simplified to reduce processing time by intermediate nodes. Several IPv4 headers have been dropped, some of which are ID, header length, flags, fragmentation offset and checksum. The ID flag has been removed as it was maintained in v4 as a part of fragmentation for intermediate nodes. Since by design fragmentation is not handled by intermediate nodes in IPv6, this field has been removed. The header length could change in v4 due to presence of options but in v6 the header length is kept constant at 6 octets. Options are taken as a part of the payload. Flags are not required in v6 as fragmentation cannot be set by intermediate nodes. Checksum is being handled by upper and lower level protocols either way apart from IPv4 so it was dropped in v6.

Figure above shows the IPv6 header format. The various fields and their sizes are as follows:

IP v6 Header Analysis

Version (4 bits) shows the IP version number which is 6.

Traffic Class (8 bits) is discussed later.
Flow Label (20 bits) is discussed later.
Payload Length (16 bits) is used to assign length. This is discussed later.
Next Header (8 bits) identifies the type of header that follows the IPv6 header.
Hop Limit (8 bits) is used to limit life of a packet on the network. This is discussed later.
Source and Destination Addresses (each 128 bits) assigns the source and destination addresses.

IPv6 Extension Headers

Further options for IPv6 headers are included in the extension headers. Each extension header is characterized by a certain value in the next header field in the preceding header. A IPv6 header may have zero, one or multiple extension headers. These headers are not processes by intermediate nodes unless they are specified by hop-by-hop option header. De-multiplexing occurs at the final destination and is done according to the content and semantics of the extension headers. If there are no extensions headers, the next header relates to the upper layer protocol header (which is the basic payload). Whether to process the next header is decided by the content of the extension header. Processing must follow the sequence of the extension headers. The only exception to this rule is the hop-by-hop option header. If this header is present this is processed ahead of any other extension header. Hence this is placed right after the IPv6 header with the next header value of the 6 header set to ‘0’. In case of multiple extension headers being present they occur in the following order:

Hop–by–hop, then

Destination option header (for processing by the first node), then

Routing header, then

Fragmentation header, then

Authentication header, then

Encapsulating security payload header, then

Destination option header (for processing by the final destination), then

Upper layer protocol header.

Each header can only occur once except the destination option header. It can occur twice, once right after the IPv6 header and again before the upper layer protocol header. The general format of an extension header is shown in the figure below:

The structure and functionality is as follows:

Option Type: This field consists of 8 bits out of which the first 2 highest order bits defines method of treating the packet if option is unrecognizable by a node. The third highest order bit says whether or not the option data can change while in transit.

Option Length: This field, having a size of 8 bits, shows the length of the option data exclusive of the option length field size (8 bits).

Option Data: This field has a variable size and consists of the optional data.

The type and function of each extension header is discussed in subsequent sections.

Hop–by–Hop Option Header

This header is placed after the IPv6 header and is processed by all link nodes. This has a next header value of ‘0’. The only options are pad1 and padn option. In order to align a packet, an option header of padding is used. Pad1 is used to create one octet padding whereas padN is used to create ‘n’ octet padding.

Routing Header

This header is analogous to IPv4 loose routing / record route header. This has a next header value of ‘43’. The format of a routing header is shown in figure below:

Explanation of the header is as follows:

Next Header (8 bits): This is used to denote the type of header placed next after this header.

Header Extension Length (8 bits): This is used to denote the length of the routing header excluding the double octets for next header and this header.

Routing Type (8 bits): This is used to denote the type of routing option that is being carried within the routing header. This will be broadly discussed later.

Segments Left (8 bits): This field is used to denote the number of link nodes left before reaching the final destination node.

Type Specific Data: This field has a variable size, as it depends on the routing type.

While processing, if the routing is unrecognizable by a link node it checks for the number of segments left. If that value is ‘0’, then the link node processes the next header. If the segments left field has a non ‘0’ value, then the packet is discarded and an ICMP message with ‘unrecognizable route option’ is sent to the source. If a node finds that the MTU is less for a packet to be sent to the next node, then it is discarded as well.

The point worth noting here is that PMTU calculation is done before sending a packet, and fragmentation is maintained only by source and destination. So it can be presumed that the packet size will conform to the outgoing PMTU. So this kind of discarding of a packet for not conforming to PMTU is contradictory.

Routing formats: Type ‘0’ routing header format is displayed below:

The basic explanation of the fields of the routing has already been done. The only difference here is the reserved field of 32 bits, which is ignored while processing by the link nodes.
A routing header is not processed until it reaches a node which is mentioned as one of the addresses in the address fields. This is checked by the destination address field. If a destination address field and an intermediate address is the same then, as directed by the next header in the hop-by-hop header, processing reaches the routing header. The node then checks if the segments left values is ‘0’.

If yes, then it proceeds to the next header which can be the upper layer protocol header. If no, then the following algorithm is maintained:

if Segments Left = 0 {
      proceed to process the next header in the packet, whose type is
      identified by the Next Header field in the Routing header
   }
   else if Hdr Ext Len is odd {
         send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Hdr Ext Len field, and discard the
         packet
   }
   else {
      compute n, the number of addresses in the Routing header, by
      dividing Hdr Ext Len by 2

      if Segments Left is greater than n {
         send an ICMP Parameter Problem, Code 0, message to the Source
         Address, pointing to the Segments Left field, and discard the
         packet
      }
      else {
         decrement Segments Left by 1;
         compute i, the index of the next address to be visited in
         the address vector, by subtracting Segments Left from n

         if Address [i] or the IPv6 Destination Address is multicast {
            discard the packet
         }
         else {
            swap the IPv6 Destination Address and Address[i]

            if the IPv6 Hop Limit is less than or equal to 1 {
               send an ICMP Time Exceeded -- Hop Limit Exceeded in
               Transit message to the Source Address and discard the
               packet
            }
            else {
               decrement the Hop Limit by 1

               resubmit the packet to the IPv6 module for transmission
               to the new destination
            }
         }
      }
   }

(Courtesy: RFC 2460, www.ietf.org)

The algorithm works as follows: At each link node having the same address as the destination address of the incoming packet, the segments left value is checked for a non ‘0’ value. If found true, then a value n = (header length)/2 is calculated. At each respective node, value of segments left is recalculated as segments left = segments left -1. To pick the next address from the list carried by the packet, a value i is calculated as i = segments left – n. Now the ith address from the array is taken and swapped with the destination address field. Hence the table is maintained throughout the path.

The problem with this is that the table values are not removed and the burden of the array is carried along the entire path. If this is to ensure a record route option then the above algorithm does not serve the purpose. If this is to ensure a packet follows a particular path, then addresses of nodes already visited are of no during processing by intermediate nodes which have not been visited yet. An alternate algorithm which reduces the load as a packet passes through nodes listed in the address array can be implemented. On reaching a node, if the destination address matches the node address a node processes the segments left field. On a non ‘0’ value, it processes the topmost address of the address list.

If found valid, this new address is swapped with the destination address field, the hop limit is decremented by 1 and the segments left is decremented by 1. The topmost address from the list is now removed and the next address is incremented to its position. This allows incremental reduction of load on a packet and by the time it reaches its final destination the list holds only 1 address, which should be the same as the final destination.

Fragmentation Header

Fragmentation in IPv6 is analogous in functionality in IPv4. The only difference is that this is handled by only the source and destination nodes. Intermediate link nodes are not allowed to fragment packets. The header format is shown in the figure below:

The fragmentation header has a next header value of ‘44’. The respective fields are:

Next Header (8 bits): The next header contains the type of header following the fragmentation header.

Reserved (8 bits): This field is reserved and is ignored during processing.

Fragmentation Offset (13 bits): This field shows the relative position of the fragment in the whole packet.

Res (2 bits): This field is reserved and is ignored during processing.

M (1 bit): This field denotes whether the fragment is the last fragment of a packet or an intermediate one. Value ‘0’ means last fragment, value ‘1’ means there are more fragments.

Identification (32 bits): This field is generated by the source to label a fragment. At the destination, all fragments with the same identification field, source and destination address are reassembled.

Each packet has two parts:

Unfragmentable Part: the IPv6 header which does not change in any of the fragments and is carried by all of the fragments.

Fragmentable Part: which comprises the extension headers and the payload. Each fragment has the following changed. The next header value in the IPv6 header is changed to 44. For reassembly the next header field value of the unfragmented part is obtained from the next header field value of the fragment header of the first fragment. The payload length is calculated by taking the length of the unfragmentable part and the length and offset of the last fragment. The formula is as follows:
PL.ORIG = PL.FIRST – FL.FIRST – 8 + (8*FO.LAST) + FL.LAST (courtesy:RFC2460, www.ietf.org)
where:
PL.ORIG = payload length of the reassembled packet.

PL.FIRST = payload length of the first fragment.

FL.FIRST = length of the fragment which follows the fragment header of the first fragment.

FO.LAST = fragment offset field of the last fragment.

FL.LAST = length of the fragment which follows the fragment header of the last fragment.

Reassembly of packets is discarded under the following conditions:

If all the fragments do not arrive at their destination within the first 60 seconds from the time of arrival of the first fragment.
For a fragment whose M flag is set to 1, and the packet is not a multiple of 8 octets as calculated from the packet’s payload length.
If a fragment, after reassembly makes a whole packet size greater than 65535 octets.

Destination Option Header

This header is only processed by the destination node. This is the only header which can occur twice, once just after the hop-by-hop option header, and once before the actual payload. It has a next header value of 60.

No Next Header

This header has a next header value of 59. This signifies that there is no header following the header whose next header value is 59. If the IPv6 header payload depicts data beyond such a header, it is passed unchanged for forwarding.

This ends the discussion on the various types of header formats and their subsequent uses in the v6 header. A major improvement in IPv6 has been the packet size management and transmission unit calculation. The next section deals with these two issues.

Packet Size & MTU Issues

IPv6 needs to have every link on the internet to have an MTU of 1280 octets which is 1280 bytes. Any link that cannot conform to this value needs to have the lower layer protocol manage some form of fragmentation and reassembly below the Ipv6 protocol layer. It has been recommended that higher layer protocols with configurable MTU should have it set to 1280 bytes. It is preferable to have it set to 1500 bytes to utilize encapsulation facility without fragmentation.

An Ipv6 node should be able to implement PMTU discovery (RFC 1981). If this is not available then it should restrict to the minimum size of 1280 bytes. Fragmentation algorithm is to be followed for a node trying to send a packet of size bigger than the PMTU. But if an upper layer protocol can resize its segments to match the PMTU, it should be followed. Problem is, once PMTU is discovered using the algorithm detailed in RFC 1981, how do we conform to the upper layer to start constructing segments which will match the PMTU? No specific communication protocol has been designed to send PMTU information to upper layer protocols.

Flow Label

A new field in the IPv6 header is the flow label. This is used to assign a label to all traffic which requires the same level of handling, e.g. ‘real time’ traffic. Problems arise in the level of priority handling of such packets. Instances where routers and hosts don’t support flow labelling, this field is set to ‘0’ and routers ignore it. So there is a question of recognizing the feature. A router which does not recognize this feature ignores the value.

A flow label is identified by a set of same source address, destination address and a flow label. If any packet has the hop-by-hop option set, then all packets belonging to the same flow must have the same option, except the value of the next header field. If any packet in the flow has a routing header, then all packets in the same flow must have the same content up to and including the routing header, except the value of the next header field. So the problem is that the burden of a hop-by-hop or routing header requirements of any one packet in a flow has to be borne by all the packets in that flow, whether or not it applies to them. Flow label recovery after a router has crashed is also difficult, while keeping in mind the time constraints and domain of values within a given time frame.

Traffic Classes

This field is analogous to the TOS field in IPv4 headers. This is created to provide the same type of functionality.

Upper Layer Checksum Issues

Any upper layer protocol which also takes into account the IP addresses, while calculating checksum, needs to modify its checksum calculating algorithm to accommodate 128 bit addresses instead of 32 bit addresses.

Maximum Payload Size

While calculating the maximum payload size, an upper layer protocol has to take into account the header size of the v6 header. Hence a TCP segment can have a maximum size of 60 bytes less than the PMTU calculated. This is to accommodate 40 octets of the IPv6 header and 20 octets for the TCP header.

Responding the Packets Carrying Routing Headers

Certain methods have to be followed while a response packet is being sent to an incoming packet carrying a routing header. When an upper layer protocol is responding to a packet which carried a routing header, the response packet generated will not carry a routing header by reversing the order of addresses found in the routing header of the incoming packet. The only exceptions to this rule are:

Response To Packets Not Carrying A Routing Header

Packets having a routing header supplied by the local configuration, which was not generated by reversing the address list found in the incoming packet to which this response packet is being generated. Routing headers generated by reversing the list of the routing header in an incoming packet, if, and only if, the incoming packet carried an authentication header and has been verified by the receiver.

About The Writer

Understanding the Need for IPv6 - How IPv6 Overcomes IPv4 Limitations

2012-05-16T05:36:46+10:00

Internet has been around in its current form since the 1980s. What started off as an in-house project in ARPA in 1958 rapidly expanded into what we know today as the Internet. IPv4 as a protocol has been in practice since the 1980s. Back then it was only designed to allocate addresses for a few billion, 4.3 billion to be exact. The Internet Assigned Numbers Authority (IANA) was in charge of allocating these addresses and it did so by sending them in blocks of 16.8 million. This it did by putting in place certain regional Internet registries or RIRs.

But as the popularity of the Internet grew exponentially, so did the need for more and more IP addresses. This already was becoming a problem in the late 1980s. Through time, as computers become more affordable and people wanted to be on the World Wide Web, the need was growing more acute. With more advancement of technology, today, phones, cameras, video game consoles and other devices are also joining the internet.

This added to the issue of the lack of IP addresses to allocate to this new breed of machines on the Internet. IANA officially exhausted its pool of addresses on 31^st January 2011 and one RIR exhausted its on 15^th April 2011. The rest are destined to run out within the next few years.

Guided by this sense of Internet catastrophe, the most logical solution to this problem was to create a new protocol, a protocol that would go where no protocol has gone before, or at least provide more internet addresses to use.

As is traditional in our networking community, prescribed by the Internet Engineering Task Force or IETF (the main promoter and developer of Internet standards), any new standard, method, behaviours, research and innovation needs to be published as a memorandum. This can include anything that involves or is applicable to the internet or internet related systems. It’s what they call a Request for Comment or an RFC.

Hence, an RFC was released in January 1995 that detailed the creation of a new protocol IPv6. This was called RFC 1752 and the opening lines said, and I quote “This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the Internet Protocol.”

The solution was for IPv6 to accommodate the increased demand by providing a much larger address space, along with improved traffic routing and better security. Some of the salient features include:

Larger IP address space: IPv6 has 128-bit address space or 4 times more address bits than IPv4's 32-bit address space. This large address space is enough for many decades to come. In real terms, every residential or commercial customer will be able to receive more address space from TWC than the entire IPv4 address space contains – several billion IP addresses!

Better security: IPv6 includes security in the underlying protocol. For example, encryption of packets (ESP: Encapsulated Security Payload) and authentication of the sender of packets (AH: Authentication Header).
Consideration to real time: To implement better support for real-time traffic (such as videoconference), IPv6 includes a flow label mechanism so routers can more easily recognize where to send information.
Plug and play: IPv6 includes plug and play, which is easier for novice users to connect their machines to the network. Essentially, configuration will happen automatically.
Better optimization: IPv6 takes the best of what made IPv4 successful and gets rid of minor flaws and unused features.

The recommendation to create the next generation protocol was raised in the Toronto IETF conference. The main changes from IPv4 can be summarised as follows:

Expanded addressing capability and auto configuration mechanism: the address size in this protocol has been increased from 32 bit to 128 bit with deeper addressing hierarchy and simpler configurations. A new type of address called Anycast has been created to send a message to a single nearest member of a group.
Simplification of the header format and reduction in size: the header now has a fixed length of 40 bytes. Some header fields that were a part of IPv4 have been removed. They are discussed more in detail in the description of IPv6 header. This was done to improve on header processing time and forwarding techniques.
Improved support for extensions and options: unlike IPv4, the extensions in IPv6 are made optional and inserted between the header and the payload when needed. This improves flexibility and any new options in the future can be integrated easily.
Extensions for authentications and privacy: support for data authentications and data security has been specified.
Flow labelling capability: packets belonging to the same traffic flow needing special handling or security can be labelled by the sender.

So, in all, the proposal was adopted by IETF and implemented. The deployment of IPv6 is the only available solution to the IPv4 address shortage. IPv6 is endorsed and implemented by all Internet technical standards bodies and network equipment vendors. It encompassed many design improvements, including the replacement of the 32-bit IPv4 address format with a 128-bit address for a capacity of about 3.4×10³⁸ addresses. IPv6 has been in active production deployment since June 2006.

In the next tutorial, IPv6 - Analysing the IPv6 Protocol Structure and IPv6 Header, we will see exactly how and why is IPv6 the next best thing since sliced bread, or in our world, the next best protocol!

About The Writer

Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode - What's the Difference?

2012-05-06T11:14:51+10:00

IPSec’s protocol objective is to provide security services for IP packets such as encrypting sensitive data, authentication, protection against replay and data confidentiality.

As outlined in our IPSec protocol article, Encapsulating Security Payload (ESP) and Authentication Header (AH) are the two IPSec security protocols used to provide these security services. Analysing the ESP and AH protocols is out of this article’s scope, however you can turn to our IPSec article where you’ll find an in-depth analysis and packet diagrams to help make the concept clear.

Understanding IPSec Modes –Tunnel Mode & Transport Mode

IPSec can be configured to operate in two different modes, Tunnel and Transport mode. Use of each mode depends on the requirements and implementation of IPSec.

IPSec Tunnel Mode

IPSec tunnel mode is the default mode. With tunnel mode, the entire original IP packet is protected by IPSec. This means IPSec wraps the original packet, encrypts it, adds a new IP header and sends it to the other side of the VPN tunnel (IPSec peer).

Tunnel mode is most commonly used between gateways (Cisco routers or ASA firewalls), or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it.

Tunnel mode is used to encrypt traffic between secure IPSec Gateways, for example two Cisco routers connected over the Internet via IPSec VPN. Configuration and setup of this topology is extensively covered in our Site-to-Site IPSec VPN article. In this example, each router acts as an IPSec Gateway for their LAN, providing secure connectivity to the remote network:

Another example of tunnel mode is an IPSec tunnel between a Cisco VPN Client and an IPSec Gateway (e.g ASA5510 or PIX Firewall). The client connects to the IPSec Gateway. Traffic from the client is encrypted, encapsulated inside a new IP packet and sent to the other end. Once decrypted by the firewall appliance, the client’s original IP packet is sent to the local network.

In tunnel mode, an IPSec header (AH or ESP header) is inserted between the IP header and the upper layer protocol. Between AH and ESP, ESP is most commonly used in IPSec VPN Tunnel configuration.

The packet diagram below illustrates IPSec Tunnel mode with ESP header:

ESP is identified in the New IP header with an IP protocol ID of 50.

The packet diagram below illustrates IPSec Tunnel mode with AH header:

The AH can be applied alone or together with the ESP, when IPSec is in tunnel mode. AH’s job is to protect the entire packet. The AH does not protect all of the fields in the New IP Header because some change in transit, and the sender cannot predict how they might change. The AH protects everything that does not change in transit. AH is identified in the New IP header with an IP protocol ID of 51.

IPSec Transport Mode

IPSec Transport mode is used for end-to-end communications, for example, for communication between a client and a server or between a workstation and a gateway (if the gateway is being treated as a host). A good example would be an encrypted Telnet or Remote Desktop session from a workstation to a server.

Transport mode provides the protection of our data, also known as IP Payload, and consists of TCP/UDP header + Data, through an AH or ESP header. The payload is encapsulated by the IPSec headers and trailers. The original IP headers remain intact, except that the IP protocol field is changed to ESP (50) or AH (51), and the original protocol value is saved in the IPsec trailer to be restored when the packet is decrypted.

IPSec transport mode is usually used when another tunneling protocol (like GRE) is used to first encapsulate the IP data packet, then IPSec is used to protect the GRE tunnel packets. IPSec protects the GRE tunnel traffic in transport mode.

The packet diagram below illustrates IPSec Transport mode with ESP header:

Notice that the original IP Header is moved to the front. Placing the sender’s IP header at the front (with minor changes to the protocol ID), proves that transport mode does not provide protection or encryption to the original IP header and ESP is identified in the New IP header with an IP protocol ID of 50.

The packet diagram below illustrates IPSec Transport mode with AH header:

The AH can be applied alone or together with the ESP when IPSec is in transport mode. AH’s job is to protect the entire packet, however, IPSec in transport mode does not create a new IP header in front of the packet but places a copy of the original with some minor changes to the protocol ID therefore not providing essential protection to the details contained in the IP header (Source IP, destination IP etc). AH is identified in the New IP header with an IP protocol ID of 51.

In both ESP and AH cases with IPSec Transport mode, the IP header is exposed.

ISDN Layers, Protocols & Components

2011-06-10T07:40:39+10:00

Our previous article was an Introduction To The ISDN Protocol. This article dives a bit deeper by examining ISDN Layers, Protocols & Components.

ISDN uses circuit-switching to establish a physical permanent point-to-point connection from the source to the destination. ISDN has standards defined by the ITU that encompass the OSI bottom three layers of which are Physical, Data Link and Network, see Table 1 below.

At the physical layer the ITU has defined the user network interface standard as I.430 for Basic Rate Access and I.431 for Primary Rate Access; please see the ITU-T I.414 “Overview of Recommendations on Layer 1 for ISDN and B-ISDN customer accesses” document on the ITU's website. ANSI has defined the user network interface standard as T1.601. As already stated above, the physical layer uses the normal telephone cabling as its physical cabling structure.

The ISDN B channels will typically utilise a Point-to-Point protocol such as HDLC (High-Level Data Link Control) or PPP frames at Layer 2 however you can sometimes see other encapsulation such as Frame relay. As you would expect, at layer 3 you typically see IP packets. ISDN operates in Full-Duplex which means that traffic can be received and transmitted at the same time.

The ISDN D channel will utilise different signalling protocols at Layer 3 and Layer 2 of the OSI Model. Typically at Layer 2, LAP-D (Link Access Procedure – D Channel) is the Q.921 signalling used and DSS1 (Digital Subscriber Signalling System No.1) is the Q.931 signalling that is used at Layer 3. It is easy to remember which one is used at which layer by simply remembering that the middle number corresponds to the layer it operates at.

Table 1

OSI Layer	B Channel	D Channel
3	IP	DSS1 (Q.931)
2	HDLC/PPP	LAP-D (Q.921)
1	I.430/I.431 or ANSI T1.601

Users requiring information on how to configure a Cisco router for ISDN dialup can read our How To Configure ISDN Internet Dialup On A Cisco Router article.

The Different ISDN Components

As part of the ISDN Standards, there are several types devices that are used to connect to the ISDN network which are known as Terminal Equipments (TE) and also Network Termination (NT) equipment. You also have Reference Points which are used to define the connections between the various equipment that is used within the ISDN network.

Terminal Equipment and Network Termination Definitions

• Terminal Equipment Type 1 (TE1) are devices that can plug directly into an ISDN Network and understands the ISDN standards

• Terminal Equipment Type 2 (TE2) are devices that predate the official ISDN standards and require the use of a terminal adapter (TA) to facilitate plugging into the ISDN Network. These can simply be routers that only have a serial interface on them and not an ISDN WIC. The terminal adapter can plug into the serial interface and allow the router to be used to connect to the ISDN network. Another example would be a Personal Computer (PC).

• Network Termination 1 (NT1) is typically a customer's device that is used to implement the physical layer specification into the ISDN Network (or the NT2 device). This is the U Reference point that connects through to the telco. This operates at Layer 1 of the OSI Model.

• Network Termination 2 (NT2) is typically the telco's device (it's very rare to see this at the customers site) that is used to terminate from the customers NT1 device before traffic hits the ISDN network. This operates at Layer 2 & 3 of the OSI Model and is an intelligent device performing the switching.

• Terminal Adapter (TA) is used to convert TE2 device signalling into signalling that is used by the ISDN switch.

Different ISDN Reference Points

• R – This reference point is used to specify the point between the TE2 device and the TA device.

• S – This reference point is used to specify the point between the customers router and the NT2 device.

• T – This reference point is used to specify the point between the NT1 device and the NT2 device S and T reference points can perform the same functions therefore they are sometimes referred to as an S/T reference point. When we are plugging into the S/T reference point location, the function of the NT2 is redundant since it's built in.

• U – This reference point is used to specify the point between the NT1 device and the telco's termination equipment in the ISDN carrier network, apart from in North America where the NT1 function isn't provided by the carrier network.

Cisco Router Options

With Modular Cisco Routers, they come with slots where you can plug in various cards different types of WAN Interface Cards (WIC). Cisco provide 2 different types of WICs for ISDN support. These different cards provide either a ISDN WIC with the S/T reference points which plug into an NT1 device or an ISDN WIC with a U reference point which has the NT1 built into the WIC itself.

Which WIC is required depends on your location and the telco that provides the ISDN circuit. For example, in North America , they use a two-wire connection which is a WIC card with the U reference point, having the NT1 built into it.

More information regarding the configuration of Cisco routers and ISDN confguration can be found in our Basic ISDN Configuration article.

Introduction To The ISDN Protocol

2011-06-10T07:28:03+10:00

ISDN (Integrated Services Digital Network) is a digital telephone standard designed to replace analogue connections by utilising ordinary copper wires that are used in standard analogue telephone systems. It started as a recommendation within the ITU's (International Telecommunication Union) Red Book in 1984, although prior to 1992, the ITU was known as the CCITT (International Telegraph and Telephone Consultative Committee). The ITU is responsible for developing recommendations on International Standards within the industry.

ISDN was developed to provide digital transmission of both voice and data resulting in better quality and speeds over that of PSTN (Public Switched Telephone Network) systems.

Getting to Know the Digital Protocol

There are two types of IDSN Channels.

• The B-Channel – This is known as the Bearer (“B”) channel which is a 64Kbps channel used for voice, video, data or multimedia transfer. These can be aggregated together to get higher bandwidth utilisation.

• The D-Channel – This is known as the Delta (“D”) channel which can be either 16Kbps or 64Kbps used primarily for the signalling between the switching equipment. Some say that this adds to the security of ISDN because the controlling and data channels are separate.

N.B. Digital Signal 0 (DS0) is a basic digital signalling rate of 64Kbits which may be used to describe a single Bearer channel.

Users requiring information on how to configure a Cisco router for ISDN dialup can read our How To Configure ISDN Internet Dialup On A Cisco Router article.

BRI (Basic Rate Interface)

Can also be known as BA (Basic Access), this operates a single 16Kbps D channel and two 64Kbps B channels. Although it isn't usually pointed out, the BRI total speed is 192Kbps, this is because you have an additional 48Kbps overhead for framing and synchronisation on the D channel. (64 * 2) + (16 + 48) = (128 + 64) = 192Kbps.

PRI (Primary Rate Interface)

Can also be known as PA (Primary Access), this can operate in two different modes depending on your geographic location. For European locations, PRI is made up of 30 x 64Kbps B channels and a single 64Kbps D channel which gives a total of 2.048Mbps which is also known as an E1 line (or DS1).

For American and Japanese locations, PRI is made up of 23 x 64Kbps B channels and a single 64Kbps D channel which give a total of 1.544Mbps which is also known as a T1 line (or DS1). Framing and Synchronisation is at 8Kbps for T1 or 64Kbps for E1. T1 PRI is commonly referred to as “23B+D” and for E1 PRI is commonly referred to as “30B+D”.

N.B. E1 PRI actually has 32 channels which are comprised of 30 x B Channels, 1 x D Channel and 1 Synchronisation Channel.

Digital Signal Levels (DSx)

Digital Signal X is used to describe standard digital transmission rates or levels based on DS0 which is defined as a transmission rate of 64Kbps. This is the rate for one telephone voice channel. This is based on the ANSI T1.107 guidelines and the ITU guideline does differ slightly. The following tables show you the DS level and the corresponding speed and T/E classification.

T Carrier

Digital Signal Level	T Speed	T Classification	Channels
DS0	64 Kbps	N/A	1
DS1	1.544 Mbps	T1	24
DS2	6.312 Mbps	T2	96
DS3	44.368 Mbps	T3	672

E Carrier

Digital Signal Level	E Speed	E Classification	Channels
DS0	64 Kbps	N/A	1
DS1	2.048 Mbps	E1	32
DS2	8.448 Mbps	E2	128
DS3	34.368 Mbps	E3	512
DS4	139.264 Mbps	E4	2048
DS5	565.148 Mbps	E5	8192

As you can see from the tables, you can see where the guidelines differ slightly. In fact, depending on what sources you read, these tables may differ slightly.

Point-to-Point Protocol (PPP)

ISDN will typically use the Point-to-Point (PPP) Tunnelling protocol as its basis of transmitting packets over the ISDN circuit. The IP Packets are encapsulated into the PPP packets before the traffic is sent.

PPP provides link specific control functions via Link Control Protocol (LCP) such as Link Configuration, Link Quality Testing & Address Negotiation. LCP provides more advanced features, such as Multilink, Header Compression, Callback, Scripting, Demand Dialing, Filtering, Tunnelling and Server Routing. There are also authentication mechanisms that can help to ensure that the ISDN connection that is established is from a trusted source. Authentication is optional which can be performed by the use of PAP, CHAP & EAP (although EAP is not used in ISDN implementations, EAP is however a valid authentication method of PPP).

PAP – Password Authentication Protocol is not strong since the password is sent in clear text. PAP occurs during the LCP phase of the PPP connection.

CHAP – Challenge Handshake Authentication Protocol, is much stronger then PAP and is much more widely used. It uses a Challenge/Response security mechanism which uses a one way Hash Function to ensure that the passwords are not sent over the link. The password is Hashed and sent over the link, the other side of the link then performs the same hashing function on the password that they have configured then check to ensure that the two hash values are the same. This can also provide protection against playback.

EAP – Extensible Authentication Protocol provides the ability to use multiple authentication protocols such as static passwords, CHAP, Token Cards, Biometrics, etc... As you can imagine, since CHAP is available on its own and ISDN cannot really work with Token Cards or Biometrics it isn't used in ISDN implementations.

The next article deals with ISDN Layers, Protocols & Components.

Introduction To Protocols

2011-04-25T10:00:00+10:00

In the networking and communications area, a protocol is the formal specification that defines the procedures that must be followed when transmitting or receiving data. Protocols define the format, timing, sequence, and error checking used on the network.

In plain english, the above means that if you have 2 or more devices e.g computers which want to communicate, then they need a common "Protocol" which is a set of rules that guide the computers on how and when to talk to each other.

The way this "defenition" happens in computer land is by the RFC's (Requests For Comments) where the IETF (a group of enginners with no life) make up the new standards and protocols and then the major vendors (IBM, Cisco, Microsoft, Novell) follow these standards and implement them in their products to make more money and try to take over this world !

There are hundreads of protocols out there and it is impossible to list them all here, but instead we have included some of the most popular protocols around so you can read up on them and learn more about them.

The table below shows the most popular TCP/IP protocols. The OSI model is there for you to see which layer each of these protocols work at.

One thing which you should keep in mind is that as you move from the lower layers (Physical) to the upper layers (Applications), more processing time is needed by the device that's dealing with the protocol.

There is a great amount of protocols covered on Firewall.cx, these include: IP protocol, Subnetting, TCP/UDP protocol, ICMP, DNS, FTP, TFTP, Netflow, Spanning Tree Protocol, Ethernet, RIP, OSPF and many more.

To read up on any of our covered topics, simply navigate through our Networking menu above.

File Transfer Protocol - FTP

2011-04-25T10:00:00+10:00

File transfer is among the most frequently used TCP/IP applications and it accounts for a lot of the network traffic on the Internet. Various standard file transfer protocols existed even before the Internet was available to everyone and it was these early versions of the file transfer software that helped create today's standard known as the File Transfer Protocol (FTP). Most recent specifications of the protocol are listed in RFC 959.

The Protocol

FTP uses TCP as a transport protocol. This means that FTP inherits TCP's robustness and is very reliable for transferring files. Chances are if you download files, you've probably used ftp a few hundred times without realising it ! And if you have a huge warez collection, then make that a couple of thousand times :)

The picture below shows where FTP stands in contrast to the OSI model. As I have noted in other sections, it's important to understand the concept of the OSI model, because it will greatly help you understand all this too :)

Now, we mentioned that FTP uses TCP as a transport, but we didn't say which ports it uses! Port numbers 21 and 20 are used for FTP. Port 21 is used to establish the connection between the 2 computers (or hosts) and port 20 to transfer data (via the Data channel).

But there are some instances where port 21 is used for both, establishing a connection and data transfer and I will analyse them shortly.

The best thing you can do to "see" it yourself is to grab a packet sniffer which you will conveniently find in our download section and try to capture a few packets while you're ftp'ing to a site.

Both Ports - 20 and 21 - Active FTP Mode

Included below is a screenshot clearly showing TCP ports 20 and 21 being used:

Only Port 21 - Passive FTP Mode

The next screenshot shows captures an FTP session using only TCP Port 21:

FTP has two different modes of operation: Active and Passive. The mode used depends on a number of circumstances, but mainly if you are behind a firewall or not.

Active Mode FTP

Active mode is usually used when there isn't any firewall between you and the FTP server. In such cases you have a direct connection to the Internet. When you (the client) try to establish a connection to a FTP server, your workstation includes a second port number (using the PORT command) that is used when data is to be exchanged, this is known as the Data Channel.

The FTP server then starts the exchange of data from its own port 20 to whatever port was designated by your workstation (in the screen shot, my workstation used port 1086), and because the server initiated the communication, it's not controlled by the workstation client. This can also potentially allow uninvited data to arrive to your computer from anywhere posing as a normal FTP transfer. This is one of the reasons Passive FTP is more secure.

Passive Mode FTP

Using normal or passive FTP, a client begins a session by sending a request to communicate through TCP port 21, the port that is conventionally assigned for this use at the FTP server. This communication is known as the Control Channel connection.

At this point, a PASV command is sent instead of a PORT command. Instead of specifying a port that the server can send to, the PASV command asks the server to specify a port it wishes to use for the Data Channel connection. The server replies on the Control Channel with the port number which the client then uses to initiate an exchange on the Data Channel. The server will thus always be responding to client-initiated requests on the Data Channel and the firewall can correlate these.

It's simple to configure your client FTP program to use either Active or Passive FTP. For example, in Cute FTP, you can set your program to use Passive FTP by going to FTP--> Settings --> Options and then selecting the "Firewall" tab :

If you remove the above options, then your workstation will be using (if possible) Active FTP mode, and I say "if possible" cause if your already behind a firewall, there is probably no way you will be using Active FTP, so the program will automatically change to Passive FTP mode.

So let's have a look at the process of a computer establishing an FTP connection with a server: .

The above is assuming a direct connection to the FTP server. For simplicity reasons, we are looking at the way the FTP connection is created and not worring if it's a Passive or Active FTP connection. Since FTP is using TCP as a transport, you would expect to see the 3-way handshake. Once that is completed and there is data connection established, the client will send its login name and then password. After the authentication sequence is finished and the user is authenticated to the Server, it's allowed access and is ready to leach the site dry :)

Finally, below are the most commonly used FTP commands:

ABOR: abort previous FTP command

LIST and NLST: list file and directories

DELE: delete a file

RMD: remove a directory

MKD: create a directory

PWD: print current working directory ( show you which dir. your at)

PASS: send password

PORT: request open port number on specific IP address/port number

QUIT: log off from server

RETR: retrieve file

STOR: send or put file

SYST: identity system type

TYPE: specify type (A for ASCII, I for binary)

USER: send username

And that just about complete's our analysis on the FTP protocol !

Trivial File Transport Protocol - TFTP

2011-04-25T10:00:00+10:00

TFTP is a file transport protocol and its name suggests it's something close to the FTP protocol (File Transfer Protocol), which is true .. to a degree. TFTP isn't very popular because it's not really used on the Internet because of its limitations which we'll explore next.

The TFTP Protocol

TFTP's main difference from FTP is the transport protocol it uses and the lack of any authentication mechanisim. Where FTP uses the robust TCP protocol to establish connections and complete the file transfers, TFTP uses the UDP protocol which is unsecure and has no error checking built in to it (unless they have implemented some type of error checking in the program you are using to transfer files), this also explains why you are more likely to find TFTP in a LAN, rather than a WAN (Wide Area Network) or on the Internet.

The major limitations with TFTP are authentication and directory visibility, meaning you don't get to see the files and directories available at the TFTP server.

As mentioned, TFTP uses UDP as a transport, as opposed to TCP which FTP uses, and works on port 69, you can clearly see that in the cool 3D diagram on the left.

Port 69 is the default port for TFTP, but if you like, you can modify the settings on your TFTP server so it runs on a different port.

Now, to make things a bit clearer I have included a screen shot of my workstation tftp'ing into a TFTP server which I have setup in my little network.

You can see my workstation (192.168.0.100) contacting the TFTP server (192.168.0.1) on port 69(destination port). In this first packet, my workstation is contacting the server and requesting the file I entered before I connected to the server. Click here for the full picture.

Because you don't get a listing of the files and directories, you must know which file you want to download ! In the response I received (2nd packet) the server gets straight into business and starts sending the file. No authentication whatsoever !

Note: The workstation usally won't send back any acknowlegement (because UDP, which is the transport protocol, by nature, never sends acknowledgements), but the software developers can incorporate such a feature by forcing the workstation to send a small packet which the TFTP server is able to pickup as an acknowledgement of the previous data packet it sent to the workstation.

In the example I provide, you can see my workstation sending small packets to the server after it receives one packet from it. These small acknowledgements have been added by the software company who created the program I was using for this example.

Below is a screen shot of the program I used to TFTP (TFTP Client) to the server:

Notice how I entered the file I wanted to downloaded (server.exe), and selected the name which the file will be saved as on my local computer (Local File). If I didn't provide the Remote File name, I would simply get an error poping up at the server side, complaing that no such file exists. You can also send files using TFTP, as it's not just for downloading :)

So where is TFTP used?

TFTP is used mostly for backing up router configuration files like Cisco and its IOS images, it is also used for diskless booting PC's where, after the workstation has booted from the network card's ROM, TFTP is used to download the program it needs to load and run from a central server.

Below is a diagram which shows what takes place during a TFTP session:

In this diagram we are assuming that there is no error checking built into the software running at both ends (client and server).

This completes our discussion on the TFTP protocol. More information around different protocols can be found in the Network Protocol section.

net.

The major limitations with TFTP are authentication and directory visibility, meaning you don't get to see the files and directories available at the TFTP server.

As mentioned, TFTP uses UDP as a transport, as opposed to TCP which FTP uses, and works on port 69, you can clearly see that in the cool 3D diagram on the left.

Port 69 is the default port for TFTP, but if you like, you can modify the settings on your TFTP server so it runs on a different port.

You will find some very good TFTP servers and clients in the download section.

Now, to make things a bit clearer I have included a screen shot of my workstation tftp'ing into a TFTP server which I have setup in my little network.

Note: The workstation usally won't send back any acknowlegement (because UDP, which is the transport protocol, by nature, never sends acknowledgements), but the software developers can incorporate such a feature by forcing the workstation to send a small packet which the TFTP server is able to pickup as an acknowledgement of the previous data packet it sent to the workstation.

Below is a screen shot of the program I used to TFTP (TFTP Client) to the server:

So where is TFTP used ?

Below is a diagram which shows what takes place during a TFTP session:

.....

In this diagram we are assuming that there is no error checking built into the software running at both ends (client and server).

And that pretty much sums it all up for the TFTP protocol.

IPSec - Internet Protocol Security

2011-04-25T10:00:00+10:00

IPSec is one of the new buzz words these days in the networking security area. It's becoming very popular and also a standard in most operating systems. Windows 2000 fully supports IPSec and that's most probably where you are likely to find it. Routers these days also support IPSec to establish secure links and to ensure that no-one can view or read the data they are exchanging.

When the original IP (Internet Protocol) specification was created, it didn't really include much of a security mechanisim to protect it from potential hackers. There were 2 reasons they didn't give IP some kind of security. First was because back then (we are talking around 30 years ago) most people thought that users and administrators would continue to behave fairly well and not make any serious attempts to compromise other people's traffic. Second reason was because the cryptographic technology needed to provide adequate security simply wasn't widely available and in most cases not even known about!

How IPSec Works

The Internet Security Agreement/Key Management Protocol and Oakley ( ISAKMP)

ISAKMP provides a way for two computers to agree on security settings and exchange a security key that they can use to communicate securely. A Security Association (SA) provides all the information needed for two computers to communicate securely. The SA contains a policy agreement that controls which algorithms and key lengths the two machines will use, plus the actual security keys used to securely exchange information.

There are two steps in this process. First, the two computers must agree on the following three things:

1) The encryption algorithm to be used (DES, triple DES)

2) Which algorithm they'll use for verifying message integrity (MD5 or SHA-1)

3) How connections will be authenticated: using public-key certificate, a shared secret key or Kerberos.

Once all that has been sorted out, they start another round of negotiations which cover the following:

1) Whether the Authentication Header (AH) protocol will be used

2) Whether the Encapsulating Security Payload (ESP) protocol will be used

3) Which encryption algorithm will be used for ESP

4) Which authentication protocol will be used for AH

IPSec has 2 mechanisms which work together to give you the end result, which is a secure way to send data over public networks. Keep in mind that you can use both or just one of these mechanisms together.

These mechanisms are:

Authentication Header (AH)
Encapsulating Security Payload - ESP

The Authentication Header (AH) Mechanism

The Authentication Header information is added into the packet which is generated by the sender, right between the Network (Layer 3) and Transport (Layer 4) Layer (see picture below) of the OSI model.

Authentication protects your network, and the data it carries, from tampering. Tampering might be a hacker sitting between the client and server, altering the contents of the packets sent between the client and server, or someone trying to impersonate either the client or server, thus fooling the other side and gaining access to sensitive data.

To overcome this problem, IPSec uses an Authentication Header (AH) to digitally sign the entire contents of each packet. This signature provides 3 benefits:

1) Protects against replay attacks. If an attacker can capture packets, save them and modify them, and then send them to the destination, then they can impersonate a machine when that machine is not on the network. This is what we call a replay attack. IPSec will prevent this from happening by including the sender's signature on all packets.

2) Protection against tampering. The signatures added to each packet by IPSec means that you can't alter any part of a packet undetected.

3) Protection against spoofing. Each end of a connection (e.g client-server) verifies the other's identity with the authentication headers used by IPSec.

The AH is computed on the entire packet, including payload (upper layers - 4,5,6,7) and headers of each layer. The following picture shows us a packet using AH :

Below is the analysis of the Authentication Header:

AH Algorithms

For point-to-point communication (e.g client to server), suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g DES) or on one-way hash functions (e.g MD5 or SHA-1).

For multicast communication (e.g between a group of routers), one-way hash algorithms combined with asymmetric signature algorithms are usually used, but they are also more cpu intensive.

The Encapsulating Security Payload - ESP

The Authentication Header (AH) we spoke about will protect your data from tampering, but it will not stop people from seeing it. For that, IPSec uses an encryption which provides the Encapsulating Security Payload (ESP). ESP is used to encrypt the entire payload of an IPSec packet (Payload is the portion of the packet which contains the upper layer data).

ESP is a bit more complex than AH because alone it can provide authentication, replay-proofing and integrity checking. It acomplishes this by adding 3 separate components:

An ESP header
An ESP trailer and
An ESP authentication block.

Each of these components contains some of the data needed to provide the necessary authentication and integrity checking. To prevent tampering, an ESP client has to sign the ESP header, application data, and ESP trailer into one unit, of course ESP is used to encrypt the application data and the ESP trailer to provide confidentiality. The combination of this overlapping signature and encryption operation provides good security.

Let's have a look at a packet using IPSec - ESP:

IPSec can get very complicated and messy. I have tried keeping everything as simple as possible, but you should keep in mind that this topic can be studied in far greater depth than is presented here!


	On the left you are seeing the analysis of the Authentication Header.
AH Algorithms For point-to-point communication (e.g client to server), suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g DES) or on one-way hash functions (e.g MD5 or SHA-1). For multicast communication (e.g between a group of routers), one-way hash algorithms combined with asymmetric signature algorithms are usually used, but they are also more cpu intensive.
The Encapsulating Security Payload - ESP The Authentication Header (AH) we spoke about will protect your data from tampering, but it will not stop people from seeing it. For that, IPSec uses an encryption which provides the Encapsulating Security Payload (ESP). ESP is used to encrypt the entire payload of an IPSec packet (Payload is the portion of the packet which contains the upper layer data). ESP is a bit more complex than AH because alone it can provide authentication, replay-proofing and integrity checking. It acomplishes this by adding 3 separate components: 1) An ESP header 2) An ESP trailer and 3) An ESP authentication block. Each of these components contains some of the data needed to provide the necessary authentication and integrity checking. To prevent tampering, an ESP client has to sign the ESP header, application data, and ESP trailer into one unit, of course ESP is used to encrypt the application data and the ESP trailer to provide confidentiality. The combination of this overlapping signature and encryption operation provides good security. Let's have a look at a packet using IPSec - ESP:

IPSec can get very complicated and messy. I have tried keeping everything as simple as possible, but you should keep in mind that this topic can be studied in far greater depth than is presented here!

Network Protocols

IPv6 Subnetting - How and Why to Subnet IPv6

Network Address Range

Subnetting Range

0000000000000000.0000000000000000.0000000000000000.1111111111111111.0000000000000000.0000000000000000.0000000000000000.0000000000000000Device (Interface) Range

Subnetting Example

About the Writer

IPv6 - Analysing the IPv6 Protocol Structure and IPv6 Header

Addressing Capability - Three Types of Addresses IPv6 Supports

Unicast

Multicast

Anycast

Simplification Of The Header Format

IPv6 Extension Headers

Hop–by–Hop Option Header

Routing Header

Fragmentation Header

Destination Option Header

No Next Header

Packet Size & MTU Issues

Flow Label

Traffic Classes

Upper Layer Checksum Issues

Maximum Payload Size

Responding the Packets Carrying Routing Headers

Response To Packets Not Carrying A Routing Header

About The Writer

Understanding the Need for IPv6 - How IPv6 Overcomes IPv4 Limitations

About The Writer

Understanding VPN IPSec Tunnel Mode and IPSec Transport Mode - What's the Difference?

Understanding IPSec Modes –Tunnel Mode & Transport Mode

IPSec Tunnel Mode

IPSec Transport Mode

ISDN Layers, Protocols & Components

The Different ISDN Components

Terminal Equipment and Network Termination Definitions

Different ISDN Reference Points

Cisco Router Options

Introduction To The ISDN Protocol

BRI (Basic Rate Interface)

PRI (Primary Rate Interface)

Digital Signal Levels (DSx)

Point-to-Point Protocol (PPP)

Introduction To Protocols

File Transfer Protocol - FTP

The Protocol

Both Ports - 20 and 21 - Active FTP Mode

Only Port 21 - Passive FTP Mode

Active Mode FTP

Passive Mode FTP

Trivial File Transport Protocol - TFTP

The TFTP Protocol

So where is TFTP used?

IPSec - Internet Protocol Security

How IPSec Works

The Authentication Header (AH) Mechanism

AH Algorithms

The Encapsulating Security Payload - ESP

0000000000000000.0000000000000000.0000000000000000.1111111111111111.0000000000000000.0000000000000000.0000000000000000.0000000000000000

Device (Interface) Range