IP Engineering Overview
Wray Castle Limited Bridge Mills, Stramongate, Kendal, LA9 4UB, UK.
[email protected] www.wraycastle.com © Wray Castle Limited all rights reserved
IP Engineering Overview
IP ENGINEERING OVERVIEW
First published 2003 Last updated December 2004 WRAY CASTLE LIMITED BRIDGE MILLS STRAMONGATE KENDAL LA9 4UB UK
Yours to have and to hold but not to copy The manual you are reading is protected by copyright law. This means that Wray Castle Limited could take you and your employer to court and claim heavy legal damages. Apart from fair dealing for the purposes of research or private study, as permitted under the Copyright, Designs and Patents Act 1988, this manual may only be reproduced or transmitted in any form or by any means with the prior permission in writing of Wray Castle Limited.
© Wray Castle Limited
IP Engineering Overview
ii
© Wray Castle Limited
IP Engineering Overview
IP ENGINEERING OVERVIEW
CONTENTS Section 1 Section 2 Section 3 Section 4
IP Networks Overview IP Network Services Service Provider Architectures Future Directions in IP Engineering
© Wray Castle Limited
iii
IP Engineering Overview
iv
© Wray Castle Limited
IP Engineering Overview
SECTION 1
IP NETWORKS OVERVIEW
© Wray Castle Limited
v
IP Engineering Overview
vi
© Wray Castle Limited
IP Engineering Overview
SECTION CONTENTS 1
Background to the Internet and ISPs 1.1 Internet History 1.2 Emergence of Commercial Operations 1.3 The Changing Architecture of the Public Internet 1.4 Internets, Intranets and the Internet 1.5 Service Providers (SPs)
1.1 1.1 1.3 1.3 1.5 1.5
2
The Internet Paradigm 2.1 Switching Approaches 2.2 Circuit Switching 2.3 Packet Switching 2.4 Connectionless Versus Connection-Oriented Switching 2.5 How High-Functionality IP Networks Alter The Paradigm
1.7 1.7 1.9 1.11 1.13 1.15
3
Data Link Layer Protocols 3.1 The OSI and TCP/IP Protocol Stacks 3.2 The Role of L2 Protocols in the WAN 3.3 The Types of Layer 2 Switching 3.4 ATM as an L2 Switching Protocol for IP Traffic 3.5 Introduction to MPLS 3.6 MPLS as an L2 Switching Protocol 3.7 MPLS Forwarding Plane 3.8 MPLS Control Plane
1.17 1.17 1.19 1.21 1.23 1.25 1.27 1.27 1.29
4
The IP Layer 4.1 IP Datagram Forwarding 4.2 IP Address Classes 4.3 IP Subnet Masks 4.4 Network and Host Addresses 4.5 Control of IP Addresses 4.6 Network and Host Addresses 4.7 Subnetting IP Networks 4.8 Implementation 4.9 Classless Interdomain Routing (CIDR) 4.10 CIDR Example
1.31 1.31 1.33 1.35 1.37 1.37 1.39 1.41 1.41 1.43 1.45
© Wray Castle Limited
vii
IP Engineering Overview
viii
© Wray Castle Limited
IP Engineering Overview
SECTION CONTENTS 5
The Transport Layer 5.1 Introduction 5.2 The Functions of Transmission Control Protocol (TCP) 5.3 The Functions of User Datagram Protocol (UDP)
1.47 1.47 1.49 1.51
6
The Domain Name System (DNS) 6.1 The Role of the DNS 6.2 The Overall Architecture of the DNS 6.3 DNS Operation 6.4 Zones of Authority 6.5 Name Resolution 6.6 DNS Implementation 6.7 Types of DNS Server 6.8 Querying the Domain Name System
1.53 1.53 1.55 1.57 1.57 1.59 1.61 1.63 1.65
7
The Application Layer 7.1 Hypertext Transfer Protocol (HTTP) for Web Services 7.2 Simple Mail Transfer Protocol (SMTP) E-mail 7.3 POP3 and IMAP for E-mail Services 7.4 Post Office Protocol (POP) 7.5 Internet Message Access Protocol (IMAP4)
1.67 1.67 1.69 1.71 1.71 1.71
8
Section 1 Questions
1.73
© Wray Castle Limited
ix
IP Engineering Overview
x
© Wray Castle Limited
IP Engineering Overview
SECTION OBJECTIVES At the end of this section you will be able to: • • • •
explain the evolution of public service Internet Protocol (IP) networks compare and contrast the features of traditional data networks with IP networks explain the key functions of the IP network layer and IP addressing schemes describe the key transport and application-layer protocols of public service IP networks
© Wray Castle Limited
xi
IP Engineering Overview
1
BACKGROUND TO THE INTERNET AND ISPS
1.1
Internet History
In 1969, the Advanced Research Projects Agency (ARPA) funded a research and development project to create an experimental ‘packet switching’ network. This network was called ARPANET and was built in order to study techniques for the provision of a robust, reliable, vendor-independent data communications system. As a direct result of the success of ARPANET, many of the organizations involved in its development began to use it and, in 1975, the experimental network was converted into an operational one with the responsibility for it being given to the Defense Communications Agency (DCA). During this time, the early development of the basic Transmission Control Protocol/Internet Protocol (TCP/IP) took place. The TCP/IP protocols were adopted as Military Standards (MIL STD) in 1983, and all hosts that were to connect to the ARPANET were required to convert to these protocols. At the same time, the term Internet came into common use with the division of ARPANET into two new networks. These were MILNET, the unclassified part of the Defence Data Network (DDN), and a new, smaller ARPANET. The term ‘Internet’ was thus used to refer to the entire network, which comprised MILNET and ARPANET In 1985, the National Science Foundation (NSF) became involved by creating the NSFNet, which was connected to the Internet. The original NSFNet comprised five NSF super-computer centres, yet was still smaller than ARPANET and was restricted to data rates of only 56 kbit/s. However, the creation of NSFNet was a significant milestone in the development of the Internet as it brought a new vision of how the Internet should be used. The NSF wanted every scientist and engineer in the United States of America to be connected and, as such, they created a new, faster, backbone network that connected regional and local networks. In 1990, the ARPANET formally passed out of existence. NSFNet ceased its role as the primary Internet backbone network in 1995. In 1998, the Internet Corporation for Assigned Names and Numbers (ICANN) was established to take responsibility for Internet address management.
1.1
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
1969
–
Advanced Research Projects Agency fund research – ARPANET
1975
–
Defense Communications Agency take responsibility TCP/IP development begins
– 1983
– –
TCP/IP protocols adopted as standard Internet formed – MILNET – ARPANET
1985
–
National Science Foundation create NSFNet
1990
–
ARPANET and NSFNet cease overall responsibility
1998
–
Competition introduced with the establishment of ICANN
Figure 1 Internet Development IP2300/S1/v2.1
© Wray Castle Limited
1.2
IP Engineering Overview
1.2
Emergence of Commercial Operations
The original ARPANET and the successor NFSNET both operated Acceptable Use Policies (AUP) that did not permit commercial use of the network, and restricted traffic to research, educational and government use. Under pressure to make the Internet a commercial entity, the NSF managed a process of handing over responsibility for various functions to new commercial Service Providers (SPs) through the 1990s, including the backbone networks, the interconnect points and various registry functions. This new model specifically allowed commercial exploitation of the Internet, and as a result massive growth in the number of attached hosts and traffic carried has continued. In October 1998, competition was introduced in domain name registration for the toplevel domains. The Internet Corporation for Assigned Names and Numbers (ICANN) was established as a not-for-profit business to take responsibility for Internet address management, management of the Domain Name System (DNS), management of assigned numbers and operation of the Internet root servers. It achieves this through cooperation with organizations including the InterNIC, the Internet Assigned Numbers Authority (IANA) and Regional Internet Registries (RIR) that it has accredited.
1.3
The Changing Architecture of the Public Internet
The single backbone approach of NFSNET was gradually replaced by a collection of commercial backbone providers such as Sprint and UUNet. Mergers and acquisitions in the last few years have left five major networks providing most transit within the global Internet. The number of SPs and their peering arrangements continues to grow and become more complex. The NSF interconnect points were replaced by Network Access Points (NAPs) within north America as part of the commercialization process. These provide a facility where networks can peer, managed by an independent third party. A large number of Internet eXchange Points (IXP) now operate on a commercial or cooperative basis, allowing smaller ISPs to peer on a regional basis.
1.3
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
1.7 x106
Hosts
The commercial Internet era
200 4 1980
Time
Data >1,000,000,000,000,000 Bits/Day
Figure 2 Growth of the Internet IP2300/S1/v2.1
© Wray Castle Limited
1.4
IP Engineering Overview
1.4
Internets, Intranets and the Internet
The term internet was originally used to describe the network built upon the Internet Protocol (IP). However, the term is generic and is used to describe an entire class of networks. We will use the term ‘internet’ to mean any collection of separate physical networks, interconnected by means of the IP protocol, to form a single logical network. The ‘Internet’ is the worldwide collection of interconnected networks that grew out of the original ARPANET. It uses IP to link the various networks into a single logical global network. Since TCP/IP is required for Internet connection, the growth of the Internet has spurred interest in TCP/IP. More organizations have become familiar with the protocol suite and have applied it to many other applications. The IPs are now often used for local area networking even when the Local Area Network (LAN) is not connected to the Internet. In addition, TCP/IP is also widely used in building Enterprise Networks that use Internet techniques and World Wide Web (WWW) tools to disseminate internal corporate information. These networks are referred to as ‘intranets’ and may or may not be connected to the Internet.
1.5
Service Providers (SPs)
Private organizations obtain services on the public Internet through an SP. Internet Service Providers (ISPs) offer a range of services on the public Internet to their customers, such as dial-up access, and mail and web hosting. IP Service Providers (IPSPs) offer business-class IP networks to their customers. Rather than an open model of interconnection with other networks, where very few restrictions on traffic flows are applied, these networks connect with other networks in a much more controlled way. By keeping general Internet traffic off these networks, the quality of service they can offer to their directly connected customers is improved. These networks still require connectivity to the public Internet to allow Internet e-mail and other services.
1.5
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
These connections allow Internet connectivity to IPSP customers
ISP 3
Three separate IP Service Providers
Internet
ISP 2 ISP 1
IPSP 3
IPSP 2
IPSP 1
This connection provides traditional Internet access
Network 1
Intranet
Network 2 Network 3
This connection gives the customer access to high functionality IP services
Figure 3 Intranets, ISPs and IP Service Providers IP2300/S1/v2.1
© Wray Castle Limited
1.6
IP Engineering Overview
2
THE INTERNET PARADIGM
2.1
Switching Approaches
The two main switching approaches used in public switched networks are circuit switching and packet switching. Within packet switching, the switching process can be connection-oriented, or connectionless. Connection-oriented switching provides a logical circuit from source to destination, while a connectionless approach has no concept of a circuit. We explore these different types of switching in the next few slides.
1.7
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Public Switched Networks
Circuit Switched
Packet Switched
Physical circuit from source to destination
Virtual Circuit “connection-oriented”
Datagram “connectionless”
Logical circuit from source to destination
No concept of a circuit
Figure 4 Types of Switching IP2300/S1/v2.1
© Wray Castle Limited
1.8
IP Engineering Overview
2.2
Circuit Switching
Circuit switching involves a physical circuit being established between two given terminals for a period of time. The circuit is allocated to, and maintained for, the exclusive use of the terminals concerned for the whole duration of the connection. These resources only become available for use by other terminals upon release of the connection by the initial terminals. Circuit switching has several advantages. Firstly, the end terminals/devices/users are allocated the full data carrying capability (full bandwidth) of the connection for the whole duration of the call irrespective of whether they have data to send or not. In addition, although the initial routing process (or set-up) takes a period of time to be established at the switches, further data exchange via the switches is relatively short. This is because any further data exchange does not involve the analysis of addresses; instead the data simply flows through the provided physical connection. Finally, as all data for the connection takes the same physical route, the time taken for data to be transferred between terminals is kept nearly constant for the whole duration of the call. The disadvantage of circuit switching is that the initial set-up procedure takes time, as does the final release procedure. Also, should the network fail for any reason, the connection is lost completely and a new connection would need to be created. In addition, if the end terminals have a circuit-switched connection but no data to send, the end terminals will still hold the network resources unless they release the connection. In other words, the resources cannot be used by any other devices. This final fact is a disadvantage to both the user and the network operator. From the view of terminal owners it means that they are paying for a connection even though they may have no data to send; from the network operator’s view, it means that the network may have no resources available for users waiting to use the network. The advantages and disadvantages of circuit switching are highlighted in Figure 5. Although the two parties, A and C, are not presently speaking, network resources are still allocated to them. In addition, they are paying for call time. Parties B and D are unable to communicate with one another even though at that moment no meaningful data is being sent across the network. Circuit switching is important in IP engineering because dial-up access to various data networks is normally carried across a circuit-switched connection between the user and the location in the network where the data network is available.
1.9
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
A
C
Sorry all the lines are busy
D
B
Circuit Switched Short Delay Constant Delay Single Connection Affected By Network Failure Figure 5 Circuit Switching IP2300/S1/v2.1
© Wray Castle Limited
1.10
IP Engineering Overview
2.3
Packet Switching
Packet switching involves the segmentation of users’ information into smaller blocks of data known as packets. Each packet is then fed into the network and passed from one switching point to the next until it reaches its destination. The network handles each packet separately therefore each must contain some control information to allow the forwarding process to take place at each switch. Packet switching has the advantage that each terminal to terminal exchange of data is not provided by a physical connection. Instead terminals share the network, each terminal being allocated network resources only as and when it has packets (or datagrams) to send. From the users’ point of view this is advantageous as they pay only for the data sent as opposed to time connected, i.e. users can be charged per packet as opposed to per second. From the network operator’s point of view packet switching allows all users to be given access to the network and also allows for more efficient dimensioning of the network. This final fact can lead to financial saving that can ultimately result in an even lower cost per packet for the user. In addition, as the network handles each packet separately, any failure within the network need not affect the transfer of packets itself. The network may simply route the packets via an alternative path so bypassing any failed elements. One disadvantage of packet switching is that the delay between a packet arriving at a switch and it being routed onwards may vary. This is because a packet switch may need to queue packets for sending onwards, the length of the queue varying with the number of packets involved with the onward leg.
1.11
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Packet Switched Long Delay Variable Delay Shared Resources Resilient to network failures
Figure 6 Packet Switching IP2300/S1/v2.1
© Wray Castle Limited
1.12
IP Engineering Overview
2.4
Connectionless Versus Connection-Oriented Switching
2.4.1
Connectionless Services
Within the packet-switched network, packets can be forwarded through the network switches on a packet-by-packet basis. In other words, when a packet arrives at a switch or router, it reads the address information within the packet and then forwards the packet on to an appropriate destination based on forwarding tables within the switch. Once the packet has been sent, the switch or router sending it has no further dealings with the packet. Even packets that have arrived at the switch or router from the same source are treated individually. Because of this, there is no guarantee that packets sent by a single source will take the same path through the network, thus it is possible that packets could arrive at their destination out of sequence. In other words, the forwarding device makes no association between any packets that it receives or sends. When a network operates in this manner it is said to be providing a connectionless service to the users.
2.4.2
Connection-Oriented Services
It is possible for a packet-switched network to provide what is termed a connectionoriented service to its users. When providing a connection-oriented service, information must first be passed across the network to set up a path for a user’s data. This path is termed a logical connection, virtual circuit or software-defined data path. The network then makes an association between all the packets sent from and to a specific user. This association allows the network to forward all of the packets for a specific user via the same path through the network, thus ensuring that packets arrive at the destination in the same order that they were sent. At the end of the data exchange, information is sent across the network to release the logical connection. This set-up and release of virtual circuits is analogous to setting up and releasing a physical circuit in circuit switching. Some delay is associated with these set-up and release operations. User packets cannot be forwarded until the virtual circuit has been set up. With a connection-oriented service, users appear to have their own connection through the network but it must be borne in mind that this is a logical connection only and that other users may use segments of the physical connection.
1.13
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Packet 1
Pa ck et
2
Connectionless Service (packets may arrive out of sequence)
Packet 2
Packet 1
Connection-Oriented Service (guaranteed sequenced delivery)
Figure 7 Connectionless and Connection-Oriented Services IP2300/S1/v2.1
© Wray Castle Limited
1.14
IP Engineering Overview
2.5
How High-Functionality IP Networks Alter The Paradigm
The traditional best-endeavours model of IP networks and services is unsatisfactory for most business users. These users typically expect guarantees on network performance that a conventional IP network cannot provide. As a result, many of the techniques of connection-oriented packet-switched networks have been developed as optional components of IP networks, and are widely deployed in SP networks. Two or more Classes of Service (CoS) may be offered to customers, with different guarantees on performance for each of these. Traffic policing may be applied on the customer access circuit to ensure that the contracted data rates per CoS are not exceeded. Sophisticated queuing techniques may be applied in the network routers to implement the CoS behaviour expected by customers. Policy controls and route filtering may be applied to control how traffic is carried across the network, and how it enters and leaves the network. As well as measures at the IP layer, data link layer traffic engineering may be implemented to help control how traffic is carried, and more sophisticated restoration schemes may be implemented to ensure service outages are within acceptable limits to the customer. Therefore IP networks can broadly be categorized as: • Private enterprise networks (intranets) – these only carry the traffic of the owning organization. • Public, low functionality networks – these are typically part of the Internet structure, although they need not be. They carry traffic on a best-endeavours basis, and are offered by traditional ISPs. • Public, high functionality networks – these typically connect to the public Internet as well as to customer networks, but carefully control the traffic flows, types and utilization using the techniques outlined above. These networks are offered by IPSPs.
1.15
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Customer 2 Premises Router
Core Network Router Traffic policing ensures that only the contracted traffic quantity is accepted
QoS-aware queuing in core routers selects low priority traffic to drop, and protects high priority traffic
Customer 2 Premises Router
Best endeavours queuing in core routers causes high priority traffic to be dropped when congestion occurs
Overuse by one customer leaves other customers starved of bandwidth
Contention on customer access circuit causes high priority traffic to be dropped Customer 1 Premises Router
Customer Access Router
Diffserv CoS on access circuit protects high priority traffic
Customer Access Router
Customer 1 Premises Router
Core Network Router
Figure 8 Low- and High-Functionality IP Networks IP2300/S1/v2.1
© Wray Castle Limited
1.16
IP Engineering Overview
3
DATA LINK LAYER PROTOCOLS
3.1
The OSI and TCP/IP Protocol Stacks
The OSI Seven-Layer Reference Model was developed before internetworking based upon the IP protocols became widespread. The developers of the TCP/IP suite produced a five-layer model, where the higher layers of the OSI model are collapsed into a single application layer. The TCP/IP model can be described as follows: Layer 1: Physical Layer Layer 1 deals with the physical network hardware just as Layer 1 in the OSI Seven Layer Reference Model. Layer 2: Link Layer Layer 2 protocols deal with how to organize data into frames and how a host transmits these frames over a network. Once again, these protocols are similar to the Layer 2 protocols in the OSI Seven-Layer Reference Model. Layer 3: Internet Layer Layer 3 protocols specify the format of the packets which are sent across the Internet as well as the mechanisms used to forward packets from a computer through one or more ‘routers’ to a final destination. Layer 4: Transport Layer Layer 4 protocols in the TCP/IP suite are similar to those in the OSI Seven-Layer Model in that they ensure reliable transfer of messages. Layer 5: Application Layer Layer 5 protocols in this model correspond to Layers 5, 6 and 7 in the OSI Model. These protocols specify how an application uses an internet. TCP/IP can, therefore, be looked upon as a family of protocols, each designed to solve a particular network communication problem.
1.17
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
APPLICATION LAYER
OSI Layer 5–7
TRANSPORT LAYER
OSI Layer 4
INTERNET LAYER
OSI Layer 3
LINK LAYER
OSI Layer 2
PHYSICAL LAYER
OSI Layer 1
Figure 9 The TCP/IP Protocol Suite IP2300/S1/v2.1
© Wray Castle Limited
1.18
IP Engineering Overview
3.2
The Role of L2 Protocols in the WAN
The Link Layer in an IP network operates immediately below the IP layer, and so provides services to it. Whereas the IP layer is responsible for end-to-end transport of the data between hosts across the network, the link layer is responsible for transport on individual links of the network, between hosts and routers, and between intervening routers. Link layer protocols normally operate in one of three modes: • connectionless, across a point-to-point connection • connectionless, across a shared medium • connection-oriented, across a virtual circuit-switched network
1.19
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Router
Ethernet
Router
ATM
Token Ring
IP (Layer 3) Ethernet (Layer 2)
ATM (Layer 2)
Token Ring (Layer 2)
Connectionless (point-to-point)
Connectionless (shared medium)
Connection-oriented (virtual circuit network) Figure 10 The Role of Layer 2 Protocols IP2300/S1/v2.1
© Wray Castle Limited
1.20
IP Engineering Overview
3.3
The Types of Layer 2 Switching
It is important to understand the distinction between connection-oriented and connectionless Layer 2 networks, as this affects how IP operates across them. When a traditional shared medium network such as Ethernet is partitioned using Ethernet switching, the complete network retains the ability to broadcast frames, because ‘Ethernet’ is a connectionless switching technology. The IP layer uses these broadcast frames to discover the address mapping between the IP layer and the connectionless Layer 2 addresses of hosts and interfaces. The use of switches can improve the performance of ‘Ethernet’ by reducing the number of hosts that share a particular medium. However, this is still connectionless switching, and still retains the ability to use broadcast frames across the entire switched network. Connection-oriented Layer 2 networks use virtual circuits to connect hosts. They have no ability to send packets to a destination address until the Layer 2 address of the destination is known. Therefore, conventional IP techniques for address resolution between the IP and Layer 2 addresses are not available. Although these connection-oriented Layer 2 technologies are more scalable than the connectionless approaches, the lack of broadcast makes interworking with IP networks more difficult.
1.21
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Router
Ethernet
Router
ATM
Token Ring
IP (Layer 3) Ethernet (Layer 2)
ATM (Layer 2)
Token Ring (Layer 2)
Connectionless (point-to-point)
Connectionless (shared medium)
Connection-oriented (virtual circuit network) Figure 10 (repeated) The Role of Layer 2 Protocols IP2300/S1/v2.1
© Wray Castle Limited
1.22
IP Engineering Overview
3.4
ATM as an L2 Switching Protocol for IP Traffic
ATM is a Layer 2 switching technology that is widely used in public service networks¹. The architectures of IP and ATM are quite different, with different addressing schemes, forwarding approaches and control planes. Therefore little integration between the IP layer and the ATM layer is possible. Nonetheless, ATM is widely used as a Layer 2 switching technology to carry IP traffic. Typically a set of ATM virtual circuits is established between edge routers, either through signalling, or more usually by configuration from a Network Operations Centre (NOC). Viewed from the perspective of the IP layer, these virtual circuits are simply virtual leased lines that connect adjacent routers. The IP layer has no visibility of the intervening switches. IP views the ATM protocol as just another encapsulation, similar to HDLC or PPP. In order to route traffic correctly to the other routers across the ATM Wide Area Network (WAN), each edge router must either have static routes configured which point traffic to the correct outbound virtual circuit, or else a conventional routing protocol must run across the WAN between edge routers.
¹ Instead of variable length frames, ATM uses short, fixed-length cells to transport traffic across the network, since this makes delay and delay variation smaller and more predictable. To convert various types of traffic into cell payloads, ATM requires the use of adaptation functions at the edge of the network. As well as adding any ATM-specific headers or trailers required, the ATM adaptation process segments inbound traffic into cell payloads, and reassembles the original data structures for outbound traffic. Despite this unique aspect of ATM, it can still be considered as a Layer 2 switching technology; the adaptation process is hidden from the IP layer above it.
1.23
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Router
1. Establish ATM virtual circuit between pairs of routers 2. Routers are adjacent at the IP layer, see ATM network as a virtual leased line
IP
IP
Ether
ATM
ATM
ATM
Phys
Phys
Phys Phys
Phys Phys
ATM Phys
Ether Phys
Figure 11 Simple IP Over ATM IP2300/S1/v2.1
© Wray Castle Limited
1.24
IP Engineering Overview
3.5
Introduction to MPLS
Traditionally, switches have offered greater performance than routers in terms of the speed at which data can be forwarded. However, routers can be configured to make more sophisticated decisions about the processing of datagrams. As well as forwarding a packet based upon destination IP address, a router can also classify packets based upon other header fields, including source address and TCP port numbers. This leads to the argument, why not build a device that combines fast forwarding across the core of a network, based upon classification of packets carried out at the edge of the network? While this is essentially what an IP over ATM approach achieves, the key innovation of the MPLS approach was the use of traditional IP routing protocols to determine how these switched paths should be set up. For the first time in MPLS, a switching model closely coupled to the IP layer it was intended to support was available. The argument leads to the idea of Label Switching Routers (LSR), devices that integrate the best of both routing and switching. Whereas traditional Layer 2 switching was not integrated with the IP layer, MPLS is closely coupled to the routing and addressing schemes of the IP layer.
1.25
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Router
Switch
Sophisticated Routing Layer 3
Fast Switching Layer 2
V Connectionless
Connection-Oriented
MPLS
LSR Integration of Routing and Switching
Figure 12 MPLS Combines Routing and Switching IP2300/S1/v2.1
© Wray Castle Limited
1.26
IP Engineering Overview
3.6
MPLS as an L2 Switching Protocol
There are many similarities between the switching and forwarding operations of LSRs and the switching and forwarding of traditional Layer 2 switching technologies, such as Frame Relay and ATM. MPLS introduces some new terminology for Layer 2 switching: • a Label Switching Router (LSR) is an MPLS Layer 2 switch • a Label Switched Path (LSP) is an end-to-end MPLS virtual connection • an edge-LSR is a special LSR that originates or terminates LSPs, and can classify IP traffic for forwarding across the best LSP • a Forwarding Equivalence Class (FEC) is a grouping of IP addresses that are treated identically by the LSRs, and are forwarded along a common LSP
3.7
MPLS Forwarding Plane
The MPLS forwarding plane can operate on individual packets arriving at an edgeLSR once an appropriate LSP has been set up. When a packet arrives at the ingress edge-LSR, this router determines the outgoing port and FEC. On the assumption that LSPs have been set up, the edge-LSR will be able to identify the label to be used for the ongoing port and FEC. The edge-LSR appends this label to the received packet and passes this out over the designated port. The LSR receiving the MPLS packet on a given port will look up the incoming port and label entry within its Label Information Base (LIB). This will produce an outgoing port and label result. The incoming MPLS packet will then have its label swapped for the new label and is then passed out over the outgoing port (with this new label). The LSR within the MPLS network (as opposed to the edge-LSR) therefore need operate at Layer 2 only. All LSRs within the MPLS network operate in this manner until the packet arrives at the egress LSR. At the egress LSR, the MPLS label is removed, the packet is passed to Layer 3, and is then routed in the normal router manner. In essence, MPLS allows Layer 3 processing to be pushed to the edge of the MPLS network.
1.27
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Downstream IP Packet
MPLS Network
Header A
M
IP Packet
S PL
Pa
La
Labe lC
cket MPL
S Pa
Performs Label Swapping
Upstream
IP
MPLS Packet
et ck
Label B
lA be
Header A
IP
LSR
edge-LSR
edge-LSRs LSRs
Both operate at L2 and L3
Figure 13 MPLS Forwarding of Packets IP2300/S1/v2.1
© Wray Castle Limited
1.28
IP Engineering Overview
3.8
MPLS Control Plane
ATM and Frame Relay use a development of traditional ISDN signalling protocols to set up, tear down and manage virtual circuits. This is known as a data driven approach. MPLS generalizes this approach, and allows LSPs to be set up in several different ways: • by extensions to traditional IP routing protocols such as Border Gateway Protocol (BGP) • by a specialized IP signalling protocol, Resource Reservation Protocol (RSVP) • by a dedicated label distribution protocol operating between LSRs, Label Distribution Protocol (LDP) However the LSPs are set up, once they are in place, the forwarding and switching operations carried out by LSRs are identical.
1.29
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
1. Extensions to BGP protocol carry LSP information between LSRs
MPLS Network
2. RSVP protocol used to signal the set-up of LSP, as required by data flows 3. LDP protocol distributes LSP information between adjacent LSRs IP Packet
LSR
edge-LSR
edge-LSRs LSRs
Both operate at L2 and L3
Figure 14 MPLS Control Plane Options IP2300/S1/v2.1
© Wray Castle Limited
1.30
IP Engineering Overview
4
THE IP LAYER
4.1
IP Datagram Forwarding
Because IP networks operate a connectionless forwarding model, the routers hold no information about the flow of packets; the routing decision is made independently for each packet arriving at each router along its path. The router makes this decision by comparing the destination address of an incoming packet with the entries already held in its routing table. The most specific match in the routing table to the destination address is used to find the next hop for this packet. We can see from Figure 15 that the routing table contains three parameters: a Destination field, which contains network addresses, an Address Mask that specifies which bits of the destination correspond to the network ID, and finally a Next Hop field, which contains the IP address of the router if required. For example, if we consider a datagram designed for address 192.4.10.3 and assume the datagram arrives at router 2, which contains the routing table shown in Figure 16, the router software will sequentially search the routing table.
1.31
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
30.0.0.0
40.0.0.7
Router 30.0.0.7 #1 40.0.0.0 128.1.0.8 40.0.0.8
Router #2
128.1.0.0 192.4.10.9
192.4.10.0
Router 128.1.0.9 #3
192.4.10.3
Destination 30.0.0.0 40.0.0.0 128.1.0.0 192.4.10.0
Next Hop 40.0.0.7 Direct Direct 128.1.0.9
Simplified Routing Table For Router #2
Figure 15 IP Datagram Forwarding IP2300/S1/v2.1
© Wray Castle Limited
1.32
IP Engineering Overview
4.2
IP Address Classes
The problem with using an IP Address containing network IDs and host IDs is deciding how big to make each field. If the network ID field is too small (limited permutations), only a few networks will be able to be connected to the Internet and still ensure that each has a unique address; yet should the network ID field be increased, then the host ID will have to be reduced and only a few computers will be able to be connected to a particular network with a given network ID. As an internet is likely to include various types of network technologies, one given structure of an IP Address is not appropriate. The developers of IP therefore chose a compromise in the IP addressing scheme that is able to accommodate both large and small networks. This scheme divides the IP Address (32 bits) into three primary classes where each class has a different-size network ID and host ID. The first four bits of an IP Address determine which class the address belongs to, and how much of the remainder of the 32 bits have been divided into network and host addresses. Although IP Addresses are 32 bits in length, they are seldom represented in binary format but instead use a dotted decimal notation. This method of representation takes the four 8-bit sections (octets) and represents each as a decimal number. The ‘.’ sign is used to separate each of the four decimal numbers. For example, the 32-bit binary code: 10000100
00110000
00000110
00000000
has the dotted decimal notation: 132.48.6.0 Since each octet can have a maximum decimal value of 255, IP addresses can range from: 0.0.0.0 to 255.255.255.255
1.33
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
32 bits Network ID
Class B
Example
Host ID
A .
B
.
C
.
D
132 .
48
.
6
.
0
Class A Network ID
Host ID
0
Class B Network ID
Host ID
1 0
Class C Network ID
Host ID
11 0
Class D Multicast 11 1 0
Class E Experimental 1 11 1
Figure 16 IP Address Classes IP2300/S1/v2.1
© Wray Castle Limited
1.34
IP Engineering Overview
4.3
IP Subnet Masks
A subnet mask is applied to the IP address to determine which part of the 32-bit address makes up the network address, and which part constitutes the host address. Figure 17a shows the default subnet masks for Class A, B and C networks, and Figure 17b shows how it is applied to a Class B network. When sending packets, a host or router needs to determine if the IP address of the destination host is on the local or a remote network. When TCP/IP initializes, the host’s IP address is ANDed with its subnet mask, and the result stored. When sending data to another host the destination IP address is also ANDed with the local host’s subnet mask. If the resulting values match (see Figure 17c), the destination host is on the local network; if not, the datagram is sent to the source host’s default router.
1.35
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Default Subnet Masks Address Class
Bits used for Subnet Mask
Class A
11111111
Class B
11111111
11111111
Class C
11111111
11111111
Dotted Decimal Notation
00000000 00000000 00000000
255.0.0.0
00000000 00000000 11111111
255.255.0.0
00000000
255.255.255.0
Figure 17a Example of a Class B Subnet Mask
IP Address
132
.
48
.
6
.
0
Subnet Mask
255
.
255
.
0
.
0
Network ID
132
.
48
.
x
.
x
Host ID
x
.
x
.
6
.
0
Figure 17b Determination of a Packet’s Destination
Destination Hosts IP Address is ANDed with local Subnet Mask • 1 AND 1=1 • Other Combinations = 0 • If ANDed results of source and destination hosts match, the destination is local. IP Address Subnet Mask Result
10000100
00110000
00000110
00000000
11111111
11111111
00000000
00000000
10000100
00110000
00000000
00000000
132
•
48
•
0
•
0
Figure 17c IP Subnet Masks and Determination of a Packet’s Destination IP2300/S1/v2.1
© Wray Castle Limited
1.36
IP Engineering Overview
4.4
Network and Host Addresses
Relating the dotted decimal notation method to the different classes of IP address, we can see that first octet will carry the information necessary to determine the IP class of the host. The IP class scheme does not divide the 32-bit address space into equal size classes and these classes do not contain equal numbers of networks. For example, half of all IP addresses lie within Class A, as this class is represented by a zero in the first bit position. Therefore, since Class A addresses only have eight bits to represent the network ID and one of these is used to indicate this is an A class address, there only remain seven bits to indicate the network. In other words, a Class A address can only account for a maximum of 128 different networks. However, the host ID in a Class A address is made up of 24 bits, which allows up to 16,777,216 computers to be connected to each of the 128 networks.
4.5
Control of IP Addresses
As we have already determined, each network ID must be unique and as such all networks connecting to the global Internet must have their own unique network address. Therefore, if an organization wishes to connect its network to the Internet, it must obtain a network address from an ISP. The ISPs obtain network numbers through a system of approved Internet registries, who ensure that numbers are globally unique. In the case of a private internet (intranet), the choice of the IP Address can be made by the organization, although no two computers may have the same address. It is difficult and time-consuming to renumber a large IP network, and historically problems have occurred when private IP networks have subsequently connected to the public Internet, and found that address conflicts occurred. For this reason, a group of class A, B and C addresses were reserved for private use in RCF 1918, and organizations often use these addresses for private IP networks, whether connected to the public Internet or not.
1.37
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Class
Range of Values
A B C D E
0 – 127 128 – 191 192 – 223 224 – 239 240 – 255
Figure 18a IP Address Classes and Dotted Decimal Notation
Address Class
Bits in Prefix
Maximum number of Networks
Bits in Suffix
Maximum number of Hosts per Network
A B C
8 16 24
126 16382 2097150
24 16 8
16777214 65534 254
Figure 18b Network/Host Numbers IP2300/S1/v2.1
© Wray Castle Limited
1.38
IP Engineering Overview
4.6
Network and Host Addresses
In summary, when assigning a network ID, a number must be selected from either Class A, B or C depending upon the size of the physical network. In real terms, a network will be assigned a Class C address ((256 – 2) hosts per network) unless a Class B is needed ((65,536 – 2) hosts). Class A addresses are seldom assigned. Figure 19 shows a possible configuration when connecting four networks together; a small network (Class C), two medium size networks (Class B), and one large network (Class A). Thus, the four networks may have the following IP Addresses: Class A
11.0.0.0
Class B
128.270.0 145.56.0.0
Class C
195.34.127.0
Note: IP reserves the host address set to zero and uses it to denote the network address. Likewise the all 1s host address is used for broadcasts to all hosts. These addresses cannot be assigned to any host on that particular network. As we can see, all host computers connected to each network carry the same network ID. However, the host ID will be different for each of the hosts connected to that network.
1.39
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
128.27.0.18
195.34.127.13
router 195.34.127.48
Prefix =128.27
‘C’
‘B’
Prefix = 195.34.127
128.27.0.19
145.56.74.118
‘A’ ‘B’ Prefix = 10 Prefix = 145.56
10.18.74.15 145.56.19.4
10.0.127.16
Figure 19 Example Network with IP Addressing IP2300/S1/v2.1
© Wray Castle Limited
1.40
IP Engineering Overview
4.7
Subnetting IP Networks
The traditional boundaries of class A, B and C networks are too inflexible in many real networking situations. An organization might have, for example, a class B network that it wants to partition to allow separate administration of the subnetworks, or to impose policy controls on which traffic can flow between subnets. This partitioning is done by subnetting the original address space. A unique subnet ID is derived for each segment by partitioning the bits in the host ID into two parts. One part is used to identify the segment as a unique network, and the other part is used to identify the hosts. The total number of networks bits in the address is the sum of the original network part and the subnet part. It is indicated by a value given after the address. So, for example, the private class C address 192.168.1.0/24 might be subnetted by using an additional five host bits to create a set of smaller subnets from the original space, each of the form 192.168.1.x/29. Some implementations disallow the lowest and highest valued subnet, because they contain the original network address and broadcast address of the classful network. In this case the total available subnets are reduced by two. It is important to note that this subnet structure does not propagate beyond the local network boundary. Therefore as traffic enters the public Internet from such a subnetted structure, all of the subnets are summarized into a single, class-based routing announcement.
4.8
Implementation
Before subnetting is implemented, the current and future requirements of the network need to be considered. This should include the number of physical segments that will be required and the number of hosts on each segment. (It should be noted that hosts include routers). Based on requirements, if possible one subnet mask should be defined for the entire network, with a unique subnet ID for each segment and a range of host IDs for each subnet. When more bits are used for the subnet mask, more subnets are available, but fewer host addresses are available per subnet. A balance has to be reached between leaving room for the network to grow, and allowing sufficient hosts on each subnet. In some cases, the number of hosts required on each subnet is uneven. A particular subnet may need perhaps 100 host addresses, while a WAN link may require only two addresses. In this case, Variable Length Subnet Masks (VLSM) can be used to partition the available space efficiently.
1.41
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
/29
8.0.8 6 1 . 192
192.168.0.16/29
192.168.0.0/24
192. 168. 0
.24/2
9
Traditional Class C address has: 28 – 2 host addresses X.X.X.0
= network address
X . X . X . 255 = broadcast address X.X.X.1 = host address space X . X . X . 254
Subnetting on /29 boundary X . X . X . nnnnnhhh Each subnetwork has: 23 – 2 host addresses = 6 host addresses Total number of subnets is: 25 – 2 = 30 subnets Figure 20 An Example of IP Subnetting IP2300/S1/v2.1
© Wray Castle Limited
1.42
IP Engineering Overview
4.9
Classless Interdomain Routing (CIDR)
Subnetting allows more efficient use of a traditional class-based IP network within an organization, by allowing it to be subdivided. However traditional subnetting does not propagate through the Internet routing tables, because routes are summarized back to their classful form at the administrative boundary of the network. Therefore Internet routing tables in this model must contain separate routes for each assigned class A, B or C address. In the mid-1990s, the size of Internet routing tables was growing massively, to the point where performance of the backbone networks was affected. It was realized that much of the fine-grained detail in Internet routing tables was redundant, and that a more flexible hierarchy should be imposed, by allowing routes for smaller networks to be aggregated together before they were advertised into the public Internet. This also allows more efficient use of available IP addresses by allocating blocks of class C addresses rather than a single class B, and by subnetting class A and B networks into smaller allocations, rather than offering an entire classful network to an enterprise. CIDR is essentially a generalization of the subnetting concept². To make CIDR effective, it was necessary to impose some geographical structure on the IP address space, so that aggregation could be as effective as possible. As a result of a policy change, IP addresses are now assigned in blocks through a hierarchy of SPs. In general, large blocks of IP addresses are allocated to regional registries, which will in turn assign smaller blocks of address space to SP, which will in turn assign yet smaller blocks to ISP. Finally, individual users will rent IP addresses from their respective ISP.
² CIDR allows larger networks to be subdivided, and smaller networks to be aggregated together into a single routing table entry, in a flexible way, by using VLSM. By carrying these VLSM values in routing protocol updates, and within routing tables, it allows the VLSM structure to propagate across the Internet between domains, instead of reverting to classful networks at the boundaries, according to the original subnetting model.
1.43
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Block A
Block B
A
IANA and IR
B
Sub Blocks of B
Sub Blocks of A
Major ISP
Smaller ISP
Smaller ISP
Users Leased IP Addresses
Area
Address
Multiregional Europe Others North America Central/South America Pacific Rim Others Others
192.0.0.0-193.255.255.225 194.0.0.0-195.255.255.225 196.0.0.0-197.255.255.225 198.0.0.0-199.255.255.225 200.0.0.0-201.255.255.225 202.0.0.0-203.255.255.225 204.0.0.0-205.255.255.225 206.0.0.0-207.255.255.225
Reference
RFC 1518
Figure 21 IP Address Blocks IP2300/S1/v2.1
© Wray Castle Limited
1.44
IP Engineering Overview
4.10
CIDR Example
A common use of both subnetting and CIDR occurs where an SP wants to offer a few public network IP addresses to a small business network, for example as part of a business ADSL offering, where the customer may host some servers at their premises. In the example shown in Figure 22, the SP has subnetted a class C address into 30 subnets, each with 6 host addresses, by subnetting at the /29 boundary. The detail of one such subnet is shown, where the subscriber has 5 host addresses available, in addition to the IP address needed for the ADSL router on the customer premises. In total 120 customer subnets are available from the 4 class C addresses shown. Within the SP network, rather than advertise the individual class C addresses, instead it aggregates 4 networks into a new /22 route advertisement, and passes this into the Internet routing tables. In this example, traffic for all of the customer networks shown would be represented by a common /22 routing entry within the Internet until it reached the SP network. Individual /24 routing table entries in router A would direct it to the correct customer access router, in our example router B. Router B would then direct traffic to the correct customer network using /29 entries in its routing table.
1.45
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Routers
CIDR route aggregation at this layer, beyond the conventional Class C boundary
0/ .3.
24
8 .16 2 19 24 2.0/ . 8 6 1 192.
RA
192.168.1.0/24
192.168.0.0/22
Routers
Routed on /22 /24 .0.0 .168 /24 192 on ted Rou
RB
32 .0.
/29
4 .16 8 19 /29 0.24 . 4 6 1 198.
198.164.0.16/29 Routed on /29
8 19
.18
64 .1
.20 .19
.0 .8
.22 .21
/2 9
Route summarization up to conventional Class C boundary at this layer
.17
Figure 22 An Example of CIDR IP2300/S1/v2.1
© Wray Castle Limited
1.46
IP Engineering Overview
5
THE TRANSPORT LAYER
5.1
Introduction
The transport layer of the TCP/IP Protocol Suite comprises two protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Fundamentally, the services offered by TCP are reliable and connection-oriented, whereas UDP provides a best efforts, connectionless service.
1.47
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
APPLICATION LAYER OSI Layer 5–7
Transmission Control Protocol
Internet Control Messaging Protocol
Internet Protocol
User Datagram Protocol
Address Resolution Protocol
TRANSPORT LAYER OSI Layer 4
INTERNET LAYER OSI Layer 3
Link Layer Protocols
LINK LAYER OSI Layer 2
Physical Networks
PHYSICAL LAYER OSI Layer 1
Figure 23 TCP/IP Suite IP2300/S1/v2.1
© Wray Castle Limited
1.48
IP Engineering Overview
5.2
The Functions of Transmission Control Protocol (TCP)
The Transmission Control Protocol (TCP) provides a highly reliable transport service. Applications such as FTP and HTTP that require reliable transport services use the TCP protocol. TCP offers several key features as shown below.
5.2.1
Connection-Oriented
TCP provides a connection-oriented service in which an application must first establish a connection to the destination before any data is transferred. TCP requires that both applications creating a connection agree to the new connection.
5.2.2
Error Control
TCP ensures that data sent across a connection is error free and in the correct sequence. It does this by including sequence numbers within the protocol header, and requesting retransmission of lost or corrupted packets.
5.2.3
Flow Control
TCP measures the throughput of traffic between TCP applications, and tries to maximise the bandwidth available. When packets are lost in transit, TCP assumes this is due to congestion, and slows down its transmission rate. When packets are arriving successfully, TCP assumes more bandwidth is available, and increases its transmission rate. In this way, TCP is always trying to get the maximum available bandwidth from the network.
5.2.4
TCP Port Addressing
Within an IP network, data is routed according to its IP address, with no distinction made regarding the user or process on the destination host. The Transport Layer extends the TCP/IP protocol suit to distinguish between applications on a given host. These ports are known as ‘Protocol Ports’ and can be addressed using the 16 bits in the Source and Destination Port address fields. These 16 bits can describe 65,536 possible ports on the host.
1.49
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Connection-oriented Error control Flow control Source and destination ports
7 0 1 2 3
6
5
4
3
2
1
0
- bits
Source Port Destination Port
4 5
Sequence Number
6 7 8 9
Acknowledgement Number
10 11 12
Data Offset
Reserved
13
Reserved URG ACK
PSH RST SYN FIN
14 15 Octets
Window
16 17 18
Checksum Urgent Pointer
19 20 21
Options (Optional)
22 23
Padding
Figure 24 TCP Functions IP2300/S1/v2.1
© Wray Castle Limited
1.50
IP Engineering Overview
5.3
The Functions of User Datagram Protocol (UDP)
User Datagram Protocol (UDP) provides Application Layer Services with a transaction-oriented, datagram-type service that is connectionless and unreliable. It is a simple and efficient protocol that is stateless, and so ideal for such applications as Trivial File Transfer Protocol (TFTP), Simple Network Management Protocol (SNMP) and queries to the Domain Name System (DNS). The UDP protocol is extremely simple, and this is reflected in the protocol fields of UDP. As for TCP, the UDP protocol carries source and destination port values, so that traffic can be directed to the correct applications on machines running multiple simultaneous sessions. The Checksum field allows corrupted data to be detected and (silently) discarded, but UDP does not have the error recovery mechanisms of TCP. Responsibility for error recover lies with the higher layer protocol that is using the UDP service in this case.
1.51
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Connectionless No error control No flow control Source and destination ports
Bits 7 Octets
6
5
4
3
2
1
0
0 Source Port 1 2 Destination Port 3 4 Message Length 5 6 Checksum 7
Figure 25 UDP Functions IP2300/S1/v2.1
© Wray Castle Limited
1.52
IP Engineering Overview
6
THE DOMAIN NAME SYSTEM (DNS)
6.1
The Role of the DNS
To a human, identifying hosts on a network by their IP address is not easy. IP addresses are difficult to remember and do not convey any meaning about the respective host. Humans find it far easier to remember names, and if the name indicates the role of the host, it can also be used to convey meaning. In the 1980s there were only a few hundred hosts on the ARPANET. The computer name-to-IP mapping was held in a single file called Hosts.txt on a server at the Stamford Research Institute Network Information Centre (SRI-NIC). This was manually updated. If details of a host changed, the SRI-NIC was called and asked to change the file. As the network grew this system became too difficult to administer. DNS was designed as a distributed database using a hierarchical name structure to overcome this problem.
1.53
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Root
Domain
Sub-Domain
Domain
Sub-Domain
Domain
Sub-Domain
Figure 26 Domain Name System (DNS) IP2300/S1/v2.1
© Wray Castle Limited
1.54
IP Engineering Overview
6.2
The Overall Architecture of the DNS
The root domain of the Internet is represented by a single period (.), and the Internet Corporation for Assigned Numbers (ICANN) manages the operation of the root servers that resolve for all domains beneath the root. Beneath this root are the Top Level Domains (TLDs) that may be global or contain a country code (ccTLDs). Some examples of these domains, and their intended use, is given in Figure 27, and described below: com Commercial organizations such as: America OnLine (aol.com), British Telecom (bt.com) and Wray Castle (wraycastle.com) edu Educational institutions (namely colleges and universities in USA) net Networking organizations such as the central network concerning the Internet, i.e. InterNIC (Internet Network Information Centre) – internic.net org Non-commercial organizations such as the Internet Engineering Task Force (IETF) at ietf.org Recently some new TLDs have been created, including the .biz TLD, which is intended to be broadly equivalent to the popular .com domain. As might be expected, the Internet namespace is extremely inefficient, with even very small businesses wanting a second level domain. Overall control of the Domain Name System is within ICANN. The central IR is held on INTERNIC.NET, which is in North America and is responsible for networks in this area and other unspecified parts of the world. Europe and Asia-Pacific are two specified areas and as such have their own registries. These are RIPE NCC (or ripe.net) and APNIC (or apnic.net) respectively.
1.55
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
root
.biz
.com
wraycastle.com
.edu
.net
.org
telecoms-engineering.net
.uk
.co.uk
.ac.uk
wraycastle.co.uk
Figure 27 The Hierarchy of the Internet DNS IP2300/S1/v2.1
© Wray Castle Limited
1.56
IP Engineering Overview
6.3
DNS Operation
The DNS is a client/server-distributed database management system. The client is known as the ‘Resolver’. It passes name requests that contain queries to a server known as the ‘Name Server’. These name servers are grouped into logical levels known as ‘Domains’. DNS is analogous to a telephone book. You look up the name of the person you want to call, and read across to get the telephone number. Using DNS, the resolver passes the name to the name server who runs a query on the database to return the IP address. The host name queried must be in the form of a Fully Qualified Domain Name (FQDN).
6.4
Zones of Authority
The implementation of the DNS uses the concept of Zones of Authority to make administration of the hierarchy easier. The zone of authority is the portion of the domain for which a particular primary name server is responsible. It stores all mappings for the zone and answers queries for those names. The name server’s zone of authority covers at least one domain, known as the zone root domain. The zone of authority may also cover sub-domains. The zone does not necessarily cover all the sub-domains under the root domain, but the zone must be contiguous. So in the example shown, the zone one database does not contain name-to-IP address mapping for machines in the sales domain, although the sales domain is a sub-domain of the wraycastle domain. A single DNS server can be configured to manage one or more multiple zone files.
1.57
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
.com
wraycastle.com
zone 1 database
zone 2 database
development.wraycastle.com
sales.wraycastle.com
Figure 28 DNS Zones of Authority IP2300/S1/v2.1
© Wray Castle Limited
1.58
IP Engineering Overview
6.5
Name Resolution
The operation of a DNS query to resolve the IP address of a web server within an example domain, ‘wraycastle.com’, is shown in Figure 29. 1
The client sends a query to its local name server, requesting the IP address of www.wraycastle.com.
2
The local name server checks its zone for the name www.wraycastle.com. It then sends an iterative query for this name to the root server.
3
The root server has authority for the root domain and will reply with the IP address of the .com top-level domain. It returns this to the local server.
4
The local server sends an iterative query to the .com name server for www.wraycastle.com. The name server responds with the IP address of the wraycastle.com name server.
5
The local server sends an iterative query to the wraycastle.com name server for the full address. The wraycastle.com server sends the IP address of www.wraycastle.com back to the local server.
6
The local server sends the IP address for www.wraycastle.com back to the original resolver.
1.59
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
2.
se me na
re
fer
.com name server
3.
req
ue s
ta
dd
to .
res
co
m
sw
ww .w ray ca
stl
rv er
e.c om
root name server
4. reque
Local name server
refe
st addre
am e.com n l t s a c y r to wra
5. r e qu est
RE
SP
ON S
E=
6. Answer: The IP address of www.wraycastle.com is 217.199.161.3
1. Query: what is the IP address of www.wraycastle.com
.c raycastle w . w w w ss
add
add
res s
res
ww
so
r e serve
w.w ray c as
fw
ww .wr
om
tle.
wraycastle.com name server
com
ayc as
tle.
com
host local host www.wraycastle.com Figure 29 Name Resolution IP2300/S1/v2.1
© Wray Castle Limited
1.60
IP Engineering Overview
6.6
DNS Implementation
6.6.1
DNS Data Structure
The commonest use of the DNS is to map from a Fully Qualified Domain Name (FQDN) to the corresponding IP address of the host, or vica versa, as shown in the previous diagram. In fact each entry in the DNS can have a large number of properties associated with it. Each property is stored as a set of four parameters: • the Type field indicates which parameter is stored • the Class field indicates the protocol family • the Time To Live (TTL) field indicates for how long the data may be cashed by a resolver or other cache before a fresh request should be made to the definitive source of the data • the Data field holds the actual parameter value Most records of interest are of class IN, for Internet. The data field might be an IP address, or a FQDN, or other field, depending upon the type of parameter being stored.
6.6.2
Commonly Used DNS Entries
Figure 30 shows a few of the key parameters commonly accessed in the DNS, together with how these might be used in forwarding an e-mail. In this example, an organization has its own domain name, but uses a commercial hosting service for its e-mail and web presence. • the A fields gives the IPv4 address of a host named • the MX fields gives the FQDN of a Mail eXchange (i.e. a mail forwarder or server) • the CNAME field gives the canonical name matching an alias, in other words the actual definitive name for a host • the TXT field gives freeform text related to the host, for example its type or location Another key entry in the DNS is the Start of Authority (SOA) record. The SOA gives various times and sequence numbers that are important to control for how long any downstream server caches the information it obtains from a zone transfer.
1.61
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
> dig -t MX wraycastle.com wraycastle.com wraycastle.com
43049 43049 . . . . 172616 172616
wraycastle.com wraycastle.com
IN MX 10 wray-ltd.demon.co.uk IN MX 20 etrn.magic-moments.com
IN NS IN NS
NS0.magic-moments.com 34155 IN A NS1.magic-moments.com 25665 IN A
Time to Live (TTL) in seconds
Class
A: MX: CNAME: TXT: NS:
NS0.magic-moments.com NS1.magic-moments.com
217.199.161.27 212.67.202.220
Type
Data
IPv4 address Mail eXchanger Canonical Name Free-form textual information Name server
Figure 30 Data Structures Within the DNS IP2300/S1/v2.1
© Wray Castle Limited
1.62
IP Engineering Overview
6.7
Types of DNS Server
6.7.1
Primary Name Server
Each domain must have a primary domain server. It is the administrative point for the control and configuration of the domain. This is where hosts are added and zones are maintained.
6.7.2
Secondary Name Server
Secondary name servers obtain their data from the primary server, which has authority for the zone. This transfer of data is called a zone transfer. Secondary servers give redundancy, faster access at remote locations, can avoid resolving across slow links, and allow load sharing across multiple servers. The primary and secondary server definition is set at zone level, hence a secondary server in one zone may be a primary server in another. Information for each zone is stored in a separate file on the server.
6.7.3
Caching Servers/Forwarders
Cache servers are often used to conduct queries for resolvers (clients) and cache the results; they have no authority for zone databases. If the cache does not hold the requested DNS information already, it performs a recursive query to obtain it, and then caches the result. Most ISPs operate caching servers, and implemented properly they can substantially speed up the operation of the DNS. Forwarders are normally caches that hold no DNS data, and so must forward all requests they receive.
1.63
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
Primary name server moves, changes, updates
zone transfer
DNS requests
Secondary name server
Caching name server
DNS requests
Forwarder DNS requests
Resolver
Figure 31 Types of DNS Server IP2300/S1/v2.1
© Wray Castle Limited
1.64
IP Engineering Overview
6.8
Querying the Domain Name System
Details of the primary and one secondary name server are required when a domain is registered, and the names and addresses of the name servers are one of the fields returned by a basic ‘whois’ query against a domain. Other tools that are standard on Unix systems allow interactive querying of the DNS, including the host command, the dig command, and nslookup command. Many web sites provide web-based access to these tools.
1.65
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
whois wraycastle.com . . Name Server ........................ NS1.MAGIC-MOMENTS.COM Name Server ........................ NS0.MAGIC-MOMENTS.COM host -t ns wraycastle.com. wraycastle.com NS ns1.magic-moments.com wraycastle.com NS ns0.magic-moments.com host -t mx wraycastle.com. wraycastle.com mail is handled (pri=10) by wray-ltd.demon.co.uk wraycastle.com mail is handled (pri=20) by etrn.magic-moments.com dig @ wraycastle.com. axfr will return all DNS entries for the host through a zone transfer, if the name server permits it
Figure 32 Tools to Query the DNS IP2300/S1/v2.1
© Wray Castle Limited
1.66
IP Engineering Overview
7
THE APPLICATION LAYER
7.1
Hypertext Transfer Protocol (HTTP) for Web Services
Hypertext Transfer Protocol (HTTP) is specified in IETF RFC 2616. It is a generic, stateless, object-oriented protocol that can be used for many tasks. HTTP has been in use by the WWW global information initiative since 1990. This first version, known as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0 refined the earlier version by the introduction of MIME-like messages. These Multipurpose Internet Mail Extensions (MIME) messages contained meta-information about the data transferred and modifiers on the request/response semantics. The current version, HTTP/1.1 (RFC 2616) provides persistent connections, so that multiple requests and responses can be carried across a single connection, rather than requiring a new connection for each protocol exchange. It also supports a negotiation on compression of data. Both of these changes improve the efficiency and responsiveness of the protocol. HTTP is best described as a request/response protocol. A client, normally a web browser application, sends a request to the server in the form of a request method, URI (Uniform Resource Identifier) and protocol version, followed by a MIME-like message containing request modifiers, client information, and possibly content. The server runs a process or daemon which listens for HTTP requests, and responds to the client with a status line, including the message’s protocol version and a success or error code, followed by a MIME-like message containing server information, entity meta-information, and possibly entity-body content. The status codes returned by the server are grouped into major categories as follows: • Informational
1xx
• Success
2xx
• Redirection
3xx
• Client Error
4xx
• Server Errors
5xx
The ISP browser software will provide the User Agent (UA) HTTP communication between itself and the resource located on some (HTTP) Origin Server (OS), the OS being the device containing the requested resource(s). The simplest type of connection is direct between the user and the OS, as shown in Figure 33. Other forms of connection are those of the UA to OS with a number of other network devices in between. These will be proxies, gateways, or tunnelling servers.
1.67
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
a) User Agent to Origin Server – Direct Connection Origin Server IP resU single connection User Agent HTTP
Resources Database
b) User Agent to Origin Server – via Proxy Server Server acting as proxy
Origin Server
IP resU connection
connection
User Agent HTTP
HTTP
HTTP Transfer
Resources Database
Figure 33 HTTP Connections IP2300/S1/v2.1
© Wray Castle Limited
1.68
IP Engineering Overview
7.2
Simple Mail Transfer Protocol (SMTP) E-mail
Internet mail is based on RFC 821, which defines the Simple Mail Transfer Protocol (SMTP), and RFC 822, which defines the format of Internet Text Messages. A further set of RFCs, RFC 2045-2049 inclusive, defines the MIME, which are extensions to the standard text messages found in RFC 822. These extensions allow the inclusion of multimedia information within the e-mail. SMTP was originally designed for use on Unix machines that were permanently connected to each other. Individual users of these machines have a mailbox to which messages can be delivered, whether they are logged in or not. In the SMTP architecture, mail users interact with a Mail User Agent (MUA), which in turn queues their messages for transport between machines by Message Transfer Agents (MTA). The MUA provides the interface to the user, as well as presenting views of various mailboxes, etc. The MTAs communicate with each other across a TCP connection using SMTP messages. Mail for users is received from an MTA by a Mail Delivery Agent (MDA), which places the mail in the appropriate mailbox. SMTP is a very simple command/response protocol. Five commands are used in this example to send mail between the MTAs. • HELO is used to establish the SMTP connection, • MAIL is used to identify the sender of an outbound e-mail • RCPT is used to identify the recipient of an outbound e-mail • DATA is used to begin sending the message body • QUIT is used to close the SMTP connection There are additional SMTP commands, including RSET, to abort the current connection, and TURN, to allow client and server to swap roles without having to start a new TCP connection.
1.69
© Wray Castle Limited
IP2300/S1/v2.1
IP Engineering Overview
SMTP MTA (Client)
SMTP MTA (Server) TCP connection to port 25
Mailboxes
e.com 220 mailser ver.acm HELO mailser ver.w raycastle.com
250 mailser ver.acm
e.com
MAIL FROM:
raycastle.com> 250 whois wraycastle.com . . . name server ....... ns1.myISP.com
www.wraycastle.com IN A 192.168.1.1 www.company.co.uk IN A 192.168.1.2 IN A 192.168.1.3 www.ISP.org
Figure 22 Dedicated Hardware or Co-location Hosting IP2300/S2/v2.1
© Wray Castle Limited
2.46
IP Engineering Overview
3.6
Web Caching
Requests for popular web pages are made continuously from locations across the global Internet. Since many users make the same request, it often makes sense to provide some local caching of web pages, rather than to serve these at each request from the original server. A web cache implements this function, and although various deployment models are possible, the cache itself always operates on the same basic principle; when a page is first requested (or has expired according to the page header information), the cache fetches the page from the web server on behalf of the requesting client. Subsequent requests until the expiry of the page are served directly from the cache, rather than from the original web server. A cache can be operated in one of several modes: • the cache may be made available on a given IP address and port, in which case the client machines must be configured to use the cache in preference to directly fetching pages from web servers • the ISP may block outbound traffic leaving its network on port 80, so forcing clients to use the web cache • the cache may also be implemented transparently, by redirecting traffic on port 80 to the ISP cache, without the client being reconfigured However a cache is implemented, it typically generates several potential problems: • web servers dislike the fact that the cache prevents them collecting statistics and data on ‘hits’ to the server. They may cause even static pages to expire instantly to thwart caching systems • dynamic content in pages, for example CGI scripts, preclude web caching, so as pages become more dynamic, the effectiveness of caching reduces. The configuration file for a cache normally includes a setting to exclude URLs containing ‘cgi-bin’ from caching • although cache hits (i.e. where a requested page is in the cache) are very responsive, cache misses (i.e. where the page is not in the cache) may be very unresponsive In short, effective web caching is a difficult engineering issue. In the simple configuration shown in Figure 23, a web cache is contacted on port 3128 (the well-known proxy port) for the requested content, and it contacts the original server on port 80 (the well-known HTTP port).
2.47
© Wray Castle Limited
IP2300/S2/v2.1
IP Engineering Overview
Web client
GET
Web cache
www . w ray
castl
e.com
GET
Web server
www . w ray
.w www ca . w ray w w w
s t l e. c
cast l
stl r ayc a
e.com
e. c o m
om
. . . . Page expiry period
GET
w
GET
www . w r ay
castl
r ayc a ww.w
www . w ray
e.com
s t l e. c
cast l
om
e.com
GET
www . w ray
.w www ca . w ray w w w
s t l e. c
castl
stl r ayc a
e.com
e. c o m
om
Figure 23 Web Cache Operation IP2300/S2/v2.1
© Wray Castle Limited
2.48
IP Engineering Overview
4
PROVIDING NAME SERVERS
4.1
Implementing Primary and Secondary DNS Servers
For a given domain, it is a requirement of registration that at least one secondary domain server is implemented, and normally two secondary domain servers are implemented for extra resilience; without an operating name server, most transactions involving the domain will fail. These servers should be physically separate, and ideally served by completely different infrastructure, to minimize the risk of a single point of failure. The simplest configuration of public name server services has the ISP providing entries in its name servers for the customer domain. However, in some cases, the customer may wish to operate the primary name server, and have the ISP operate secondary name servers for resilience. In order to implement one or more secondary name servers homed to a corporate primary name server, careful configuration of all of the servers is necessary: • the parent domain, for example the .com domain for our example, should list all of the name servers for the domain directly • the primary name server should permit zone transfers from the named secondary servers, while normally (for security reasons) blocking all other zone transfers • the secondary name servers should be configured with the details of the primary name server, specifically its IP address to allow transfers to take place
2.49
© Wray Castle Limited
IP2300/S2/v2.1
IP Engineering Overview
private network
Internet
ns1.wraycastle.com
ns2.myISP.com
wraycastle.com
IN NS ns1.wraycastle.com IN NS ns2.myISP.com IN NS ns3.myISP.com
Figure 24 Providing Secondary Nameservers IP2300/S2/v2.1
© Wray Castle Limited
2.50
IP Engineering Overview
4.2
DNS Caches and Forwarders
DNS caches are operated by large enterprises as well as ISPs to speed the resolution of information from the global DNS. They are not definitive for any domain, and carry out recursive DNS queries. In other words they will request a DNS resolution on behalf of their clients. DNS software normally includes a setting that allows forwarding of requests that the DNS itself cannot resolve. This type of operation is known as recursion. The service provided by an ISP normally includes providing a DNS cache as part of the client configuration. For dial-up accounts, the IP address of the DNS cache is normally provided as part of the Dynamic Host Configuration Protocol (DHCP) when the client machine connects. For client networks that access the Internet via an access router, this router normally operates as a DNS forwarder. Although definitions vary, it is useful to think of a forwarder as a special case of a cache that holds no cache information. Because it holds no DNS data, all requests are forwarded to the designated name server, which in this case will normally be the ISP cache, as before. This forwarding action can be used to implement internal and external DNS for a client within the corporate network, as follows: • requests are sent to a local name server in the business domain, which resolves requests for hosts internally • because the corporate DNS cannot resolve Internet addresses, these are passed to the Internet DNS for resolution Figure 25 shows this scheme for as dial-up network, where DHCP from the ISP is used to assign the public dial-up router address for the client (192.168.1.1 in this example), and a DHCP server also operates within the dial-up router to provide IP addresses to the private network clients (in this example the internal address of the DHCP server is 10.0.0.1, and it assigns addresses in the range 10.0.0.0/24). Each DHCP dialogue lists the correct DNS server, so that DNS requests from internal hosts are passed to the dial-up router, which in turn forwards them on to the ISP cache for resolution.
2.51
© Wray Castle Limited
IP2300/S2/v2.1
IP Engineering Overview
DNS Cache
ns1.myISP.com 192.168.1.100
NAS 192.168.1.254
192.168.1.1
Internet DHCP configuration IP address: 192.168.1.1 IP address mask: 124 Gateway address: 192.168.1.254 DNS server address: 192.168.1.100
DNS Cache 10.0.0.2
ns1.myISP.com 10.0.0.3
10.0.0.1
192.168.1.100
DNS forwarder
NAS
10.0.0.4
Internet DHCP configuration Recursive resolution for client via DNS forwarder
IP address: 192.168.1.1 IP address mask: 124 Gateway address DNS server address: 192.168.1.100
DHCP configuration IP address: 10.0.0.X IP address mask: 124 Gateway address: 10.0.0.1 DNS server address: 10.0.0.1
Figure 25 DNS Configuration through DHCP IP2300/S2/v2.1
© Wray Castle Limited
2.52
IP Engineering Overview
4.3
Partitioning Enterprise and Service Provider DNS
Any large organization will typically be operating an internal DNS, as well as making some parts of the corporate DNS visible on the public Internet. At least two Internet name servers are required for the public parts of the domain, and multiple name servers may be configured within the corporate network to provide fast and efficient name resolution between sites, or to partition the administration tasks between divisions or geographies. This combination of public and private DNS entries requires the DNS to operate as a split DNS, for security reasons. In a split DNS architecture, the DNS is divided into two types of logical platform: • a public name server provides resolution of the public DNS fields of the enterprise • a private name server provides resolution from internal and trusted sources Corruption of name server data can be a very effective method of mounting DoS and masquerading attacks against a domain. It is extremely important that internal host information is not visible from the Internet. The DNS application should be hardened in various ways beyond the basic splitting described above, but this is a more detailed topic than can be covered in this introduction to the subject.
2.53
© Wray Castle Limited
IP2300/S2/v2.1
IP Engineering Overview
Private Server development name servers development.wraycastle.com
Authoritative for private (internal) zones Queried only by internal or trusted forwarders or resolvers Recursive for trusted sources through ISP name server cache
sales.wraycastle.com sales name servers internal query internal host external query internal host
public name server wraycastle.com Public Server Authoritative for public zones Listed in parent zones as NS records Queried by Internet name servers Non-recursive
Internet
ISP name server (cache)
external query external host
Figure 26 Implementing a Split DNS IP2300/S2/v2.1
© Wray Castle Limited
2.54
IP Engineering Overview
5
SECTION 2 QUESTIONS
1
Explain the function of DHCP.
2
What are the advantages of DHCP over static configuration of host IP parameters?
3
The PPP protocol is widely used in dial-up Internet access because: a it is the most efficient link layer protocol b it includes additional protocols to support dial-up user, including link and IP configuration c it operates end-to-end between IP hosts, whereas other link layer protocols are limited to the access network only d it can carry multiple network layer protocols, using its NLPID field, rather than just IP
4
Local loop unbundling may be: a b c d
physical logical neither a nor b both a and b
5
Explain how a sending mail server would discover the IP address of the mail server it wishes to send SMTP mail to.
6
When might a business with its own Internet domain use an ISP-hosted secondary mail server? How would the MX preference records be set in this case?
7
Dynamic content can be generated for web pages using: a b c d
8
2.55
server-side programming client-side programming neither a nor b both a and b
When would an enterprise use a split DNS approach?
© Wray Castle Limited
IP2300/S2/v2.1
IP Engineering Overview
SECTION 3
SERVICE PROVIDER ARCHITECTURES
© wray castle limited
i
IP Engineering Overview
ii
© wray castle limited
IP Engineering Overview
SECTION CONTENTS 1
Network Architectures 1.1 The Core, Distribution and Access Model 1.2 The Access Layer 1.3 The Distribution Layer 1.4 The Core Layer 1.5 Peering Points and Internet Exchanges 1.6 Intra-PoP Architecture 1.7 Core Transmission Networks
3.1 3.3 3.5 3.11 3.13 3.15 3.17 3.19
2
Routing Overview 2.1 The Role of Routing Protocols 2.2 Routing Dynamics 2.3 Routing Protocols for Service Provider Networks 2.4 The AS Architecture of IP Networks 2.5 Interior (IGP) Versus Exterior (EGP) Routing 2.6 OSPF Basic Operation 2.7 BGP4 Basic Operation
3.21 3.21 3.23 3.25 3.27 3.27 3.29 3.31
3
Routing across the Customer/Service Provider Interface 3.1 Maintaining Separation of Routing Domains 3.2 Routing for Dial-up Users 3.3 Static Routing for a Single-homed Customer 3.4 Dynamic Routing for a Multi-homed Customer
3.33 3.33 3.35 3.37 3.39
4
Design Considerations for Control, Scale and Stability 4.1 Balancing SDH, ATM and IP Restoration 4.2 Isolation of Routing Domains and Traffic Filtering 4.3 Selection of OSPF Areas 4.4 The use of Default Routes and Networks for Network Protection 4.5 Route Reflectors and BGP Confederations for Scaling iBGP 4.6 IP Traffic Management using BGP4 Techniques
3.41 3.41 3.43 3.45 3.47 3.49 3.51
5
Section 3 Questions
3.57
© wray castle limited
iii
IP Engineering Overview
iv
© wray castle limited
IP Engineering Overview
SECTION OBJECTIVES At the end of this section you will be able to: • • • • •
explain the hierarchy of a typical IP network compare and contrast router and switch features at core, distribution and access layers explain the functions and key properties of routing protocols evaluate a routing design at the customer/service provider interface present the key mechanisms for control, scale and stability in routing design
© wray castle limited
v
IP Engineering Overview
1
NETWORK ARCHITECTURES
Before a technical architecture can be proposed or updated, it is important to answer various ‘business case’ questions, such as: • the set of services the infrastructure must provide. For example, does the network provide dial-up access or GSM access? • the customers the network intends to serve. For example, residential users, small business users, large global enterprises, or other service providers? • the rollout of network and service functionality. For example a regional, national or international network, and in what sequence? • the forecast volumes of traffic over time, and the traffic matrix Assuming answers to these questions are available, then a range of technical architecture decisions can be made, including: • what access platforms must be provided? • what protocols must be supported directly or through tunnelling? • what network services platform must be provided? • how should peering be carried out? • what capacity should key components be designed for? The results of these considerations leads to a technical architecture for the network, which allows the planned set of services to be offered, at the volumes predicted and the locations planned.
3.1
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Business Plan Services Customers Locations Forecast volumes etc.
Technical Architecture Access platforms Service platforms Routing architecture Switching architecture PoP architecture Peering arrangements Protocols etc.
Figure 1 Relating the Technical Architecture to the Business Plan IP2300/S3/v2.1
© wray castle limited
3.2
IP Engineering Overview
1.1
The Core, Distribution and Access Model
The IP network of any medium to large ISP is structured into (typically) three logical levels of hierarchy. This approach normally achieves the best overall balance between manageability, scalability, reliability and economy. The three levels of hierarchy are commonly known as the Core, Distribution and Access layers. • the Core is responsible for simple, high-speed switching of transit traffic • the Distribution Layer contains network services, and collects traffic from the access layer for the core layer • the Access Layer connects users to the network in an efficient way We discuss each of these layers in more detail in the next few slides.
3.3
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Access
Distribution
Modem banks
Customer premises equipment Peering
Core Simple, high-speed switching
User connections
Policy
Service platforms
Local PoPs
Aggregation
ADSL access etc.
Figure 2 The Core, Distribution and Access Architecture IP2300/S3/v2.1
© wray castle limited
3.4
IP Engineering Overview
1.2
The Access Layer
The access layer occurs at the edge of the network. It provides customer premises routers, where these are managed by the service provider, as well as the bearer connection to a Point of Presence (PoP). Dial-up customers are connected to the PoP through a circuit-switched connection to a Network Access Server at the PoP, while directly connected customers are attached to a customer access router.
1.2.1
Customer Premises Equipment (CPE)
A customer premises router will normally offer a suitable WAN access interface, such as ISDN, E1 or E3, or switched services such as Frame Relay or ATM. Often a serial interface based upon the X.21, V.35 or High-Speed Serial Interface (HSSI) specifications is provided, and this is fed into a service provider Channel Service Unit/Data Service Unit (CSU/DSU) or Network Termination Point (NTU), which provides a standard signal interface complying with the G.703 standard of the ITU-T. The customer side of the CPE normally provides an ‘Ethernet’ interface at 10 or 100 Mbit/s, to which the LAN network can be attached. Units designed for small office use may have an integral 8 or 16 port ‘Ethernet’ switch, so that hosts can be directly connected. These routers may contain various value-added components of hardware or software, including: • firewalls • network address translation • DHCP servers for the LAN • IP-VPN gateways • packet classification, where QoS techniques have been implemented on the access circuit
3.5
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Customer premises router
Customer access router
‘Ethernet’ switch To Distribution Layer Flexible WAN interfaces DHCP server NAT device Firewall IPVPN gateway
High port density Traffic policing Traffic shaping Traffic classification Packet filtering Dual power supplies Hot-swappable modules
Figure 3 The Access Layer IP2300/S3/v2.1
© wray castle limited
3.6
IP Engineering Overview
1.2.2
Access Routers
Customer access routers must match the WAN capabilities of CPE routers, including the ability to provide traditional leased line and switched service connectivity. Normally a mid-range router with a configurable chassis is used, to give the best possible port density. Normally this device will contain dual power supplies, multiple route processor cards (to perform IP forwarding), and the ability to hot-swap components, including customer interfaces. In addition to any routing protocol run across the service interface, the access router provides the boundary of the service provider network, and so filtering and policing actions normally take place on this unit. These may include: • filtering of traffic on source address for security reasons • packet classification, where QoS techniques have been implemented in the core network • policing of traffic flows against permitted volumes, particularly where QoS techniques have been implemented on the access circuit • filtering of routing information against a list of allowed customer networks at the site being serviced
3.7
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Customer premises router
Customer access router
‘Ethernet’ switch To Distribution Layer Flexible WAN interfaces DHCP server NAT device Firewall IPVPN gateway
High port density Traffic policing Traffic shaping Traffic classification Packet filtering Dual power supplies Hot-swappable modules
Figure 3 (repeated) The Access Layer IP2300/S3/v2.1
© wray castle limited
3.8
IP Engineering Overview
1.2.3
Network Access Servers (NAS)
Network Access Servers (NAS) terminate dial-up connections to the ISP from individual or private network users. They must support a wide range of modem speeds effectively as well as ISDN connections. Where a licensed telecommunication operator operates the NAS, then an internal signalling connection to the NAS is normally made using Signalling System No. 7 (SS7). This allows a high port density in the NAS equipment. If a conventional ISP operates the NAS equipment, then a conventional customer ISDN connection must be used, which limits the port density achievable. Normally the NAS will feed traffic to a high-speed access router that will provide network services such as those outlined above. Increasingly NAS equipment supports sophisticated management tools to allow wholesale Internet access and VoIP to be offered, including virtual modem pooling, soft limiting of modem capacity, and usage-based charging to wholesale customers. As well as terminating traditional modem calls, most NAS devices will act as Voice over IP (VoIP) gateways, under the control of a separate gateway controller.
3.9
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
SS7
Signalling controller/ Media gateway controller
Bearers with ISDN/ modem
To Distribution Layer
High port density Flexible modem/ISDN termination Voice gateway functionality SS7 control functionality Virtual modem banks
Figure 4 The Network Access Server IP2300/S3/v2.1
© wray castle limited
3.10
IP Engineering Overview
1.3
The Distribution Layer
The distribution layer provides aggregation of traffic from the customer access routers, as well as providing transit for traffic within the local area from a routing perspective. Traffic within the local area is normally routed between access routers by the distribution layer; traffic between areas is routed by the core layer, via the distribution layer routers. The distribution layer is the layer at which: • network servers are deployed • peering with other service providers takes place • high bandwidth access circuits are attached to the network
1.3.1
Distribution Layer Routers
Distribution layer routers typically require lower port density than an access router, since they will interconnect with banks of access routers and typically with a small number of core routers. A LAN switched network may be used to concentrate access traffic onto the distribution routers. The distribution router may need to apply policing, traffic shaping and filtering to traffic from high-speed customer connections that enters the network at the distribution layer. The distribution router must be able to perform a range of IP processing functions, including participating in the IGP protocol of the ISP, effectively, as well as achieving a high packet-forwarding rate.
3.11
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
From Access Layer
To Core
Medium port density Filtering and policing for high-speed access Dual power supplies Hot-swappable modules Powerful route processing Line-speed forwarding
Figure 5 Properties of a Distribution Router IP2300/S3/v2.1
© wray castle limited
3.12
IP Engineering Overview
1.4
The Core Layer
The core layer acts as a high-speed transit layer for traffic flowing between the separate distribution areas of the network. The core routers must be able to forward traffic at extremely high line speeds, and must also have the memory and processing power to hold the full Internet routing tables for the ISP. Whereas lower levels of the routing architecture typically use a default route to pass traffic up to the core, the core routers must either route each packet on a genuine routing, or discard it. The core network connecting these routers is typically a Layer 2 switching technology, either ATM or MPLS. Traditionally, separate ATM switches were used to provision a full mesh connectivity between core routers, however as MPLS is deployed into routers the need for a separate switching layer reduces, and the cost and complexity saving that this provides is attractive. The use of Layer 2 switching makes traffic engineering much easier for the core portion of the network. By configuring multiple virtual circuits across the physical infrastructure between core router sites, it is possible to control the bandwidth available between destinations, and to adjust this to react to unusual demand or to meet medium term demand.
3.13
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Routing adjacency
u Ro tin g
Ro u
t in
cy en jac ad
Routing adjacency
ga dja ce nc y
Full mesh PVCs
Routing adjacency
Routing adjacency
Figure 6 The Core Architecture IP2300/S3/v2.1
© wray castle limited
3.14
IP Engineering Overview
1.5
Peering Points and Internet Exchanges
Peering between service providers can take place at a managed Internet eXchange Point (IXP) or on a bilateral basis between two operators. In both cases, the technical requirements include a public Autonomous System Number (ASN) and a Border Gateway Protocol (BGP4) router facing the peering point. Some IXPs limit themselves to purely providing a switched infrastructure; others offer extra technical services, e.g. route servers, private interconnects. The majority of IXPs are located in co-location facilities, which provide basic services including power, air-conditioning, security and first level support.
1.5.1
LAN Infrastructure
The majority of IXPs have adopted a Layer 2 switched ‘Ethernet’ architecture. There are examples of other architectures such as ATM and FDDI, however these are not common.
1.5.2
Collector Router
To assist in troubleshooting peering arrangements, some IXPs provide a router with which all members peer and announce their routes. The router listens to, or ‘collects’ these announcements, but does not announce any routes itself; hence some IXPs use the term ‘collector’ router for this equipment. IXP staff and member ISPs have user accounts on this router, enabling them to have a central ‘view’ of all of the peering dialogues at the IXP, independent of the view through their own connection.
1.5.3
Private Interconnect
The concentration of ISP connections at an IXP can make it a very convenient place for one ISP to have a direct physical connection to another where their router equipment is co-located and with whom they exchange significant traffic. This is the equivalent of a bilateral peering connection, but hosted at the IXP.
1.5.4
Route Servers
Some IXPs offer a route server facility. This is typically a device that interrogates routing registries, builds a database of the entries in the registries for the member networks, and provides a routing table based on this information. An IXP member’s router may then build its routing table with just one peering session with the route server rather than taking many routing tables from all its peers. The principal aim is to reduce the processing power required in the member router connected to the IXP. 3.15
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Internet Exchange Point (IXP) 1 and ISP3 peer ISP
ASBR ISP1
ASBR ISP2
ASBR ISP3
Route server
d ISP5 p 4 an eer ISP
ASBR ISP4
Private Peering
ASBR IXP ASBR ISP5
Collector router
Figure 7 Architecture of an Internet Exchange Point IP2300/S3/v2.1
© wray castle limited
3.16
IP Engineering Overview
1.6
Intra-PoP Architecture
A service provider PoP will typically contain many access routers and at least two distribution routers. In order to achieve the fan-out necessary at the PoP, and to make the LAN connections resilient, it is common to use a dual-homed switched ‘Ethernet’ to interconnect the layers of the architecture, as shown in Figure 8. Where the distribution layer routers are co-located with core routers, the same model may be repeated.
3.17
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Point of Presence
LAN Switch
LAN Switch
Distribution layer
Access layer
Figure 8 Switching used within an Internet PoP IP2300/S3/v2.1
© wray castle limited
3.18
IP Engineering Overview
1.7
Core Transmission Networks
For large Internet networks, the interconnection of the core routers has traditionally been across an ATM switched infrastructure that is dedicated to the Internet core. In this architecture the switching layer is used to provide control of the path traffic takes across the backbone, and to control bandwidth utilization. The physical layer connections are essentially point-to-point, rather than across a managed transmission network such as Synchronous Digital Hierarchy (SDH). Traditional telecommunication operators have often built their IP services network separate from the public Internet. The traffic volumes in this case are smaller than in an Internet backbone. Also these operators often have a network strategy based upon multiservice ATM switching and a common SDH-based transmission network. As a result, they have often, at least initially, run their IP services traffic as another service across an integrated ATM layer. As the demand for bandwidth grows in a typical IP services network, it dominates the utilization of general-purpose transmission and switching capacity, and the operator typically moves to a model of dedicated IP switching and transmission capacity in the core network. In the future, it is likely that MPLS will replace ATM as the Layer 2 traffic engineering technology for large IP networks, running across switched wavelengths in a managed optical network.
3.19
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Traffic engineering
IP
IP
IP over ATM Core
IP IP
FR ATM Voice
Voice ATM FR
IP
IP over multiservice ATM Core
SDH
SDH PVCs for each service
Managed optical switch
IP over MPLS Core MPLS traffic engineering
Figure 9 Options for Core Transmission Architecture IP2300/S3/v2.1
© wray castle limited
3.20
IP Engineering Overview
2
ROUTING OVERVIEW
2.1
The Role of Routing Protocols
Packet forwarding in an IP network is carried out by checking the destination IP address of arriving packets against a routing table within the router. This routing table contains matched entries of IP network or host addresses, and the address of the next hop router which can best be used to reach the packet destination. The entries in the routing table may be generated manually, in which case they are known as static routes. Static routes can be useful in certain circumstances, however they also have two drawbacks. • Static routes have no resilience. If the physical connection that a static route points to becomes unavailable, it may be impossible to deliver traffic to its destination, even if alternative paths could be found. • In all but the smallest networks, the manual configuration of static routes, and the effort involved in moves and changes, makes them unattractive. Routing protocols are used to make IP networks more scaleable and more resilient. The main role of routing protocols is to keep the routing tables accurate, even if the network state changes. Routing protocols consist of advertisements, which communicate routing information to neighbouring routers and a routing algorithm, which processes the routing advertisements, and generates routing table entries. Figure 10 shows a simple network of three routers, and the routing table that might result once updates have been exchanged. In this example we have subnetted the 192.168.1.0/24 network to produce two /27 networks, and we have used Cisco’s Interior Gateway Routing Protocol (IGRP) to exchange advertisements and to calculate the best route to destination subnets. The table at the bottom of Figure 10 shows the routing table entry that results in router 3. It shows that the subnet connecting routers 1 and 2 was learnt through the IGRP routing protocol, as well as indicating the interface traffic should be transmitted on to reach the subnet (Ethernet 1), and the IP address of the router interface it should be sent to (192.168.1.65).
3.21
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
192.168.1.34/27 e0
192.168.1.66/27
.32
e0 e1
R1
.64
e1
R2
192.168.1.33/27
R3
192.168.1.65/27
Run the igrp routing protocol for network 192.168.1.0
> router igrp > network 192.168.1.0
router3 > show ip route 192.168.1.0 is subnetted, 2 subnets I 192.168.1.32 [metric] via 192.168.1.65 eth 1 C 192.168.1.64 is directly connected, eth 1
How this route was learnt
The subnet that can be reached
Metric measures how ‘good’ the next hop is
Address of next hop router
Outbound interface
I – IGRP C – direct connection also S – static (i.e. manually configured) ...and many others
Figure 10 An Example of Routing Protocol Operation IP2300/S3/v2.1
© wray castle limited
3.22
IP Engineering Overview
2.2
Routing Dynamics
The structure of a network, i.e. its nodes and links, is known as the network topology. When the topology of the network changes, routing updates are sent from the affected router to its neighbouring routers. When a router receives a routing update that indicates a change in the network topology, the router must recalculate the routing table entries using its routing algorithm. These updates and recalculations quickly propagate to all of the routers in the routing domain. The routing algorithm is designed to generate optimum routes to any given dest inat ion, based upon the rout ing protocol metric provided in rout ing advertisements. Different protocols use different metrics, but examples of metrics commonly used include the number of router hops, the bandwidth of a link and the delay across a link. The time taken to calculate these new routing table entries, and for these to propagate between all of the routers, is called the convergence time of the routing protocol. Early routing protocols either took a long time to converge as the network size grew, or generated a lot of unnecessary routing traffic. Modern routing protocols such as Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) are more complex to configure than these earlier, simpler protocols, but also perform much more effectively in large networks.
3.23
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
R2 discovers that this interface has failed R2
1
Initial topology R1 2 2
directly connected directly connected
Routing updates sent and topology recalculated in each router
R3
Routing updates
Stability
Interface fails
Route calculation
New topology stable
Time
Convergence time
R1
R2
reachable via directly connected R3 Figure 11 The Dynamics of Routing Protocols IP2300/S3/v2.1
© wray castle limited
3.24
IP Engineering Overview
2.3
Routing Protocols for Service Provider Networks
Routing protocols operating within a large service provider network must be scalable, efficient and stable, even if attached networks are themselves unstable. Compared with the early routing protocols such as RIP, protocols such as OSPF and IS-IS have several desirable properties: • they only transmit changes, rather than the complete routing table, making them more efficient in their use of network bandwidth • they can separate a routing domain into smaller areas, which allows them to scale to extremely large networks • they support Variable Length Subnet Masks (VLSM), which allows flexible use of the address space, and Classless Interdomain Routing (CIDR) • they avoid routing loops, including indirect routing loops, which early protocols could not achieve • they converge very quickly, compared to the convergence time of older routing protocols • they allow load sharing across parallel links, rather than simply selecting the single best link between two points
3.25
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Routing Protocols for large Service Provider Networks only transmit changes routing domain hierarchy protocol supports VLSM and CIDR protect against routing loops fast convergence algorithm supports load sharing
Figure 12 Requirements for Service Provider Routing Protocols IP2300/S3/v2.1
© wray castle limited
3.26
IP Engineering Overview
2.4
The AS Architecture of IP Networks
The global Internet is a highly connected set of networks, each under separate administrative control. For this reason, networks operate one or more interior routing protocols (within their own network), and an exterior routing protocol across points where they interconnect with other IP networks. These interior protocols are known as Interior Gateway Protocols (IGP), and we will explore the operation of Open Shortest Path First (OSPF). The exterior routing protocols are known as Exterior Gateway Protocols (EGP), and we will explore the operation of Border Gateway Protocol version 4 (BGP4). Each IP network that is connected to the Internet and under a single administrative control is known as an Autonomous System (AS).
2.5
Interior (IGP) Versus Exterior (EGP) Routing
The roles of interior and exterior routing protocols are very different, although each is concerned with allowing routers to forward packets towards their destination. An IGP protocol provides full and free exchange of topology information between participating routers. There is normally no commercial or other reason to restrict this flow of information, and by allowing all routers to see the internal structure of the network they are part of, they can best optimize their routing tables. An EGP protocol provides reachability information from the routers in one AS to the routers in other ASs. They do not specifically provide information on the internal structure of their own network; they simply inform their neighbours in other networks that particular destinations are reachable through them. This protects the commercially sensitive structure of the service provider network, while still allowing traffic to be effectively forwarded to its destination. This approach also more easily allows routing policies between ASs to be imposed through the EGP protocol routing updates.
3.27
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
EGP protocol ‘network 192.168.1.0 is reachable through AS1234’ ‘network 10.0.0.0 is reachable through AS5678’
AS5678 service provider 2
AS1234 service provider 1
192.168.1.0 customer 1
10.0.0.0 customer 2
IGP protocol
IGP protocol
Full topology exchange
Full topology exchange
Figure 13 Interior versus Exterior Routing IP2300/S3/v2.1
© wray castle limited
3.28
IP Engineering Overview
2.6
OSPF Basic Operation
The structure of OSPF is hierarchical and is detailed in Figure 14. The Autonomous System (AS) is split into areas that are in turn linked together by a backbone area. Within an area, each router builds an identical link state database, by sending and receiving Link State Advertisements (LSA) to all of the participating routers within the area. If routers are on a shared medium or Non-Broadcast Multiple Access (NBMA) network, they hold elections in which a Designated Router (DR) and a Backup Designated Router (BDR) are identified to represent the area, in which case each DR is responsible for building the link state database for its respective area. Otherwise, each router builds this link state database independently. Area Border Routers (ABR) connect each area to the backbone area. The ABRs may either forward all LSAs from their area to the backbone routers, or more usually summarize this information. In an OSPF network, traffic between destinations within an area must be routed entirely within the area. This is known as inter-area routing. Traffic between destinations in different areas must be carried across the backbone area, area 0. This approach imposes a strict hierarchy in the routing of traffic. Although this may be less than optimal in any particular case, it makes the design of the overall network, the control of traffic flows, and the isolation of problems much simpler than would be the case if this hierarchy were not imposed. Perhaps most importantly, it protects the areas from bad topology information in another area, and so allows the scope of such problems to be constrained.
3.29
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Backbone routers
LS
LS
A
LS
LS
A
LSA
A
LSA
LSA
LSA
Area border routers
LSA
A LS
A
area 0
LSA
A
LSA
LSA
A
LSA LS
A
A
A LS
area 3
LS
LS
LS A
LSA
LSA
LSA
A
LSA
LS
area 1
LSA
A
LS
A LSA
LS
LS
area 2 area 4 Area routers
Figure 14 OSPF Basic Operation IP2300/S3/v2.1
© wray castle limited
3.30
IP Engineering Overview
2.7
BGP4 Basic Operation
Border Gateway Protocol version 4 (BGP4) is the main routing protocol that operates between ASs. It communicates the reachability of networks it is aware of, as well as the AS path necessary to reach them. Much of the emphasis in BGP operation is in controlling how traffic is routed across peering points; BGP provides various settings that can be used to impose a policy on interconnect points. BGP can operate in two modes: External BGP (eBGP) operates between a pair of Autonomous System Border Routers (ASBR), and so runs across external links and Internal BGP (iBGP) operates between ASBRs within an autonomous system, and so runs across internal links. The BGP routers must also participate in the autonomous system IGP, since traffic destined for the ASBRs must be routed across the internal network. BGP routing tables include a next-hop entry which is the address of the correct ASBR; however there will be intervening routers in most cases that must also route these packets. Routes learnt from BGP can be added to the IGP routing tables, and routes learnt from the IGP can be added to the BGP routing tables.
3.31
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
eBGP
iBGP ‘network 10.0.0.0 is reachable through AS5678’
‘network 192.168.1.0 is reachable through AS1234’
‘network 192.168.1.0 is reachable through AS1234’
‘network 10.0.0.0 is reachable through AS5678’
AS5678 AS1234 eBGP
iBGP
GP
IG P
IG P
iB
IGP
P
G
iB
IGP
IGP
192.168.1.0
10.0.0.0
IGP protocol iBGP protocol Full topology exchange
‘network 192.168.1.0 is reachable through AS1234’ ‘network 10.0.0.0 is reachable through AS5678’
Figure 15 BGP4 Basic Operation IP2300/S3/v2.1
© wray castle limited
3.32
IP Engineering Overview
3
ROUTING ACROSS THE CUSTOMER/SERVICE PROVIDER INTERFACE
3.1
Maintaining Separation of Routing Domains
Routing protocols are designed to quickly propagate changes in the topology of one part of the network to all routers in the network. While this is generally a good way to maintain optimal routing within a network, it can cause problems across the boundary between a service provider network and a customer network: • it is important that changes in the customer network do not affect the routing within the service provider network • it is important that internal changes within the service provider network do not affect the customer network • it is particularly important that service providers are protected from any routing instability that might occur in a customer network; if allowed to enter the service provider network, this could make other customer network unreachable, and services unavailable The guiding principle in connecting customers to the service provider network is to maintain good separation of the routing domains. How easy this is to achieve depends upon the routing relationship between the two networks. Part of providing an IP service in many cases is: • the propagation of customer routes into the public network, so that public network traffic can reach the corporate network • the propagation (in some sense) of Internet routes into the private network, so that traffic destined for the public network is sent to the service provider
3.33
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
‘Network ‘The Internet 192.168.1.0 is reachable is reachable over this link’ through AS1234’
AS1234
Customer network 192.168.1.0
Service provider network
Customer routing domain
Service provider routing domain
Internet
Figure 16 Maintaining Separation at the Customer/Service Provider Interface IP2300/S3/v2.1
© wray castle limited
3.34
IP Engineering Overview
3.2
Routing for Dial-up Users
Dial-up users normally do not have a static IP address. Instead they are assigned an IP address using Dynamic Host Configuration Protocol (DHCP) from a pool of addresses available at a Network Access Server (NAS) operated by their ISP. In this case, there are no customer routes to propagate, since the customer either operates a single host, or uses Network Address Translation to map multiple private IP addresses into the address assigned dynamically by their ISP. In this case, the ISP normally injects a static route for the subnet containing the DHCP pool into their IGP, which then propagates across the public Internet. This allows traffic from the public network to be delivered to the correct NAS. The NAS then directs this traffic to the NAS port on which the customer is attached.¹ The example in Figure 17 shows a dial-up network receiving an address from the NAS address pool (192.168.1.2). A default route has been set up (represented by the all zeros network address), so that all non-local traffic is sent to the ISP. The ISP in turn routes this traffic on to its destination. In the reverse direction, the ISP has advertised the NAS address pool into its IGP and from there out into the wider Internet via BGP at its peering points. The situation is more complicated if the user has a fixed IP address. In this case, the correct address can be assigned on a repeatable basis to this user by including extra information in their RADIUS or TACACS profile, which is invoked when the user connects to their ISP. A static route to this address is also announced from the NAS into the service provider IGP. If the fixed-address dial-up user is also mobile, a route can be dynamically loaded into the NAS as part of the RADIUS profile, however this level of complexity is seldom justified or implemented.
¹ Interestingly, several specialized service providers now offer Dynamic Domain Name Service (DDNS) to the public. This allows users with a DHCP-assigned public address to have this captured and entered into the DNS system while they are logged into the network.
3.35
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
DHCP server with address pool 192.168.1.2
192.168.1.2 (for example) assigned by DHCP
192.168.1.254
NAS Internet 192.168.1.0/24
All Internet traffic
0.0.0.0 via me
198.168.1.0/24 via me
Figure 17 Routing for Dial-up Users IP2300/S3/v2.1
© wray castle limited
3.36
IP Engineering Overview
3.3
Static Routing for a Single-homed Customer
A single-homed customer is a customer with a single service provider. We will assume the customer site is permanently connected, and operating a private IP network that has some public address space. Because the customer has their own public IP addresses, the service provider must advertise the customer routes across the public Internet. A static routing approach can still work in this case, and thereby avoid the need to operate a routing protocol across the customer/service provider interface. This could be achieved by configuring the customer network addresses as static routes within the customer access router, so that these propagate in a stable way into the service provider IGP and beyond. In a similar way a default route to the ISP can be configured in the Customer Premises Equipment (CPE) router, which then propagates through the customer network via the customer’s own IGP. A strong advantage of this approach is that it avoids completely any dynamic routing updates across the service boundary, and so protects each network from instability in the other. One disadvantage of this approach is that it requires reconfiguration of the service provider router when the customer makes a change to the addressing in their network. If a client has multiple sites, but still uses a single service provider, this same approach can be extended, with the access router for each site announcing the subnets at that site based upon static route entries. If a single-homed client has a large private network, it may be better to operate a dynamic routing protocol across the service interface, to minimize the overhead of maintaining static routes for the client network. In this case, the same approach as that used for multi-homed clients can be followed (see Figure 19).
3.37
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
192.168.1.0/24
Internet
0.0.0.0 via me
192.168.1.0/24 via me
Into customer IGP
Into service provider IGP
Customer routing domain
Service provider routing domain
Figure 18 Routing for Single-homed Customers IP2300/S3/v2.1
© wray castle limited
3.38
IP Engineering Overview
3.4
Dynamic Routing for a Multi-homed Customer
A multi-homed customer is a customer that uses more than one service provider for Internet access. We assume the customer has a substantial network of public IP addresses that must be announced to the public network. Customers may choose to be multi-homed for resilience, for commercial reasons, or may simply be multi-homed for historical reasons. Static routing is typically not a good approach for multi-homed clients. Although in principle traffic from the customer sites and the Internet will choose the nearest exit service provider, this approach provides no techniques for tuning the flow of traffic, and troubleshooting is difficult. Typically eBGP is used in these circumstances, since it maintains isolation of the routing domains, while still providing reachability information. If the customer does not have an AS number for the private network, one may be assigned from the private AS space by the service provider. Normal eBGP peering then takes place between the customer AS and the various service providers ASs, through their respective Autonomous System Border Routers (ASBR). The service providers can now apply BGP policies to the routes learnt from the customer, before importing these into their own IGP. These routes are then propagated across the public network via eBGP peering with other service providers, and are represented as part of the originating ISP’s AS. The customer may also apply filtering and policy settings to the routes learnt from each ISP through the eBGP peering sessions. This would allow traffic meeting certain criteria to be directed towards a chosen ISP or exit point, for example. The customer must in turn import the routes learnt from eBGP into their IGP, so that these routes are available to their internal routers. This approach adds significant complexity to the internal customer network over the single-homed case, where default routes can be used.
3.39
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
ISP1 Into service provider IGP
s route t e n Inter ia eBGP v
Customer network
r rou ome t s u C BGP via e
tes
Into customer IGP
Internet
Custo m via eB er routes GP
ISP2
Intern
et rou via eB t e s GP
ASBRs
Into service provider IGP
ASBRs
Figure 19 Routing for Multi-homed Customers IP2300/S3/v2.1
© wray castle limited
3.40
IP Engineering Overview
4
DESIGN CONSIDERATIONS FOR CONTROL, SCALE AND STABILITY
4.1
Balancing SDH, ATM and IP Restoration
A typical IP service provider network carries IP traffic across some switched Layer 2 technology (often ATM), and this in turn may operate over a resilient physical layer, such as Synchronous Digital Hierarchy (SDH) or a managed optical network. The responsiveness of these technologies varies greatly: • SDH restoration across pre-provisioned links takes between 50–100 ms • ATM restoration using backup PVC or Soft-PVCs takes between 100–1000 ms • IP restoration using routing updates and reconfiguration takes between 1 second and perhaps 30 seconds Given this spread of responsiveness, it is important that hold-off timers are used to prevent the various restoration schemes working against each other. Otherwise, a fault at the SDH layer might trigger restoration at the SDH, ATM and IP layers simultaneously, and these might work against each other in the overall restoration of traffic.
3.41
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
IP
IP
ATM
ATM
SDH
SDH
IP restoration time:
1 s – 30 s
ATM restoration time:
100 ms – 1 s
SDH restoration time:
50 – 100 ms
Figure 20 Comparing Restoration Times IP2300/S3/v2.1
© wray castle limited
3.42
IP Engineering Overview
4.2
Isolation of Routing Domains and Traffic Filtering
The filtering of routing updates at both the customer/provider boundary and the boundary between service providers is a key technique in protecting the stability of the service provider network. Various filtering scenarios are discussed below.
4.2.1
BGP Damping
When routes within the Internet are unstable, that instability can propagate through the Internet and remain for some time. Most BGP implementations include a form of damping to contain this effect as close to the source as possible. Typically a route which has changed several times in quick succession is removed from the BGP routing tables of the receiving AS, and not reinstated until some hold-down timer has expired. Although this prevents traffic from being routed to the destination, this maintains stability in the receiving network, and penalises networks that allow route flapping to occur.
4.2.2
Filtering at Peering Points
Filtering of BGP updates across peering points is one of the key methods of controlling the networks transited by specific traffic. By filtering out BGP routes that transit specific ASs, or by removing entries for specific networks, the transit behaviour of traffic can be influenced.
4.2.3
Filtering at the Customer Interface
Where eBGP is used to connect a multi-homed client, it is necessary to apply filters to the routing updates. If this is not done, the service provider may inadvertently allow transit through the customer AS. The normal approach is to permit only the agreed network addresses to be announced into the service provider IGP across the customer/service provider interface.
3.43
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Inbound filtering Outbound filtering
Remove 10.0.0.1 from BGP routing table
Inbound filtering Outbound filtering
eBGP
myISP
Route flap on 10.0.0.1 (for example)
eB
eB
GP
GP
Blocks transit
> allow 192.168.1.0 AS_PATH 65100 > deny all
192.168.1.0 AS65100
Figure 21 Route Filtering in BGP4 IP2300/S3/v2.1
© wray castle limited
3.44
IP Engineering Overview
4.3
Selection of OSPF Areas
The OSPF routing model of a single backbone area and multiple distribution areas interconnected through it fits well with the Internet model of network hierarchy based around a core, distribution and access layer. A typical design might construct an OSFP area 0 from the set of core routers, with the distribution and access layers partitioned into a further set of areas based upon the traffic matrix. The OSFP routing paradigm then treats traffic according to whether it is within or between areas. Intra-area (typically intra-region) traffic is routed entirely within the area, without passing over the backbone area. Inter-area (typically interregional) traffic is always passed across the backbone area. To keep the processing load manageable on the area routers, most vendors recommend an upper limit of 50–100 routers within an OSPF area.
3.45
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
Inter-area traffic transits Area 0 Core routers
Area 0
Distribution routers
Access routers Area 1
Area 3
Area 2
Intra-area traffic stays with area
Figure 22 Designing OSPF Areas IP2300/S3/v2.1
© wray castle limited
3.46
IP Engineering Overview
4.4
The use of Default Routes and Networks for Network Protection
Current Internet routing tables, even with the introduction of CIDR and a more hierarchical allocation of address space, now exceed 140,000 entries, and continue to grow. This size of routing table would be impossible to manage at the lower network levels. Also, by allowing these externally learnt routes explicitly into the IGP, then any instability in these routes will also propagate into the IGP. A better approach is to inject a default route from the various backbone transit routers into the IGP. This will then propagate down to the lower-level routers via the IGP, so that traffic they cannot route directly is passed to the transit routers automatically. In this case, the normal IGP metrics will select the lowest cost transit router, based upon the cost between the access router and the transits (rather than the total cost to egress from the ISP network). These transit routers must also be iBGP peers with the ASBR routers, otherwise they will not be able to select the best route for egress from the ISP network.
3.47
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
0.0.0.0 via me
0.0.0.0. via me
0.0.0.0. via me
Core routers
ASxxxx
iBGP peering eBGP
ASyyyy
Into service provider IGP
ASBRs eBGP
Distribution routers myISP
Figure 23 The Use of Default Routes in Service Provider Networks IP2300/S3/v2.1
© wray castle limited
3.48
IP Engineering Overview
4.5
Route Reflectors and BGP Confederations for Scaling iBGP
4.5.1
Route Reflectors
The operation of iBGP can place considerable strain on routers participating in BGP peering. The basic operation of BGP prevents one BGP peer from passing on routes learnt by another, so normally a full mesh topology is required. The use of BGP Route Reflectors converts this topology from a full mesh to a hub and spoke topology, where each iBGP router peers with a central iBGP peer; as a result the number of peering sessions is greatly reduced. Route reflectors consider the routers that peer with them as clients, although the clients themselves need no special configuration. Even a simple topology with all iBGP handled through a route reflector should have logical and physical redundancy incorporated into the design, as shown in Figure 24.
4.5.2
Confederations
A BGP confederation is an alternative approach to scaling the iBGP process. In this case, the original AS is divided into sub-ASs, and each is typically allocated a private AS number. Within each sub-AS, iBGP is used in a full mesh topology. Between the sub-ASs, eBGP is used, and the private AS numbers are used in these sessions. Peering between the confederation and other public ASs is via eBGP, using the (public) confederation AS number. Both route reflectors and confederations are methods of scaling iBGP. Confederations can also be used when networks are combined or consolidated into a larger AS. Neither approach need affect the external appearance or peering behaviour of the network.
3.49
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
BGP route reflectors
Client
eBGP AS1234
eBGP AS1234
Client
AS1234
Client
Client
iBGP Route Reflectors
eBGP 0 0 AS651101 5 AS6
AS65101 eBGP AS1234
eBGP AS1234 AS65100 AS1234
iBGP Confederation Figure 24 Route Reflectors and Confederations IP2300/S3/v2.1
© wray castle limited
3.50
IP Engineering Overview
4.6
IP Traffic Management using BGP4 Techniques
BGP has several techniques to allow the flow of traffic towards and across an eBGP peering point to be modified. Reachability is carried in the AS_PATH attributes for routes, and so most tuning of traffic flows using BGP involves altering the path attributes between ASs. Path attributes can be modified before being sent, or after receipt. There are three common techniques used. By removing particular AS numbers from the AS path before sending it across an eBGP session, an AS can avoid offering transit for this traffic from other ASs. The other two, path pre-pending and specific route injection are discussed overleaf.
3.51
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
192.168.1.0/24 AS_PATH 2 1
192.168.1.0/24 AS_PATH 1
AS3 192.168.1.0/24 AS_PATH 3 2 1
AS2
192.168.1.0 Internet AS1
All traffic
192.168.1.0/24 AS_PATH 1
AS4
192.168.1.0/24 AS_PATH 4 1
Figure 25 BGP Traffic Engineering Techniques IP2300/S3/v2.1
© wray castle limited
3.52
IP Engineering Overview
4.6.1
Path Pre-pending
By pre-pending the BGP path to particular networks with its own AS number, an ISP can negatively bias the ISPs receiving these announcements against sending traffic for this ISP via them. This approach can modify the flow of ingress traffic at this peering point, but can make Internet routing very sub-optimal.
3.53
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
192.168.1.0/24 AS_PATH 2 1
192.168.1.0/24 AS_PATH 1
AS3 AS2
All
tra
192.168.1.0/24 AS_PATH 3 2 1
ffic
192.168.1.0 Internet AS1
192.168.1.0/24 AS_PATH 1 1 1
AS4
192.168.1.0/24 AS_PATH 4 1 1 1
Figure 25 (continued) BGP Traffic Engineering Techniques IP2300/S3/v2.1
© wray castle limited
3.54
IP Engineering Overview
4.6.2
Specific Route Injection
BGP route calculation always prefers a longer prefix match over the AS path length. Therefore by injecting a more specific route into eBGP announcements, it is possible to attract traffic for this destination network across the peering point. This approach has a high administrative overhead, however, and works against address aggregation and CIDR.
3.55
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
192.168.1.8/29 AS_PATH 2 1
192.168.1.8/29 AS_PATH 1
AS3 AS2
192.168.1.8/29 AS_PATH 3 2 1 192
.16 tra 8.1.8 ffic /29
192.168.1.0 AS1 19
192.168.1.0/24 AS_PATH 1
ing affic n i tr a 4 m 2 Re 1.0/ 8. 6 1 2.
AS4
Internet
192.168.1.0/24 AS_PATH 4 1
Figure 25 (continued) BGP Traffic Engineering Techniques IP2300/S3/v2.1
© wray castle limited
3.56
IP Engineering Overview
5
SECTION 3 QUESTIONS
1
Describe the main functions carried out in the core, distribution and access layers of a service provider IP network.
2
An IXP mainly offers: a b c d
3
Routing tables may be populated: a b c d
4
statically dynamically neither, routes are learnt from routing protocols running in the network both a and b
OSPF is an example of: a b c d
5
the ability to host application servers to smaller ISPs the ability to outsource network operations the ability to interconnect with other ISPs in a shared facility the ability to access the overall Internet backbone, operated by the NSF
a traditional IGP, which does not scale well a traditional EGP, which does not scale well a modern IGP, which scales well a modern EGP, which scales well
BGP4 is an example of: a a protocol that exchanges reachability information between autonomous systems b a protocol that allows policy control across peering points c a protocol that allows the control of traffic flows through tuning of its routing metrics d all of the above
3.57
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
6
Routing across the customer/service provider routing domain should adhere to the following principles: a use a dynamic routing protocol where possible across the customer/service provider interface, to minimize administrative work b avoid dynamic routing across the customer/service provider interface, unless the size or complexity of the customer network demands it c always import and export the maximum number of routes between the customer and service provider, so that customer routers can always forwards packets successfully d always allocate a private AS number to customer networks, so that eBGP can operate across the customer/service provider interface
7
BGP implementations within an AS can be made more scalable by the use of: a b c d
IP2300/S3/v2.1
BGP path pre-pending BGP route filtering OSPF areas BGP route reflectors
© wray castle limited
3.58
IP Engineering Overview
3.59
© wray castle limited
IP2300/S3/v2.1
IP Engineering Overview
SECTION 4
FUTURE DIRECTIONS IN IP ENGINEERING
© wray castle limited
i
IP Engineering Overview
ii
© wray castle limited
IP Engineering Overview
SECTION CONTENTS 1
IP QoS Technologies 1.1 What is Quality of Service (QoS)? 1.2 Why QoS is Important 1.3 What Causes Poor QoS? 1.4 Where do Packet Loss and Delay Occur? 1.5 QoS Approaches in IP Networks 1.6 The Overcapacity Approach 1.7 IETF Approach to IP QoS 1.8 Integrated Services Model 1.9 Resource Reservation Protocol (RSVP) 1.10 Differentiated Services Model (DiffServ) 1.11 IP over ATM QoS 1.12 QoS in MPLS Networks
4.1 4.1 4.3 4.3 4.3 4.5 4.5 4.7 4.7 4.9 4.11 4.13 4.15
2
IP Virtual Private Networks (VPN) 2.1 What is a VPN? 2.2 Tunnelling 2.3 VPN Applications: Intranets, Extranets and Remote Access 2.4 Types of VPN 2.5 MPLS-based IP-VPN Motivation 2.6 Architecture of MPLS-based IP-VPNs 2.7 MPLS VPN Operation 2.8 Motivation for Encryption-based IP-VPNs 2.9 Secret Key Cryptography 2.10 Public Key Cryptography (PKC) 2.11 IPSec Operation 2.12 IPSec Gateway Location 2.13 Products Supporting IPSec
4.17 4.17 4.17 4.19 4.21 4.23 4.25 4.27 4.29 4.31 4.31 4.33 4.35 4.35
© wray castle limited
iii
IP Engineering Overview
iv
© wray castle limited
IP Engineering Overview
SECTION CONTENTS 3
Security Engineering 3.1 The Basics 3.2 Quantifying the Risk 3.3 Basic Countermeasures 3.4 Other Countermeasures – Security Appliances 3.5 Other Countermeasures – Software Solutions 3.6 Proportionality of Countermeasures 3.7 Case Study 1 – Enabling B2B and B2C Communications 3.8 Case Study 2 – Enabling B2C Transactions 3.9 Case Study 3 – Mobile Computing
4.39 4.39 4.41 4.43 4.45 4.47 4.49 4.51 4.53 4.55
4
IPv6 4.1 4.2 4.3
4.57 4.57 4.59 4.59
Motivation for IPv6 Development IPv4/IPv6 Co-existence IPv6 Product Availability
5
Mobility 5.1 Public Service Wireless LANs 5.2 The IETF Architecture for Mobile IP
4.61 4.61 4.63
6
Section 4 Questions
4.65
© wray castle limited
v
IP Engineering Overview
vi
© wray castle limited
IP Engineering Overview
SECTION OBJECTIVES At the end of this section you will be able to: • • • • • •
differentiate between the QoS techniques available for IP networks understand the applicability of QoS to public service IP networks describe the strengths and weaknesses of the main VPN technologies discuss the main countermeasures against these threats understand the threats, vulnerabilities and risk to IP networks describe recent innovations in IP networking, including wireless LANs, IPv6 and mobility
© wray castle limited
vii
IP Engineering Overview
1
IP QOS TECHNOLOGIES
1.1
What is Quality of Service (QoS)?
The ITU has defined both Quality of Service (QoS) and Network Performance as important measures of communications effectiveness. In their model QoS is concerned with the experience of users of the service, while network performance is concerned purely with the network, rather than end equipments or subjective measures. However, the general models have not been well developed for connectionless networks such as IP, for the reasons discussed below. QoS measures can be applied to aspects such as the availability of a service on a long-term basis. The focus in this section will be on the short-term performance of the network for a particular flow of traffic. QoS is easily measured and engineered in circuit-switched networks, partly because of many years of experience in doing it, but mainly because the circuit-switching is relatively simple to analyze and measure. Generally the QoS is characterized for each phase of a call, namely connection set-up, user information transfer and connection tear-down. Measures such a Post Dial Delay (PDD) and Grade of Service (GoS) are well-established and effective measures of the performance of a circuit-switched network in the call-set-up phase, and because a hard resource reservation is made when a voice circuit is seized, performance in the user information transfer phase is dominated by the Bit Error Rate (BER) of the transmission system. Virtual circuit technologies present additional challenges in measuring QoS. The three phases used in circuit-switching still apply, and so measures such as PDD and GoS can still be used to assess the quality of the call set-up phase in BroadbandISDN networks, for example. However the packet-switched information transfer phase introduces new complications, such as lost packets, misdelivered packets, delay and delay variation. The ATM model also makes hard resource reservations when a virtual circuit is established (at least for the higher priority services), and so by making the correct planning assumptions, and running effective Connection Admission Control (CAC) in the network when calls are offered, an ATM network can meet any necessary QoS performance required of it. Connectionless technologies, such as IP, no longer have the set-up and tear-down phases that occur for real in virtual circuit switching. Because there is no concept of a circuit in an IP network, there can be no reservation of resources on a per-circuit basis. Therefore traditional IP networks have been unable to offer any meaningful QoS guarantees, because the techniques to engineer QoS were not available within the architecture.
4.1
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Circuit Switching Real circuits Signalling entity
.. ..
.. ..
Connection Admission Control (is a circuit available?) ‘Hard’ Resource Reservation (seize a circuit)
Virtual Circuit Switching Virtual circuits Signalling entity
Connection Admission Control (are resources available?) ‘Hard’ Resource Reservation (seize memory and bandwidth)
Datagram Switching Router
Datagrams
No Connection Admission Control No Resource Reservation Figure 1 The QoS Capabilities of Switching Technologies IP2300/S4/v2.1
© wray castle limited
4.2
IP Engineering Overview
1.2
Why QoS is Important
Different applications place different requirements upon the QoS available from a network as it carries user traffic. Real-time interactive applications such as voice and videoconferencing require very low delay and delay variation, but will tolerent significant packet loss within the network. Non-real-time applications such as file transfers will accept significant delay and delay variation but are intolerant of packet loss that is not recovered.
1.3
What Causes Poor QoS?
Lack of resources within the network to meet demand is the cause of poor QoS. In the circuit-switched case, insufficient call handling capacity or bearer capacity leads to blocked calls. In an IP network, congestion at the routers can cause increased delay, increased delay variation and dropped packets. If packets do not experience congestion, then they will achieve the best performance possible with the network.
1.4
Where do Packet Loss and Delay Occur?
In most cases, network congestion occurs at the edge of the network, rather than in the core. It is typically at the edge of the network that bandwidth is most constrained. This may be because of the high cost of access bandwidth to the service provider Point of Presence (PoP), or high contention ratios in the distribution network.
4.3
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
User Customer router
Ok
Ok
Access router
Low bandwidth link Dropped packets
Distribution router
High contention ratios
Core router
Ok
Ok
Dropped packets Increasing congestion Increasing bandwidth
Figure 2 The Causes of Poor QoS IP2300/S4/v2.1
© wray castle limited
4.4
IP Engineering Overview
1.5
QoS Approaches in IP Networks
There are three main approaches to avoiding congestion in IP networks: • overcapacity • integrated services • differentiated services
1.6
The Overcapacity Approach
The overcapacity approach simply relies on planning to have excess capacity that provides headroom within the network, and so avoids congestion. Most Internet backbones rely on this overcapacity approach to achieve very low packet loss, and delay close to the physical propagation limits. This approach has been strongly advocated by Internet ‘purists’, who dislike the move away from the dumb network, smart host model of IP networks, which other QoS approaches represent. However there are issues with this approach: • the overcapacity model works well when network demand is growing strongly; by commissioning capacity a few months earlier than necessary, the network maintains the necessary headroom to operate without loss or delay • conversely, when growth is not strong, this overcapacity is expensive • overcapacity works well in the core of the network, but is difficult to provide on expensive access circuits • the overcapacity model works well with large numbers of independent traffic flows (as in the core), but works less well with a smaller number of flows, which are not independent (as at the access layer) • the over capacity model may work well in ‘normal’ operating conditions, but in extreme conditions, it is impossible to protect critical traffic, since there is no way to distinguish it from other traffic
4.5
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Network capacity
S
cas e r o f upply
a Dem
Q1 2003
Q2
Q3
Q4
Q1 2004
Q2
Q3
t
s reca o f d n
Q4
t
Q1 2005
Q2
Time
Figure 3 The Overcapacity QoS Model IP2300/S4/v2.1
© wray castle limited
4.6
IP Engineering Overview
1.7
IETF Approach to IP QoS
Two methods of providing QoS on the Internet have been proposed by the IETF. The first uses Resource Reservation Protocol (RSVP) and is known as the Integrated Services (IntServ) architecture. The second is known as Differentiated Services (DiffServ). Both approaches rely upon altering the Per Hop Behaviours (PHBs) of routers forwarding IP traffic. However, whereas DiffServ simply sets up categories of traffic in the routers, and classifies packets into one of these categories for proper handling, IntServ uses a signalling protocol to request the reservation of resources on a flow-by-flow basis.
1.8
Integrated Services Model
The Integrated Services Model uses a protocol called RSVP for a call set-up process in which users request bandwidth and QoS. The routers in the network respond as to whether they have sufficient resources. Processing is required within each router from source to destination and each packet sent by the source is monitored to ensure that the source does not exceed the agreed traffic specification. Each packet has attached to it a flow identifier, which is analyzed by each router, which it traverses so as to identify the packet as one for which bandwidth has been reserved.
4.7
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Source Resources reserved across networks
Individual User
Destination
QoS Guaranteed Controlled Load
Figure 4 The Integrated Services QoS Model IP2300/S4/v2.1
© wray castle limited
4.8
IP Engineering Overview
1.9
Resource Reservation Protocol (RSVP)
RSVP has two fundamental RSVP message types for Reserving QoS. These are the PATH and RESV messages. The PATH messages are sent to the receiver in order to store path state in each node along the way. The RESV messages are sent from the receiver towards the sender following the reverse of the PATH message. They create and maintain reservation state in each node towards the sender.
1.9.1
PATH Message
The source sends out a PATH message requesting a certain Reserved Rate, R. Each router and switch between source and destination examines the PATH message and estimates the delay that it would cause to traffic if the connection specified in the PATH message was established. These delays are accumulated as the PATH message traverses the network.
1.9.2
RESV Message
By the time the PATH message has reached the destination, it contains the cumulated total of all the nodal delays. The destination can then calculate the end-toend delay and send a RESV message back to the source with the requested QoS. If the destination can accept a longer delay, it can inform the network about this by setting a slack term, S, in seconds. In return, the destination would expect the network operator to give a discounted price. The RESV message contains a flowspec which has two parameters, an Rspec and Tspec.
1.9.3
Have We Created a Virtual Circuit?
The IntServ model using RSVP mimics some of the behaviour of circuit switching. It allows the path through the network to be established and stored for each signalled flow, and it makes a resource reservation for that flow at each router. The concept of a connection has been imposed upon the connectionless IP network. The main difference between this approach and a virtual circuit is that the path taken is still controlled by routing protocols in the IP network. Therefore if the network decides that traffic should be rerouted, the RSVP messages will request reservations on the new routers they cross. A reservation will expire if new messages are not received to renew it, hence the continuous flow of signalling that is required in the RSVP model¹.
¹ This approach is known as soft state, to distinguish it from the hard state of traditional circuit switching or virtual circuit switching.
4.9
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
PATH Dest:158.20.2.7 Source: 134.199.200.20 UDP Port 1234 Tspec
PATH Dest:158.20.2.7 Source: 134.199.200.1 UDP Port 1234 Tspec
PATH Dest:158.20.2.7 Source: 158.20.2.1 UDP Port 1234 Tspec
134.199.200.20
158.20.2.7 PATH
PATH
PATH
RESV 134.199.200.1
RESV
RESV
Source
RESV UDP to 134.199.200.20 Flowspec (Rspec, Tspec)
PATH
158.20.2.1
RESV
Receiver
RESV UDP to 134.199.200.1 Flowspec (Rspec, Tspec)
RESV UDP to 158.20.2.1 Flowspec (Rspec, Tspec)
Figure 5 RSVP Operation IP2300/S4/v2.1
© wray castle limited
4.10
IP Engineering Overview
1.10
Differentiated Services Model (DiffServ)
The Diffserv architecture does not include a signalling mechanism such as RSVP, and does not reserve resources for individual flows. Instead a set of Class of Service (CoS) is designed for the network, and router resources are apportioned to these classes. So, for example, a network operator might implement a gold, silver and bronze CoS which can be sold to customers. By configuring the queuing behaviour of the routers within the network, it is possible to give priority to packets in the gold category over those in the silver, and to those in the silver over those in the bronze. Queuing algorithms also allow a guaranteed portion of the available output bandwidth on any port to be allocated to one of the CoS. So, for example, 20% of the available bandwidth might be guaranteed for the gold class. If more bandwidth is required, the non-guaranteed bronze bandwidth can be taken. However if the gold class required more than 70% of the available bandwidth, this could not be provided, because this would violate the silver guarantees (30%). All unused bandwidth is available for other classes as required. So in the example in Figure 6, when silver no longer needs its allocation, this is available for gold (or bronze) to use. To allow routers to recognize which category a packet belongs to, it must be tagged as belonging to the gold, silver or bronze class. This is done as the packet enters the DiffServ network, by packet classifiers. These classifiers are configured to recognize traffic from particular addresses, or on particular TCP or UDP ports, as belonging to one of the three classes. The DiffServ CoS for a packet is carried in the IPv4 datagram Type of Service (ToS) byte, which has been re-designated the Differentiated Services (DS) header for this purpose.
4.11
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
100
Per hop behaviour
Bronze bandwidth utilization
Category
% Bandwidth
Priority
Gold
20 %
High
Silver
30 %
Medium
Bronze
unassigned
Low
% Bandwidth
90 80
50 40 30
Per hop behaviour
Silver bandwidth utilization
Gold bandwidth utilization
20 10
Time
DiffServ packet classifier
Site A
Site B DiffServ routers
from
to
port
CoS
Comment
corp. site A
corp. site B
tcp/80
silver
Intranet WWW
*.*.*.* *.*.*.* *.*.*.* *.*.*.* *.*.*.* *.*.*.*
tcp/80
bronze
Internet WWW
tcp/21
bronze
Internet FTP
tcp/110
bronze
Internet POP3 e-mail
corp. site A
udp/rtp
gold
. . .
corp. site B
. . .
. . .
. . .
Corporate VoIP
. . .
Figure 6 The Differentiated Services QoS Model IP2300/S4/v2.1
© wray castle limited
4.12
IP Engineering Overview
1.11
IP over ATM QoS
1.11.1
ATM Class of Service (CoS)
ATM has CoS which allow predictable performance to be achieved for a wide range of requirements. Although other classes are available, most public service ATM networks limit the CoS available to Constant Bit Rate, Variable Bit Rate, and Unassigned Bit Rate.
1.11.2
QoS mapping between IP and ATM
With the introduction of IntServ and DiffServ, IP and ATM each have QoS mechanisms. ATM Permanent Virtual Circuits (PVC) allow traffic to be carried on trunk connections, without the need to set up connections through ATM signalling. Each PVC has a category of service, which defines the QoS to be expected from the connection. ATM Switched Virtual Connections allow circuits to be set-up and disconnected on demand using ATM signalling, and with a CoS to meet the QoS parameters of the connection being requested. The IP Diffserv architecture allows reservations of bandwidth to be made for each CoS being carried by the network, without the need to signal each flow. The IntServ architecture provides a signalling mechanism rather like ATM signalling, which allows reservations to be set up on demand for particular flows through the network. Public ATM networks almost unanimously use a PVC-only model of service, and do not support user-network signalling to set up ATM connections on demand. Furthermore, the IP network operators have unanimously preferred the DiffServ model to the IntServ model for providing QoS in IP networks. And finally, the signalling models of ATM and RSVP are fundamentally different; ATM assumes a sender-initiated connection, whereas RSVP assumes a received-initiated connection. For these reasons, approaches that involve service interworking between Intserv and ATM signalling have not been deployed, and IP over ATM approaches are based upon combinations of DiffServ, ATM PVCs and packet classification.
4.13
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
ATM SVC and IntServ Interworking
IWF
IWF ATM SVC
RSVP path RSVP resv
RSVP path RSVP resv
IWF must provide signalling interworking
ATM PVC and DiffServ Interworking ATM PVC DS packets
IWF
IWF
Packet classifier
Packets contain DS pattern
Packets contain DS pattern IWF provides Class of Service to Category of Service mapping
IWF Functions DS code to ATM CoS mappings IP to ATM adaptation functions IP address to PVC mappings (RSVP to ATM signalling mapping)
Figure 7 IP over ATM QoS Models IP2300/S4/v2.1
© wray castle limited
4.14
IP Engineering Overview
1.12
QoS in MPLS Networks
MPLS technology was designed to support the IP QoS techniques. The MPLS header has a section designed to carry the CoS field from IP packets. MPLS allows Label Switched Paths (LSPs) to be set up in a variety of ways, including by signalling using RSVP, and by manual configuration. The manual configuration of MPLS LSPs is similar to the PVC approach of ATM and the signalling approach of MPLS using RSVP is similar to the RSVP signalling approach of the Intserv architecture, or the signalling approach of ATM. Although an MPLS core network could establish LSPs for each flow of traffic on demand (the equivalent of ATM Virtual circuits), instead it typically operates more like Diffserv, by providing a trunk connection between the edges of the network, and guaranteeing the delay, delay variation and loss performance of that trunk for all traffic carried across it. Public network operators generally see MPLS technology as a way to provide reliable, controlled forwarding of IP traffic. Normally a separate trunk connection is provided between the edges of the MPLS network for each CoS being carried by the service provider. When MPLS implements QoS in this way, then instead of one FEC for a set of IP addresses, there are multiple FECs, one per CoS to this group of addresses. This also means that the MPLS Label Switched Routers (LSRs) do not need to consider QoS when forwarding packets, making their operation simpler. Packet classifiers in the LSRs at the edge of the network place traffic into the correct FEC (and hence trunk) within the MPLS network by classifying packets as in the DiffServ architecture. If the packets have already been classified (perhaps because DiffServ has operated at the edge of the network), then the DiffServ codes would be mapped into the appropriate FEC. Effectively setting up and managing the MPLS trunks that provide this service is itself a complex task, known as traffic engineering.
4.15
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
LSR
bronze LSP
LSR
192.168 . .
**
10.2 . .
**
silver LSP edgeLSR
LSR corp. site B
go
corp. site A
ld LS P
MPLS ‘packet classifier’ LSR
from
to
192.168 . .
**
port
10.2 . .
**
tcp/
**
LSR
CoS
FEC . . .
bronze
24
corp. site A
corp. site B
udp/rtp
gold
25
corp. site A
corp. site B
tcp/21
silver
26
. . .
Figure 8 QoS in MPLS Networks IP2300/S4/v2.1
© wray castle limited
4.16
IP Engineering Overview
2
IP VIRTUAL PRIVATE NETWORKS (VPN)
2.1
What is a VPN?
The answer to the simple question ‘What is a VPN?’ is anything but simple, and leads to much of the confusion and debate surrounding the subject. AT&T coined the term Virtual Private Network (VPN) to market a corporate voice service that ran across their Public Switched Telephone Network (PSTN), but which provided the look and feel of a leased line interconnection between Private Branch Exchanges (PBXs) by using a proprietary signalling protocol. A good working definition of a VPN might be ‘A service with the behaviour and characteristics of a private, dedicated network, but constructed on a shared infrastructure’. Although this definition could include a private leased circuit as a Layer 1 VPN, we normally limit the definition to L2 services and above.
2.2
Tunnelling
VPNs normally require that user traffic be tunnelled across the shared infrastructure. This provides several benefits: • it ensures that VPN traffic enters and exits the public network at the intended points, rather than by some alternative route • it ‘hides’ the private address scheme from the shared network, so that address conflicts are avoided, and changes within the private network do not require changes to the public service • it ‘hides’ the shared network architecture from the private network, so that internal architecture issues do not affect the service, and changes to it do not affect the operation of the VPN Figure 9 shows IP traffic being tunnelled within IP. The hosts communicating have addresses in the 192.168.1.0 network, but are connected through routers with addresses in the 10.0.0.0 network. These interfaces on the routers are also configured to act as tunnel endpoints, and so they encapsulate the user traffic so that it appears to originate and terminate on the routers. The original IP source and destination addresses are now simply part of the payload of the tunnelled packet. At the far-end tunnel endpoint, the encapsulation is removed, and the original packet is routed to the intended host at 192.168.1.2. This example shows tunnelling of IP traffic within IP, but we can consider transport of IP traffic across Layer 2 switched connection such as Frame Relay and ATM as tunnelling also. The two main types of VPN we will consider in this section are Multiprotocol Label Switching (MPLS) VPNs and IP Security (IPSec) VPNs. MPLS VPNs tunnel IP traffic across MPLS LSPs. IPSec VPNs tunnel IP traffic across IPSec tunnels.
4.17
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Virtual Private Network ‘A service with the behaviour and characteristics of a private, dedicated network, but constructed on a shared infrastructure’
Conventional Connection
192.168.1.1 (A)
10.0.0.1 (C)
B A
Payload
192.168.1.2 (B)
10.0.0.2 (D)
B A
header
Payload
B A
header
Payload
Tunnelled Connection
192.168.1.1 (A)
10.0.0.1 (C)
header
192.168.1.2 (B)
10.0.0.2 (D)
Tunnel established
B A
Payload
B A D C
header
Payload
B A
header
Payload
header
Figure 9 Tunnelling IP2300/S4/v2.1
© wray castle limited
4.18
IP Engineering Overview
2.3
VPN Applications: Intranets, Extranets and Remote Access
2.3.1
Intranet
An Intranet application connects separate sites within an organization across a public infrastructure. These connections are normally long-standing, and can be in a hub and spoke, full mesh or hybrid configuration. Traditional L2 VPN technologies have favoured hub and spoke arrangements, due to the higher cost of provisioning a mesh of PVCs. In an intranet VPN, it is assumed that all sites are equally trusted with access to other sites across the VPN, and that users already have accounts and privileges on the remote systems, hence implementing an intranet VPN and integrating it with existing enterprise systems is normally fairly straightforward.
2.3.2
Extranet
An Extranet VPN application connects separate sites within separate organizations across a public infrastructure. Extranet VPNs allow businesses to permit access to controlled portions of their IT systems to partners, customers or suppliers on a long or short-term basis. Establishing suitable access control mechanisms for extranet users is typically a separate issue from the authentication of end-points and the security of data across the VPN, and can lead to difficult policy and practice issues. One of the attractions of the Secure Socket Layer (SSL) protocol for extranet use is the ability to place shared information and applications in a controlled zone away from the main corporate network.
2.3.3
Remote Access
A Remote Access VPN provides access to the corporate intranet via some ondemand access technology, typically a dial-up modem or ISDN call across the circuitswitched network, or an ADSL connection for a home worker. Because the connection is on demand and may be roaming, special care must be taken in mutual authentication of the client and gateway, and to ensure that vulnerabilities of the laptop or home system do not allow penetration of the corporate network across the ‘trusted’ VPN connection. Once the VPN is established, remote workers typically have the same access to facilities as they would have at their normal office location, although of course the end-to-end performance of the VPN connection will determine the QoS experienced by the user.
4.19
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
wraycastle USA
wraycastle UK Intranet
Public IP network
Extranet
Remote access
wraycastle home worker
Customer site
Figure 10 Intranets, Extranets and Remote Access VPNs IP2300/S4/v2.1
© wray castle limited
4.20
IP Engineering Overview
2.4
Types of VPN
Various approaches to building VPNs have been developed: • Layer 2 virtual leased line VPNs (for example Frame Relay and ATM) • Layer 3 over native Layer 2 VPNs (for example Multiprotocol over ATM (MPOA) and LAN Emulation (LANE)) • transport layer VPNs (for example Secure Sockets Layer (SSL) and Transport Layer Security (TLS)) • application layer VPNs (for example Secure MIME (S/MIME) and Secure Shell (SSH)) In this course, we concentrate on the two main approaches to implementing VPNs at the IP layer. These are very different in their approach, but both are sold by a wide range of IP Service Providers as IP-VPNs.
2.4.1
Layer 3 Network Protocol-based VPNs
The IP networking community, led by the major equipment vendors, has developed an MPLS-based VPN architecture, specified in RFC 2547. The MPLS architecture builds upon the basic technology of IP and MPLS. It can be viewed as a development of the traditional Layer 2 VPNs and the Layer 3 over native Layer 2 VPNs.
2.4.2
Layer 3 Encryption-based VPNs
The network security community has developed an IP VPN architecture based upon a technology called IPSec, which is specified in RFCs 2401–2412. The IPSec architecture is driven by security, and it has much in common with protocols such as Secure Sockets Layer, in that its basic technology is encryption. However IPSec operates exclusively at the IP layer, by encrypting packet payloads, and so is a true IP layer VPN.
4.21
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Encryption-based VPNs Application Layer:
S/MIME SSH etc.
Transport Layer:
SSL TLS
IP Layer:
Reference
IPSec RFC 2401–2412
Network Protocol-based VPNs IP Layer: IP Layer over Native Layer 2: Link Layer:
MPLS VPN LAN emulation MPOA Virtual Leased Lines ATM Frame Relay
Reference
RFC 2547
Figure 11 Encryption and Network-Protocol-Based VPNs IP2300/S4/v2.1
© wray castle limited
4.22
IP Engineering Overview
2.5
MPLS-based IP-VPN Motivation
MPLS integrates the label swapping approach of Frame Relay and ATM with a new control plane model for setting up and tearing down ‘connections’ (LSPs in MPLS terminology) that moves away from the ITU-T signalling model, and towards IP routing for control. This philosophy extends to the MPLS-VPN application also, and potentially delivers some attractive benefits: • A Layer 2 VPN requires configuration by the Network Operations Centre (NOC) of the Customer Premises Equipment (CPE) router with virtual circuit identifiers and IP to Layer 2 mappings, however the MPLS VPN approach requires no CPE configuration; all provisioning is carried out on the Provider Edge (PE) routers within the service provider network. • A Layer 2 VPN must be provisioned by the NOC through the core network by establishing end-to-end virtual circuits for each customer. However, an MPLS core network holds no information concerning the MPLS-VPNs that run across it. • A Layer 2 VPN has scalability limitations because all CPE routers are adjacent from a routing perspective, leading to processing overload as the number of customer sites grows, unless some routing hierarchy is introduced. In an MPLS VPN, each CPE router has a single routing peer, and has no direct interaction with the other CPE routers, therefore the processing load on customer routers is much reduced.
4.23
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Conventional Frame Relay or ATM VPN Service Customer premises
Customer premises
Service provider network
CPE
CPE
NOC
Provisioning of VPN Router A
Router B Routers A and B are routing peers
MPLS VPN Service Customer premises
Customer premises
Service provider network
LSR
LSR LSR
Router A and service provider router are routing peers
LSR
Router B and service provider router are routing peers
LSR LSR
CPE
LSR
Provisioning of VPN
CPE
NOC Router A
Router B
Figure 12 Motivation for MPLS VPNs IP2300/S4/v2.1
© wray castle limited
4.24
IP Engineering Overview
2.6
Architecture of MPLS-based IP-VPNs
MPLS VPNs operate from a service perspective at the IP layer, and classify routers in the customer and service provider network into one of four types, as shown in Figure 13. Customer Edge (CE) and Provider Edge (PE) routers operate at the boundary of the customer and service provider networks respectively. Unlike the L2 VPN model, the CE and PE routers are peers from a routing perspective. The VPN functionality is centred on the PE router. The CE router typically requires no VPN-specific configuration, simply treating the PE router as the next hop router in a ‘private’ network. The Provider routers (P) in the service provider core also have no knowledge of the VPN address or routing information, and simply provide transport across the core network. The Customer (C) routers are conventional enterprise routers, with no special relationship to the VPN service. MPLS VPNs assume that the service provider operates an MPLS core between PE routers to which customers attach, and that this core has mechanisms for the establishment of LSPs between these edge routers. The MPLS core LSPs may have been manually provisioned, or may have been established by one of the other MPLS control plane mechanisms. All of this is independent of the MPLS VPN service, but this infrastructure is required for the MPLS VPN model of RFC 2457 to operate. This separation of the core routing from the VPN functionality that MPLS VPNs achieve is possible because the MPLS VPN architecture uses label stacking to tunnel a customer’s VPN traffic across the MPLS core. Decisions about how to switch the traffic are made at the originating PE router, which understands both the customer VPN locations, and the LSPs in place across the core. Therefore it can apply a pair of labels as traffic enters the network from customer sites. The inner label is a VPN label, and allows the traffic to be routed to the correct customer site at the destination PE router. This label is not examined or changed by the core routers. The outer label is a conventional LSP label, which allows the packet to be switched across a trunk LSP through the network core which joins the PE routers. This label is examined and modified at the core routers, and operates like a conventional virtual circuit identifier.
4.25
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Customer router
Customer router CE router
PE router
PE router
Provider routers
LSR
LSR
LSR
LSR LSR
IP
Conventional IP packet from customer
CE router
IP 1 2
LSR
IP 1 3
IP 1 4
IP packet within MPLS label stack 1 = VPN label 2, 3, 4 = MPLS trunk labels
IP
Conventional IP packet to customer
PE – Provider Edge CE – Customer Edge
Figure 13 Architecture of MPLS VPNs IP2300/S4/v2.1
© wray castle limited
4.26
IP Engineering Overview
2.7
MPLS VPN Operation
To set up an MPLS VPN, a service provider provisions the service at the PE routers serving that customer’s sites only. No configuration of non-serving PE routers, or of the core routers, is required. Conventional Interior Gateway Protocols (IGP) running between Provider and Provider Edge routers propagate reachability within the service provider core, and conventional MPLS techniques are used to establish the trunk LSPs between PE routers. All of this is independent of the VPN service. The VPN service itself is controlled by a routing overlay that does not interact with the core network routing and switching. Once the VPN sites have been configured within the PE routers, the PE routers learn which customer networks are reachable at the directly connected customer site. These customer routes may be statically configured by the service provider, or learnt through a conventional routing protocol running between the PE and CE routers. This information is stored in what are logically per-VPN routing tables, by attaching a VPN Identifier to the routing entries that is unique to each customer VPN. The per-VPN routing table entries held in the PE routers are propagated between all PE routers in the service provider network using Multiprotocol Border Gateway Protocol (MP-BGP). The PE routers therefore operate rather like conventional iBGP peers advertising external reachability. As the number of PE routers and customer sites grows, scalability of the MPLS/VPN approach can be improved by normal BGP mechanisms, such as use of BGP route reflectors. Traffic is forwarded between PE routers serving different sites of a VPN by MPLS label stacking. The originating PE router attaches a label for the destination IP address within the relevant VPN, followed by a label for the LSP across the core to the relevant PE router. The outer label is used to switch the packet across the service provider core without the core network needing any awareness of customer VPN routing. Subsequently at the destination PE router, the VPN-specific label is used to direct the packet to the appropriate local VPN site. Moves and changes to sites on an existing VPN are automatically propagated once the PE router serving the affected sites has been configured.
4.27
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
3. MP-BGP propagation of VPN routes and labels 2. Customer/SP routing protocol
2. Customer/SP routing protocol 4. Forwarding of customer traffic in label stack
1. VPN configuration
NOC
1. VPN configuration
Figure 14 Operation of MPLS VPNs IP2300/S4/v2.1
© wray castle limited
4.28
IP Engineering Overview
2.8
Motivation for Encryption-based IP-VPNs
Encryption-based VPNs achieve the separation of a customer’s traffic from that of other customers and the shared network infrastructure by using the mathematics of secret and/or Public Key Cryptography (PKC). The basic building blocks of cryptography are used to provide a set of security services in the encryption-based VPN approach. IPSec technology was developed because there was a perceived need to be able to secure traffic at the IP layer that was travelling across a variety of networks. VPNs are only one example of the use of IPSec, just as MPLS is used for other than VPN applications. The IPSec VPN approach is typically attractive to organizations with a strong security focus, for example financial organizations, healthcare organizations and government departments. IPSec VPNs can provide end-point authentication, data integrity, and data confidentiality services on a per-packet basis between two IPSec peers².
² It is common in the cryptographic community to use Alice and Bob as the intended communicators on a secure channel. By convention, Eve is an eavesdropper, and Mallory is an active attacker.
4.29
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
‘Alice’
‘Bob’ Intended communication
IPSec VPN user (source)
IPSec VPN user (destination)
‘Eve’ / ‘Mallory’
confidentiality interception
integrity
modification
authenticity
masquerading
Figure 15 Encryption-based VPN Security Services IP2300/S4/v2.1
© wray castle limited
4.30
IP Engineering Overview
2.9
Secret Key Cryptography
Traditionally secret key encryption has been used in military and government systems to protect the confidentiality of data in transit. The mathematics of secret key cryptography have changed very little in hundreds of years, but as processing power has increased, the cryptographic strength needed by an algorithm for it to be considered secure has increased dramatically. Secret key cryptography uses a symmetrical algorithm and a secret key known only to the sender and recipient. A plaintext message to be sent across an insecure channel is encrypted using the secret key and the algorithm. The receiver is able to recover the plaintext message provided they have the ciphertext, the algorithm and the secret key that was used to encrypt it. Secret key cryptography is widely used in many systems, and there are various algorithms available, some of which are government approved and licensed. Examples include the Data Encryption Standard and the Advanced Encryption Standard (AES). Although secret key encryption is secure and efficient, the distribution of secret keys to the communicators has always been problematic. While government and military organizations could achieve this through their highly structured organizations, secret key encryption is extremely difficult to implement in less controlled environments.
2.10
Public Key Cryptography (PKC)
In the early 1970s, a new approach to cryptography called Public Key Cryptography was proposed and proved for the first time, and has subsequently revolutionized the use of encryption. Public key systems use an asymmetric encryption approach. Two matching keys are generated, such that a message encrypted with one key of the pair can only be decrypted using the other, matching key. While the public key is freely distributed, the private key is closely guarded. Because someone sending a secure message only needs the recipient’s public key, the key distribution problem is much simplified. Examples of public key algorithms include the Rivest, Shamir and Adleman (RSA) algorithm, and the Diffie-Helman (DH) algorithm. The main role of public/private key encryption is in solving the key distribution problem. It is computationally much less efficient than secret key encryption, and so hybrid systems combining both techniques are commonly developed.
4.31
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Secret Key Cryptography plaintext
ciphertext
plaintext
message
secret key algorithm
secret key algorithm
message
‘Alice’
secret key
secret key
‘Bob’
Public Key Cryptography plaintext
ciphertext
plaintext
message
public/private key algorithm
public/private key algorithm
message
‘Alice’
Bob’s public key
Bob’s private key
‘Bob’
Figure 16 Secret and Public Key Cryptography IP2300/S4/v2.1
© wray castle limited
4.32
IP Engineering Overview
2.11
IPSec Operation
IPSec is normally used with IKE, so that the negotiation and configuration of IPSec tunnels can be largely automated. In order to protect traffic between two IP devices using IPSec, an IPSec Security Association (SA) is established between the IPSec endpoints. This SA defines all of the parameters of the IPSec session, including: • which modes of IPSec are to be used, including tunnel or transport, and ESP or AH • which algorithms are to be used for key generation, encryption and authentication • various timers that control the regeneration of key material and expiry of the SA • policy filters that specify whether particular traffic should bypass the IPSec tunnel or is passed through IPSec In order to establish an IPSec SA, a number of steps are necessary: • the candidate end points for the association are configured with the policy setting to be applied to any SA established, and the definition of traffic that should be passed through an IPSec association • once a host has traffic that requires IPSec protection (based upon the traffic definition in the device), an IKE session is negotiated between the hosts. This is essentially a special IPSec tunnel used to carry IKE traffic only. This is known as IKE Phase One • once the IKE Phase One association is in place, an IPSec SA for the actual traffic can be negotiated. This is known as IPIKE Phase Two • once the IPSec tunnel is in place, traffic can flow across the tunnel. After a period of inactivity, or when the SA lifetime parameter expires, the IPSec tunnel is cleared
4.33
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Host A
Host B
Router B
Router A
1. Host A sends traffic invoking IPSec tunnel to host B 2. Routers A and B negotiate an IKE phase one session IKE SA
IKE Phase 1
IKE SA
3. Routers A and B negotiate an IKE phase two session IPSec SA
IKE Phase 2
IPSec SA
4. Information is exchanged via IPSec tunnel
5. On SA expiry, IPSec tunnel is terminated
Figure 17 IKE and IPSec Operation IP2300/S4/v2.1
© wray castle limited
4.34
IP Engineering Overview
2.12
IPSec Gateway Location
The normal position for IPSec gateway devices is at the boundary between the private and public network. Where the enterprise builds and operates an IPSec VPN itself, gateways will normally be behind an Internet firewall. Where a service provider installs and operates the VPN gateway, this may be on the customer premises, or at the local PoP. IPSec capability is widely supported in network devices, in operating systems and in applications. Because IPSec places no requirements on the network infrastructure (unlike the MPLS VPN approach), it can be deployed between any two devices that can operate IPSec.
2.13
Products Supporting IPSec
In practice, IPSec is normally deployed on one of four types of platform
2.13.1
Routers
IPSec functionality is often included in the capabilities of routers, or provided as an optional component in the software load. The border router connecting an enterprise to the public network can be used as an IPSec endpoint for Intranet and Extranet connections. These are typically not used to terminate dial-up users. Small access routers of the type used for home workers and branch offices increasingly have an IPSec VPN capability, and make effective branch office VPN endpoints, connecting to a VPN gateway at headquarters.
2.13.2
Firewalls
The main firewall vendors all support VPNs using IPSec on their products. Because these devices are already extensively tested from a security perspective, and are located at the boundary between the private and public network, they can provide an effective VPN gateway for remote access, Intranet and Extranet VPNs. For remote access, the firewall vendor may offer a remote access client application that is loaded on the PC connecting to the gateway.
4.35
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Intranet, extranet
Intranet, extranet
Firewall
Firewall
Remote access client Intranet, extranet
Dedicated VPN gateway
Dedicated VPN gateway
Intranet, extranet Software only
Software only
Figure 18 VPN Platforms and Supported Applications IP2300/S4/v2.1
© wray castle limited
4.36
IP Engineering Overview
2.13.3
Dedicated VPN Gateways
Dedicated VPN gateways typically have some routing and firewall functionality, but are primarily designed to make configuration and operation of VPNs using IPSec as simple and scalable as possible. These devices are typically deployed at the boundary of the corporate and public network, often in the De-Militarized Zone (DMZ), so that Intranet, Extranet and remote access VPN endpoints can access the gateway. The product vendor normally supplies a software VPN client for use in remote access applications.
2.13.4
Operating Systems
Since the launch of Windows 2000 Professional™ and Server™, Microsoft™ has included IPSec VPN functionality in their operating system products. The Routing and Remote Access Server (RRAS) component of their server products can act as a gateway for multiple remote access clients, and intranet and extranet configurations between machines are also possible. Other operating systems typically do not include IPSec VPNs as standard, however products and open source software are available to implement these on most varieties of Unix. Each type of platform has strengths and weaknesses, which will make it more or less suitable for a given set of requirements.
4.37
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Intranet, extranet
Intranet, extranet
Firewall
Firewall
Remote access client Intranet, extranet
Dedicated VPN gateway
Dedicated VPN gateway
Intranet, extranet Software only
Software only
Figure 18 (repeated) VPN Platforms and Supported Applications IP2300/S4/v2.1
© wray castle limited
4.38
IP Engineering Overview
3
SECURITY ENGINEERING
3.1
The Basics
Security is a fundamental part of any Internet Engineering project but is often overlooked or underestimated. The risks to a business and its information are varied and complex but once understood, can very often be mitigated against and/or managed. There are four fundamental principles that any business or organization needs to consider when reviewing its security.
3.1.1
Confidentiality
A business must protect its information from unauthorized access or disclosure. Such information may be company proprietary, human resource related, e.g. staff salaries, or customer proprietary, e.g. credit card details. Confidentiality may be compromised in many ways, both electronic and physical and the potential solutions will similarly be a combination of electronic, physical, procedural measures.
3.1.2
Integrity
Integrity is concerned with the completeness of information as well its accuracy. A business may rely on the integrity of its data to recover revenue and any compromise of such information can have a dramatic effect, e.g. billing information.
3.1.3
Availability
Can the information required to carry out a business’s day-to-day activities be accessed when required and if it can’t, what’s the maximum delay it can withstand before there is a significant impact?
3.1.4
Authentication and Non-repudiation
Can I be certain that the document I have really is from the business or organization that it appears to be from? Businesses need some assurance that a document received electronically is from a trusted source and also that certain actions can be attributed without question to certain individuals, e.g. I don’t want staff in sales to be able to masquerade as staff in credit control.
4.39
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
‘Alice’
‘Bob’ Intended communication
IPSec VPN user (source)
IPSec VPN user (destination)
‘Eve’ / ‘Mallory’
confidentiality interception
integrity
modification
authenticity
masquerading
Figure 19 Generic Security Services (revisited) IP2300/S4/v2.1
© wray castle limited
4.40
IP Engineering Overview
3.2
Quantifying the Risk
Knowing there is a risk and being able to mitigate it with a proportionate response requires an organization to quantify (at least to some degree) that risk. A common view of risk is that it is a function of threat, vulnerability and impact. Risk = f (threat, vulnerability, impact)
3.2.1
Threat
Threat can be considered to be the likelihood that some person or persons will attempt to compromise your information. Sources of threat may include competitors, journalists, internal staff and even activists.
3.2.2
Vulnerability
This is a measure of what potential vulnerabilities exist in the system that is protecting the information you care about. What are the mechanisms that you rely on to protect your information and just how well designed and implemented are they?
3.2.3
Impact
If your information is compromised do you care? What are the outcomes (from a financial perspective as well as reputation) to the business? Some case studies are given later but it its simplest form, a business with an aggressive competitor, numerous ways for its data be compromised and a significant likelihood of lost business and/or revenue if such a compromise took place has a lot to consider. A business that perceives no threat, is confident their information cannot be compromised and cares little if it actually is, probably has little to worry about (apart from being extremely naive!).
4.41
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Investigative journalist
Business network
Present employee Hacker
Organized crime
Past employee
Removeable media
Competitor
e-mail
WWW
lost customers and revenue fraud bad publicity business failure
Figure 20 Security Threats, Vulnerabilities and Impacts IP2300/S4/v2.1
© wray castle limited
4.42
IP Engineering Overview
3.3
Basic Countermeasures
3.3.1
Identification and Authentication
One of the most widely known security countermeasures is the ubiquitous logon. To ensure only those that are authorized to access information do so, mechanisms to check a user’s authenticity are employed. This can be something you know, have or are, but traditionally has been a username and password. However, increasing use is being made of tokens and smart cards (something you have) and a significant amount of research is being undertaken into technologies such as biometrics (something you are). This includes fingerprints, retina scanning and face recognition.
3.3.2
Access Control
Once authenticated, users may still want to ensure only certain individuals can access sensitive information and this is often enforced using access controls on files and folders. It is usual for these controls to be Discretionary (i.e. the file/folder owner can set access rights). Such controls are often implemented using a technique know as Access Control Lists which allow the file/folder owner to list those with explicit allow and deny permissions.
3.3.3
Accounting and Audit
In order to detect when actual or potential breaches in security occur, accounting is often performed and this data then audited at regular intervals to highlight any potential breach. Information such as who has logged on, when, from where and the actions they undertook while online, e.g. sent an e-mail, tried to access a file they didn’t have authorized access to. This data can be for a significant period of time and used at a later date to identify patterns over time or investigate users’ actions when they come under suspicion some time in the future. Figure 21 shows examples of each of these functions from Microsoft Windows 2000™, but similar functions are available in all multi-user operating systems.
4.43
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Figure 21 An Example of Security Services in Operation IP2300/S4/v2.1
© wray castle limited
4.44
IP Engineering Overview
3.4
Other Countermeasures – Security Appliances
3.4.1
Firewalls
Firewalls are the most widely used security appliance. A firewall is a device that protects one network from another, offering a controlled path between the two and providing a strong barrier to ensure that controlled path isn’t bypassed. Firewalls can come in a number of varieties. The simplest type of firewall is known as a stateless packet filter where individual packets are compared against a set of rules and allowed based on those rules. These devices are often the quickest as they only have to decode and examine the IP header of each packet but they offer the least security. More sophisticated is a stateful inspection firewall that allows more complex rules and the ability to control access based on the type of application being allowed or denied. These are perhaps the most common these days as they allow for some sophistication in the rule set but are still relatively quick. The most comprehensive of firewalls is known as a proxy firewall. Rather than connecting to the actual destination host (be it a web server, mail server or other device), a proxy firewall requires you to connect to it and allow it to act on your behalf by forwarding your requests on to the intended server. Using proxy servers often requires the client software (e.g. a web browser) to be aware of its existence and be configured accordingly although transparent proxies are becoming increasing popular, allowing client programs to be unaware that a proxy is acting on its behalf.
3.4.2
Intrusion Detection Systems (IDS)
Intrusion detection technologies are a relatively new security technology but are becoming increasingly popular. The aim of IDS is to detect (and as the technology develops, defend) against network intrusions. There are two types of IDS, host based and network based. As the name suggests, host-based systems protect a single host and monitor incoming and outgoing network activity for malicious activity. Network-based systems run as sensors on the network itself, monitoring all network traffic for malicious activity. The main underlying technology behind current IDS systems is signature based and (as with virus scanners), being able to detect the latest attacks relies on having the latest signatures loaded. There are anomaly detection-based systems that try to learn the normal activity on a network and then detect when activity diverts from that profile. However, these systems are still in their infancy and tend to lead to a significantly high false positive rate (i.e. highlighting problems which are in fact innocuous behaviour). 4.45
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
SMTP SMTP
Corporate network
Public network
HTTP (port 80)
HTTP (port 80)
Firewall configuration blocks inbound WWW connections in this example
IDS monitoring
IDS probe
Corporate network
Public network
IDS monitors packets for signature of hostile content
Figure 22 Firewalls and Intrusion Detection Systems IP2300/S4/v2.1
© wray castle limited
4.46
IP Engineering Overview
3.5
Other Countermeasures – Software Solutions
3.5.1
Virus Scanning
Virus scanners have been available for many years and the technology has changed little in that time. Their aim is to detect malicious software on a machine, either when it is run, copied from one media to another, or just resident on the machine’s internal hard disk drive. Virus scanners operate in two basic modes – signature and heuristic. Signature mode means that files are scanned for known virus signatures. The major disadvantage of this technique is that the signatures need constant updating if you are to be protected from the latest viruses. Heuristic mode offers the most potential but is still less than perfect. The idea behind this technique involves scanning for certain code segments or operating system library calls within an executable and making assumptions about their intent. Unfortunately this is far from an exact science and has significantly less than a 100% success rate.
3.5.2
Content Scanning
This is a very similar technique to virus scanning but is done in a slightly different way. As organizations have rushed to connect their corporate networks to the Internet, the risk from malicious attachments to e-mail or malicious content on web pages has become a significant problem. Content scanners usually reside at the boundary between the Internet and a corporate network and filter all incoming e-mail and web content for malicious attachments, e.g. executables and feature-rich application documents, and malicious web pages, e.g. those containing malicious ActiveX, Java and other active web content. These devices are increasingly becoming integrated with firewall products offering a cheaper single solution (although the security benefits over more traditional architectures is limited). There is also an increasing trend to outsource this functionality. Numerous companies are now offering to scan all incoming e-mails on an organization’s behalf. This can offer significant overhead savings (reduced cost of signature maintenance for example) but care should be taken when choosing such a provider and there is always a danger that you increase your risk in other areas by directing all incoming mail via another commercial company that has the potential at least to read it all!
4.47
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Client virus scanning
Mail server virus scanning
To public network
File server virus scanning
Internet firewall with content scanning
Figure 23 Virus Scanning and Content Scanning IP2300/S4/v2.1
© wray castle limited
4.48
IP Engineering Overview
3.6
Proportionality of Countermeasures
We have considered a number of countermeasures that mitigate some of the risks highlighted earlier. What is often hard to determine is which one (or combination) of these is appropriate and proportionate to the risk being considered. When considering countermeasures always consider the cost to your business of the compromise you are trying to prevent. Example – firewalls don’t prevent content attacks Organizations often deploy a firewall at the boundary of their corporate network and the Internet expecting it to mitigate all the risks associated with such a connection. However, with modern attacks becoming more application orientated, firewalls offer limited protection against such attacks and they can often leave organizations with a false sense of security. Meanwhile, their corporate secrets may leak out as a result of some malicious mail attachment that goes through the corporate firewall(s) unchecked.
4.49
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Countermeasures must be PROPORTIONATE to threats and impacts
Threats and Impacts Countermeasures
Figure 24 Proportionality of Countermeasures IP2300/S4/v2.1
© wray castle limited
4.50
IP Engineering Overview
3.7
Case Study 1 – Enabling B2B and B2C Communications
ACME Corporation wish to connect their internal corporate office network to the Internet and enable electronic commerce with customers, suppliers and business partners. What security implications are associated with such a plan?
3.7.1
Threats
• customers (wishing to get something for nothing) • business partners (wishing to get a commercial advantage) • other competitors
3.7.2
Vulnerabilities
• attack via the external connection itself • attack via malicious e-mail attachments
3.7.3
Impact
• loss of business • loss of reputation with customers and business partners
3.7.4
Countermeasures
• firewall between Internet and corporate network • virus scanning on the desktop • content filtering at the network boundary
4.51
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
ACME corporation
Business partner
Internet
Supplier 1
Customer 1
Customer 2
What are the security implications?
Figure 25 Case Study 1: Opening up the Corporate Network IP2300/S4/v2.1
© wray castle limited
4.52
IP Engineering Overview
3.8
Case Study 2 – Enabling B2C Transactions
ACME Corporation is keen to start selling their product via the Internet. What security implications are associated with such a plan?
3.8.1
Threats
• customers (wishing to get something for nothing) • business rivals • criminals • script kiddies • others
3.8.2
Vulnerabilities
• attack against the web server
3.8.3
Impact
• loss of business • loss of reputation with customers and business partners • loss of money • loss of customer information (e.g. credit card numbers)
3.8.4
Countermeasures
• authentication of customers • encrypted communications channel • firewall between Internet and the web server • intrusion Detection System
4.53
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
ACME
ACME corporation
e-commerce WWW server
ACME product database customer database order database inventory database invoicing
Internet
e-commerce customer
What are the security implications?
Figure 26 Case Study 2: Operating an E-commerce Site IP2300/S4/v2.1
© wray castle limited
4.54
IP Engineering Overview
3.9
Case Study 3 – Mobile Computing
ACME Corporation would like to allow their staff to work while away from the office. This will entail staff being able to access the corporate network from home or when working away from home. They want their staff to able to either dial in via the PSTN and/or connect over the Internet. What security implications are associated with such a plan?
3.9.1
Threats
• internal staff • competitors • others
3.9.2
Vulnerabilities
• attack via the Internet connection itself • attack via the dial-up connection • attack via a trusted host
3.9.3
Impact
• loss of business • compromise of proprietary information
3.9.4
Countermeasures
• firewall between Internet and corporate network • VPN between staff PCs and corporate network • Intrusion Detection System on corporate network • security awareness training for staff
4.55
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
ACME corporation
ACME internal systems
Internet Mobile ACME employee
What are the security implications?
Figure 27 Case Study 3: Allowing Remote Access to the Corporate Network IP2300/S4/v2.1
© wray castle limited
4.56
IP Engineering Overview
4
IPv6
4.1
Motivation for IPv6 Development
The current version of the IP protocol, IP version 4, has not changed significantly since it was first developed and standardized in RFC 791. However, despite the success of IPv4, there are some fundamental issues with the protocol in the current Internet: • the massive growth of the Internet has threatened to exhaust the IPv4 32-bit address space, despite efforts to mitigate this using Network Address Translation • the same growth has made conventional Internet routing tables extremely large and flat, despite attempts to make the address space more geographically significant through new address allocation policies and CIDR • the configuration of IP devices is still too complicated, despite the widespread use of Dynamic Host Configuration Protocol (DHCP) to assist in this • IP QoS and security services are often mutually exclusive when IPSec encryption is applied to IPv4 packets IPv6 addresses these issues by providing • larger address space • more hierarchical addressing, supporting hierarchical routing • more flexible address configuration • improved support for security and QoS features
4.57
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
IPv4
IPv6
32-bit address space
128-bit address space
Mixed flat and hierarchical address space
Hierarchical address space
Manual configuration or DHCP configuration
Address autoconfiguration link local, site local or global unicast
IPSec support is optional
IPSec support is mandatory
Figure 28 Motivation for IPv6 IP2300/S4/v2.1
© wray castle limited
4.58
IP Engineering Overview
4.2
IPv4/IPv6 Co-existence
The migration of hosts and routers from IPv4 to IPv6 will take many years, and the original designers of the IPv6 protocol specifically required that IPv4 and IPv6 should be able to interoperate without requiring reconfiguration of other elements to support this. In other words, there should be excellent forwards and backwards compatibility between IPv4 and IPv6. While the migration from IPv4 to IPv6 continues, a host or router may have only an IPv4 protocol stack, only an IPv6 protocol stack, or it may have both. In order to assist with migration, the following components are typically required in network devices and hosts. • devices with a dual IP layer, so that communication with IPv4 and IPv6 hosts is possible during migration • devices that can provide a gateway function between IPv4 and IPv6 • IPv6 over IPv4 tunnelling, so that IPv6 traffic can be carried across an IPv4 infrastructure • an IPv4 and IPv6 DNS infrastructure, so that name resolution can be carried out for both forms of address
4.3
IPv6 Product Availability
Although still not widely deployed in operational networks, IPv6 is now widely available in production software for hosts and network devices.
4.59
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Application Layer Transport Layer IPv4
IPv6
Network Interface
Dual IPv4/IPv6 protocol stack
IPv4 header
Payload
IPv6 header
extension headers
Payload
IPv6 over IPv4 tunnelling
host A
IN A
IPv4 address
host A
IN AAAA
IPv6 address
host B
IN A
IPv4 address
host C
IN AAAA
IPv6 address
IPv4 and IPv6 DNS address records Figure 29 IPv4 and IPv6 Co-existence IP2300/S4/v2.1
© wray castle limited
4.60
IP Engineering Overview
5
MOBILITY
5.1
Public Service Wireless LANs
The increasing use of Local Area Networks has generated a market in private networks over the last five years for wireless access to the LAN, rather than use of a conventional structured wiring approach. The standards governing these wireless access networks are in the IEEE 802.11 series. There are currently four specifications in the family: 802.11, 802.11a, 802.11b, and 802.11g. All four use the ‘Ethernet’ protocol and CSMA/CD (Carrier Sense Multiple Access with Collision Detection) for path sharing. The most recently approved standard, 802.11g, offers wireless transmission over relatively short distances at up to 54 Mbit/s compared with the 11 megabits per second of the 802.11b standard. Like 802.11b, 802.11g operates in the 2.4 GHz range and is thus compatible with it. The key components of the architecture are: • a Wireless LAN Access Point provides a base station and connectivity to the network infrastructure • a wireless LAN card in each host provides the client end of the wireless link • a Service Set Identifier (SSID) is a sequence of characters that uniquely names a wireless local area network. This name allows stations to connect to the desired network when multiple independent networks operate in the same physical area Public service WLAN Internet access has been offered for some time in North America, and since 2002 in the UK, through WLAN ‘hot-spots’. To offer the service, a network operator installs a WLAN access point in a public location, such as airport departure lounge or coffee shops. Subscribers typically purchase the service on a monthly plan, which provides them with a username and password. They configure the correct SSID for their service provider into their WLAN network card, and can then connect to the nearest available access point for that service provider. To enable the connection on each occasion, they typically browse to a login screen on a secure web server, where they enter their username and password. This allows the user to be authenticated to the network, and traffic from the MAC address of their network interface card will then be permitted through the access point for the duration of this connection. Some service providers allow casual use without a subscription, in which case the logon screen will include payment options for this session. The security of WLAN has caused concern for some years. While the login approach described here makes fraudulent use of the service more difficult, it does not protect the user from a rogue access point, or their traffic from eavesdropping, or the user machine from attacks through the Internet. Corporate users are normally advised to operate an IP-VPN between their laptop and a corporate gateway to secure this type of service, and the user machine should run a personal firewall and virus scanning, as for any Internet-connected machine.
4.61
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
MyISP wireless access point
Roaming user
locate ac
WLAN connection
cess poin
locate mo
t (SSID)
bile (SSID
)
Connect
SSL connection
Authentication server and web server
Lc Provide SS
to SSL se r ver
ertificate
Provide s ess Send login
login/ authentication
Submit <
usernam
Login succ
ion key
form
e, passw ord>
essful
ffic ‘Accept tra ’ C address A M is th from General In
Internet access
ternet ac ce
Authentication database
ss
Figure 30 Operation of Public Service Wireless LANs IP2300/S4/v2.1
© wray castle limited
4.62
IP Engineering Overview
5.2
The IETF Architecture for Mobile IP
In many situations, an IP host is physically mobile, and must connect to different subnets over time. Where the host effectively reboots or resets higher-layer protocols between such moves, then DHCP is sufficient to provide a valid IP address on the current subnet. If the host must be reachable from the public Internet on the current IP address, then Dynamic DNS (DDNS) coupled with DHCP may be an acceptable solution. In some situations, notably in GSM, GPRS and UMTS networks, an IP host needs transparency in the higher-layer protocols while roaming. In this case, the IETF Mobile IP architecture is appropriate. Mobile IP is intended to address ‘macro’ mobility issues, in other words roaming away from the normal home location. It is not intended to address ‘micro’ mobility issues, for example moving between base stations attached to the same switching centre. The mobile IP architecture provides mobile stations with a home IP address, which is unchanging. When the host is roaming, it obtains an IP address from the network it is currently attached to, and returns this ‘care-of’ address to a home mobility agent. This may be done directly, or through a mobility agent on the foreign network (a foreign mobility agent). Traffic for the roaming host is always sent to its home address, and this is the only address advertised for the host. When this traffic arrives at the home network, the home agent tunnels this traffic to the host at its ‘care of’ address. Traffic from the roaming host uses its home address as the sending address, so that return traffic always flows through the home agent. A set of management messages is defined as part of the Mobile IP standards to allow the roaming host and the home agent to maintain the necessary addressing information. Security services are included in this management protocol to prevent masquerading, replay or other attacks based upon exploiting IP mobility.
4.63
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
Internet
Home network
Foreign network
To/from IPhma IProam
To/from
rom IPh ef
ost
I
st
P ho
To IP
P home to
IP home
From ho I
m
Foreign mobility agent
IP host
Home mobility agent – address is IPhma
Mobile station on home network – home IP address is IPhome
Internet host – address is IPhost Mobile station on foreign network – roaming IP address is IProam
Figure 31 Mobile IP Architecture IP2300/S4/v2.1
© wray castle limited
4.64
IP Engineering Overview
6
SECTION 4 QUESTIONS
1
Explain how QoS engineering differs between circuit-switched, virtual circuit, and datagram networks.
2
RSVP is used as part of the IntServ architecture to: a b c d
establish the path traffic will take through the network state the traffic requirements in terms of bandwidth, etc request the reservation of resources within the network for a specific flow do all of the above
3
Explain the difference between IntServ and DiffServ architectures. Which is more common in service provider networks?
4
MPLS can support IP QoS by: a b c d
5
An IP-VPN can be used to implement: a b c d
6
mapping the DiffServ DS field into the MPLS equivalent providing a separate MPLS LSP for each DiffServ CoS MPLS cannot support IP QoS the approaches in A and B are both possible
intranets extranets remote Access VPNs all of the above
MPLS VPNs: a require an MPLS core to operate b benefit from networks with an MPLS core, but it is not essential c can operate across any core technology, including MPLS, ATM and Frame Relay d require a private network for each customer, otherwise privacy cannot be achieved
4.65
© wray castle limited
IP2300/S4/v2.1
IP Engineering Overview
7
IPSec VPNs are based upon encryption services. For VPN users these provide: a b c d
8
data confidentiality guaranteed service availability prevention of denial of service attacks virus checking, but at the VPN gateways only
MPLS and IPSec VPNs have different deployment possibilities: a MPLS and IPSec are both widely built and operated by private enterprises b IPSec is widely built by private enterprises, but MPLS solutions must be provided by service providers c MPLS can be built by private enterprises, but IPSec solutions must be provided by service providers d both IPSec and MPLS VPNs are pure service provider technologies, and cannot be implemented by private enterprises
9
Quantifying the risk in security terms is best expressed by: a risk is a function of threat, vulnerability and impact b risk is a function of threat and vulnerability c risk is always there, so maximizing the countermeasures at each point in the network is the best approach d risk is mainly from outsiders, so an effective firewall is the main precaution that is necessary
IP2300/S4/v2.1
© wray castle limited
4.66
IP Engineering Overview
4.67
© wray castle limited
IP2300/S4/v2.1
Glossary of Terms
IP ENGINEERING OVERVIEW
GLOSSARY OF TERMS
© wray castle limited
Glossary of Terms
© wray castle limited
IP2300/Glossary
Glossary of Terms
AAL ABR ADSL AES AH ARPA AS ASBR ASN ASP ATM AUP
ATM Adaptation Layer Area Border Router Asymmetric Digital Subscriber Line Advanced Encryption Standard Authentication Header Advanced Research Projects Agency Autonomous System Autonomous System Border Router Autonomous System Number Active Server Page Asynchronous Transfer Mode Acceptable Use Policies
B2B B2C BAS Bcc BDR BER BGP BGP4
Business to Business Business to Customer Broadband Access Server Blind carbon copy Backup Designated Router Bit Error Rate Border Gateway Protocol Border Gateway Protocol Version 4
CAC CE CGI CHAP CIDR CLEC CNAME CO CoS CPE CRC CSMA-CD CSU/DSU
Connection Admission Control Customer Edge Common Gateway Interface Challenge Handshake Authentication Protocol Classless Interdomain Routing Competitive Local Exchange Carrier Canonical Name Central Office Class of Service Customer Premises Equipment Cyclic Redundancy Checking Carrier Sense Multiple Access with Collision Detection Channel Service Unit/Data Service Unit
IP2300/Glossary
© wray castle limited
G.1
Glossary of Terms
DCA DDN DDNS DH DHCP DiffServ DLCI DMZ DNS DNS DoS DR DS DSLAM DTMF
Defence Communications Agency Defence Data Network Dynamic Domain Name Service Diffie-Helman Dynamic Host Configuration Protocol Differentiated Services Data Link Connection Identifier De-Militarized Zone Domain Name Server Domain Name System Denial of Service Designated Router Differentiated Services DSL Access Multiplexer Dual Tone Multi Frequency
eBGP EGP ESP
external BGP Exterior Gateway Protocol Encapsulating Security Payload
FDDI FEC FQDN FTP
Fibre Distributed Data Interface Forwarding Equivalence Class Fully Qualified Domain Name File Transfer Protocol
GoS GPRS GSM
Grade of Service General Packet Radio Service Global System for Mobile communications
HDLC HSSI HTTP
High-level Data Link Control High-Speed Serial Interface Hypertext Transfer Protocol
G.2
© wray castle limited
IP2300/Glossary
Glossary of Terms
IAD IANA iBGP ICANN IDS IEEE IETF IGP IGRP IKE IMAP IMAP4rev1 IntServ IP IPCP IPSec IPSP IPv4 IPv6 IP-VPN IR ISDN IS-IS ISP ITU IWF IXP
Integrated Access Device Internet Assigned Number Authority internal BGP Internet Corporation for Assigned Names and Numbers Intruder Detection Systems Institute of Electrical and Electronics Engineers Internet Engineering Task Force Interior Gateway Protocol Interior Gateway Routing Protocol Internet Key Exchange Interactive Mail Access Protocol Internet Message Access Protocol, Version 4 rev 1 Integrated Services Internet Protocol Internet Protocol Control Protocol IP Security IP Service Provider Internet Protocol version 4 Internet Protocol version 6 IP Virtual Private Network Internet Registry Integrated Services Digital Network Intermediate System to Intermediate System Internet Service Provider International Telecommunication Union Interworking Function Internet Exchange Point
LAN LANE LCP LDP LE LER LIB LSA LSP LSR
Local Area Network LAN Emulation Link Control Protocol Label Distribution Protocol Local Exchange Label Edge Router Label Information Base Link State Advertisement Label Switched Path Label Switching Router
IP2300/Glossary
© wray castle limited
G.3
Glossary of Terms
MAC Mbit/s MDA MDF MIL STD MIME MP-BGP MPLS MPOA MTA MUA MX
Medium Access Control Megabits per second Mail Delivery Agent Main Distribution Frame Military Standard Multipurpose Internet Mail Extensions Multiprotocol Border Gateway Protocol Multiprotocol Label Switching Multiprotocol over ATM Message Transfer Agent Mail User Agent Mail Exchanger
NAP NAPT NAS NAT NBMA NCP NLPID NOC NS NSF NTP NTS
Network Access Point Network Address Translation/Port Address Translation Network Access Server Network Address Translation Non-Broadcast Multiple Access Network Control Protocol Network Layer Protocol Identification Network Operations Centre Name Server National Science Foundation Network Termination Point Number Translation Services
OS OSI OSPF
Origin Server Open Services Interconnection Open Shortest Path First
G.4
© wray castle limited
IP2300/Glossary
Glossary of Terms
PAP PAT PBX PDD PDU PE PHB PHP PKC PoP POP POP3 POTS PPP PRI PSTN PVC
Password Authentication Protocol Port Address Translation Private Branch Exchange Post Dial Delay Protocol Data Unit Provider Edge Per Hob Behaviour Hypertext Preprocessor Public Key Cryptography Point of Presence Post Office Protocol Post Office Protocol Revision 3 Plain Old Telephone Service Point-to-Point Protocol Primary Rate Interface Public Switched Telephone Network Permanent Virtual Circuit
QoS
Quality of Service
RADIUS RFC RIP RIPE RIR RRAS RSA RSVP
Remote Authentication Dial-In User Service Request for Comments Routing Information Protocol Réseaux IP Européens Regional Internet Registries Routing and Remote Access Server Rivest, Shamir and Adleman Resource Reservation Protocol
S/MIME SA SCP SDH SLIP SMTP SNMP SOA SP SRI-NIC SS7 SSH SSID SSL SSP SVC
Secure MIME Security Association Service Control Point Synchronous Digital Hierarchy Serial Line IP Simple Mail Transfer Protocol Simple Network Management Protocol Start of Authority Service Provider Stamford Research Institute Network Information Centre Signalling System No. 7 Secure Shell Service Set Identifier Secure Socket Layer Service Switching Point Switched Virtual Circuit
IP2300/Glossary
© wray castle limited
G.5
Glossary of Terms
TACACS TCP TFTP TLD TLS ToS TTL
Terminal Access Controller Access Control System Transmission Control Protocol Trivial File Transfer Protocol Top Level Domain Transport Layer Security Type of Service Time To Live
UA UCE UDP UMTS URI URL
User Agent Unsolicited Commercial E-mail User Datagram Protocol Universal Mobile Telecommunications System Uniform Resource Identifier Universal Resource Locator
VGW VLSM VoIP VPN
Voice Gateway Variable Length Subnet Mask Voice over IP Virtual Private Network
WAN WLAN WWW
Wide Area Network Wireless Local Area Network World Wide Web
G.6
© wray castle limited
IP2300/Glossary
