Quidway Eudemon 200E-C&200E-F Firewall Feature Description (V100R002 - 01)

Quidway Eudemon 200E-C/200E-F Firewall V100R002
Feature Description
Issue Date
01 2009-12-01
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For any assistance, please contact our local office or company headquarters.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Copyright Huawei Technologies Co., Ltd. 2009. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are the property of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but the statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.
Quidway Eudemon 200E-C/200E-F Firewall Feature Description
Contents
Contents
About This Document.....................................................................................................................1 1 Overview......................................................................................................................................1-1
1.1 Introduction to the Device...............................................................................................................................1-2 1.2 Location of the Eudemon................................................................................................................................1-3 1.3 Functions and Features of the Eudemon.........................................................................................................1-3 1.3.1 Network Interconnection........................................................................................................................1-3 1.3.2 Security Defense....................................................................................................................................1-4 1.3.3 Service Application................................................................................................................................1-5 1.3.4 Configuration and Management.............................................................................................................1-5 1.3.5 Maintenance...........................................................................................................................................1-6 1.3.6 System Log Management.......................................................................................................................1-6
2 Introduction.................................................................................................................................2-1
2.1 Working Mode................................................................................................................................................2-2 2.1.1 Working Mode Classification................................................................................................................2-2 2.1.2 Working Process in Route Mode...........................................................................................................2-4 2.1.3 Working Process in Transparent Mode..................................................................................................2-4 2.1.4 Working Process in Composite Mode..................................................................................................2-10 2.2 Security Zone................................................................................................................................................2-10 2.2.1 Introduction to Security Zone..............................................................................................................2-10 2.2.2 Features of the Security Zone...............................................................................................................2-10 2.2.3 Security Zone on Eudemon..................................................................................................................2-11
3 System Management.................................................................................................................3-1
3.1 SNMP Overview.............................................................................................................................................3-2 3.1.1 Introduction to SNMP............................................................................................................................3-2 3.1.2 SNMP Versions and Supported MIB.....................................................................................................3-3 3.2 Introduction to the Features of Web Management..........................................................................................3-4
4 Security Features........................................................................................................................4-1
4.1 ACL.................................................................................................................................................................4-2 4.1.1 ACL Definition......................................................................................................................................4-2 4.1.2 ACL Application....................................................................................................................................4-2 4.1.3 ACL Step................................................................................................................................................4-3 4.1.4 ACL on the Eudemon.............................................................................................................................4-4 Issue 01 (2009-12-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. i
Contents
4.2 Security Policy................................................................................................................................................4-6 4.2.1 Packet Filter............................................................................................................................................4-6 4.2.2 ASPF......................................................................................................................................................4-6 4.2.3 Blacklist..................................................................................................................................................4-8 4.2.4 MAC and IP Address Binding...............................................................................................................4-8 4.2.5 Port Identification...................................................................................................................................4-8 4.2.6 Virtual Firewall......................................................................................................................................4-9 4.3 NAT...............................................................................................................................................................4-10 4.3.1 Introduction..........................................................................................................................................4-10 4.3.2 NAT on the Device..............................................................................................................................4-12 4.4 Attack Defense..............................................................................................................................................4-17 4.4.1 Introduction..........................................................................................................................................4-17 4.4.2 Classes of Network Attacks.................................................................................................................4-17 4.4.3 Typical Examples of Network Attacks................................................................................................4-18 4.4.4 Introduction to the Attack Defense Principle.......................................................................................4-19 4.5 P2P Traffic Limiting.....................................................................................................................................4-21 4.5.1 Introduction to P2P Traffic Limiting...................................................................................................4-21 4.5.2 P2P Traffic Detection and Limiting.....................................................................................................4-21 4.6 IM Blocking..................................................................................................................................................4-22 4.6.1 Introduction to IM Detecting and Blocking.........................................................................................4-22 4.6.2 IM Detecting and Blocking..................................................................................................................4-22 4.7 Static Multicast..............................................................................................................................................4-23 4.7.1 Restrictions of Unicast or Broadcast....................................................................................................4-23 4.7.2 Overview of Static Multicast................................................................................................................4-25 4.7.3 Implementing Static Multicast on the Eudemon..................................................................................4-26 4.8 Keyword Authentication...............................................................................................................................4-26 4.9 Authentication and Authorization.................................................................................................................4-27 4.9.1 Introduction to Authentication and Authorization...............................................................................4-27 4.9.2 Introduction to Domain........................................................................................................................4-28 4.9.3 Introduction to Local User Management..............................................................................................4-28 4.10 IP-CAR........................................................................................................................................................4-28 4.11 TSM Cooperation........................................................................................................................................4-29 4.11.1 Introduction to TSM Cooperation......................................................................................................4-29 4.11.2 Work Flow of TSM Cooperation.......................................................................................................4-30 4.11.3 Specifications of TSM Cooperation...................................................................................................4-31 4.12 SLB..............................................................................................................................................................4-31 4.12.1 Introduction to SLB............................................................................................................................4-31 4.12.2 Virtual Service Technology...............................................................................................................4-32 4.12.3 Server Health Check...........................................................................................................................4-33 4.12.4 Traffic-based Forwarding...................................................................................................................4-33
5 VPN...............................................................................................................................................5-1
5.1 Introduction.....................................................................................................................................................5-2 ii Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2009-12-01)
Contents
5.1.1 VPN Overview.......................................................................................................................................5-2 5.1.2 Basic VPN Technology..........................................................................................................................5-3 5.1.3 VPN Classification.................................................................................................................................5-5 5.2 L2TP................................................................................................................................................................5-7 5.2.1 VPDN Overview....................................................................................................................................5-7 5.2.2 L2TP Overview......................................................................................................................................5-7 5.3 IPSec..............................................................................................................................................................5-13 5.3.1 IPSec Overview....................................................................................................................................5-13 5.3.2 IPSec Basic Concepts...........................................................................................................................5-14 5.3.3 IKE Overview......................................................................................................................................5-17 5.3.4 Overview of the IKEv2 Protocol..........................................................................................................5-19 5.3.5 Security Analysis of IKEv2..................................................................................................................5-20 5.3.6 IKEv2 and EAP Authentication...........................................................................................................5-21 5.3.7 NAT Traversal of IPSec.......................................................................................................................5-22 5.3.8 Realizing IPSec on the Eudemon.........................................................................................................5-23 5.4 GRE...............................................................................................................................................................5-25 5.4.1 GRE Overview.....................................................................................................................................5-25 5.4.2 Implementation of GRE.......................................................................................................................5-25 5.4.3 GRE Application..................................................................................................................................5-26
6 Network Interconnection..........................................................................................................6-1
6.1 VLAN..............................................................................................................................................................6-2 6.1.1 Introduction............................................................................................................................................6-2 6.1.2 Advantages of VLAN.............................................................................................................................6-3 6.2 PPP..................................................................................................................................................................6-4 6.2.1 Introduction............................................................................................................................................6-4 6.2.2 PPP Authentication................................................................................................................................6-5 6.2.3 PPP Link Operation................................................................................................................................6-6 6.3 PPPoE..............................................................................................................................................................6-9 6.3.1 Basic Principles of PPPoE......................................................................................................................6-9 6.3.2 PPPoE Discovery Period......................................................................................................................6-10 6.3.3 PPPoE Session Period..........................................................................................................................6-12 6.4 DHCP Overview...........................................................................................................................................6-12 6.4.1 DHCP Service......................................................................................................................................6-12 6.4.2 DHCP Relay.........................................................................................................................................6-13 6.4.3 DHCP Client........................................................................................................................................6-14 6.5 Static Route Overview..................................................................................................................................6-16 6.5.1 Static Route..........................................................................................................................................6-16 6.5.2 Default Route.......................................................................................................................................6-18 6.6 RIP.................................................................................................................................................................6-18 6.6.1 RIP Overview.......................................................................................................................................6-18 6.6.2 RIP Versions........................................................................................................................................6-19 6.6.3 RIP Startup and Operation...................................................................................................................6-19 Issue 01 (2009-12-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. iii
Contents
6.7 OSPF.............................................................................................................................................................6-20 6.7.1 OSPF Overview....................................................................................................................................6-20 6.7.2 Process of OSPF Route Calculation.....................................................................................................6-20 6.7.3 Basic Concepts Related to OSPF.........................................................................................................6-21 6.7.4 OSPF Packets.......................................................................................................................................6-25 6.7.5 Types of OSPF LSAs...........................................................................................................................6-25 6.8 BGP...............................................................................................................................................................6-27 6.8.1 BGP Overview.....................................................................................................................................6-27 6.8.2 Classification of BGP Attributes..........................................................................................................6-30 6.8.3 Principles of BGP Route Selection......................................................................................................6-31 6.9 Introduction to Policy-Based Routing...........................................................................................................6-33 6.10 Routing Policy Overview............................................................................................................................6-33 6.10.1 Applications and Implementation of Routing Policy.........................................................................6-34 6.10.2 Differences Between Routing Policy and Policy-based Routing.......................................................6-34 6.11 Load Balancing...........................................................................................................................................6-35 6.12 Introduction to QoS.....................................................................................................................................6-37 6.12.1 QoS Overview....................................................................................................................................6-37 6.12.2 Traditional Packets Transmission Application..................................................................................6-37 6.12.3 New Application Requirements.........................................................................................................6-37 6.12.4 Congestion Causes, Impact and Countermeasures.............................................................................6-38 6.12.5 Traffic Control Techniques................................................................................................................6-39 6.13 GPON Line..................................................................................................................................................6-40 6.13.1 Introduction to the GPON Line Feature.............................................................................................6-40 6.13.2 Principles of GPON Upstream Transmission.....................................................................................6-41 6.13.3 Principles of GPON Lines..................................................................................................................6-41 6.14 Introduction to Voice Services....................................................................................................................6-42 6.14.1 Overview of Voice Features...............................................................................................................6-42 6.14.2 General Specifications........................................................................................................................6-43 6.14.3 H.248based Voice Services..............................................................................................................6-45 6.14.4 SIP-based Voice Services...................................................................................................................6-54 6.14.5 Key Voice Feature..............................................................................................................................6-69 6.14.6 Voice Reliability................................................................................................................................6-78
7 Reliability....................................................................................................................................7-1
7.1 Overview of VRRP......................................................................................................................................... 7-2 7.1.1 Traditional VRRP...................................................................................................................................7-2 7.1.2 Disadvantages of Traditional VRRP in Eudemon Backup.................................................................... 7-4 7.2 Introduction to Dual-System Hot Backup.......................................................................................................7-6 7.2.1 HRP Application....................................................................................................................................7-6 7.2.2 Primary/Secondary Configuration Devices............................................................................................7-7 7.3 Relations Between the VRRP Backup Group, Management Group, and HRP.............................................. 7-7 7.4 IP-Link Auto-detection Overview...................................................................................................................7-8
A Glossary..................................................................................................................................... A-1
iv Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2009-12-01)
Contents
B Acronyms and Abbreviations.................................................................................................B-1
Issue 01 (2009-12-01)
Figures
Figures
Figure 2-1 Networking diagram in route mode....................................................................................................2-2 Figure 2-2 Networking diagram in transparent mode..........................................................................................2-3 Figure 2-3 Networking in composite mode..........................................................................................................2-4 Figure 2-4 Broadcasting a data packet.................................................................................................................2-5 Figure 2-5 Reversely learning the relationship between the MAC address of workstation A and the interface ...............................................................................................................................................................................2-6 Figure 2-6 Reversely learning the relationship between the MAC address of workstation B and the interface ...............................................................................................................................................................................2-7 Figure 2-7 Forwarding the frame after successfully obtaining corresponding information from the address table ...............................................................................................................................................................................2-8 Figure 2-8 Filtering frames after successfully obtaining corresponding information from the address table ...............................................................................................................................................................................2-9 Figure 2-9 Forwarding the frame after failing to obtain corresponding information from the address table......2-9 Figure 2-10 Relationship diagram of interface, network and security zones.....................................................2-12 Figure 3-1 MIB tree..............................................................................................................................................3-3 Figure 4-1 Networking diagram of virtual firewall..............................................................................................4-9 Figure 4-2 Networking diagram of basic processes of NAT..............................................................................4-11 Figure 4-3 NAPT allows multiple internal hosts to share a public address by translating IP address and port number .............................................................................................................................................................................4-13 Figure 4-4 Networking diagram of configuring inbound NAT..........................................................................4-15 Figure 4-5 Networking diagram of NAT within the zone..................................................................................4-15 Figure 4-6 Unicast information transmission.....................................................................................................4-24 Figure 4-7 Broadcast information transmission.................................................................................................4-24 Figure 4-8 Multicast information transmission..................................................................................................4-25 Figure 4-9 Transmission mode of static multicast.............................................................................................4-26 Figure 4-10 Networking diagram of TSM Cooperation.....................................................................................4-30 Figure 4-11 Schematic diagram of Virtual Service............................................................................................4-32 Figure 5-1 Networking diagram of VPN applications.........................................................................................5-3 Figure 5-2 Networking diagram of a VPN access................................................................................................5-4 Figure 5-3 Networking diagram of VPDN application based on L2TP...............................................................5-8 Figure 5-4 L2TP protocol structure......................................................................................................................5-9 Figure 5-5 Two typical L2TP tunnel modes......................................................................................................5-10 Figure 5-6 Typical networking diagram of L2TP..............................................................................................5-11 Figure 5-7 Procedure for setting up an L2TP call..............................................................................................5-11 Figure 5-8 Data encapsulation format for security protocols.............................................................................5-16 Issue 01 (2009-12-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. vii
Figures
Quidway Eudemon 200E-C/200E-F Firewall Feature Description Figure 5-9 Relationship of IKE and IPSec.........................................................................................................5-18
Figure 5-10 Procedure for setting up an SA.......................................................................................................5-18 Figure 5-11 IP network interconnection through the GRE tunnel.....................................................................5-25 Figure 5-12 Format of the encapsulated packet.................................................................................................5-26 Figure 5-13 IP packet transported in the tunnel.................................................................................................5-26 Figure 5-14 Network enlargement.....................................................................................................................5-27 Figure 5-15 Inconsistent subnet connection.......................................................................................................5-27 Figure 5-16 GRE-IPSec tunnel...........................................................................................................................5-28 Figure 6-1 Example of VLAN..............................................................................................................................6-3 Figure 6-2 Operation process of PPP...................................................................................................................6-7 Figure 6-3 Diagram of the host sending PADI packets in broadcast.................................................................6-10 Figure 6-4 Sending the PADO packet from the server.......................................................................................6-11 Figure 6-5 Diagram of the host choosing a server and sending a PADR packet...............................................6-11 Figure 6-6 Diagram of the server sending a PADS packet to the host...............................................................6-11 Figure 6-7 DHCP relay.......................................................................................................................................6-14 Figure 6-8 OSPF area partition..........................................................................................................................6-22 Figure 6-9 OSPF router types.............................................................................................................................6-23 Figure 6-10 Area and route summary.................................................................................................................6-24 Figure 6-11 Opaque LSAs structure...................................................................................................................6-26 Figure 6-12 BGP operating mode......................................................................................................................6-29 Figure 6-13 Synchronization of IBGP and IGP.................................................................................................6-33 Figure 6-14 Networking diagram of packet-by-packet load balancing..............................................................6-35 Figure 6-15 Networking diagram of session-by-session load balancing............................................................6-36 Figure 6-16 Schematic diagram of traffic congestion........................................................................................6-38 Figure 6-17 Overall voice service solution of the SRG.....................................................................................6-43 Figure 6-18 Registration flow of the MG...........................................................................................................6-47 Figure 6-19 Unsolicited deregistration flow of the MG.....................................................................................6-48 Figure 6-20 Unsolicited deregistration flow of the MGC..................................................................................6-48 Figure 6-21 Authentication flow........................................................................................................................6-49 Figure 6-22 Principle of the VoIP feature that supports the H.248 protocol ....................................................6-50 Figure 6-23 Principles of the T.38 fax...............................................................................................................6-54 Figure 6-24 IETF multimedia data and control protocol stack..........................................................................6-55 Figure 6-25 Flowchart of the registration through unsafe connection...............................................................6-59 Figure 6-26 Flowchart of the registration through safe connection...................................................................6-60 Figure 6-27 SIP-based call flow of a VoIP calling party...................................................................................6-61 Figure 6-28 SIP-based call flow of a VoIP called party.....................................................................................6-62 Figure 6-29 Flow of call release.........................................................................................................................6-63 Figure 6-30 Flow of the negotiated-switching transparent transmission fax.....................................................6-64 Figure 6-31 Flow of the negotiated-switching T.38 fax.....................................................................................6-65 Figure 6-32 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 1)..........................................................................................................................................................6-66 Figure 6-33 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 2)..........................................................................................................................................................6-67 viii Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2009-12-01)
Figures
Figure 6-34 Flow of the negotiated-switching modem service..........................................................................6-69 Figure 6-35 Generation of the electrical echo....................................................................................................6-71 Figure 6-36 Implementation of the EC function................................................................................................6-72 Figure 6-37 Working principles of dual homing................................................................................................6-79 Figure 6-38 Operating principle for implementing the dual-homing with no auto-switching...........................6-80 Figure 6-39 Operating principle for implementing the dual-homing with auto-switching................................6-81 Figure 6-40 Call releasing flow..........................................................................................................................6-82 Figure 6-41 802.1q frame format.......................................................................................................................6-83 Figure 6-42 DSCP identification format............................................................................................................6-84 Figure 7-1 Networking using the default route....................................................................................................7-2 Figure 7-2 Networking of using the VRRP virtual router....................................................................................7-3 Figure 7-3 Typical networking of Eudemon backup............................................................................................7-4 Figure 7-4 Eudemon backup state........................................................................................................................7-5 Figure 7-5 Typical data path in primary/secondary mode....................................................................................7-6 Figure 7-6 Hierarchical relations between the VRRP backup group, management group, and HRP..................7-7
Issue 01 (2009-12-01)
ix
Tables
Tables
Table 3-1 MIB supported by the system.............................................................................................................. 3-3 Table 4-1 Classification of the ACL.....................................................................................................................4-4 Table 6-1 Default settings of the timers.............................................................................................................6-16 Table 6-2 Route attributes and their types..........................................................................................................6-30 Table 6-3 Differences between routing policy and PBR....................................................................................6-35 Table 6-4 Voice services supported....................................................................................................................6-43 Table 6-5 SIP request messages.........................................................................................................................6-58 Table 6-6 SIP response messages.......................................................................................................................6-59 Table 6-7 Codec list............................................................................................................................................6-70 Table 6-8 Mapping between frequencies and numbers......................................................................................6-75
Issue 01 (2009-12-01)
xi
About This Document
About This Document
Purpose
This document describes the functions and features of the Quidway Eudemon 200E-C/200E-F ( hereafter referred to as the Eudemon ), including system management, security features and network interconnection. This document introduces the functions, principles and features of the Eudemon.
Related Versions
The following table lists the product versions related to this document. Product Name Quidway Eudemon 200E-C/200E-F Version V100R002
Intended Audience
This document is intended for:
l l l l l
Technical support engineers Maintenance engineers Network engineers Network administrators Network maintenance engineers
Organization
This document is organized as follows.
Issue 01 (2009-12-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 1
About This Document
Chapter 1 Overview 2 Introduction 3 System Management 4 Security Features
Description This section describes introduction to Eudemon, the location of the Eudemon in network and the functions of Eudemon. This section describes the operating modes and the security zones of the Eudemon. This section describes SNMP management features and Web management features of the Eudemon, This section describes the security features of the Eudemon, including ACL, security policy, attack defense, NAT, keyword authentication, authentication and authorization , IP-CAR, P2P Traffic Limiting, IM Blocking, Static Multicast, TSM Cooperation and SLB. This describes the VPN features of the Eudemon, including L2TP, IPSec, and GRE. This section describes the network interconnection features of the Eudemon, including VLAN, PPP, PPPoE, DHCP, IP static route, RIP, OSPF, BGP, policy-based routing and QoS. This describes the reliability features of the Eudemon, including VRRP, two-node cluster hot backup, and IP-Link. This section lists acronyms in the volume. This section lists abbreviations in the volume.
5 VPN 6 Network Interconnection
7 Reliability A Glossary B Acronyms and Abbreviations
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description
DANGER
Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results.
WARNING
CAUTION
Issue 01 (2009-12-01)
About This Document
Symbol
TIP
Description Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
NOTE
General Conventions
The general conventions that may be found in this document are defined as follows. Convention Times New Roman Boldface Italic Courier New Description Normal paragraphs are in Times New Roman. Names of files, directories, folders, and users are in boldface. For example, log in as user root. Book titles are in italics. Examples of information displayed on the screen are in Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows. Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] { x | y | ... }* Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in brackets [ ] are optional. Optional items are grouped in braces and separated by vertical bars. One item is selected. Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected. Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.
[ x | y | ... ]*
Issue 01 (2009-12-01)
About This Document
GUI Conventions
The GUI conventions that may be found in this document are defined as follows. Convention Boldface > Description Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK. Multi-level menus are in boldface and separated by the ">" signs. For example, choose File > Create > Folder.
Keyboard Operations
The keyboard operations that may be found in this document are defined as follows. Format Key Key 1+Key 2 Key 1, Key 2 Description Press the key. For example, press Enter and press Tab. Press the keys concurrently. For example, pressing Ctrl+Alt +A means the three keys should be pressed concurrently. Press the keys in turn. For example, pressing Alt, A means the two keys should be pressed in turn.
Mouse Operations
The mouse operations that may be found in this document are defined as follows. Action Click Double-click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
Update History
Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.
Issue 01 (2009-12-01)
About This Document
Updates in Issue 01 (2009-12-01)

Initial commercial release.
Issue 01 (2009-12-01)
1 Overview
1
About This Chapter
1.1 Introduction to the Device 1.2 Location of the Eudemon 1.3 Functions and Features of the Eudemon
Overview
Issue 01 (2009-12-01)
1-1
1 Overview
1.1 Introduction to the Device

The Eudemon is a Firewall developed by Huawei. The Eudemon is a cost-effective security and access solution for small and medium-sized enterprise networks and the telecommunication networks.
Powerful Networking and Service-Supporting Capability

The Eudemon is integrated with powerful routing capabilities:
l l l l l l
Static routing Routing Information Protocol (RIP) dynamic routing Open Shortest Path First (OSPF) dynamic routing Routing policy Routing iteration Routing management
These increase the flexibility in the Eudemon networking application. Besides the powerful routing capabilities, the Eudemon is integrated with security and safety capabilities:
l l l l
Supports detection to malicious commands. Supports Network Address Translation (NAT) application. Supports filtering static and dynamic black list. Supports proxy-based SYN Flood defense flow control.
Multiple Types of Interfaces

The Eudemon provides fixed interfaces, such as the Gigabit Ethernet (GE) interfaces and Console ports, and extended slots for optional Mini Interface Cards (MICs) and Flexible Interface Modules (FICs). The Ethernet fiber and electrical interface card, Asymmetric Digital Subscriber Line 2+ (ADSL2+) interface card, E1/CE1 interface card, GE interface card can be inserted in the extended slots. You can select the interface cards according to the network environment. The excellent software scalability provides you with an economical solution for future network upgrades.
Enhanced Security
The Eudemon uses a specially designed hardware platform and a secure operating system with independent intellectual property right. Its packet processing is totally separated from operating system, which greatly increases the security of the system. With its own Application Specific Packet Filter (ASPF) state inspection technology, the Eudemon can:
l l l
Monitor the connection process and malicious commands. Cooperate with ACL to achieve packet filtering. Provide a number of attack defense capabilities.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2009-12-01)
1-2
1 Overview
All of the above features ensure the security of networks.
High-Speed Processing Capability

Oriented to medium and small-sized enterprise and industry users, the Eudemon provides wirerate, high-performance security defense and packet processing capabilities by using the multicore technology. The Eudemon uses high speed algorithm and optimized software structure, which effectively ensure the performance of the system. For example, ACL high speed algorithm can search a few or thousands of policies for a specific one at the same speed.
Powerful Log and Statistic

Based on powerful log and statistic provided by the Eudemon, you can obtain useful help in security analysis and event tracing.
1.2 Location of the Eudemon

The Eudemon is often deployed in the entrance to the zone protected to provide access control policy-based security defense. For example:
l
When you need to protect malicious attack or internal network and data from illegal access of external network, (such as unauthorized or unauthenticated access), you can deploy the Eudemon at the joint of the internal and external network. When you need to deny internal users access to sensitive data, you can deploy the Eudemon at the joint where relatively open segment meets relatively sensitive ones (such as segment that holds sensitive or private data).
1.3 Functions and Features of the Eudemon

1.3.1 Network Interconnection 1.3.2 Security Defense 1.3.3 Service Application 1.3.4 Configuration and Management 1.3.5 Maintenance 1.3.6 System Log Management
1.3.1 Network Interconnection

Link Layer Protocol
Description of the link layer protocol of the Eudemon:
l
Supports Ethernet_II and Ethernet_SNAP.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 1-3
Issue 01 (2009-12-01)
1 Overview
l l l l l
Supports VLAN (Virtual Local Area Network). Supports HDLC (High-level Data Link Control). Supports PPP (Point-to-Point Protocol). Supports PPPoE (PPP over Ethernet). Supports DDR (Dial-on-Demand Routing)
IP Service
Description of the IP services of the Eudemon:
l l
Supports ARP (Address Resolution Protocol). Supports DHCP (Dynamic Host Configuration Protocol) relay, DHCP server and DHCP client. Supports FTP client/server. Supports TFTP client. Supports ping and tracert.
l l l
Routing Protocol
Description of the routing protocol of the Eudemon:
l l l l l
Supports static routing. Supports dynamic routing (RIP, OSPF). Supports route policy. Supports policy-based routing. Supports route management and route iteration.
1.3.2 Security Defense

Packet Filtering
The Eudemon supports the following packet filtering modes:
l l l l l l l
Supports basic ACL, advanced ACL. Supports time range ACL. Supports inter-zone ACL. Maintains ACL rules dynamically. Supports blacklist, MAC and IP addresses binding. Supports the application specific packet filter (ASPF) and the state inspection. Provides the port mapping mechanism.
NAT
The following describes the NAT (Network Address Translation) of the Eudemon:
l
Address translation.
1-4

l l l
1 Overview
Provides the internal server. Port-level NAT server. Supports multiple NAT ALG (Application Level Gateway), including FTP (File Transfer Protocol), PPTP (Point-to-Point Tunneling Protocol), ILS (Instrument Landing System), ICMP (Internet Control Message Protocol), H.323, QQ, MSN and RTSP (Real-Time Streaming Protocol).
Attack Defense
The following describes the attack defense of the Eudemon:
l
Defends multiple DoS attacks, such as SYN Flood, ICMP Flood, UDP Flood, ARP, WinNuke, ICMP redirection and unreachable packet, Land, Smurf and Fraggle. Defends scanning and snooping, such as address scanning, port scanning, IP source routing option, IP routing record option and ICMP snooping packet. Defends other attacks, such as IP Spoofing.
Traffic Monitoring
The following describes the traffic monitoring of the Eudemon:
l l l
Supports the limit to connection rate and connection number based on IP. Supports CAR (Committed Access Rate). Supports real time traffic statistic and attack packet statistic.
1.3.3 Service Application

AAA
AAA (Authentication, Authorization and Accounting) service application of the Eudemon:
l l l
Supports AAA domain. Supports local user management. Supports multiple ISP.
QoS
QoS (Quality of Service) service application of the Eudemon:
l l l
Supports traffic categorization. Supports traffic monitoring. Supports congestion management.
1.3.4 Configuration and Management

Command Line Interface
The following describes the command line interface of the Eudemon:
Issue 01 (2009-12-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 1-5
1 Overview
l l l l
Prompt and help information in English and Chinese. Hierarchical protection of command lines from the intrusion from the unauthorized users. Detailed debugging information helps network fault diagnosis. Network test tools, such as tracert and ping tools, which can help rapidly identify whether the network is normal.
Web Configuration Interface

The Eudemon provides user-friendly and easy-to-use Web configuration interfaces to help you operate and maintain the Eudemon in a centralized manner. In addition, the Eudemon supports both encrypted access and unencrypted access.
System Management
The following describes the system management of the Eudemon:
l l l
Supports programs upload, download, or delete files through FTP. Supports programs upload or download files through TFTP. Supports programs upload configuration file or license file, download, or delete files through web.
Terminal Service
The following describes the terminal service of the Eudemon:
l l l
Supports terminal services of the console port. Supports terminal services of Telnet and secure shell (SSH). Supports the send function so that terminal users can communicate with each other.
1.3.5 Maintenance
System Management
Supports standard network management protocol SNMP v1/v2c/v3.
CPU Protection for Over-high Temperature

When the temperature of the CPU is higher than 60C, the alarm indicator on the front panel is on. The system sends an alarm information for high temperature and a log. When the temperature of the CPU is higher than 90C, the system sends an alarm information of shutting down and a log. If the temperature is still rising, the system switches to the heat protection state after the alarm information of shutting down is generated for three minutes. The indicators on the front panel are flashing except for the system indicator and the active/standby indicators. This indicates that the system is in the heat protection state. After 16 minutes, the system switches on automatically.
1.3.6 System Log Management

The following describes the system log of the Eudemon:
1-6 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2009-12-01)

l l
1 Overview
Provides the log server for browsing and querying log information. Provides input and output IP packets statistics. NAT log, ASPF log, attack defense log, blacklist log, address binding log, traffic statistics alarm/recovery log, and operation log can be queried. Supports the syslog format and binary log format. The syslog logs can be queried based on date. The binary logs can be queried based on time, protocol, source address/port, NAT address/port, and destination address/port. The system supports fuzzy query. The query results can be exported as an Excel file.
l l
Issue 01 (2009-12-01)
1-7
2 Introduction
2
About This Chapter
2.1 Working Mode 2.2 Security Zone
Introduction
Issue 01 (2009-12-01)
2-1
2 Introduction
2.1 Working Mode

2.1.1 Working Mode Classification 2.1.2 Working Process in Route Mode 2.1.3 Working Process in Transparent Mode 2.1.4 Working Process in Composite Mode
2.1.1 Working Mode Classification

Route Mode
In the scenario where the Eudemon is connected to external networks through Network Layer (the physical interface is configured with an IP address), the Eudemon works in route mode. When the Eudemon is deployed between an internal network and an external network, you need to configure the Eudemon interfaces connecting respectively with the internal network and external network with IP addresses in different segments. In addition, you need to replan the network topology. The Eudemon fulfills the routing function in internal networks and external networks. It functions as a router. As shown in Figure 2-1, the Eudemon is connected to the internal network through an interface segmented to the Trust zone, and connected to the external network through an interface segmented to the Untrust zone. The two interfaces respectively in the Trust zone and the Untrust zone are segmented to different subnets. Figure 2-1 Networking diagram in route mode
PC 10.110.1.254/24 202.10.0.1/24 PC PC
Server
Eudemon Trust Internal network
Router Untrust External network Server
When working in route mode, the Eudemon can implement functions such as ACL packet filtering, ASPF dynamic filtering, and NAT. When you configure a Eudemon to work in route mode, you need to change the topology of the existing network. For example, internal network users need to change their gateway settings and the route configuration of the router should be changed as well. Reconstructing a network is time and resource consuming. It is recommended that you weigh the advantages and disadvantages in selecting this mode.
2 Introduction
Transparent Mode
In the scenario where the Eudemon is connected to external networks through Data Link layer (the physical interface is not configured with an IP address), the Eudemon works in transparent mode. Letting the Eudemon to work in transparent mode saves you from the trouble in changing network topology. To adopt the transparent mode, you only need to deploy the Eudemon on the network just like placing a bridge. That saves you from the trouble in changing any current configuration. Similar to the transaction in route mode, the Eudemon checks and filters IP packets, protecting internal users against threats. Figure 2-2 shows a typical networking in transparent mode. Figure 2-2 Networking diagram in transparent mode
PC 202.10.0.2/24 202.10.0.1/24 PC PC
Server
Router Trust Internal network
Eudemon
Router Untrust External network
Server
In transparent mode, the Eudemon can perform packet forwarding only. The two connected networks must be in the same network segment. The Eudemon is connected with the internal network through an interface in the Trust zone, and connected with the external network through an interface in the Untrust zone. Note that the internal network and external network should be in the same subnet.
Composite Mode
If there are interfaces working in routing mode (such interfaces have IP addresses) and interfaces working in transparent mode (such interfaces have no IP address) in the Eudemon, it means that the Eudemon works in composite mode. The composite mode is applied to the two-node cluster hot backup in transparent mode. The interface on which Virtual Router Redundancy Protocol (VRRP) is enabled needs to be configured with an IP address, and other interfaces do not need to be configured with IP addresses.. Figure 2-3 shows a typical networking in composite mode.
Issue 01 (2009-12-01)
2-3
2 Introduction
Figure 2-3 Networking in composite mode

Eudemon (Master)
PC
PC
PC
HUB Server Trust 202.10.0.0/24 Untrust 202.10.0.0/24 Server
Eudemon (backup)
Primary and secondary Eudemons are connected to the intranet through interfaces in the Trust zone, and connected to the Internet through interfaces in the Untrust zone. In addition, primary and secondary Eudemons:
l l
Connect with each other through a hub or a local area network (LAN) Switch. Perform backup over VRRP.
NOTE
The primary and secondary Eudemons can be connected directly or through a hub or a LAN Switch. You can connect the primary and the secondary Eudemons based on the actual conditions. The intranet and the Internet must reside in the same subnet.
2.1.2 Working Process in Route Mode

When packets are forwarded between interfaces in the network layer, the Eudemon acts as a router, searching for routing entries based on IP addresses of the packets. Different from a router, the Eudemon delivers the forwarded IP packets to the upper layer for filtering. The Eudemon determines whether to allow the packets pass through or not according to session entries and ACL rules. In addition, the Eudemon is also responsible for some other attack defense checks.
2.1.3 Working Process in Transparent Mode

When packets are forwarded between interfaces in the layer 2 network, the Eudemon acts as a transparent bridge, searching for outbound interfaces based on MAC addresses of the packets. Different from a bridge, the Eudemon delivers the forwarded IP packets to the upper layer for filtering. The Eudemon determines whether to permit the packets to pass through or not according to session entries and ACL rules. In addition, the Eudemon is also responsible for some other attack defense checks. In transparent mode, the Eudemon is connected to a LAN at Data Link Layer; therefore, end users do not need to perform special configurations on devices for connecting the networks (like LAN Switch connection).
2 Introduction
The working process in transparent mode has several phases, which are described in the following sections:
l l
Obtaining an Address Table Forwarding or Filtering a Frame
Obtaining an Address Table

In transparent mode, the Eudemon forwards packets based on the MAC address table, which consists of MAC addresses and interfaces. To forward packets, the Eudemon must obtain information about the relationship between MAC addresses and interfaces. In transparent mode, the process that the Eudemon obtain address table is as follows: 1. Broadcast a data packet. When connected with a physical network segment, the transparent Eudemon monitors all Ethernet frames on the physical network segment. Once it detects an Ethernet frame from a certain interface, it extracts the source MAC address from the frame, and then adds the relationship between the MAC address and the interface to the MAC address table. Figure 2-4 shows the process. Figure 2-4 Broadcasting a data packet
00e0.fcaa.aaaa Workstation A Source address Destination address 00e0.fcbb.bbbb Workstation B
00e0.fcaa.aaaa 00e0.fcbb.bbbb Interface 1 00e0.fccc.cccc Workstation C Eudemon Interface 2 Workstation D Segment 2 Segment 1 00e0.fcdd.dddd
Segments 1 and 2 are respectively connected with interfaces 1 and 2 on the Eudemon. For example, when workstation A sends an Ethernet frame to workstation B, both the transparent Eudemon and workstation B receive the frame. 2. Reversely learn the relationship between the MAC address of workstation A and the interface. After receiving the Ethernet frame, the transparent Eudemon knows that workstation A is connected with interface 1 on the Eudemon because interface 1 receives the frame. Then the Eudemon adds the relationship between the MAC address of workstation A and interface 1 of workstation A to the MAC address table. Figure 2-5 shows the process.
2 Introduction
Figure 2-5 Reversely learning the relationship between the MAC address of workstation A and the interface
00e0.fcaa.aaaa 00e0.fcbb.bbbb Address table MAC address Interface 00e0.fcaa.aaaa 1 Segment 1 Interface 1 Eudemon Interface 2 Workstation C 00e0.fccc.cccc Workstation D 00e0.fcdd.dddd Segment 2
3.
Reversely learn the relationship between the MAC address of workstation B and the interface. After workstation B responds to the Ethernet frame from workstation A, the transparent Eudemon can detect the response Ethernet frame of workstation B. The transparent Eudemon knows that it is connected with workstation B through interface 1, because interface 1 receives the frame. Then the Eudemon adds the relationship between the MAC address of workstation B and interface 1 to the MAC address table. Figure 2-6 shows the process.
2-6
Issue 01 (2009-12-01)
2 Introduction
Figure 2-6 Reversely learning the relationship between the MAC address of workstation B and the interface
00e0.fcaa.aaaa Workstation A Destination address 00e0.fcbb.bbbb Workstation B Source address
00e0.fcaa.aaaa 00e0.fcbb.bbbb Address table MAC address Interface 00e0.fcaa.aaaa 00e0.fcbb.bbbb 1 1 Segment 1 Interface 1 Eudemon Interface 2 00e0.fcdd.dddd
Workstation C 00e0.fccc.cccc
Workstation D Segment 2
The reverse learning process continues until the transparent Eudemon obtains all relationship between MAC addresses and interfaces.
Forwarding or Filtering a Frame

At Data Link Layer, the transparent Eudemon processes a frame in the following situations:
l
When the transparent Eudemon successfully obtains corresponding information from the address table, it forwards the frame. After workstation A sends an Ethernet frame to workstation C, the transparent Eudemon searches the address table for the interface corresponding with workstation C. Then the Eudemon forwards the frame through interface 2 according to the searching result. Figure 2-7 shows the process.
Issue 01 (2009-12-01)
2-7
2 Introduction
Figure 2-7 Forwarding the frame after successfully obtaining corresponding information from the address table
00e0.fcaa.aaaa 00e0.fccc.cccc Segment 1 Address table MAC address Interface 1 00e0.fcaa.aaaa 1 00e0.fcbb.bbbb 00e0.fccc.cccc 2 2 00e0.fcdd.dddd Workstation C 00e0.fccc.cccc Forwarding Interface 1 Eudemon 00e0.fcdd.dddd Interface 2 Workstation D Segment 2
Destination Source address address 00e0.fccc.cccc 00e0.fcaa.aaaa
If the transparent Eudemon receives a broadcast frame or multicast frame from a interface, it forwards the frame to other interfaces.
l
When the transparent Eudemon successfully obtains corresponding information from the address table, it does not forward the frame. If workstation A sends an Ethernet frame to workstation B, the Eudemon does not forward but filter the frame. That is because workstations B and A reside in the same physical network segment. Figure 2-8 shows the process.
2-8
Issue 01 (2009-12-01)
2 Introduction
Figure 2-8 Filtering frames after successfully obtaining corresponding information from the address table
00e0.fcaa.aaaa 00e0.fcbb.bbbb Address table MAC address Interface 1 00e0.fcaa.aaaa 00e0.fcbb.bbbb 1 00e0.fccc.cccc 2 00e0.fcdd.dddd 2 Workstation C 00e0.fccc.cccc Not forwarding Segment 1 Interface 1 Eudemon Interface 2 Workstation D 00e0.fcdd.dddd Segment 2
When the transparent Eudemon fails to obtain corresponding information from the address table, it forwards the frame. When workstation A sends an Ethernet frame to workstation C and the Eudemon does not obtain the relationship between the MAC address of workstation C and the interface from the address table, the Eudemon forwards this frame to all the other interfaces but the source interface of the frame. In this case, the Eudemon acts as a hub, ensuring the continuous transfer of the frame. Figure 2-9 shows the process. Figure 2-9 Forwarding the frame after failing to obtain corresponding information from the address table
00e0.fcaa.aaaa 00e0.fcccc.cccc Address table Interface 1 MAC address Interface 00e0.fcaa.aaaa 1 00e0.fcbb.bbbb 1 Workstation C 00e0.fccc.cccc Segment 2
Segment 1 Eudemon 00e0.fcdd.dddd Workstation D Interface 2
2 Introduction
2.1.4 Working Process in Composite Mode

When the Eudemon works in composite mode, some interfaces should be configured with IP addresses and some not. The interfaces configured with IP addresses reside in the layer 3 network, with VRRP enabled for dual-system hot backup. The interfaces not configured with IP addresses reside in the layer 2 network. External users connected with the interfaces in the layer 2 network belong to the same subnet. When packets are forwarded between interfaces in the layer 2 network, the forwarding process is the same as that in transparent mode. For details, see section "2.1.3 Working Process in Transparent Mode". When packets are forwarded between interfaces in the layer 3 network, the forwarding process is similar to that in route mode. For details, see section "2.1.2 Working Process in Route Mode".
2.2 Security Zone

2.2.1 Introduction to Security Zone 2.2.2 Features of the Security Zone 2.2.3 Security Zone on Eudemon
2.2.1 Introduction to Security Zone

Zone is a concept introduced in Eudemon, which is one of main features distinguishing the Eudemon from the router. For the router, the network security check is performed on interfaces because the networks connected with each interface are equal in security. That is, there is no obvious difference between internal networks and external networks for the router. In this way, when a data stream unidirectionally passes through a router, it may be checked twice on both the ingress interface and the egress interface to meet the separate security definitions on each interface. However, the Eudemon's situation is different, where internal networks and external networks are clearly defined. The Eudemon protects internal networks from illegal intrusion of external networks. When a data stream passes through a Eudemon device, the security operation triggered varies with data stream direction. At this time, it is not suitable to check the security policy on the interface of the Eudemon. Therefore, the Eudemon introduces the concept of security zone.
2.2.2 Features of the Security Zone

A security zone is composed of one or more interfaces with the same security level. The features of the security zones are as follows:
l
The security level is denoted by an integer in the range of 1 to 100. The greater the number is, the higher the level is. There are no two zones with the same security level.
2-10
2 Introduction
2.2.3 Security Zone on Eudemon

Security Zone Classification
The default security zones on Eudemon are as follows:
l
Virtual zone (Vzone) It is a lowest-level security zone whose security level is 0. Untrust zone It is a low-level security zone, whose priority is 5. Demilitarized Zone (DMZ) It is a medium level security zone, whose priority is 50. Trust zone It is a high-level security zone, whose priority is 85. Local zone It is a highest-level security zone, whose priority is 100.
When Eudemon works in router mode, you do not need to create the five zones above. At the same time, deleting and re-setting the security level is prohibited. When Eudemon works in transparent mode or composite mode, by default, the Vzone is not supported. And the other zones neither be created nor deleted or reset the security level. In addition to the preceding default zones, the Eudemon also supports 11 customized zones.
NOTE
Derived from military, DMZ is an intermediate zone between the severe military zone and the incompact public zone. That is, it is partially dominated by military. Here in Eudemon, it indicates a zone that is independent of internal networks and external networks both logically and physically, in which public devices such as Web Server and FTP Server are placed. It is hard to locate these servers for external access if they are placed in external networks, their securities cannot be assured; while placed in internal networks, their security defects might provide opportunity for some external malicious client to attack internal networks. DMZ is developed to solve this problem.
Relations Between Interface, Network and Security Zones
CAUTION
Neither two security zones with the same security level nor an interface belonging to two different security zones are allowed in the system. Relations between interface, network and security zones:
l
Relation between interface and security zones A security zone includes one or several interfaces with one security level. Except for the Local zone, all the other security zones need to be associated with some interfaces of the Eudemon respectively, that is, to add the interface into those zones.
Relations between network and security zones

Issue 01 (2009-12-01)
2 Introduction

Internal networks should be located in high-level security zone, for example, trust zone. External networks should be located in low-level security zone, for example, untrust zone. Networks offering conditional services for the external should be located in medium level DMZ. The Local zone has no interface. The Eudemon device is in the Local zone. The Vzone has no interface and is used for the traffic forwarding between Virtual Private Network (VPN) instances.
Relation between the interface, network and security zones The relationship is shown in Figure 2-10. Figure 2-10 Relationship diagram of interface, network and security zones
Outbound Inbound Eudemon GE0/0/0 GE0/0/2 Local Trust Inbound Outbound Inbound Server DMZ Outbound Inbound Outbound
GE0/0/1 Outbound
Untrust
Inbound
......
Server Inbound Outbound
Vzone
Inbound and Outbound

Data flows of the two security zones (interzone) are grouped into two directions:
l
Inbound It refers to the direction that data are transmitted from low-level security zones to highlevel security zones.
2-12
Issue 01 (2009-12-01)

l
2 Introduction
Outbound It refers to the direction that data are transmitted from high-level security zones to lowlevel security zones.
Data transmission between security zones in different levels will enable the Eudemon to check security policy. You can set different security policy to different direction of the same interzone. When data flow moves in the two directions of the security zones, different security policy check is triggered. Data transmission direction on the Eudemon is determined based on the side with higher level security. You can conclude that:
l
Data stream transmitted from the Local zone to the Trust zone, DMZ zone and Untrust zone is called outbound data stream while inbound data stream contrarily. Data stream transmitted from the Trust zone to the DMZ zone, Untrust zone and vzone is called outbound data stream while inbound data stream contrarily. Data stream transmitted from the DMZ zone to the Untrust zone and vzone is called outbound data stream while inbound data stream contrarily. The data stream transmitted from the Untrust zone to the Vzone is called outbound data stream, while the data stream transmitted from the Vzone to the Untrust zone is called inbound data stream.
NOTE
If you allow users in high security zone to access external networks, you can configure a default interzone packet-filtering rule for the Eudemon, allowing packets to travel from a high-level security zone to a low-level security zone. Data transmission direction on the router is determined based on the interface, which is also one of main features differentiating the Eudemon from the router. Data stream sent from the interface is called outbound data stream while inbound data stream contrarily.
Issue 01 (2009-12-01)
2-13
3 System Management
3
About This Chapter
3.1 SNMP Overview
System Management
3.2 Introduction to the Features of Web Management
Issue 01 (2009-12-01)
3-1
3 System Management
3.1 SNMP Overview

3.1.1 Introduction to SNMP 3.1.2 SNMP Versions and Supported MIB
3.1.1 Introduction to SNMP

At present, the Simple Network Management Protocol (SNMP) is widely used in network management. It is an industrial standard. The SNMP protocol ensures that management information can be transmitted between any two nodes. Based on the SNMP, a network administrator can perform the following operations at any node on the network:
l l l l l l
Retrieve information Modify information Locate a fault Diagnose a failure Plan capacity Generate reports
SNMP adopts the polling mechanism and provides a basic set of functions. It is applicable to the small-sized, fast, and low-cost scenario. SNMP is widely supported by many products because it requires only the unacknowledged transport layer protocol UDP. The architecture of the SNMP protocol can be divided into the following parts:
l
Network Management Station (NMS) It is a workstation on which the client program runs. Agent It is a kind of server-side software running on the network device.
The detailed operations are described as follows: The NMS sends packets to the agent, including:
l l l l
GetRequest GetNextRequest Getbulk SetRequest packet
After receiving the request packet from the NMS, the agent reads or writes the management variables based on the packet type. The agent generates a response packet, and then return the packet to the NMS. When exceptions occur during the cold/hot startup of the device, the agent sends a trap packet to the NMS to report the event.
3 System Management
3.1.2 SNMP Versions and Supported MIB

To uniquely identify the management variable of the device in the SNMP packet, SNMP uses a hierarchical naming scheme to identify the management object. The hierarchical structure is like a tree. Each node on the tree represents a management object. As shown in Figure 3-1, one path starting from the root can be used to uniquely identify the management object. Figure 3-1 MIB tree
1 1 1 1 1 A B 2 2 2 2
As shown in Figure 3-1, management object B can be uniquely identified by a string of numbers {1.2.1.1} that is an object identifier of the management object. The management information base (MIB) is used to describe the hierarchical structure of the tree. It is a set of standard variable definitions of the monitored network device. At present, the SNMP agent on the Eudemon system supports standard network management system SNMP v3 and is compatible with SNMP v1 and SNMP v2c. Table 3-1 shows MIB supported by the system. Table 3-1 MIB supported by the system Attribute Public MIB Content MIB II based on the TCP/IP network device RIP-2 MIB Ethernet MIB PPP MIB OSPF MIB IF MIB SNMPV2 MIB Framework MIB
Issue 01 (2009-12-01) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
Standard or Specifications RFC1213 RFC1724 RFC2665, RFC2668 RFC1471, RFC1473 RFC1253 RFC1573 RFC1907 RFC2571
3-3
3 System Management
Attribute
Content Usm MIB Mpd MIB Vacm MIB Target MIB Notification MIB RADIUS MIB
Standard or Specifications RFC2573 RFC2572 RFC2275 RFC2273 RFC2273 RFC2618, RFC2620 -
Private MIB
Performance alarm MIB Device panel MIB Device resource MIB VLAN QoS Configuration management MIB System management MIB
3.2 Introduction to the Features of Web Management

The web-manager function provides users with a simple and friendly web configuration interface. Through this interface, users can operate and maintain the Eudemon conveniently. Users can access the interface with either of the following methods:
l
Encryption The Web browser communicates with the Eudemon through the HTTP security protocol (HTTPS). The encryption function ensures the security of user information.
Non-encryption The Web browser communicates with the Eudemon through the HTTP protocol.
Users access the Eudemon through the Web browser and send HTTP packets to the Eudemon. The Eudemon starts the Web server to process the HTTP packets sent from the users. HTTP packets are classified into the following two types:
l
get If the HTTP packets sent from the Web browser to the Eudemon are get packets, the Eudemon triggers the get-processing process and gets the configuration information about each function modules from the Eudemon.
post
3-4
3 System Management
If the HTTP packets sent from the Web browser to the Eudemon are post packets, the Eudemon triggers the post-processing process and sends the configuration information to each function module of the Eudemon.
Issue 01 (2009-12-01)
3-5
4 Security Features
4
About This Chapter
4.1 ACL 4.2 Security Policy 4.3 NAT 4.4 Attack Defense 4.5 P2P Traffic Limiting 4.6 IM Blocking 4.7 Static Multicast 4.8 Keyword Authentication 4.9 Authentication and Authorization 4.10 IP-CAR 4.11 TSM Cooperation 4.12 SLB
Security Features
Issue 01 (2009-12-01)
4-1
4 Security Features
4.1 ACL
4.1.1 ACL Definition 4.1.2 ACL Application 4.1.3 ACL Step 4.1.4 ACL on the Eudemon
4.1.1 ACL Definition

The Eudemon must be capable of controlling network data stream so as to define:
l l l
Network security QoS requirement Various policies
Access Control List (ACL) is one of methods to control data stream. An ACL is a series of ordered rules composed by permit or deny statements. The permit action allows the packets to pass through the Eudemon while the deny action forbids the packets to pass through the Eudemon. The rules are described mainly by:
l l l l
Source address Destination address Port number Upper layer protocol
4.1.2 ACL Application

Packet Filter
Packet filter is a kind of network security protection mechanism. It is used to control the inbound and outbound data between networks in different security levels. Before forwarding the data packet, the Eudemon needs to check information in the packet header, including source address of packets, destination address of packets, source port, destination port, upper layer protocol and so on. Then, the Eudemon determines whether to forward the data packet or discard it based on the comparison result with the defined rule.
NAT
Network Address Translation (NAT) is to translate an IP address in a data packet header into another IP address. The NAT mechanism is mainly used to enable internal networks (that use
4 Security Features
private IP addresses) to access external networks (that use public IP addresses) and solve the lack of IP addresses.. In practice, it is required that some internal hosts (with private IP addresses) can access the Internet (namely the external network) while others cannot. It can be achieved by associating ACL and NAT address pools, that is, only the data packet matching ACL rules can perform NAT. In this way, it efficiently controls the range of NAT.
QoS
Quality of Service (QoS) is used to evaluate the service capability to meet the need of clients. In order to assure QoS on the Internet, it is required to enhance traffic control and resource allocation of IP layer to provide differentiated services for different requirements. Traffic classification is the premise and basis for differentiated service. In practice, you need to do as follows. 1. Defining traffic classification rules. Traffic classification rules can classify traffic by identifying traffic priority based on:
l l
Type of Service (ToS) field in the IP packet header Defined ACL, For example, ACL including the following elements.

Source address Destination address MAC address IP protocol Port number of application program
2.
Applying traffic classification policy or ACL on traffic monitoring and congestion management.
Routing Policy
Routing policy is used to send and receive routing information as well as filter routing information. There are many methods to filter routing information, in which ACL is one of the most important methods and widely used. A client can apply ACL to specify an IP address or subnet range as the destination address or the next hop address for matched routing information.
4.1.3 ACL Step

Configuring the Eudemon, you can set a step for an ACL rule group. Step means the difference between neighbor IDs automatically allocated to each rule in the ACL rule group. For instance, given the step is set to 5, IDs of rules should be multiples of 5 beginning with 0, that is, 0, 5, 10, 15 and so on. By default, the step of the ACL rule group is 5. Setting step is helpful for inserting new rules between rules. For example, there are four rules, and their rule numbers are 0, 5, 10, and 15. To insert a rule after the first rule, you can use the rule 1 xxxx command to insert a rule numbered 1 between 0 and 5.
NOTE
Suppose you set a step. You must delete the existed rule (including rule 0) before you use the step command to change the step or use the undo step command to restore the default step value.
Issue 01 (2009-12-01)
4-3
4 Security Features
4.1.4 ACL on the Eudemon

Eudemon supports various ACLs as well as time-range-based application and logging of ACL.
ACL Classification
Eudemon supports the following ACL:
l l l
Basic ACL Advanced ACL MAC-based ACL
Table 4-1 lists the classification of the ACL. Table 4-1 Classification of the ACL Type Basic ACL Advanced ACL Value Range 2000 to 2999 3000 to 3999 Description Basic ACL only uses source addresses to define data flow. Advanced ACL can define rules based on source addresses, destination addresses, and IP payload protocol type, such as TCP source or target port, the type of the ICMP protocol, and message codes. MAC-based ACL can define data flows though the source MAC addresses, destination MAC addresses, and type field in the Ethernet frame header.
MAC-based ACL
700 to 799
ACL Match Order

An ACL is composed of multiple permit or deny statements. Each statement describes different rules, which may be repeated or inconsistent. When matching a packet to the ACL rules, you need to set the ACL match order. By default, the Eudemon is matched in configuration order; that is, the Eudemon is matched according to the configuration order of the ACL rules. When configuring the ACL rules, you need to pay attention to the matching order. Configure the ACL rule according to the specific situation. Once the data stream successfully matches with a rule, it does not go on matching. The Eudemon performs the subsequent data stream configuration based on this rule.
4 Security Features
Source Address and Wildcard Mask

When basic ACL is applying, a source address need to be specified, which can be a host, a host group or an entire subnet or network. The range of the source address is determined by its wildcard mask field. Different from a subnet mask, 0 in a wildcard mask refers to a bit that must be matched and 1 refers to a bit that allows of mismatch. That is, perform "not" algorithm of each bit sourcewildcard and then perform "and" with source-address to get the source address range as follows: source-address = 192.168.15.16 11000000.10101000.00001111.00010000 source-wildcard = 0.0.0.255 00000000.00000000.00000000.11111111 source-address range = 192.168.15.0 11000000.10101000.00001111.00000000 The any parameter indicates that packets from any source IP address match the rule. In this case, the value of the source-wildcard parameter is 255.255.255.255 and the value of the sourceaddress parameter can be any address.
ACL Rule Based on Time Range

It is required to improve the flexibility on the control of resource access. For example, system administrator only permits passing some data streams during worktime or allows clients to access some resources in some time ranges. In this case, ACL rule based on time range can be used.
ACL Rules Quoting Address Set and Port Set

To simplify the configuration and maintenance of ACL rules, the Eudemon supports the ACL that quotes the address set and port set. An ACL rule that is described through the address set and port set shows as a traditional set of rules with the same priority in application. The formula in the new set is described as follows: The number of the rule elements with the same priority = the number of the elements in address set 1 the number of elements in address set 2 the number of elements in port set 1 the number of elements in port set 2. For example, configure two address sets and one port set, and each set respectively contains two elements and is applied in ACL 3000.
<Eudemon> system-view [Eudemon] ip address-set a1 [Eudemon-address-set-a1] address 1 1.1.1.1 0 [Eudemon-address-set-a1] address 2 2.2.2.1 0 [Eudemon-address-set-a1] quit [Eudemon] ip address-set a2 [Eudemon-address-set-a2] address 1 3.3.3.1 0 [Eudemon-address-set-a2] address 2 4.4.4.1 0 [Eudemon-address-set-a2] quit [Eudemon] ip port-set p1 protocol tcp [Eudemon-tcp-port-set-p1] port 1 eq 21 [Eudemon-tcp-port-set-p1] port 2 eq 22 [Eudemon-tcp-port-set-p1] quit [Eudemon] acl 3000 [Eudemon-acl-adv-3000] rule permit tcp source address-set a1 destination addressset a2 destination-port port-set p1
The configuration effects of the above commands are the same as the following ACL rules:
[Eudemon] acl 3000 [Eudemon-acl-adv-3000] rule permit tcp source 1.1.1.1 0 destination 3.3.3.1 0
Issue 01 (2009-12-01)
4-5
4 Security Features
destination-port eq 21 [Eudemon-acl-adv-3000] destination-port eq 22 [Eudemon-acl-adv-3000] destination-port eq 21 [Eudemon-acl-adv-3000] destination-port eq 22 [Eudemon-acl-adv-3000] destination-port eq 21 [Eudemon-acl-adv-3000] destination-port eq 22 [Eudemon-acl-adv-3000] destination-port eq 21 [Eudemon-acl-adv-3000] destination-port eq 22
rule permit tcp source 1.1.1.1 0 destination 3.3.3.1 0 rule permit tcp source 1.1.1.1 0 destination 4.4.4.1 0 rule permit tcp source 1.1.1.1 0 destination 4.4.4.1 0 rule permit tcp source 2.2.2.1 0 destination 3.3.3.1 0 rule permit tcp source 2.2.2.1 0 destination 3.3.3.1 0 rule permit tcp source 2.2.2.1 0 destination 4.4.4.1 0 rule permit tcp source 2.2.2.1 0 destination 4.4.4.1 0
4.2 Security Policy

4.2.1 Packet Filter 4.2.2 ASPF 4.2.3 Blacklist 4.2.4 MAC and IP Address Binding 4.2.5 Port Identification 4.2.6 Virtual Firewall
4.2.1 Packet Filter

Packet filter is a kind of network security protection mechanism. It is used to control the inbound and outbound data between networks in different security levels. When forwarding packets, first, the Eudemon compares ACL with the information in the packet header, including:
l l l l l
Source address Destination address Upper layer protocol borne on IP layer Source port of the data packet Destination port of the data packet
After that, the Eudemon determines whether to forward the data packet or discard it based on the comparison result with the defined rule. A series of filter rules are needed to filter data packets, which can be carried out by applying filter rules defined by ACL between different zones in the Eudemon.
4.2.2 ASPF
Overview of ASPF
Application Specific Packet Filter (ASPF) is the packet filter based on the application layer, that is, the status-based packet filter. It cooperates with the common static packet filter function to
4 Security Features
carry out the security policy of internal network. ASPF can detect the application layer protocol session to prevent the unmatched data packet from passing the Eudemon. In order to protect the security of network, the packet filter based on ACL rule can detect data packets on network layer and transmission layer to prevent illegal intrusion. ASPF can detect protocols on application layer and monitor application traffic. In addition, ASPF provides the following functions:
l l
Java Blocking can prevent network from being destroyed by harmful Java Applets. ActiveX Blocking can prevent network from being destroyed by harmful ActiveX.
ASPF detects protocols on the application layer and prevents malicious intrusion, through maintaining session status and checking packet protocol and port number of session. The ASPF protocol of the Eudemon supports multiple types of traffic monitoring:
l l l l l l l l l l l l l l
File Transfer Protocol (FTP) H.323 Protocol (H323) Hyper Text Transport Protocol (HTTP) Huawei Conference Control protocol (HWCC) Windows Messenger (MSN) Network Basic Input/Output System (NetBIOS) Detect QQ protocol (QQ) Point to Point Tunnel Protocol (PPTP) Real-Time Streaming Protocol (RTSP) Session initiation Protocol (SIP) SQL*NET Protocol (SQLNET) Media Gateway Control Protocol (MGCP) Multimedia Messaging Service (MMS) Remote Procedure Call (RPC)
QQ/MSN Chat Detection

At present, most networks deploy the NAT devices to save resources of IP addresses. Thus, users in different intranets can chat with each other after NAT. For the text chat, the communication of users can be forwarded smoothly by QQ server since the server saves the address mapping information of these two users. For audio or video chat, it is expected that the two users directly exchange file, audio, or video information of large traffic. Thus, resources resulting from transfer of the QQ server will not be consumed. However, the traditional NAT devices cannot meet such requirement. To solve this problem, on the Eudemon, you can enable the detection of QQ or MSN chats between the private network and public network. Thus, address mapping is set up when a QQ or MSN chat is started up. In this case, users in two different private networks can transfer files and conduct audio or video chat directly.
4 Security Features
Triplet ASPF
The Eudemon is equivalent to a quintuple NAT device. That is, to set up a session on the Eudemon, five elements are required, including the source IP address, source port number, destination IP address, destination port number, and protocol number. A session can be created and packets can pass through the Eudemon only when these elements are available. However, some real-time communication tools, such as QQ and MSN, require process of triplet fields:
l l l
Source IP address Source port Protocol number
In order to adapt to such communication mechanism, the Eudemon changes quintuple process to triplet process. In this way, communications such as QQ and MSN can traverse smoothly. Besides the NAT traversal of QQ or MSN, other sessions like TFTP, which only uses the source IP address, the source port and the protocol number, also need configuring triplet ASPF on the Eudemon.
4.2.3 Blacklist
Blacklist is one of security features of the Eudemon. The most important feature of blacklist is that it can be added or deleted dynamically by the Eudemon module. Compared with the ACLbased packet filter, the blacklist packet filter can filter users with specific IP addresses at a much higher speed. This is because that the blacklist packet filter can associate with advanced ACLs to match only IP addresses, which significantly accelerates blacklist entries matching. You can create blacklist entry in three ways:
l l l
Creation through command lines. Dynamical creation through the Eudemon attack defense module. If a user consecutively failed to log in to the system for three times, the user is added to the blacklist.
After corresponding attack defense is enabled, when Eudemon discovers the attack attempt of a specific IP address based on the packet action, it can automatically modify its blacklist to filter all the packets sent from the specific address.
4.2.4 MAC and IP Address Binding

MAC and IP address binding means that the Eudemon associates the specific IP address and MAC address based on the client configuration. In this way, the Eudemon will discard the packet whose MAC address does not correspond to the associated IP address and forcibly forward the packet whose destination address is the specific IP address to the bound MAC address. As a result, the imitated IP address attack is avoided and the network is protected.
4.2.5 Port Identification

Application layer protocols usually communicate through well-known port number. Port identification allows a client to define a group of new port numbers besides the system-defined
4 Security Features
port number for various applications and also provides some mechanisms to maintain and use the user-defined port configuration information. Using port identification, you can create and maintain a system-defined port and a user-defined port identification list for various application protocols. The Eudemon supports basic ACL-based host port identification. Host port identification is to establish user-defined port number and application protocol identification on packets sent to some specific hosts. For example, regard TCP packets sent to the host at 10.110.0.0 through port 8080 as HTTP packets. The host range is defined based on basic ACL. The ACL identified by the port of the host and quoted by the packet filter differ in the following aspects:
l
When configuring the interzone packet-filtering rule, the specified ACL should have explicit directivity. The Eudemon only permits the packets that move from the source address to the target address to pass. When configuring port identification, the specified basic ACL is only used to define the range of hosts without directivity.
4.2.6 Virtual Firewall

In recent years, small private networks are increasing. Such networks usually belong to smallscale enterprises, which have the following features:
l l
High requirement on security Cannot afford a dedicated security device
According to this reason, Huawei launches the Eudemon multi-instance solution. Figure 4-1 shows the networking of the firewall multi-instance configuration. As shown in Figure 4-1, a firewall is partitioned into multiple virtual firewalls to provide relatively separate security assurance for small private networks. Carriers can adopt the virtual firewall technology to provide separate network security assurance services for multiple private networks. Figure 4-1 Networking diagram of virtual firewall
vfw2 DMZ GE 0/0/0 192.168.2.1/24 GE 5/0/0 10.1.1.1/24 Eth 1/0/0 10.2.1/24 vfw2 Trust GE 0/0/1 2.1.2.1/24
vfw2 Untrust
vfw1 Trust
GE 6/0/0 192.168.3.1/24
vfw1 Untrust
Eth 2/0/0 192.168.4.1/24 vfw1 DMZ
Issue 01 (2009-12-01)
4-9
4 Security Features
Each virtual firewall is a combination of one VPN instance, one security instance and one configuration instance. It can provide proprietary route forwarding plane, security service plane and configuration management plane for virtual firewall users.
VPN Instance
The VPN instance provides isolated VPN routes for the virtual firewall users. A VPN instance corresponds with one virtual firewall. VPN routes provide routes for packets received by virtual firewalls.
Security Instance
The security instance provides isolated security service for the virtual firewall users. A security instance corresponds with one virtual firewall. A security instance owns private interfaces, zones, inter-zones, ACLs, and NAT address pools. The security instance can provide private security services, including:
l l l l l l l
Address binding Blacklist NAT Packet filter Statistics Attack defense ASPF
Configuration Instance
The configuration instance provides isolated configuration management planes for virtual firewall users. A configuration instance corresponds with one virtual firewall. After virtual firewall users log on to the firewall, they have rights to manage and maintain the VPN instance and security instances.
4.3 NAT
4.3.1 Introduction 4.3.2 NAT on the Device
4.3.1 Introduction
NAT is to translate the IP address in IP data packet header into another IP address. It is mainly used for private network to access external network in practice. NAT can slow down the IP address space depletion by using several public IP addresses to represent multiple private IP addresses. Usually, private networks use private IP addresses. RFC 1918 defines three IP address blocks for private and internal use as follows:

l l l
4 Security Features
Class A: 10.0.0.0 to 10.255.255.255 (10.0.0.0/8) Class B: 172.16.0.0 to 172.31.255.255 (172.16.0.0/12) Class C: 192.168.0.0 to 192.168.255.255 (192.168.0.0/16)
IP addresses in the above three ranges will not be assigned in the Internet, so they can be used in the intranet of a company or enterprise without need of requesting Internet Service Provider (ISP) or register center. NAT is mainly used for private network to access external network in practice. It can slow down the IP address space depletion by using several public IP addresses to represent multiple private IP addresses. Figure 4-2 shows a basic NAT application process. Figure 4-2 Networking diagram of basic processes of NAT
Data Packet 1 Data Packet 1' 202.130.10.3 192.168.1.3 Source: 192.168.1.3 Source: 202.169.10.1 Destination: 202.120.10.2 Destination: 202.120.10.2 PC PC Untrust Trust GE0/0/0 Eudemon GE0/0/1 202.169.10.1 192.168.1.1
Data Packet 2 Source: 202.120.10.2 Destination: 192.168.1.3 Server 192.168.1.2
Data Packet 2' Source: 202.120.10.2 Destination: 202.169.10.1
Server 202.120.10.2
NAT server such as Eudemon is located at the joint between private network and public network. Interactive packets between an internal Personal Computer (PC) and an external server all pass the NAT sever. The exchange of addresses is as follows. 1. When the internal PC at 192.168.1.3 sends the data packet 1 to the external server at 202.120.10.2, the data packet will traverse the NAT server. The NAT server checks the contents in the packet header. The destination address in the header is an extranet address. The server will translate the source address 192.168.1.3 of the data packet 1 into a valid public address on the Internet 202.169.10.1, then forward the packet to the external server and record the mapping on the NAT list. After receiving the data packet 1', the external server sends the response packet 2' (The destination is 202.169.10.1). After the data packet 2' access the NAT server, the NAT server will inquire the NAT list, the NAT server replaces the destination address in packet 2 header with the original private address 192.168.1.3 of the internal PC.
2.
3. 4.
The NAT process is transparent to the internal PC and the external server. The internal PC determines that the packets exchanged with the external server are not processed by the NAT server. The external server determines that the IP address of the internal PC is 202.169.10.1. IP address 192.168.1.3 is transparent to the external server.
4 Security Features
4.3.2 NAT on the Device

NAT Mechanism on the Eudemon
NAT mechanism can be divided into the following two parts:
l
Translating an IP address and port of a host in the internal network into an extranet address and port. Translating the extranet address and port into the IP address and port of a host in the internal network.
This process is called translation between private address or port and public address or port. When data flow moves from one security zone to another, the Eudemon checks the data packet to determine whether to perform the NAT. If necessary, the NAT is performed based on the following principles:
l
At the egress of the IP layer, the Eudemon translates the source address from the private address to the public address and sends it to the external network. At the ingress of the IP layer, the Eudemon restores the destination address from the public address to the private address and sends it to the internal network.
Many-to-Many NAT and NAT Control

As shown in Figure 4-2, the IP address of the egress interface of the NAT server is the source address performed by NAT conversion. In this way, all the hosts in the intranet share one extranet IP address when they access the external network. In other words, only one host can access the external network at a time when several hosts intend to access the external network at the same time, which is called one-to-one NAT. An extended NAT implements the concurrent access, that is, multiple public IP addresses are assigned to a NAT server. When one internal host accesses the external network, the NAT server assigns a public address IP1 to a requesting host, appends a record in the NAT list, and forwards the data packet. When another internal host accesses the external network, the NAT server assigns another public address IP2 to another request host and so on. This is called many-tomany NAT.
NOTE
The number of public IP addresses on the NAT server is far less than the number of hosts in the intranet because not all hosts will access the extranet at a time. The public IP address number is determined based on the maximum number of intranet hosts that access the external network at the rush hour of the network.
In practice, it may be required that only some intranet hosts can access the Internet (external network). In other words, the NAT server will not translate source IP addresses of those unauthorized hosts, which is called NAT control. Eudemon fulfills many-to-many NAT through defining address pool and controls NAT through ACL. The detail is as follows:
l
Address pool It is a set of public IP addresses for NAT. You should configure a proper address pool based on valid IP address number, internal host number as well as the actual condition. An address will be selected from the pool as the source address during the NAT.
4-12
Issue 01 (2009-12-01)

l
4 Security Features
ACL-based NAT It indicates that only the data packet meeting the requirement of ACL rule can be translated. In this way, the NAT range can be controlled effectively and some hosts are entitled to access the Internet.
NAPT
Besides the many-to-many NAT, Network Address Port Translation (NAPT) is another way to achieve the concurrent access. NAPT allows the map from multiple internal addresses to a public address. Therefore, it can be called as "many-to-one NAT" or address multiplex informally. NAPT maps IP addresses and port numbers. Data packets from various internal addresses can be mapped to the same external address with different port numbers. In this way, different internal addresses can share the same public address. The fundamentals of NAPT are shown in Figure 4-3. Figure 4-3 NAPT allows multiple internal hosts to share a public address by translating IP address and port number
Data Packet 1 Data Packet 1' Source: 192.168.1.3 Source:202.169.10.1 Source port: 1357 Source port: 1357 202.130.10.3 Data Packet 2 Data Packet 2' 192.168.1.3 PC Source:192.168.1.3 Source:202.169.10.1 Source port:2468 Source port: 2468 PC Trust Untrust GE0/0/0 Eudemon GE0/0/1 192.168.1.1 202.169.10.1
Data Packet 3 Source:192.168.1.1 Source port: 11111 Server 192.168.1.2 Data Packet 4 Source: 192.168.1.2 Source port: 11111
Data Packet 3' Source: 202.169.10.1 Source port: 11111 Data Packet 4' Source: 202.169.10.1 Source port: 22222
Server 202.120.10.2
As shown in Figure 4-3,four data packets from internal addresses arrive at the NAT server.
l
Packet 1 and packet 2 come from the same internal address with different source port number. Packet 3 and packet 4 come from different internal addresses with the same source port number.
After the NAT mapping, all the four packets are translated into the same external address with different source port numbers, so they are still different from each other.
4 Security Features
When the response packets access the Eudemon, the NAT process can also differentiate them based on their destination addresses and port numbers and forward them to the internal hosts. After the NAPT function is configured, during the NAT conversion, the Eudemon first multiplexes the chosen address in the address pool. When the port numbers of the address are used up, the Eudemon chooses another address to fulfill the conversion. Compared with the many-to-many address conversion, that can largely reduce the number of common addresses in the address pool.
Internal Server
NAT can "shield" internal hosts by hiding the architecture of the intranet. However, sometimes you want to permit some hosts on external networks to access some hosts on the intranet, such as a Web server or a FTP server. You can flexibly add servers on the intranet through NAT. The Eudemon applies two ways to specify the external address for the internal server. For example:
l l
You can use 202.169.10.10 as the external address of the WWW server. You can use 202.110.10.12:8080 as the external address of the WWW server.
NAT on the Eudemon provides some servers on the intranet for some hosts on external networks. When a client on an external network accesses a server on the intranet, the Eudemon operates the following two parts:
l
The Eudemon translates the destination address in the request packet into a private address on the internal server. The Eudemon translates the source address (a private address) in the response packet into a public address.
Moreover, NAT can provide multiple identical servers such as WWW servers for external clients.
NOTE
he internal servers serving for external hosts are usually located in DMZ zone of Eudemon, which are not allowed to initiate connections to external hosts generally.
Bi-directional NAT
The bi-directional NAT can be used in the following two situations:
l
When users in the low-priority zone access the public IP address of the NAT server, the destination address of the packets are translated to the private IP address of the server. But, the server need be configured with the route to the public IP address. If you need to simplify the configuration, that is, do not configure the route to the public IP address, you need to configure the inbound NAT, that is, from the low priority zone to the high priority zone. When users in the same security zone access each other, you need to configure interzone NAT you need to configure the interzone NAT function.
As shown in Figure 4-4, the NAT from the low priority zone to the high priority zone is configured on the Eudemon. For example, configure the NAT from the Untrust zone to the DMZ zone.
4 Security Features
Figure 4-4 Networking diagram of configuring inbound NAT

GE0/0/0 10.1.1.1/24 GE0/0/1 200.1.1.1/24 Untrust
DMZ FTP Server 10.1.1.2/24 private IP address
Eudemon
Untrust PC 200.1.1.2/24 public IP address
When users in the Untrust zone access the server in the DMZ zone, the Eudemon carries out NAT as follows:
l
The Eudemon converts the destination address of the request packet from the external users to the private IP address of the internal server. The Eudemon converts the source IP address to the address in the address pool (private IP address). The Eudemon converts the source address (private IP address) of the response packets from the internal server to the public IP address. The Eudemon converts the destination IP address (private IP address) to the public IP address.
NOTE
The internal servers that allow the access of the external users are usually located in the DMZ zone. Normally, the equipment in the DMZ zone is not allowed to originate connections to the external device.
As shown in Figure 4-5, NAT within the same zone is configured on the Eudemon. For example, configure NAT in the Trust zone. Figure 4-5 Networking diagram of NAT within the zone
Eudemon
GE5/0/0 10.1.1.1/24
Switch
PC 10.1.1.5/24
FTP Server 10.1.1.2/24 Trust
When users in the Trust zone access the server in the same zone, the Eudemon carries out NAT as follows:
Issue 01 (2009-12-01)
4-15
4 Security Features
l
The Eudemon converts the destination IP address of the request packet from the external users to the private IP address of the internal server. The Eudemon converts the source IP address to the public IP address in the address pool. The Eudemon converts the private source IP address of the response packet in the internal server to the public IP address. The Eudemon converts the destination address (public IP address) to the address of the private network.
ALG-Application Level Gateway

NAT and NAPT can translate the address in the IP packet header and the port number in the TCP/UDP packet header only. However, the IP address and port number information can also be put in the payload of some packets, such as ICMP and FTP packets, which cannot be translated by NAT technologies and may cause some errors. For instance, an FTP server sends its internal IP address to an extranet host to establish a session connection. Because the IP address information is put in the payload of the packet, the NAT device cannot translate it. If the external host uses the untranslated private address, the FTP server will be unreachable. Adding Application Level Gateway (ALG) to NAT, you can solve the above problem. ALG is the translation proxy of some application protocols. It interacts with NAT to modify the specific data encapsulated in the IP packet based on the NAT state information and helps the application protocols to function in various ranges through other necessary processes. For instance, a "destination unreachable" ICMP packet is that its data part contains the header of packet A which causes the error (Note because packet A has been translated over NAT, the current source address is not the real address of the internal host). If ICMP ALG is enabled, it will interact with NAT and open the ICMP packet before NAT forwards the packet. Then NAT translates the address in the header of packet A into the accurate format of the internal host address and forwards the ICMP packet after other necessary processes. Eudemon provides a perfect NAT ALG mechanism with good scalability, which can support various special application protocols without need of modifying NAT platform. Between different security zones, the Eudemon implements the following ALG functions of frequently used application protocols:
l l l l l l l l l l l l
FTP H.323 HWCC (Huawei Conference control Protocol) ICMP ILS (Internet Locator Service) MGCP (Media Gateway Control Protocol) MSN NetBIOS PPTP QQ RTSP User-define
4-16
4 Security Features
4.4 Attack Defense

4.4.1 Introduction 4.4.2 Classes of Network Attacks 4.4.3 Typical Examples of Network Attacks 4.4.4 Introduction to the Attack Defense Principle
4.4.1 Introduction
Normally, network attacks intrude or destroy network servers (hosts) to steal the sensitive data on servers or interrupt server services. There are also the network attacks that directly destroy network devices, which can make networks service abnormal or even out of service. The attack defense of the Eudemon can detect various types of network attacks and take the measures to protect internal networks from malicious attacks. As a result, the Eudemon can assure the normal operations of the internal networks and systems.
4.4.2 Classes of Network Attacks

Network attacks can be divided into three classes: denial of service attack, scanning and snooping attack, and defective packet attack:
l
Denial of Service Attack
Denial of Service (DoS) attack is to attack a system by sending a large number of data packets. As a result, the system cannot receive requests from valid users normally or the host is suspended and cannot work normally. The DoS attacks include SYN Flood, Fraggle and so on. The DoS attack differs from other types of attacks. In the DoS attack, attackers prevent valid users from accessing resources or routers. In other types of attacks, attackers search for ingresses of internal networks.
Distributed denial of service (DDoS) attack is one type of DoS attack. DDoS attack is a kind of attack, where attackers attack a host by using tens of or hundreds of computers under their control, so that the system cannot accept normal requests of users or cannot normally work.
Scanning and Snooping Attack Scanning and snooping attack is to point out a potential target by identifying an existing system in the network by means of ping scanning (including ICMP and TCP). Through TCP and UDP port scanning, the attacker can detect the running system and the monitoring service and then get a general idea of the service type and the potential security defect of the system so as to prepare for the further intrusion.
Defective Packet Attack Defective packet attack is to send a defective IP packet to the destination system so that the system will crash when it processes the IP packet. The defective packet attacks include Ping of Death and Teardrop and so on.
Issue 01 (2009-12-01)
4-17
4 Security Features
4.4.3 Typical Examples of Network Attacks

The attacks in the current network fall into the following groups:
l
IP Spoofing Attack To get an access right, an intruder generates a packet carrying a bogus source address which can make an unauthorized client access the system applying the IP authentication even in the root authority. In this way, the system can also be destroyed even though the response packet does not reach the intruder. This is the IP Spoofing attack.
Land Attack Land attack is to configure both the source address and the destination address of the TCP SYN packet to the IP address of the attack target. Thus, the attack target sends the SYNACK message and sends back the ACK message to itself, and then creates a null connection. Each of the null connection will be saved till it times out. Different attack targets have different responses to the Land attack. For instance, many UNIX hosts will crash and Windows NT hosts will slow down.
Smurf Attack The simple Smurf attack is to attack a network by sending an ICMP request to the broadcast address of the target network. All the hosts in the network will respond to the request, which will generate the traffic 10 or 100 times more than the traffic of large ping packets. Network congestion thus occurs. The advanced Smurf attack is mainly used to attack the target host by configuring the source address of the ICMP packet to the address of the target host so as to make the host crash finally. It takes certain traffic and duration to send the attack packet to perform attack. Theoretically, the larger the number of the hosts is, the more obvious the effect will be. Another new form of the Smurf attack is the Fraggle attack.
WinNuke Attack WinNuke attack is to cause a NetBIOS fragment overlap by sending Out-Of-Band (OOB) data packets to the NetBIOS port (139) of the specified target installed with the Windows system so as to make the target host crash. There are also Internet Group Management Protocol (IGMP) fragment packets. Because IGMP packets cannot be fragmented generally, few systems can solve the attack caused by IGMP fragment packets thoroughly. When the system receives IGMP fragment packets, you can guess there is attack.
SYN Flood Attack Because of the limited resources, TCP/IP stacks only permit a restricted number of TCP connections. Based on the above defect, the SYN Flood attack forges an SYN packet whose source address is a bogus or non-existent address and initiates a connection to the server. Accordingly, the server will not receive the ACK packet for its SYN-ACK packet, which forms a semi-connection. A large number of semi-connections will exhaust the network resources. As a result, valid users cannot access the network until the semi-connections time out. The SYN Flood attack also takes effect in the applications whose connection number is not limited to consume the system resources such as memories.
ICMP Flood Attack ICMP flood attack is to send a large number of ICMP messages (such as ping) to the specific target in a short time. Thus, the target system is unable to transmit valid packets normally.
UDP Flood Attack The attacker sends a lot of UDP packets to the server. The packets occupy the link bandwidth of the server. In this way, the server cannot provide services for the outside properly due to the heavy load.
4-18
Issue 01 (2009-12-01)

l
4 Security Features
IP Sweeping or Port Scanning Attack IP Sweeping or Port Scanning Attack is to detect the target address and port via scanning tools to make sure the active system connected with the target network if it receives responses from the system and the port through which the host provides services.
Ping of Death Attack The field length of an IP packet is 16 bits, which means the maximum length of an IP packet is 65535 bytes. Therefore, if the data length of an ICMP request packet is larger than 65507, the entire length of the ICMP packet (ICMP data + IP header 20 + ICMP header 8) will be larger than 65535, which may make some routers or systems crash, die or reboot. This is the Ping of Death attack.
TCP Connection Flood Attack TCP Connection flood attack is a means of DDoS attack. The attacker sends a lot of requests to the attacked server. A lot of links are generated; therefore, the attacked server cannot deal with the requests for authorized users.
GET Flood Attack The attacker sends a lot of get and post packets to the attacked server. The attacked server breaks down and cannot deal with the legal packets.
DNS Flood Attack DNS flood attack is a DDoS attack means. The attacker sends a large number of query packets to the Domain Name Server (DNS) within a short time. Therefore, the server has to respond to all the query requests. As a result, the DNS can not provide services for legal users.
ARP Attacks Common ARP attacks include ARP spoofing attacks and ARP Flood attacks. ARP spoofing attacks: The attacker sends a large amount of spoofing ARP requests and response packets to attack network devices. ARP spoofing attacks mainly include ARP buffer overflow attacks and ARP DDoS attacks. ARP Flood attacks (ARP scanning attacks): When the attacker scans hosts in its own network segment or across network segments, the firewall checks the ARP entry before sending the response message. If the MAC address of the destination IP address does not exist, the ARP module of the firewall sends the ARP Miss message to the upper layer software, asking the upper layer software to send an ARP request message to obtain the MAC address. Massive scanning packets induce massive ARP Miss messages. As a result, the firewall uses a lot of its resources to handle the ARP Miss messages and thus cannot process other services properly. In this way, scanning attacks are launched.
4.4.4 Introduction to the Attack Defense Principle

The main types of the attack defense and their principle are showed as follows.
ICMP Flood Attack Defense Principle

The Eudemon defense the ICMP flood attack by restricting the speed of ICMP packets. If a large traffic of ICMP packets appears, the Eudemon judges that the traffic is the attack traffic.
SYN Flood Attack Defense Principle

The following describes how the Eudemon defense the SYN flood attack.
4 Security Features
1.
The Eudemon detects the TCP SYN packets sent to the server. If the rate of the TCP SYN packet exceeds the threshold, the Eudemon judges that the server suffers the SYN flood attack. The Eudemon uses the TCP Proxy or TCP reverse detection to defense the SYN flood attack.
2.
UDP Flood Attack Defense Principle

The UDP flood attack defense process is as follows. 1. The Eudemon detects UDP packets transmitted to the server. If the rate at which the protected server receives UDP packets exceeds the threshold configured, the Eudemon considers the server is under UDP Flood attack. 2. The Eudemon monitors the source IP addresses accessing the server. If the Eudemon finds that one source IP address sends same UDP packets to a certain server for multiple times, this source IP address is considered as the IP address of the attacker.
TCP Connection Flood Attack Defense Principle

If the TCP Connection Flood attack defense function is enabled, the Eudemon performs the following operations: 1. If the link between the user and the server is generated, the Eudemon judges whether the user is an authorized user in the following two aspects.
l
The Eudemon collects statistics on the number of packets sent by the user to the server. In a specified duration, if the number of the packets does not exceed the threshold, the link is an unauthorized link. The Eudemon collects the unauthorized links set from the user to the server. In a specified duration, if the number of the unauthorized links is larger than the threshold, the user is an unauthorized user.
2.
The Eudemon adds the IP address to the blacklist.
GET Flood Attack Defense Principle

The Eudemon detects the get or post packets that are sent from the user to the target system. If the packet rate is larger than the specific value, the Eudemon performs the URI sampling match for the source IP address. When the number of matching reaches a specific value, the Eudemon adds the source IP address to the blacklist.
DNS Flood Attack Defense Principle

The Eudemon detects the DNS flood attack based on the querying rate of the DNS packets. When the querying rate of the DNS packets is larger than the specific alarm value, the Eudemon checks the source host for validity.
ARP Flood Attack Defense Principle

The Eudemon performs detection according to the ARP request rate. When the rate exceeds the set alarm value, the ARP request is identified as an attack.
4 Security Features
4.5 P2P Traffic Limiting

4.5.1 Introduction to P2P Traffic Limiting 4.5.2 P2P Traffic Detection and Limiting
4.5.1 Introduction to P2P Traffic Limiting

Peer to Peer (P2P) protocols are widely used in downloading on the network. The constant increase of P2P traffic affects normal operation of other network applications and increases the costs of network operation, especially for enterprises and operators who are charged by traffic. To address this problem, the Eudemon is designed with the P2P traffic limiting function. The Eudemon can accurately identify P2P traffic on networks through in-depth detection and behavior detection, and then limit the traffic according to the configured traffic limiting policies. In addition, the Eudemon can produce detailed statistics on traffic of various P2P protocols to facilitate monitoring of P2P traffic tendency. The P2P traffic limiting function can control P2P traffic and guarantee normal running of other services. The P2P traffic limiting function of the Eudemon can work jointly with ACL rules and time segment-based rate control to restrict P2P traffic, thus satisfying customers' specific requirements. The P2P traffic limiting function can be widely applied to access networks carrying high volumes of P2P traffic such as community network, campus network, and enterprise intranet. The Eudemon can limit traffic of various P2P protocols, such as BT, PPlive, PPStream. When excessive packets of protocols are detected, the performance is degraded. Therefore, the Eudemon supports setting of the number of packets to be detected for each type of P2P protocol to meet different identification requirements. When the current Eudemon cannot identify certain P2P traffic, it obtains new mode files to limit the traffic.
4.5.2 P2P Traffic Detection and Limiting

P2P Traffic Detection
If P2P traffic limiting policies are configured or P2P detection is enabled, the Eudemon detects the sessions to identify P2P traffic. The Eudemon supports two modes of detection:
l
In-depth detection The detection provides feature matching based on files. It is the main detection mode. Behavior detection The detection is on the basis of the length sequence of consecutive data packets. If the length sequence complies with the preset rules, the detection result is the P2P traffic. Behavior detection mainly detects encrypted data traffic.
To lower the load of the detection, the Eudemon uses the association detection technology. When a session is identified as that of P2P traffic, its source IP address, source port number, destination
4 Security Features
IP address, and destination port number are recorded in the associate table. If the IP address and port number of a new session match those in the associate table, the session is identified as that of P2P traffic. This reduces the burden of in-depth detection.
P2P Traffic Limiting

If P2P traffic Limiting policies are configured and a session is certainly confirmed that of P2P traffic, the Eudemon limits the P2P traffic according to the policies. The Eudemon supports flexible traffic limiting modes. The Eudemon can set multiple types of traffic-limitation bandwidth concurrently, thus using different limited bandwidth based on the P2P traffic with different policies. The Eudemon performs P2P traffic limitation on certain users through ACLs, or limits the upload and download separately of users. The Eudemon can also perform traffic limitation based on time periods.
4.6 IM Blocking
4.6.1 Introduction to IM Detecting and Blocking 4.6.2 IM Detecting and Blocking
4.6.1 Introduction to IM Detecting and Blocking

The Instant Message (IM) detecting and blocking function can block IM traffic and guarantee normal running of other services. The IM detecting and blocking function of the Eudemon can work jointly with ACL rules to block IM traffic, thus satisfying customers' specific requirements. The Eudemon can block traffic of various IM protocols, such as QQ, and MSN. When the current Eudemon cannot identify certain IM traffic, it obtains new mode files to block the traffic. The number of packets that need to be inspected for each session is the larger, the more system resources are used. If the effect of IM blocking is not satisfactory, increase the number of packets to be inspected.
4.6.2 IM Detecting and Blocking

IM Detecting
If IM blocking policies are configured or IM detection is enabled, the Eudemon detects the sessions to identify IM traffic. The Eudemon supports the modes of detection, namely, in-depth detection.
IM Blocking
If IM blocking policies are configured and a session is certainly that of IM traffic, the Eudemon limits the IM traffic according to the policies.
4 Security Features
The Eudemon also supports global traffic blocking and interzone traffic limiting. You can associate ACL rules with traffic limiting policies for interzones and specify the users whose IM traffic are to be blocked.
NOTE
If you are to detect or block IM traffic for a specific interzone, you can configure only related detection and blocking policies for this interzone to improve the performance. Then, the Eudemon does not detect or block IM traffic in other interzones.
4.7 Static Multicast

4.7.1 Restrictions of Unicast or Broadcast 4.7.2 Overview of Static Multicast 4.7.3 Implementing Static Multicast on the Eudemon
4.7.1 Restrictions of Unicast or Broadcast

Overview
With the development of the Internet, a large amount of data and voice and video information are exchanged on the network. In addition, new services come into being:
l l l l l
E-commerce Online conference Online auction Video on Demand (VOD) E-learning
All these have requirements for the information security, payment, and network bandwidth.
Unicast Information Transmission

The unicast mode establishes an independent data transmission path and sends an independent copy of the information for each user. Figure 4-6 shows the unicast information transmission.
Issue 01 (2009-12-01)
4-23
4 Security Features
Figure 4-6 Unicast information transmission

User A Unicast
User B Server
User C Data transmission channel Device connection
The amount of information transmitted on the network is in direct proportion to the number of users who have demand for this information. When there are too many users, there is too much identical information flow on the network. Thus, the bandwidth bottleneck is caused. The unicast mode is not applicable to the transmission of mass information.
Broadcast Information Transmission

The broadcast mode sends information to all the users on the network regardless of whether users need it or not. Figure 4-7 shows the broadcast information transmission. Figure 4-7 Broadcast information transmission
User A Broadcast
User B Server
User C Data transmission channel Device connection
4-24
Issue 01 (2009-12-01)
4 Security Features
The broadcast mode cannot guarantee the information security and paid services. In addition, the bandwidth is wasted when only few users require the information.
4.7.2 Overview of Static Multicast

Multicast Information Transmission
The IP multicast technology solves the above problems. When some users require specified information, the multicast source sends the information only once. A tree topology is used in routing connections for multicast packets based on multicast routing protocols. The information being sent is replicated and distributed on the node as far as possible. Figure 4-8 shows the multicast information transmission . Figure 4-8 Multicast information transmission
Multicast User A User B Server Eudemon User C
User D
Data transmission channel Device connection
Suppose users A, C, and D require the information from the server. To transmit the information accurately to the three users, first you should organize them into a receiver group. Then, the routers on the network perform the information forwarding and replicating based on the geographic location of each user of the group. Finally, the information can be correctly transmitted to the three users. For the multicast mode, the following roles exist during multicast transmission:
l l
The information sender is called "multicast source". Receivers who receive the same information comprise a multicast group and each receiver is a "multicast group member". All the routers that provide the multicast function are called "multicast routers".
For the roles in each multicast transmission, the following rules exist:
l
Members in a multicast group can reside anywhere on the network without restriction on the geographic location. A multicast source may not belong to a multicast group. It sends data to the multicast group and it may not be one receiver.
Issue 01 (2009-12-01)
4 Security Features
l l
Multiple sources can send packets to a multicast group concurrently. Some routers that do not support multicast exist on the network. Based on the tunnel technology, a multicast router can encapsulate the multicast packets into unicast IP packets and send them to a neighboring multicast router. The neighboring multicast router removes the unicast IP header and continues the multicast transmission. This prevents the network topology architecture from changing greatly.
Advantages of Multicast
The advantages of multicast are as follows:
l
Enhanced efficiency It reduces network traffic and relieves server loads and CPU loads. Optimized performance It decreases redundancy traffic. Distributed application It makes multipoint application possible.
4.7.3 Implementing Static Multicast on the Eudemon

The Eudemon forwards packets in the static multicast mode. Thus, the Eudemon should be deployed between the multicast source and the access router rather than other locations on the multicast network, as shown in Figure 4-9. Figure 4-9 Transmission mode of static multicast
Multicast User A User B Server Eudemon User C
Data transmission channel Device connection

User D
The Eudemon forwards packets from the multicast source host to the multicast access router, and then the multicast access router is combined with other multicast routers to send packets to each multicast user.
4.8 Keyword Authentication

Users in the private network can download or upload files through logging in the external FTP server. For the sake of security and management, managers in the private network need to restrict the right of users to operate FTP. For example, when managers intend to configure that some users only have rights of "get" or "put" and other users have neither.
4 Security Features
The Eudemon can be located in the egress of the private network and configured with keyword authentication function. When some users in the private network log in the external FTP server and intend to put or get a file, the Eudemon will intercept these packets. In this way, the security of information is ensured and internal users are managed.
4.9 Authentication and Authorization

4.9.1 Introduction to Authentication and Authorization 4.9.2 Introduction to Domain 4.9.3 Introduction to Local User Management
4.9.1 Introduction to Authentication and Authorization

In general, Authentication and Authorization adopts the Server-Client mode. The client runs on the resource side and the server stores the user information. This structure has good extensibility and is convenient for concentrated management of user information.
Authentication Function
Eudemon supports the following authentication modes:
l
None authentication It completely trusts users and does not check their validity. It is not used usually. Local authentication It configures the user information, including the user name, password, and other attributes, on a Broadband Access Server (BAS). Its advantage lies in fast processing speed, which reduces the operation cost. Its disadvantage is that information storage capacity is limited by its hardware.
Remote authentication It authenticates the user over Remote Authentication Dial in User Service (RADIUS) protocol. BAS acts as client to communicate with RADIUS server. RADIUS protocol can be either the standard RADIUS protocol or the extended RADIUS protocol of Huawei, and cooperates with iTELLIN/CAMS to complete the authentication.
Authorization Function
Eudemon supports the following authorization modes:
l
Direct authorization It completely trusts users and directly authorizes them to pass through. Local authorization It authorizes users based on the relative attributes of the local user account configured on the BAS.
If-authenticated authorization If the user passes the authentication and the authentication mode is not none, the user is authorized.
Issue 01 (2009-12-01)
4-27
4 Security Features
l
Authorization after RADIUS authentication It authorizes users after they pass through the RADIUS authentication. The authentication and the authorization of the RADIUS protocol are bound together, so RADIUS cannot be used to perform only authorization.
4.9.2 Introduction to Domain

The Eudemon manages users in the following two modes:
l l
Management through domains Management through user accounts
Note that all users belong to some domain. Within a domain, you can configure:
l l l
Default authorizations RADIUS templates Authentication schemes
The authorization precedence configured within a domain is lower than that configured on an Authencation and Authorization server, that is, the authorization attribute of the Authencation and Authorization server is used first. The domain authorization attribute is valid only when the Authencation and Authorization server is not of this authorization or does not support this authorization. In this way, the attribute limitation from the Authencation and Authorization server has gone and the service addition becomes flexible by managing through a domain accordingly. In the event that a domain and a user within the domain are configured with some attribute simultaneously, the precedence of the user-based configuration is higher than that of the domainbased configuration.
4.9.3 Introduction to Local User Management

The Authencation and Authorization sets up a local user database on the local Eudemon to maintain the user information and to manage users. Besides creating local user accounts, the Eudemon can conduct local authentication.
NOTE
Users with information on the local user database are called local users.
4.10 IP-CAR
IP-CAR provides the following functions:
l l
Connection number limit: You can limit the number of connections of a specific IP address. Bandwidth limit: You can limit the session bandwidth of a specific IP address.
The connection number limit function can protect specific users from attacks and prevent certain users from launching attacks. The bandwidth limit function can balance network traffic, thus ensuring the normal access rate and indirectly defending against network attacks.
4 Security Features
The Eudemon offers seven levels of bandwidth limit and connection number limit. You can set a connection number limit or bandwidth limit of a certain level for a specified scope. In addition, you can limit connection number or bandwidth by using both the ACLs and the limit level setting.
4.11 TSM Cooperation

4.11.1 Introduction to TSM Cooperation 4.11.2 Work Flow of TSM Cooperation 4.11.3 Specifications of TSM Cooperation
4.11.1 Introduction to TSM Cooperation

Networks have become an indispensable part for enterprises. However, they also expose enterprises to various security threats, such as:
l l
Internal employees steal confidential information for their own interests. Internal employees access enterprise application systems to tamper with important data without permission. Illegal accounts access the enterprise networks and insecure terminals access networks.
To solve these problems, the Eudemon cooperates with the TSM (Terminal Security Management) server to protect important network resources. By working jointly with a Secospace server, the Eudemon can classify internal users and control their access to resources based on their permission classes. This mechanism helps ensure that a user can access only authorized resources, thus preventing unauthorized internal users from accessing confidential data or applications. Figure 4-10 shows a specific networking.
Issue 01 (2009-12-01)
4-29
4 Security Features
Figure 4-10 Networking diagram of TSM Cooperation

Service Server C TA1 DMZ GE0/0/1 Untrust GE0/0/0 LAN Switch TA2 Trust TC TRS Eudemon (SACG) GE5/0/0 TM Service Server A Service Server B
TSM Server Group

TSM Controller (TC) TSM Manager (TM) TSM Recover Server (TRS) TSM Agent (TA) Security Access Control Gateway (SACG)
NOTE
For information about the functions of each part, refer to TSM server-related documents.
4.11.2 Work Flow of TSM Cooperation

As shown in Figure 4-10, the Eudemon functions as the SACG and cooperates with the TSM to control users' network access and provide terminal users with services through the service server. To access network resources, a terminal user goes through the following steps: 1. The terminal user starts the TSM Agent (TA) and enters the authentication information for the TSM server to authenticate. The authentication modes are as follows:
l l l l
Normal account Domain account MAC account Third-party authentication
2.
The TA sends the information about the terminal user to the TSM server for authentication and security checks.
l
If the user is legitimate and the security policy meets the requirement of the enterprise, the user can use the network.
4-30

l
4 Security Features
If the user is not legitimate or the security policy does not meet the requirement of the enterprise, the TA triggers an alarm to the user, and the TRS proposes corresponding recovery. After recovery, the preceding process takes place again. The terminal user can obtain certain network resources only when its security meets the requirement.
3. 4.
After the terminal user passes the authentication and security check, the TSM server asks the Eudemon to grant the user certain access rights. The Eudemon determines according to the access rights delivered by the TSM server whether the terminal user can obtain specific network resources. If yes, the Eudemon allows the user to obtain the resources; if not, the user cannot obtain the resources. When the terminal user logs out, the TA reports the logout to the TSM server. After the user logs out, the TSM server asks the Eudemon to disable the user's access.
5.
When the terminal user accesses the network resource again, it need be authenticated again. In addition, a synchronization mechanism between the Eudemon and the TSM server ensures that the Eudemon can synchronize the updates and changes of users' role information on the Secospace server.
NOTE
According to the rule of roles, the Eudemon determines whether a user has the authority to access the service server. Terminal users can access network resources matching their authority.
4.11.3 Specifications of TSM Cooperation

The cooperation between the Eudemon and the TSM supports a maximum of 2500 online users and 900 roles. One user can have up to 16 roles and one role can be shared by multiple users.
NOTE
Based on its authority, the administrator can define different roles and grant access rights to roles. The administrators with the same role enjoy the same operation rights. When creating an administrator account, the administrator need only specify roles for the account, which automatically gain all the operation rights of the roles. Granting rights in this way saves repeated operations and reduces the burden of account management.
4.12 SLB
4.12.1 Introduction to SLB 4.12.2 Virtual Service Technology 4.12.3 Server Health Check 4.12.4 Traffic-based Forwarding
4.12.1 Introduction to SLB

Based on configured load balancing algorithm, the Eudemon can distribute traffic destined to the same IP address to several servers. To the users, they are accessing the same server. In fact, the Eudemon distributes their requests to several servers for processing. In this way, the processing capacity of each server is fully
4 Security Features
exploited and load balancing is accomplished. In addition, the availability of the server is guaranteed and the best network expansibility is achieved. In the typical application of SLB, the Eudemon is located in the egress of the private network. The load balancing mechanism distributes users' traffic to servers in the following ways:
l l l
Virtual Service Technology Server Health Check Traffic-based Forwarding
4.12.2 Virtual Service Technology

Every real server has a unique private IP address (real IP address). However, all the real servers are represented by one public IP. The public IP maps a virtual server. The Eudemon distributes the traffic accessing the virtual server to each real server by using the configured load balancing algorithm. For the sake of management, a group is used to connect the virtual server and the real server. Group is a logic concept. The Eudemon uses a group to manage real servers and offers network services. The relationship between the virtual server, the group, and the real server is shown in Figure 4-11. Figure 4-11 Schematic diagram of Virtual Service
Rserver1
Group1 Rserver2 Vserver1
Vserver2 PC Group2
Rserver3
Rserver4
The advantages of the virtual service are as follows:

l l
Saving the IP address of the public network Improving the security of the system
4-32

l
4 Security Features
Improving the expandability of the system
4.12.3 Server Health Check

The Eudemon completes health check through detecting real servers regularly. If the real server is available, it returns response packets. If not, the Eudemon does not use this real server and instead it assigns traffic to other real servers based on the configured policies.
4.12.4 Traffic-based Forwarding

Through specifying the algorithm, the Eudemon sends data streams to each real server to process them. So far, the Eudemon supports three SLB algorithms, that is, source address hash, source address round, and source address weighted round.
Issue 01 (2009-12-01)
4-33
5 VPN
5
About This Chapter
5.1 Introduction 5.2 L2TP 5.3 IPSec 5.4 GRE
VPN
Issue 01 (2009-12-01)
5-1
5 VPN
5.1 Introduction
5.1.1 VPN Overview As a new technology, Virtual Private Network (VPN) rapidly develops as the Internet is widely used in recent years. It is used to build private networks on a public network. Virtual mainly indicates that a VPN network is a kind of logical network. 5.1.2 Basic VPN Technology 5.1.3 VPN Classification
5.1.1 VPN Overview

As a new technology, Virtual Private Network (VPN) rapidly develops as the Internet is widely used in recent years. It is used to build private networks on a public network. Virtual mainly indicates that a VPN network is a kind of logical network.
VPN Features
VPN has the following features:
l
Different from traditional networks, a VPN does not physically exist. It is a kind of logical network, a virtual network configured based on existing public network resources. A VPN is exclusively used by an enterprise or a user group. For VPN users, a VPN is the same as a traditional dedicated network in usage. As a kind of private networks, the resources of VPNs are independent of bear network resources. Typically, the resources of one VPN are not used by other VPNs on the bear network or non-authorized VPN users. VPN offers reliable protection mechanism to defend VPN internal information against external intrusion and interruption.
VPN is a kind of sophisticated upper-layer service. VPN services help set up interconnection for the users of a private network. VPN services realize VPN internal network topology setup, routing calculation, and user login or logout. VPN technology is much more complicated than common point-to-point application mechanisms.
VPN Advantages
VPN presents the following advantages:
l
Helping set up reliable connection between remote users, overseas offices, partners, suppliers, and company headquarters to ensure secure data transmission. This advantage is significant because it realizes the convergence of E-business or financial networks with communication networks.
Using public networks to realize information communication. With VPNs, enterprises can connect remote offices, telecommuters, and business partners at a dramatically low cost. In addition, VPNs significantly increase the use rate of network resources, thus helping the Internet Service Providers (ISPs) increase revenue. Allowing you to add or delete VPN users through software without changing hardware facilities.
5-2
5 VPN
This mechanism offers great flexibility in VPN applications.

l
Allowing telecommuting VPN users to access headquarter resources at any time and in any place. That satisfies the increasing demands for mobile services. Offering high quality VPNs such as MPLS VPN and diversified VPN services to meet VPN users' different demands for quality level. Service-specific rating mechanism brings ISPs more revenue.
5.1.2 Basic VPN Technology

VPN Basic Networking Application
The following takes an enterprise network as an example to illustrate VPN basic networking. Figure 5-1 shows the internal network established through VPN. Figure 5-1 Networking diagram of VPN applications
Remote user PoP PoP PoP Cooperator Company headquarter Internal server
As shown in Figure 5-1, eligible users can connect to the Point of Presence (POP) server of the local ISP through a Public Switched Telephone Network (PSTN), Integrated Services Digital Network (ISDN), or LAN so as to access the internal resources of an enterprise. Traditional WAN networking technology requires dedicated physical links to realize connections. With established virtual networks, remote users and telecommuters can access internal resources of an enterprise without need of being authorized by the local ISP. It is helpful for telecommuting staff and scattered users. To experience VPN services, an enterprise needs to deploy only a server, such as a Windows NT server or a Eudemon that supports VPN to share resources. After connecting to the local POP server through the PSTN, ISDN, or LAN, eligible users can directly call the remote server (VPN server) of the enterprise. The access server of the ISP and the VPN server work together to realize the call.
Issue 01 (2009-12-01)
5-3
5 VPN
VPN Fundaments
Figure 5-2 Networking diagram of a VPN access
Tunnel
VPN user
NAS
VPN Server
As shown in Figure 5-2, VPN users dial up to the Network Access Server (NAS) of the ISP through the PSTN or ISDN. The NAS identifies users by checking user names or access numbers. If the NAS server identifies that a user is a VPN user, it sets up a connection (a tunnel) with the user's destination VPN server. Then the NAS encapsulates the user's data into an IP packet and transmits it to the VPN server through the tunnel. After the VPN server receives the packet, it decapsulates the packet to read the real packet. Packets can be encrypted on both sides of the tunnel. Other users on the Internet cannot read the encrypted packets. That ensures the security of packets. For users, a tunnel is a logical extension of the PSTN or ISDN link. The operations on the logical tunnel is similar to that on a physical link. Tunnels can be achieved through tunnel protocols. Based on the realization of tunnels on Open Systems Interconnection (OSI) reference model, tunnel protocols can be categorized into two groups:
l
Layer 2 (L2) tunneling protocols An L2 tunneling protocol tunnels individual Point-to-Point Protocol (PPP) frames. The existing L2 tunneling protocols are as follow:
Point-to-Point Tunneling Protocol (PPTP) PPTP is supported by Microsoft, Ascend, and 3COM. Windows NT 4.0 and later versions support PPTP. PPTP supports the tunneling of PPP frames on IP networks. PPTP, as a call control and management protocol, uses an enhanced Generic Routing Encapsulation (GRE) technology to provide flow and congestion control encapsulation services for transmitted PPP packets.
Layer 2 Forwarding (L2F) protocol It is a Cisco proprietary protocol. L2F permits the tunneling of the link layer of higher level protocols and helps divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided.
Layer 2 Tunneling Protocol (L2TP) L2TP is drafted by IETF (Internet Engineering Task Force) with the support of Microsoft. By integrating the advantages of the preceding two protocols, L2TP has
5-4
Issue 01 (2009-12-01)
5 VPN
developed into a standard RFC. L2TP can be used to realize both dial up VPN services (such as VPDN access) and private line VPN services.
l
Layer 3 (L3) tunneling protocols For an L3 tunneling protocol, both the starting point and ending point are within an ISP. A PPP session is terminated on the NAS. Tunnels carry only L3 packets. The existing L3 tunneling protocols are as follows:
Generic Routing Encapsulation (GRE) It is used to realize the encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
IP Security (IPSec) IPSec is not a single protocol. Instead, it offers a set of system architecture for data security on IP networks, including Authentication Header (AH), Encapsulating Security Payload (ESP), and Internet Key Exchange (IKE).
GRE and IPSec are mainly applied to private line VPN services.
l
Comparison between L2 and L3 tunneling protocols L3 tunneling protocol is superior to L2 tunneling protocol in the following aspects:
Security and Reliability An L2 tunnel usually ends at a user-side device, so it has higher requirements for the security of user networks and Eudemon technology. An L3 tunnel usually ends at an ISP gateway. Therefore, it has not high requirements for the security technology of user networks.
Scalability Since an L2 tunnel tunnels a whole PPP frame, transmission efficiency may be decreased. In addition, a PPP session runs through a whole tunnel and terminates at a user-side device. That requires that the user-side gateway should keep a large amount of PPP session status and information. That may overload the system and impact its scalability. Moreover, since the Link Control Protocol (LCP) and Network Control Protocol (NCP) negotiations are quite sensitive to time, degraded tunnel efficiency may result in a series of problems such as PPP session timeout. On the contrary, an L3 tunnel terminates on an ISP gateway, and a PPP session ends on the NAS. Thus, the user gateway does not need to manage and maintain the status of each PPP session. Thereby, system load is reduced.
Typically, L2 tunneling protocols and L3 tunneling protocols are used separately. If they are appropriately used together, for example, using L2TP and IPSec together, they may provide users with high security and better performance.
5.1.3 VPN Classification

IP VPN is to emulate WAN device private line service (such as remote dial-up and DDN.) with IP devices (including public Internet or private IP backbone network). IP VPN has the following classification method.
Classification Based on Operation Modes

According to the operation modes, IP VPNs can be classified into the following types:
l
Customer Premises Equipment based VPN (CPE-based VPN)

Issue 01 (2009-12-01)
5 VPN
This kind of VPN requires users to install expensive devices and special authentication tools. In addition, users need to accomplish tedious maintenance tasks such as channel maintenance and bandwidth management. The networking of this kind of VPN is complicated and hardly scaled.
l
Network-based VPN (NBIP-VPN) This kind of VPN outsource VPN maintenance to ISPs (meanwhile users are permitted to manage and control certain services). The functionalities of VPN are realized on network devices, thus reducing user investment, offering more flexibilities in adding services and scalability, and bringing new revenue to carriers.
Classification Based on Service Applications

According to usages of services, IP VPNs can be classified into the following types:
l
Intranet VPN An intranet VPN interconnects distributed internal points of an enterprise through public networks. It is an extension or substitute of traditional private line networks and other enterprise networks.
Access VPN An access VPN provides private connections between internets and extranets for telecommuting staff, mobile offices, and remote offices through public networks. There are two type of access VPN architectures:

Client-initiated VPN connection NAS-initiated VPN connection
Extranet VPN An extranet VPN uses a VPN to extend an enterprise network to suppliers, partners, and clients, thus establishing a VPN between different enterprises through public networks.
Classification Based on Networking Modes

According to networking modes, IP VPNs can be classified into the following types:
l
Virtual Leased Line (VLL) A VLL is an emulation of traditional leased line services. By emulating leased line through an IP network, a VLL provides asymmetric, low cost DDN service. For VLL users, a VLL is similar to a traditional leased line.
Virtual Private Dial Network (VPDN) A VPDN realizes a VPN through a dial-up public network, such as an ISDN and PSTN to provide access services to enterprise customers, small-sized ISPs, and mobile offices.
Virtual Private LAN Segment (VPLS) A VPLS interconnects LANs through VPN segments on IP public networks. It is an extension of LANs on IP public networks.
Virtual Private Routing Network (VPRN) A VPRN interconnects headquarters, branches, and remote offices through network management virtual routers on IP public networks. There are two kinds of VPRN services:
VPRN realized through traditional VPN protocols such as IPSec and GRE
5-6
5 VPN
VPRN based on Multiprotocol Label Switch (MPLS)
5.2 L2TP
5.2.1 VPDN Overview 5.2.2 L2TP Overview
5.2.1 VPDN Overview

Virtual Private Dial Networks (VPDNs) adopt special network encryption protocols to set up secure VPNs for enterprise customers over public networks. With VPDNs, overseas offices and telecommuting staff can obtain a network connection to their headquarter through a virtual encryption tunnel over public networks. Other users on the public networks cannot pass through the virtual tunnel to access internal resources on the enterprise network. There are two ways to realize VPDNs:
l
The NAS sets up a tunnel to the VPDN gateway based on tunneling protocols. This realization mechanism directly connects the PPP connection of users to the gateway of the enterprise network. So far, available tunneling protocols are L2F and L2TP. The advantages of this realization mechanism are as follows:

The realization process is transparent to users. Users can access the enterprise network after a one-time login. Since the enterprise network authenticates users and assigns IP addresses, no extra public addresses are required. Users can implement network access through different platforms.
This realization mechanism requires the NAS to support the VPDN protocol, and the authentication system to support VPDN attributes. Typically, a Eudemon or dedicated VPN server is used as a gateway.
l
A client host sets up a tunnel with the VPND gateway. The client host connects with the Internet first, and then it uses dedicated client software such as the L2TP client on the Windows 2000 to set up a tunnel with the gateway. The advantage and disadvantage of this realization mechanism are as follows:
Since this realization mechanism has no requirements for ISPs, users can access resources at any place and in any way. Since this mechanism requires users to install and use dedicated software, usually Windows 2000, users can select a specified platform.
There are three types of VPDN tunneling protocols:

l l l
PPTP L2F L2TP
L2TP is widely used at present.
5.2.2 L2TP Overview

5 VPN
Background
PPP defines an encapsulation mechanism for transporting multiprotocol packets across L2 pointto-point links. Typically, a user obtains a L2 connection to a NAS using one of a number L2TP supports the tunneling of PPP link layer packets. L2TP extends the PPP model by allowing the L2 and PPP endpoints to reside on different devices interconnected by a packet-switched network. By integrating the advantages of PPTP and L2F, L2TP has developed into the industry standard of layer two tunneling protocols.
Typical L2TP Networking Application

Figure 5-3 shows the typical networking of VPDN application based on L2TP. Figure 5-3 Networking diagram of VPDN application based on L2TP
L2TP tunnel Remote user LAC
LNS
NAS Remote branch Internal server
As shown in Figure 5-3, the L2TP Access Concentrator (LAC) is attached to the switch network. The LAC is a PPP endpoint system and can process L2TP. Usually, an LAC is a NAS, which provides access services for users across the PSTN or ISDN. The L2TP Network Server (LNS) acts as one node of the PPP endpoint system and is used to process the L2TP server. An LAC sits between an LNS and a remote system and forwards packets to and from each. Packets sent from the remote system to the LNS require tunneling with the L2TP protocol. Packets sent from the LNS are decapsulated and then forwarded to the remote system. The connection from the LAC to the remote system is either local or a PPP link. For VPDN applications, the connections are usually PPP links. An LNS acts as one side of an L2TP tunnel and is a peer to an LAC. The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC.
Technology Details
The following describes the technology details of L2TP:
l
L2TP protocol structure
5-8
Issue 01 (2009-12-01)
5 VPN
Figure 5-4 L2TP protocol structure

PPP frame L2TP data message L2TP data tunnel (unreliable) L2TP control messsage L2TP control tunnel (reliable)
Packet trasmission network (UDP,...)
Figure 5-4 depicts the relationship of PPP frames and Control Messages, data messages over the L2TP Control and Data Channels. PPP Frames are passed over an unreliable Data Channel encapsulated first by an L2TP header and then a Packet Transport such as UDP, Frame Relay, and ATM. Control messages are sent over a reliable L2TP Control Channel which transmits packets in-band over the same Packet Transport. L2TP uses the registered UDP port 1701. The entire L2TP packet, including payload and L2TP header, is sent within a UDP datagram. The initiator (LAC) of an L2TP tunnel picks an available source UDP port (which may or may not be 1701), and sends to the desired destination address (LNS) at port 1701. The LNS picks a free port on its own system (which may or may not be 1701), and sends its reply to the LAC's UDP port and address, setting its own source port to the free port it found. Once the source and destination ports and addresses are established, they must remain static for the life of the tunnel.
l
Tunnel and session There are two types of connections between an LNS-LAC pair:

Tunnel: defines an LNS-LAC pair. Session: is multiplexed over a tunnel to denote each session process over the tunnel.
Multiple L2TP tunnels may exist between the same LAC and LNS. A tunnel consists of one control connection and one or several sessions. A session is set up after a tunnel is successfully created, namely, information such as ID, L2TP version, frame type, and hardware transmission type are exchanged.) Each session corresponds with a PPP data stream between an LAC and an LNS. Both control message and PPP packets are transmitted through tunnels. L2TP uses Hello messages to check the connectivity of a tunnel. The LAC and the LNS periodically send Hello messages to each other. If no Hello message is received within a period of time, the session between them is cleared.
l
Control message and data message L2TP utilizes two types of messages:
Control messages Control messages are used in the establishment, maintenance, and transmission contron of tunnels and sessions. Control messages utilize a reliable Control Channel within L2TP to guarantee delivery. Control messages support traffic control and congestion control.
Data messages Data messages are used to encapsulate PPP frames being carried over the tunnel. Data messages are not retransmitted when packet loss occurs. Data messages do not support traffic control and congestion control.
Issue 01 (2009-12-01)
5-9
5 VPN
L2TP packets for the control channel and data channel share a common header format. An L2TP message header includes a tunnel ID and a session ID, which are used to identify tunnels and sessions. Packets with the same Tunnel ID but different session IDs are multiplexed over the same tunnel. Tunnel IDs and session IDs in a packet header are assigned by the peer ends.
Two Typical L2TP Tunnel Modes

Figure 5-5 shows the tunnel modes of PPP frames between a remote system or an LAC client (running L2TP) and an LNS. Figure 5-5 Two typical L2TP tunnel modes
LAC client
LAC
LNS
Remote client LAC LNS
Connections can be established in two ways:

l
Initiated by a remote dial-up user The Remote Client initiates a PPP connection across the PSTN/ISDN to an LAC. The LAC then tunnels the PPP connection across the Internet. Authentication, Authorization, and Accounting may be provided by the Home LAN's Management Domain or by the LNS.
Initiated directly by an LAC client (a host which runs L2TP natively) The LAC clients can directly initiate a tunnel connection to the LNS without use of a separate LAC. In this case, the address of the LAC is assigned by the LNS.
Setup Procedure of an L2TP Tunnel Session

Figure 5-6 shows a typical networking of L2TP.
5-10
Issue 01 (2009-12-01)
5 VPN
Figure 5-6 Typical networking diagram of L2TP

RADIUS Server IP network RADIUS Server IP network
PC PC LAC EudemonA LNS EudemonB
PC
Figure 5-7 shows the procedure for setting up an L2TP call. Figure 5-7 Procedure for setting up an L2TP call
PC LAC EudemonA LAC RADIUS server LNS EudemonB LNS RADIUS server
(1) Call setup (2) PPP LCP setup (3) PAP or CHAP authentication
(4) Access request (5) Access accept (6) Tunnel establishment (7) PAP or CHAP authentication (challenge/response) (8) Authentication passes (9) User CHAP response, PPP negotiation parameter
(10) Access request (11) Access accept
(12) CHAP authentication twice(challenge/response) (13) Access request (15) Authentication passes (14) Access accept
The procedure for setting up an L2TP call is as follows: 1. 2. 3. The PC at user side initiates a connection request. The PC and the LAC (Eudemon A) negotiate PPP LCP parameters. The LAC performs the Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) authentication based on the user information provided by the PC.
Issue 01 (2009-12-01)
5 VPN
4. 5. 6. 7. 8. 9.
The LAC sends the authentication information, including VPN username and password, to the RADIUS server for ID authentication. The RADIUS server authenticates this user. After the authentication is passed successfully, the LAC is ready for initiating a new tunnel request. The LAC initiates a tunnel request to the LNS specified by the RADIUS server. The LAC informs the LNS of CHAP challenge, and the LNS sends back the CHAP response and its self CHAP challenge, the LAC sends back the CHAP response. Authentication passes. The LAC transmits the CHAP response, response identifier, and PPP negotiation parameters to the LNS.
10. The LNS sends the access request to RADIUS server for authentication. 11. The RADIUS server re-authenticates this access request and sends back a response if authentication is successful. 12. If local mandatory CHAP authentication is configured at the LNS, the LNS will authenticate the VPN user by sending challenge and the VPN user at PC sends back responses. 13. The LNS re-sends this access request to RADIUS for authentication. 14. RADIUS server re-authenticates this access request and sends back a response if authentication is successful. 15. After all authentications are passed, the VPN user can access the internal resources of the enterprise.
Features of the L2TP Protocol

The features of the L2TP Protocol are as follows:
l
Flexible ID authentication mechanism and high security
L2TP itself does not provide connection security, but it can depend on the authentication, such as CHAP and PAP, provided by PPP. Thereby, it has all security features of PPP. L2TP can integrate with IPSec to fulfill data security, which make it more difficult to attack the data transmitted with L2TP. To improve data security, based on the requirement of specific network security, L2TP adopts:

Tunnel encryption technique End-to-end data encryption Application layer data encryption
Multi-protocol transmission L2TP transmits PPP data packet and a wide variety of protocols can be encapsulated in PPP data packet.
Supporting authentication by the RADIUS server The LAC sends user name and password to the RADIUS server for authentication request. The RADIUS server is in charge of:

Receiving authentication request of the user Fulfilling the authentication
Supporting internal address assignment

5-12
5 VPN
The LNS can be put behind Intranet Eudemon. It can dynamically assign and manage the addresses of remote users and support the application of private addresses (RFC1918). The IP addresses assigned to remote users are internal private addresses of the enterprise instead of Internet addresses. Thus, the addresses can be easily managed and the security can also be improved.
l
Flexible network charging L2TP charges in both the LAC and the LNS at the same time, that is, in ISP (to generate bills) and Intranet gateway (to pay for charge and audit). L2TP can provide the following charging data:

Transmitted packet number and byte number Start time and end time of the connection
L2TP can easily perform network charging based on these data.

l
Reliability L2TP supports the backup LNS. When the active LNS is inaccessible, the LAC can reconnect with the backup LNS, which improves the reliability and fault tolerance of VPN service.
5.3 IPSec
5.3.1 IPSec Overview 5.3.2 IPSec Basic Concepts 5.3.3 IKE Overview 5.3.4 Overview of the IKEv2 Protocol 5.3.5 Security Analysis of IKEv2 5.3.6 IKEv2 and EAP Authentication 5.3.7 NAT Traversal of IPSec 5.3.8 Realizing IPSec on the Eudemon
5.3.1 IPSec Overview

IP Security (IPSec) protocol is described as follows. The two sides of communication perform encryption and data source authentication on the IP layer to ensure the confidentiality, integrity, authenticity, and anti-replay of packets transmitted on networks. The details are as follows:
l
Confidentiality User data is encrypted and transmitted in cipher text. Integrity Received data is authenticated to check whether they are juggled. Authenticity Data source is authenticated to ensure that data is from a real sender. Anti-replay
Issue 01 (2009-12-01)
5 VPN
It prevent malicious users from repeatedly sending captured packets. In other words, the receiver can deny repeated data packets. IPSec realizes the preceding aims with two security protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). IPSec can realize auto-negotiation key exchange and SA setup as well as maintenance services through Internet Key Exchange (IKE). That simplifies the use and management of IPSec. The details are as follows:
l
AH AH mainly provides data source authentication, data integrity check, and anti-replay. However, it cannot encrypt the packet.
ESP ESP provides all functions of AH. In addition, it can encrypt the packets. However, its data integrity authentication does not cover IP headers.
IKE IKE is used to automatically negotiate cipher algorithms for AH and ESP.
NOTE
l l
AH and ESP can be used either separately or jointly. Both AH and ESP support the tunnel mode. IPSec policy and algorithm can also adopt manual mode. So IKE negotiation is not necessary. The comparison of these two negotiation modes are introduced in 5.3.2 IPSec Basic Concepts.
5.3.2 IPSec Basic Concepts

Security Association
IPSec provides secure communication between two endpoints. These two endpoints are called IPSec peers. IPSec allows systems, network subscribers, or administrators to control the granularity of security services between peers. For example, the IPSec policies of a group define that data streams from a subnet should be protected with AH and ESP and be encrypted with Triple Data Encryption Standard (3DES) at the same time. Moreover, the policies define that data streams from another site should be protected with ESP only and be encrypted with DES only. IPSec can provide protection in various levels for different data streams based on SA. An SA is the basis and essence of IPSec. An SA specifies the shared policies and keys used by two negotiating peers to protect their communication:
l l l l l
Applied protocols (AH, ESP, or both) Encapsulation mode of protocols (transport mode or tunnel mode) Encryption algorithm (DES and 3DES) Shared keys used to protect data in certain streams Life duration of the shared keys
SA is unidirectional. For directional communication between peers, at least two SAs are needed to protect data streams in two directions. Moreover, if both AH and ESP are applied to protect data streams between peers, still two SAs are needed respectively for AH and ESP. An SA is uniquely identified by a triplet, including:

l l l
5 VPN
Security Parameter Index (SPI) Destination IP address Security protocol number (AH or ESP)
SPI is a 32-bit figure, uniquely identifying an SA. It is transmitted in an AH or ESP header. An SA has a life duration, which can be calculated in one of the two methods:
l
Time-based life duration The SA is updated a specific interval. Traffic-based life duration The SA is updated after a specified volume of data (in byte) is transferred.
SA Negotiation Modes
There are two negotiation modes to create SAs:
l
Manual mode (manual) Manual mode is more complicated than auto-negotiation mode. In manual mode, all information required to create an SA has to be configured manually. Moreover, it does not support some advanced features of IPSec, such as scheduled key update. The advantage of manual mode is that it can realize IPSec without IKE.
IKE auto-negotiation mode (isakmp) In IKE auto-negotiation mode, an SA can be created and maintained by IKE autonegotiation as long as IPSec policies of IKE negotiation are configured.
Manual mode is feasible in the scenario where only a few peer devices exist or the network is small in size. IKE auto-negotiation mode (isakmp) is recommended for medium or large-sized networks.
Encapsulation Modes of the IPSec Protocol

The IPSec protocol has two encapsulation modes:
l
Transport mode In transport mode, AH or ESP is inserted after the IP header but before the transmission layer protocol, or before other IPSec protocols. Take ah-esp for example. AH is inserted after the IP header and before ESP.
Tunnel mode In tunnel mode, AH or ESP is inserted before the original IP header but after the new header.
An SA specifies the encapsulation mode for the IPSec protocol. Figure 5-8 shows the data encapsulation format for various protocols in the transmission mode and the tunnel mode. Transmission Control Protocol (TCP) is taken as an example to show the data encapsulation in the mode.
Issue 01 (2009-12-01)
5-15
5 VPN
Figure 5-8 Data encapsulation format for security protocols

Mode Protocol AH ESP AH-ESP
IP header AH
Transport
TCP header Data
Tunnel
New IP Raw IP TCP header AH header header Data
ESP TCP IP Data ESP ESP header header Tail Auth data
Raw IP TCP New IP ESP ESP ESP header header Data header Tail Auth data
Raw IP TCP IP New IP TCP Data ESP ESP ESP ESP AH ESP AH ESP header header Data header Tail Auth data header header Tail Auth data
The tunnel mode is excellent than the transport mode in security. The tunnel mode can authenticate and encrypt original IP data packets completely. Moreover, it can hide the client IP address with the IPSec peer IP address. With respect to performance, the tunnel mode occupies more bandwidth than the transport mode because it has an extra IP header. Therefore, when choosing the operation mode, you need weigh the security and performance.
Authentication Algorithm and Encryption Algorithm

Details of the authentication algorithm and the encryption algorithm are as follows:
l
Authentication algorithm Both AH and ESP can authenticate integrity for an IP packet so as to determine whether the packet is juggled. The authentication algorithm is performed through hybrid. The hybrid is a kind of algorithm that can receive a message of arbitrary length and generate a message of fixed length. The generated message is called message digest. IPSec peers calculate the packet through the hybrid respectively. If they get identical summaries, the packet is considered as integrated and intact. Usually, there are two types of IPSec authentication algorithms:
MD5 It inputs a message of arbitrary length to generate a 128-bit message digest. SHA-1 It inputs a message less than 264-bit to generate a 160-bit message digest.
The SHA-1 summary is longer than that of MD5, so SHA-1 is safer than MD5.
l
Encryption algorithm ESP can encrypt IP packets so that the contents of the packets are not snooped during the transmission. Based on the encryption algorithm, packets are encrypted or decrypted with the same key over the symmetric key system. Generally, IPSec uses the following types of encryption algorithms:
DES It encrypts a 64-bit clear text with a 56-bit key. 3DES It encrypts a clear text with three 56-bit keys (168 bits key in total).
5-16
Issue 01 (2009-12-01)
5 VPN
Advanced Encryption Standard (AES) It encrypts a clear text through a 128-bit, 192-bit, or 256-bit key.
Obviously, 3DES is more excellent than DES in security. However, its encryption speed is lower than that of DES.
5.3.3 IKE Overview

IPSec SA can be created manually. However, when the number of nodes on the network increase, it is hard to guarantee the security of the network. In this case, IKE can be used to automatically create SAs and implement key exchange. With a self-protection mechanism, IKE can distribute keys, authenticates IDs, and establish SAs on insecure networks.
IKE Security Mechanism

IKE security mechanism is as follows:
l
Diffie-Hellman (DH) exchange and key distribution DH algorithm is a public key algorithm. The both parties in communication can exchange some data without transmitting the key and find the shared key by calculation. The prerequisite for encryption is that the both parties must have a shared key. The merit of IKE is that it never transmits the key directly in the unsecured network, but calculates the key by exchanging a series of data. Even if the third party (such as Hackers) captured all exchange data used to calculate the shared key for both parties, he cannot figure out the real key.
Perfect Forward Secrecy (PFS) PFS is a security feature. PFS refers to the notion that the compromise of a single key does not impact the security of other keys. That is because a key cannot be used to derive any other keys. PFS functions based on DH algorithm. PFS is realized when key exchange is added during IKE phase 2.
ID authentication ID authentication helps identify the two parties of communication. The negotiation modes are as follows:
pre-share: you need to configure each peer with the pre-shared key. The peers of a security connection must have identical pre-shared keys. rsa-sig: you need to configure local certificates.
Identity protection After a shared key is generated, identity data is transmitted in encrypted mode.
IKE Exchange Phases

IKE uses two phases to negotiate IPSec keys and create SAs:
l
Phase 1 is where the two ISAKMP peers establish a secure, authenticated channel with which to communicate. This is called the ISAKMP Security Association (ISAKMP SA or IKE SA).
Issue 01 (2009-12-01)
5 VPN
l
Phase 2 is where SAs are negotiated on behalf of services such as IPSec or any other service which needs key material and/or parameter negotiation. IPSec SA is used for transmitting IP data.
Figure 5-9 shows the relationship of IKE and IPSec. Figure 5-9 Relationship of IKE and IPSec
SA negotiation EudemonA IKE IKE EudemonB
TCP/UDP IPSec
SA
SA
TCP/UDP IPSec
IP Encrypted IP packets
Figure 5-10 shows the procedure for setting up an SA. Figure 5-10 Procedure for setting up an SA
EudemonA Step 1 Step 2 Data flow is output from the interface EudemonB that applies IPSec Trigger SA of IKE negotiation stage 1 Under the protection of security association of IKE stage 1, IPSec SA of negotiation stage 2 Communication under the protection of security association of stage 2
Step 3
Step 4
The process for setting up an SA is as follows: 1. 2. 3. 4.

5-18
On an interface that runs IPSec, an outbound packet should be compared with IPSec policies. If the packet matches an IPSec policy, search for the relevant SA. If the SA has not been created, IKE will be triggered to negotiate an SA in stage 1, that is, IKE SA. Under the protection of IKE SA, IKE continues to negotiate the SA in stage 2, that is, IPSec SA. The IPSec SA is used to protect the communication data.
5 VPN
IKE Negotiation Modes

As defined in RFC 2409 (the Internet Key Exchange), IKE negotiation in phase 1 can use two modes:
l
Main mode In main mode, key exchange information is separated from identity and authentication information. This separation realizes identity protection. The exchanged identity information is protected by the Diffie-Hellman (DH) shared key generated. However, it takes extra messages to complete the process.
Aggressive mode In aggressive mode, payloads relevant with SA, key exchange, and authentication can be transmitted simultaneously. Transmitting these payloads in one message helps reduce round trips. However, this mode cannot provide identity protection. Although aggressive mode has some functional limitations, it can meet the requirements of some specific network environment. For example, during a remote access, the responder (server end) has no way to learn about the address of the initiator (terminal user) in advanced or the address of the initiator is always changing, but both parties wish to create IKE SAs through pre-shared key authentication. In this case, the aggressive mode without identity protection is the only available exchange method. In addition, if the initiator has learnt about the responder's policy or had a comprehensive understanding of it, aggressive mode can be adopted to rapidly create IKE SAs.
5.3.4 Overview of the IKEv2 Protocol

Introduction
As a first-choice key exchanging protocol to implement IPSec VPNs, IKE ensures secure and dynamic creation of the SA. IKE is a hybrid protocol. Its complexity inevitably incurs defects in security and performance, which already becomes a bottleneck for the current IPSec systems. The IKEv2 protocol reserves the basic functions of IKE and overcomes the problems found during IKE study. Moreover, for considerations of simplicity, efficiency, security, and robustness, relevant IKE documents are replaced by RFC4306. By minimizing core functions and default password algorithms, IKEv2 greatly improves the interoperation capability among different IPSec VPNs. Compared with IKE, IKEv2 has the following advantages:
l
After four messages, one IKE SA and a pair of IPSec SAs can be created through negotiation. Thus, the negotiation efficiency is improved. Data structures that are difficult to understand and likely to be confusing are deleted, including DOI, SIT and domain identifier. Many cryptographic loopholes are closed, and thus security is improved. IKEv2 can choose payloads of specific traffic to protect. In this way, IKEv2 takes over certain functions of the former ID payload and becomes more flexible. IKEv2 supports EAP authentication, and thus the authentication is improved in flexibility and expansibility.
l l
Issue 01 (2009-12-01)
5 VPN
Negotiation Process of IKEv2

To create a pair of IPSec SAs, IKE requires two phases, namely, the main mode + the fast mode or the aggressive mode + the fast mode. The main mode + the fast mode requires at least 9 messages while the latter requires at least 6 messages. Normally, by using IKEv2 twice and exchanging four messages, you can create one IKE SA and a pair of IPSec SAs through negotiation. To create more than a pair of IPSec SAs, only one exchange is needed for each additional pair of SAs. That is, two messages can accomplish the task. IKEv2 is much simpler than IKE in this aspect.
5.3.5 Security Analysis of IKEv2

IKEv2 closes the security loopholes of IKE and improves the security of key negotiation. In addition, IKEv2 requires that all messages should exist in the format of request/reply pairs, thus effectively improving reliability of UDP used as a transmission layer protocol. The following describes the security of IKEv2.
Defense against man-in-the-middle attacks

The man-in-the-middle attack is a kind of proactive attack. During the attack, the attacker eavesdrops the communications parties to capture the messages. After inserting data into the messages, or deleting or changing the information in the messages, the attacker returns the changed messages to the sender, or replays or redirects the original messages. This is the most harmful attack. In IKEv2, the mechanism and methods for defending against man-in-the-middle attacks is as follows:
l
Modes for generating key materials The key materials of IKEv2 are different from those of IKE in that the encryption key and the authentication key used for follow-up interactions are different. These keys are extracted from the PRF + output traffic one by one. Therefore, it is more difficult for the attacker to guess the keys. As a result, the keys are less likely to be disclosed, transmission becomes safer, and to a certain extent, man-in-the-middle attacks are prevented.
Authentication IKEv2 performs authentication by using pre-shared keys and digital signatures. The authentication is two-way authentication. The negotiation parties authenticate each other. In addition, the authentication is symmetrical. The negotiation parties use the same mechanism and method to authenticate each other. The two-way authentication can effectively defend against man-in-the-middle attacks. Meanwhile, IKEv2 defines extended authentication. That is, the negotiation parties authenticate each other through the method described in EAP. The extended authentication supports asymmetrical two-way authentication, thus further improving the flexibility of authentication and expansibility of negotiations.
Message exchange IKEv2 reduces the six messages of IKE in main mode to four messages and sends the SA payload, KE payload, and nonce payload together. So, the messages contain the nonce values. When an attacker returns the messages to their senders, the senders can decide whether the messages are real. This can prevent replay attacks to a certain extent. Each IKEv2 message header contains a message ID, which is used for matching the corresponding request and reply messages, and identifying replay attacks. When a request is sent or received, the message ID must be increased in number order. Moreover, except the IKE_SA_INIT interaction, the message ID is protected through encryption and the
5-20
Issue 01 (2009-12-01)
5 VPN
integrity of the message ID is protected to prevent replay. IKEv2 introduces the sliding window mechanism so that interactions can effectively resist replay attacks.
Defense against DoS attacks

In IKEv2, the mechanism and methods for defending against DoS attacks are as follows:
l
SPI value In the header of an IKEv2 message, there are the initiator SPIi and the responder SPIr. The SPIi and the SPIr are random 8-byte values generated by the kernel to identify the SA and a pair of nodes for exchanging messages. Only one of the requests with the same SPI value is processed, excluding retransmission messages. Other requests are discarded as repeated data. This mechanism can prevent DoS attacks to a certain extent.
Interactions with cookies IKEv2 defends against DoS attacks through auxiliary exchanges during which the Notify payload carries cookies. During communications, when the responder deems that it is suffering from DoS attacks, it can request a stateless cookie from the initiator. When the responder receives the first message from the initiator, it does not perform the IKE_SA_INIT interaction immediately. Instead, it generates a new cookie, encapsulates it into a notice payload, and then sends it to the initiator. If the initiator is not an attacker, it can receive this message, and then resume the negotiation. Moreover, it encapsulates the cookie from the responder into the message and keep the other contents in the payload unchanged.
Retransmission convention All messages of IKEv2 come in pairs. In each pair of messages, the initiator is responsible for retransmission events. The responder does not retransmit the response message unless it receives a retransmission request from the initiator. In this way, the two parties do not both initiate retransmission, and thus resources are not wasted. In addition, attackers cannot capture the messages for sending retransmission messages repeatedly to exhaust the resources of the parties of the negotiation.
Discarding half-open connections When using IKEv2, one negotiation party decides whether the other party expires in two ways. One way is to repeatedly try to contact the other party until the response times out. The other way is that it receives the encrypted Initial Contact notices of different IKE SAs from the other party. The initiator allows multiple responders to respond to the first message and in turn responds to all the responders by regarding them as legal. After sending some messages, once the initiator receives an valid encrypted response message, it ignores all the other response messages and discards all the other invalid half-open connections. In this way, DoS attacks are avoided at the beginning of the negotiation.
Perfect forward secrecy (PFS)

PFS allows individual keys to decrypt only the data protected by them. Therefore, even if the attacker obtains one key, it can only decrypt the data protected by the key. The key materials used to generate keys for the initial IKEv2 interaction are not used to generate keys for IPSec SAs. Instead, new key materials are generated by introducing available KE payloads during the CREATE_IPsec_SA interaction.
5.3.6 IKEv2 and EAP Authentication

5 VPN
The Extensible Authentication Protocol (EAP) is an authentication protocol that supports multiple authentication methods. The biggest advantage of EAP is its extensibility. New authentication modes can be added like components without changing the original authentication system. EAP authentication can conveniently adopt the original authentication mechanism of the system. IKEv2 supports third-party EAP authentication of the negotiation initiator. The responder determines whether EAP authentication is necessary according to the fact whether the Authentication (AUTH) payload exists in the message from the initiator. If the message from the initiator does not contain the AUTH payload, it indicates that the initiator requests EAP authentication. In the response message from the responder, the EAP authentication method that the responder allows is specified. The next request message from the initiator carries the authentication information for the EAP authentication method. After receiving the message, the responder sends the message to the EAP authentication server of the third party for the server to perform authentication according to RFC 3748. Then, the responder sends a response message to notify of the success or failure of the authentication. During the process, the responder does not need to know the specific authentication method and process. Instead, it functions as a relay between the initiator and the EAP authentication server. The initiator and the EAP authentication server accomplish the entire process and the responder only needs the authentication result. In this way, many authentication methods can be supported. Many high-density authentication algorithms are involved but the software complexity of the responder is not increased.
5.3.7 NAT Traversal of IPSec

NAT Traversal
One of the main applications of IPSec is to set up VPNs. In actual networking applications, there is one scenario where IPSec VPN deployment may be hindered. When the initiator resides on an private network and wishes to directly create an IPSec tunnel to the remote responder, the creation inevitably requires the cooperation of IPSec and NAT. The main problem lies in how IKE can discover the existence of the NAT gateway between the two endpoints during the negotiation and how IKE can make ESP packets normally traverse the NAT gateway. At first, the two endpoints of the desired IPSec tunnel need to negotiate the NAT traversal capacities. The negotiation is implemented with the first two messages of IKE negotiation. The Vendor ID payload specifies a group of data to identify the negotiation The definitions of the payload data vary with the draft versions. IKE depends on NAT-D payload to discover the NAT gateway. The payload is used for two purposes:
l l
To discover the NAT gateway between the IKE peers To determine which side of the peer NAT device resides
The peer on the NAT side, as the initiator, needs to periodically send NAT-Keepalive packets to help the NAT gateway ensure that the security tunnel is in active state.
IPSec Traversing NAT Gateway

The NAT traversal of IPSec is to add a standard UDP header between IP and ESP headers of the original packet (without regard for AH mode). In this case, when an ESP packet traverses
5 VPN
NAT gateway, NAT will translate the address and port number of the external layer IP header of the packet and the added UDP header. When the translated packet reaches the peer end of IPSec tunnel, it will be processed in the same method as the common IPSec. However, an UDP header also needs to be added between the IP and ESP headers when the response packet is sent.
5.3.8 Realizing IPSec on the Eudemon

Realizing IPSec on the Eudemon
The Eudemon helps realize the functions and mechanisms mentioned in the preceding sections. The following describes the realization roadmap:
l
Through IPSec, data streams between peers (here refer to the Eudemon and its peer) can perform data stream-specific protection by means of authentication, encryption, or both. Data streams are differentiated based on ACLs. Security protection elements are defined in IPSec, including:

Security protocol Authentication algorithm Encryption algorithm Encapsulation mode Association between data streams and the IPSec proposal (namely, apply a certain protection on a certain data stream) SA negotiation mode Peer IP address settings (that is, the start/end IP address of the protection path) Required key Life duration of the SA
Following are defined in the IPSec policy:
IPSec policies are applied on Eudemon interfaces.
Following details the procedure: 1. Define data streams to be protected. A data stream is a collection of a group of traffic specified by:
l l l l l
Source address/mask Destination address/mask Number of protocol over IP Source port number Destination port number
An ACL rule defines a data stream. Namely, traffic that matches an ACL rule is a data stream logically. A data stream can be a single TCP connection between two hosts or all traffic between two subnets. IPSec can apply different security protections on data streams. So the first step in IPSec configuration is to define data streams. 2. Define an IPSec proposal. An IPSec proposal defines the following for the data stream to be protected:
l
Security protocol
Issue 01 (2009-12-01)
5 VPN
l l
Authentication or encryption algorithm Encapsulation mode (namely, the packet encapsulation mode)
AH and ESP supported by the Eudemon can be used either separately or jointly. AH supports MD5 and SHA-1 authentication algorithms. ESP supports MD5 and SHA-1 authentication algorithms as well as DES, 3DES, and AES encryption algorithms. As for a data stream, peers should be configured with the same protocol, algorithm, and encapsulation mode. Moreover, if IPSec is applied on two Firewall (for example between the Eudemons), the tunnel mode is recommended so as to hide the real source and destination addresses. Therefore, you need to define an IPSec proposal based on requirements so that you can associate it with data streams. 3. Define an IPSec policy or IPSec policy group. An IPSec policy defines the IPSec proposal adopted by a data stream. An IPSec policy is uniquely defined by a name and a sequence number. There are two types of security policies:
l l
Manual IPSec policies IKE negotiation IPSec policies
For manual IPSec policies, you need to manually set parameters such as key, SPI, and SA life duration. If the tunnel mode is configured, you need to manually set the IP addresses for the two endpoints of a security tunnel. For IKE negotiation IPSec policies, these parameters are generated by IKE auto-negotiation. An IPSec policy group is a collection of IPSec policies with the same name but different sequence numbers. In an IPSec policy group, the smaller the sequence number is, the higher the priority is. 4. Apply IPSec policies on an interface. When you apply an IPSec policy group on an interface, all the security policies in the IPSec policy group are applied on the interface. Different data streams passing through the interface are protected with their respective security policies.
Realizing IKE on the Eudemon

The Eudemon supports the two modes of IKE, main mode and aggressive mode. Since the Eudemon realizes IKE based on RFC 2408 and RFC 2409, the Eudemon can interwork with the devices of most mainstream manufacturers. To realize NAT traversal for IPSec on the Eudemon, you need to adopt the main mode or aggressive mode at the stage 1 of IKE negotiation. In this case, the peer ID type is the name or IP address of the peer. In addition, you need to configure ESP and encapsulate packets in tunnel mode. On the Eudemon, IKE is realized as follows: 1. 2. 3. Set the local ID used in IKE exchange. Specify a series of attributes for the IKE peer, including IKE negotiation mode, pre-shared key, peer address or peer ID, and NAT traversal to ensure the IKE negotiation. Create an IKE IPSec proposal to determine the algorithm strength during IKE exchange, namely, the security protection strength, including ID authentication method, encryption algorithm, authentication algorithm, and DH group. Strength varies with algorithm. The
5-24
5 VPN
higher strength the algorithm has, the harder it is to decrypt the protected data. Algorithm with higher strength consumes more calculation resources. In general, the longer the key is, the higher the algorithm strength is. Besides the preceding basic steps, IKE has the keepalive mechanism. It can determine whether the peer can communicate normally. Two parameters are configured for the keepalive mechanism, interval and timeout. When IPSec NAT traversal is configured, you can set a time interval, at which NAT updating packets are sent. After the preceding IKE configuration, you need to quote the IKE peer in the IPSec policy view to complete IPSec auto-negotiation configuration.
5.4 GRE
5.4.1 GRE Overview 5.4.2 Implementation of GRE 5.4.3 GRE Application
5.4.1 GRE Overview

Generic Routing Encapsulation (GRE) is the third layer tunnel protocol of the VPN. Tunnel is the technique used between protocol layers. It is a virtual point-to-point connection. In practice, it is a virtual interface that only supports the point-to-point connection. The packet is transmitted through the interface, and encapsulated and decapsulated at the two ends of a tunnel.
5.4.2 Implementation of GRE

Take the network of Figure 5-11 as an example for describing the two processes. Figure 5-11 IP network interconnection through the GRE tunnel
Tunnel
IP group1 EudemonA
Internet EudemonB
IP group2
Encapsulation
The Eudemon A connects to the interface of IP group 1 and receives the IP packet. Then the IP packet is sent to the IP module. The IP module checks the destination address field at the IP header and decides the route. If the destination address is the virtual network number of the tunnel, the packet is sent to the port of the tunnel. The packet is encapsulated at the port of the
5 VPN
tunnel, and sent back to the IP module. The IP packet header is encapsulated. The packet is sent to a network interface based on the destination address and routing table.
Decapsulation
Decapsulation is reversed to encapsulation. TheEudemon B receives the IP packet from the port of the tunnel. If the destination address of the packet is Eudemon B, the IP header of the packet is decapsulated. The packet is sent to the GRE module. The GRE module checks the key, verifies the checking results, and checks serial number of the packet, and then decapsulates the GRE header. The packet is sent to the IP module. The IP module handles the packet in the common way. The packet to be encapsulated and routed is called payload. The payload is encapsulated into a GRE packet and then an IP packet. In this way, it can be forwarded on the network layer. The routing protocol for forwarding the packet is called Delivery Protocol or Transport Protocol. Figure 5-12 shows the format of the encapsulated packet. Figure 5-12 Format of the encapsulated packet
Delivery Header GRE Header Payload Packet Transport Protocol Encapsulation Protocol Passenger Protocol
For example, Figure 5-13 shows an IP packet transported in the tunnel. Figure 5-13 IP packet transported in the tunnel
IP GRE IP Passenger Protocol Encapsulation Protocol Transport Protocol
5.4.3 GRE Application
5-26
Issue 01 (2009-12-01)
5 VPN
Network Enlargement
Figure 5-14 Network enlargement
Tunnel Eudemon Eudemon
PC
PC
As shown in Figure 5-14, when the number of hops exceeds 15, the two terminals can not communicate with each other. The tunnel hides some hops. In this way, the network is enlarged and the communication is recovered.
Inconsistent Subnet Connection

Figure 5-15 Inconsistent subnet connection
Tunnel IP group1
IP group2 Eudemon VLAN
Eudemon
As shown in Figure 5-15, group 1 and group 2 are IP subnet in different cities. The tunnel connects group 1 and group 2, and builds the VPN.
Issue 01 (2009-12-01)
5-27
5 VPN
GRE-IPSec Tunnel
Figure 5-16 GRE-IPSec tunnel
Corporate intranet Eudemon IP Netwrok Eudemon Remote office network
GRE Tunnel IPSec Tunnel
As shown in Figure 5-16, the multicast data can be encapsulated in the GRE packet and transmitted in the GRE tunnel. According to the protocol, the IPSec only encrypts and protects unicast data. To transmit multicast data such as routing protocol, voice, and video, set up a GRE tunnel and encapsulate the multicast data in the GRE packet. Then the IPSec encrypts the GRE packet. In this way, the packet can be transmitted in the IPSec tunnel. The user can choose to record the keyword of the GRE tunnel interface, and check the encapsulated packet in end-to-end manner. Encapsulation and decapsulation, and data increase due to the encapsulation may reduce the forwarding efficiency of the Eudemon.
5-28
Issue 01 (2009-12-01)
6 Network Interconnection
6
About This Chapter
6.1 VLAN 6.2 PPP 6.3 PPPoE 6.4 DHCP Overview 6.5 Static Route Overview 6.6 RIP 6.7 OSPF 6.8 BGP
Network Interconnection
6.9 Introduction to Policy-Based Routing 6.10 Routing Policy Overview 6.11 Load Balancing 6.12 Introduction to QoS 6.13 GPON Line This topic describes the principles and security mechanism of the GPON line that is used for the upstream transmission of the SRG. 6.14 Introduction to Voice Services In line with the three-in-one trend of data, voice, and video services integration, the SRG functions as the enterprise gateway in the FTTO deployment model not only to provide broadband services (including data, video live, and VOD services), but also to provide end users with high-quality voice service by the built-in voice module directly through twisted pairs.
Issue 01 (2009-12-01)
6-1
6.1 VLAN
6.1.1 Introduction 6.1.2 Advantages of VLAN
6.1.1 Introduction
Potential Problems in LAN Interconnecting
The Ethernet is a kind of data network communication technology, which is based on the shared communication medium of Carrier Sense Multiple Access with Collision Detection (CSMA/ CD). Under CSMA/CD, each node uses the shared medium to send frames in turn. Thus, in a moment, only one host can send frames while other hosts can only receive frames. When many hosts are connected to the hub (with star topology) through the twisted pairs, or connected by the coaxial cables (with bus topology), all the hosts interconnected to the shared physical media forms a physical collision domain. That is usually regarded as a LAN segmentation. According to the previous Ethernet basic principles, the problems of using HUBs for interconnecting VLANs are:
l l l l
Severe collision Flooding broadcast Performance reduction Unavailability of network
The above problems can be solved by using the Transparent Bridge or LAN switch to interconnect the LANs. Although the switch has solved the problem of severe collision caused by using hub, it still cannot separate the broadcast. In fact, all the hosts (perhaps including many switches) interconnected by switches are in one broadcast domain. For the broadcast packets with "f" (0xffffffffffff) as their destination MAC address, such as the ARP request packet, the switch will forward them to all the ports. In this case, the broadcast storm will be caused and the performance of the entire network will be degraded.
VLAN Principle and Division

The LAN interconnection by means of switches cannot restrict the broadcast. The technology of Virtual Local Area Network (VLAN) comes into being to solve the problem. In this way, one LAN is divided into several logical "LANs" (VLANs), with each VLAN as a broadcast domain. In each VLAN, the hosts can communicate with each other just as they are in a LAN, but the VLANs cannot interact with one another directly. Therefore, the broadcast packets are restricted in one VLAN, as shown in Figure 6-1.
6-2
Issue 01 (2009-12-01)
Figure 6-1 Example of VLAN

LAN Switch
VLAN A LAN Switch VLAN B
Router
The buildup of VLAN is not restricted by physical locations, that is, one VLAN can be within one switch or across switches, or even across three layers Ethernet devices such as routers or Firewall. The VLAN can be classified based on the following aspects:
l l l l l l
Port MAC address Protocol type IP address mapping Multicast Policy
At present, the VLAN is usually classified based on the port. In this manual, the VLANs are all classified based on the port except special declaration.
6.1.2 Advantages of VLAN

The advantages of using VLAN are listed as follows:
l
It can restrict broadcast packets (broadcast storm), save the bandwidth and thus improve the performance of the network. The Broadcast domain is restricted in one VLAN and the switch cannot directly send frames from one VLAN to another except that it is a layer 3 switch.
It can enhance the security of LAN. VLANs cannot directly communicate with one another, that is, the users in one VLAN cannot directly access those in other VLANs. They need help of such layer 3 devices as routers and Layer 3 switches to fulfill the access.
It provides the virtual workgroup. VLAN can be used to group users to different workgroups. When the workgroups change, the users need not change their physical locations.
Issue 01 (2009-12-01)
6-3
On a switch, the common ports can only belong to one VLAN, that is, they can only identify and send packets of the VLAN they belong to. However, when the VLAN is across switches, it is necessary that the ports (links) among the switches can identify and send packets of several VLANs at the same time. The same problem exists among the switches and routers that support VLAN. The link of this type is called Trunk, which has two meanings:
l
Relay Namely, the VLAN packets are transparently transmitted to the interconnected switches or routers to extend the VLAN.
Trunk Namely, several VLANs run on such a link.
The common protocol used to implement Trunk is IEEE 802.1Q (dot1q) that is a standard protocol of IEEE. It identifies the VLAN by adding a 4-byte VLAN tag to the end of the source address field in the original Ethernet packet. VLANs cannot directly interconnect with each other. So routers or Layer 3 switches must be used to connect each VLAN to implement the interconnection among VLANs. Usually, this is a kind of layer 3 (IP layer) interconnection.
6.2 PPP
6.2.1 Introduction 6.2.2 PPP Authentication 6.2.3 PPP Link Operation
6.2.1 Introduction
Point to Point Protocol (PPP) is a link layer protocol that transmits network layer packets on point-to-point (P2P) links. PPP is widely applied because it is easy in expansion and supports user authentication and synchronous and asynchronous communication. PPP is located on the data link layers of both Open Systems Interconnection (OSI) and the TCP/ IP protocol stack. PPP supports synchronous and asynchronous full-duplex links in transmitting data in a P2P way. PPP mainly consists of the following three protocols:
l
The Link Control Protocol (LCP) suite: This protocol suite is responsible for establishing, removing, and monitoring data links. The Network Control Protocol (NCP) suite: This protocol suite is responsible for negotiating the format and type of packets transmitted over a data link. PPP extended protocol suite: This protocol suite such as PPPoE provides extended PPP functions. With the development of network technologies, network bandwidth is no longer a bottleneck. PPP extended protocol suite, therefore, is rarely used nowadays. When talking abouting PPP, people often forget the PPP extended protocol.
In addition, PPP provides the authentication protocols: Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP).
6.2.2 PPP Authentication

PAP Authentication Process
PAP is the authentication of two-way handshake. In PAP authentication, the password is in plain text. The authentication process is performed in the Establish phase. After the Establish phase finishes, the user name and password of the authenticated are repeatedly sent to the authenticator until the authentication succeeds or the link is ended. PAP authentication is the optimal option in the case that the plain password must be used in the simulated login on a remote host.
l l
The authenticated sends the local user name and password to the authenticator. The authenticator checks the user list for the user name and whether the password is correct, and then returns different responses (permit or deny).
PAP is an unsecured protocol. In PAP authentication, passwords are sent over links in plain text. After a PPP link is established, the authenticated repeatedly sends the user name and password until the authentication finishes. The malicious attack, therefore, cannot be avoided.
CHAP Authentication Process

The Challenge Handshake Authentication Protocol (CHAP) is a authentication protocol of threeway handshake. In CHAP authentication, only the user name is transmitted in a network. Compared with PAP, CHAP features higher security because passwords are not transmitted. The CHAP negotiation is complete before a link is set up. After a link is set up, CHAP authentication can be performed anytime through the CHAP negotiation packets. After the Establish phase, the authenticator sends a Challenge packet to the authenticated. After performing the "one-way Hash" algorithm, the authenticated returns a calculated value to the authenticator. The authenticator compares the value calculated by itself through the Hash algorithm with the value returned by the authenticated. If the two values are matched, the authentication succeeds. Otherwise, the authentication fails and the link is torn down. CHAP authentication is divided into the following two modes:
l
Unidirectional CHAP authentication: In this mode, one end acts as the authenticator, while the other end acts as the authenticated. Bidirectional CHAP authentication: In this mode, two ends act as both the authenticator and the authenticated.
Generally, unidirectional authentication is adopted. Unidirectional CHAP authentication involves two situations: the authenticator is configured with a user name and the authenticator is not configured with a user name. It is recommended to configure the authenticator with a user name. Authenticating the user name can improve the security.
l
Authentication process in the case that the authenticator is configured with a user name The authentication process in the case that the authenticator is configured with a user name is as follows:
Issue 01 (2009-12-01)
6-5
The authenticator sends a randomly-generated Challenge packet and the host name to the authenticated. After receiving the packet, the authenticated searches for the local password in the local user list according to the user name of the authenticator. According to the found password and the Challenge packet, the authenticated obtains a value calculated with the MD5 algorithm. The authenticated then sends its host name and the calculated value in a response packet to the authenticator. After receiving the response packet, according to the host name of the authenticated, the authenticator searches for the password of the authenticated in the local user list. After successful search, the authenticator uses the Challenge packet and the password of the authenticated to obtain a value through calculation with the MD5 algorithm. The authenticator compares the value with the result in the received response packet and then returns the verification result (permit or deny).
Authentication process in the case that the authenticator is not configured with a user name If the authenticator is not configured with a user name, the authenticator sends the Challenge packet to the authenticated. According to the local password and the Challenge packet, the authenticated obtains a value through the MD5 algorithm. Then the authenticated sends its host name and the calculated value in a response packet to the authenticator. The remaining process is the same as that described previously.
6.2.3 PPP Link Operation

PPP links can be set up only after a series of successful negotiations.
l
LCP negotiation: Besides establishing, closing, and monitoring PPP data links, LCP negotiates link layer parameters such as maximum receive unit (MRU) and authentication mode. NCP negotiation: NCP negotiates formats and types of packets transmitted over the data links. IP addresses are also negotiated in NCP negotiation.
To set up P2P connection through PPP, the devices on two ends must send LCP packets to set up the P2P link. After the LCP configuration parameters are determined through negotiation, the two communicating devices choose the authentication mode according to the authentication parameters in the LCP Configure-Request packets. By default, the devices on the two ends do not authenticate each other. The devices negotiate NCP configuration parameters without any authentication. After all the negotiations, the two devices on the P2P link can transmit network-layer packets. At this time, the whole link is available. If any end receives a packet that initiates an LCP or NCP close, if the carrier cannot be detected at the physical layer, or if the maintenance personnel closes the link, the link is torn down and the PPP session thus is terminated. Typically, NCP should not necessarily has the capability in closing links. Therefore, the packet used to close a link is usually sent during the LCP negotiation or application program session. Figure 6-2 shows the setup process of a PPP session and the status transition in the whole process.
6-6
Issue 01 (2009-12-01)
Figure 6-2 Operation process of PPP

Dead UP Establish OPENED Authenticate
FAIL FAIL SUCCESS CLOSED
DOWN
Terminate
Network
The PPP operation process is described as follows: 1. 2. The Establish phase is the first phase to set up a PPP link. During the Establish phase, the LCP negotiation is performed. The negotiation involves the options such as the working mode, which is either Single-link PPP (SP) or Multilink PPP (MP), MRU, authentication mode, magic number, asynchronous character mapping and so on. After the LCP negotiation succeeds, the LCP status turns Opened, which indicates the bottom layer is established. If no authentication is configured, the communicating devices directly enter the NCP negotiation phase. If authentication is configured, the communicating devices enter the Authentication phase and perform CHAP authentication or PAP authentication. If the authentication failed, the devices enter the Terminate phase, and then remove the link. At this time, LCP status turns Down. If the authentication succeeds, the devices enter the NCP negotiation phase. The LCP status remains Opened, while the NCP status turns Starting from Initial. The NCP negotiation includes IPCP, MPLSCP, and OSCICP negotiations. The IPCP negotiation mainly involves the negotiation of the IP addresses of the two ends. A network layer protocol is chosen and configured through the NCP negotiation. The network layer protocol can send packets over the PPP link only after the negotiation of the network layer protocol succeeds. The PPP link remains in the normal state until an LCP or NCP frame aiming at closing the link is generated or some forcible interruptions occur, such as user intervention.
3.
4.
5.
6.
PPP undergoes the following phases during the configuration, maintenance, and termination of a P2P link.
l l l l l
Dead Phase Establish Phase Authenticate Phase Network Phase Terminate Phase
Dead Phase
The Dead phase is also called the unavailable phase of the physical layer. Setup of a PPP link begins with and terminates at the Dead phase.
After the communicating devices on both ends detect a physical link is activated, generally, the carrier signal is detected on the link, and the devices enter the Establish phase. In the Establish phase, link parameters are set mainly by using LCP. The state machine of LCP changes according to different events. If a link is in the Dead phase, the status of the LCP state machine is Initial or Starting. After the link becomes available, the status of the LCP state machine changes. After a link is torn down, the link returns to the Dead phase. In actual process, this state lasts quite short and detects only the existence of the peer device.
Establish Phase
The Establish phase is the key and most complicated phase of PPP. In this phase, packets used to configure data links are transmitted. Those configuration parameters do not include the parameters needed for the network layer protocol. After the packets are exchanged, the link between the communicating devices enters the next phase. According to user configuration, the next phase can be either the Authenticate phase or the Network phase. The next phase is determined by the configurations of devices at two ends of the link. The configurations are usually made by users. In the Establish phase, the LCP state machine changes three times.
l
When the link status is unavailable, the status of the LCP state machine is Initial or Starting. If the link is detected as available, the physical layer sends an Up event to the link layer. After receiving the event, the link layer changes the current status of the LCP state machine to the Request-Sent state. Then LCP sends Configure-Request packets to configure the data link. If the local end receives the Configure-Ack packet from the peer end, the LCP state machine changes from the current state to the Ack-Received state. The peer end enters the Ack-Sent state. If the end in the Ack-Received state sends the Configure-Ack packet or the end in the AckSent state receives the Configure-Ack packet, the LCP state machine changes from the current state to the Opened state. After one of the two ends receives the Configure-Ack packet, the current status of the LCP state machine changes to Opened. The link enters the next phase.
The other end is in the same condition. Note that the operation process of the link configuration on either end is mutually independent. In the Establish phase, non-LCP packets are discarded after being received.
Authenticate Phase
Generally, authentication is performed before devices on both ends enter the Network phase. By default, PPP does not involve authentication. If authentication is necessary, you must specify the authentication protocol in the Establish phase. PPP authentication is mainly used on the following two types of links:
l
Links connected through the PPP server or dial-in access between hosts and routers in most cases Private links occasionally
PPP provides the following two authentication modes:


l l
Password Authentication Protocol (PAP) Challenge-Handshake Authentication Protocol (CHAP)
The authentication mode is determined by the outcome of the negotiation in the Establish phase. The link-quality detection is also performed in the Establish phase. According to the PPP protocol, the detection does not unlimitedly delay the authentication process. This phase supports only the link control protocol, authentication protocol, and quality-detection packet. Packets of other types are discarded. If a device receives the Configure-Request packet in this phase, the link restores the Establish state.
Network Phase
In the Network phase, network protocols such as IP, IPX, and AppleTalk are negotiated through corresponding NCPs, which can be enabled and disabled during any phase. After a NCP state machine turns Opened, PPP links can transmit network-layer packets. If a device receives a Configure-Request packet in this phase, the communicating devices return to the Establish phase.
Terminate Phase
PPP can terminate links at any time. Except that the network administrator manually closes the links, carrier lost, authentication failure, or link-quality detection failure can lead to the end of a link. In the Establish phase, after the exchange of LCP Terminate frames, a link is torn down physically. When a link is being established, LCP link terminating packets are possibly exchanged to close the link. After the link is closed, the link layer informs the network layer of corresponding operations and the link is also forcibly closed through the physical layer. NCP cannot, and does not need to close a PPP link.
6.3 PPPoE
6.3.1 Basic Principles of PPPoE 6.3.2 PPPoE Discovery Period 6.3.3 PPPoE Session Period
6.3.1 Basic Principles of PPPoE

Point-to-Point Protocol over Ethernet (PPPoE) describes the method to set up PPPoE sessions and encapsulate PPP datagram over Ethernet. These functions require a point-to-point (P2P) relation between the peers instead of the multi-point relationships that are available in Ethernet and other multi-access environments. PPPoE uses Ethernets to connect a large number of hosts. PPPoE uses a remote client to access the Internet, and implements the controlling and accounting functions over the access hosts. With the cost-effective feature, PPPoE is widely applied in a series of applications such as community networks. With this model, each host uses its own PPP stack and the user is presented with a familiar user interface.
The access control, payment, and Type of Service (ToS) functions supported by PPPoE are based on individual users. PPPoE is divided into two stages: Discovery stage and PPPoE Session stage. To establish the P2P connections on the Ethernet network, each PPPoE session must know the Ethernet MAC address of the counterpart. A unique session_ID needs to be given to the sesion. The PPPoE discovers the protocol through the address and looks for the Ethernet MAC address of the counterpart. When a host wants to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and set up a PPPoE Session_ID. Although PPP defines a peer-to-peer relationship, Discovery is a client-server relationship. During address discovery, a host as the client discovers the MAC address of the Access Concentrator (AC), that is, the server. Based on the network topology, the host may communicate with more than one AC. The Discovery stage allows the host to discover all ACs and then select one. When the Discovery stage is complete successfully, both the host and selected AC have the information they use to set up P2P connection over Ethernet. The Discovery stage remains stateless until a PPPoE session is set up. Once a PPPoE session is set up, both the host and the AC that serves as an access server must allocate the resources for a PPP virtual interface. After PPPoE sessions are set up successfully, the host and access server can communicate.
6.3.2 PPPoE Discovery Period

When the host accesses the server through PPPoE, it should identify the MAC address of the peer before setting up the PPPoE Session_ID. This is the function of the Discovery stage. The Discovery stage consists of four steps. When the Discovery stage completes, both peers know the PPPoE Session_ID and the peer MAC address, which together define the unique PPPoE session. Discovery stage consists of the following four steps. 1. The host broadcasts a PPPoE Active Discovery Initial (PADI) packet within the local Ethernet. This packet contains the service information that the host needs. Figure 6-3 Diagram of the host sending PADI packets in broadcast
Server A PADI Server B PC PADI
PADI PADI
Server C
2.
After receiving this PADI packet, all the servers on the Ethernet compare the requested services with services they can provide. Then, the servers that can provide the requested services send back PPPoE Active Discovery Offer (PADO) packets.
6-10
As shown in Figure 6-4, both Server A and Server B can provide services, and send back PADO packets to the host. Figure 6-4 Sending the PADO packet from the server
Server A PADO-B Server B PC PADO-B Server C
PADO-A PADO-A
3.
The host may receive more than one PADO packet from servers. The host looks through the PADO packets and chooses a server (For example, choose the one who replies first). Then, the host sends a PPPoE Active Discovery Request (PADR) packet to the server. As shown in Figure 6-5, the host chooses Server A and sends a PADR packet to it. Figure 6-5 Diagram of the host choosing a server and sending a PADR packet
Server A
PADR PADR
Server B PC Server C
4.
The server generates a unique session identifier to identify the PPPoE session with the host. Then, the server sends this session identifier to the host through the PPPoE Active Discovery Session-confirmation (PADS) packet. If no error occurs, both the server and host enter the PPPoE Session stage. As shown in Figure 6-6, Server A sends a PADS packet to the host after receiving the PADR packet. Figure 6-6 Diagram of the server sending a PADS packet to the host
Server A
PADS PADS
Server B PC Server C
Issue 01 (2009-12-01)
6-11
After sending the PADS packet, the access server can enter the PPPoE Session stage. After receiving this PADS packet, the host can enter the PPPoE Session stage.
6.3.3 PPPoE Session Period

Once a PPPoE session begins, PPP packets, as the PPPoE payload, are encapsulated in Ethernet frames and sent to the peer. The session ID should be the ID determined in the Discovery stage. The MAC address should be the MAC address of the peer. The PPP packets start with the protocol ID. In the Session stage, either the host or the server can send a PPPoE Active Discovery Terminate (PADT) packet to the peer to terminate the session. All the Ethernet packets are unicast.
l l l
The Ethernet_Type field is set to 0x8864. The PPPoE Code field must be set to 0x00. The Session_ID of a PPPoE session cannot be changed and must be the value specified in the Discovery stage. The PPPoE payload contains a PPP frame that begins with the PPP Protocol-ID.
After entering the PPPoE Session stage, either the host or access server can send a PADT packet to notify the peer to end the PPPoE session.
6.4 DHCP Overview

6.4.1 DHCP Service 6.4.2 DHCP Relay 6.4.3 DHCP Client
6.4.1 DHCP Service

With the rapid growth in network scale and complexity, network configuration has become more difficult. Because changes in computer positions and the number of hosts has exceeded that of the available IP addresses, Dynamic Host Configuration Protocol (DHCP) is created. The DHCP works in Client-Server model. With the DHCP, a client can dynamically request configuration information from a DHCP server, including the assigned IP address, the subnet mask, and the default gateway and so on. The DHCP server returns the corresponding configuration information based on a certain configuration policy to the DHCP client. The DHCP has extended BOOTP in two aspects:
l
DHCP can get all the configuration information that a host needs by sending only two message. DHCP helps the computer to get an IP address fast and dynamically, instead of specifying an IP address for each host manually.
6-12
IP Address Assigned by DHCP

Different hosts need to occupy the IP addresses in different periods. For example:
l l
A server may need to occupy a fixed IP address for a long time. Some enterprise hosts may need to occupy a dynamically assigned IP address for a long time. Some clients may need only a temporary IP address.
The DHCP server supports the following address assignation methods:

l
Manual The administrator assigns fixed IP addresses for specific hosts, such as the Web server. Automatic The server assigns long-term fixed IP addresses for some hosts when they are connected to the network for the first time.
Dynamic The server assigns an IP address to a client in a leasing manner. The client needs to request an IP address again when the service expires. This method is widely used.
Distribution Sequence of IP Addresses

The DHCP server selects IP addresses for clients in the following sequence:
l
The IP address in the database of the DHCP sever is statically bound with the client's MAC address. The IP address assigned to the client before. That is, the IP address in the Requested IP Address Option that is in the DHCP Discover packet sent by the client. The IP address that is found first when the server searches for the available IP addresses in the DHCP address pool.
If no IP addresses are available, the DHCP server searches the timeout IP addresses and the collision IP addresses in turn and assigns the found IP address. Otherwise, it sends a fault report.
6.4.2 DHCP Relay

The DHCP client sends interactive messages through broadcasting. Therefore, the DHCP clients and servers can only take effect in the same sub-network rather than work in different network segments, whereas it is not economic. Therefore, DHCP relay is introduced to solve the problem. It provides relay services between DHCP clients and servers on different network segments, relaying a DHCP packet to its destination DHCP server or client of a different network segment. In this way, multiple DHCP clients in a network can share one DHCP server. That not only saves cost but also facilitate centralized management. The schematic diagram of DHCP relay is as shown in Figure 6-7.
Issue 01 (2009-12-01)
6-13
Figure 6-7 DHCP relay
DHCP Relay DHCP Client Eudemon DHCP Client DHCP Server DHCP Client DHCP Client
The working principle of DHCP relay is as follows:

l
After the DHCP client starts up and begins to initialize the DHCP, the configuration request packet is broadcast in the local network. If there is a DHCP server in the local network, the DHCP can be configured without the DHCP relay. If there is no DHCP server in the local network, the network device with the DHCP relay, which is connected with the local network, will forward the packets to the specific DHCP servers in the other networks after it receives and processes the broadcast packets properly. Based on information offered by the client, the server sends configuration information to the client via DHCP relay. Thus, dynamic configuration of client finishes.
In fact, there may be more than one similar interactive process from the beginning to the end of the configuration. In nature, DHCP relay fulfills the transparent transmission of DHCP broadcast packets; that is, transparently send broadcast packets of the DHCP client (or the DHCP server) to the DHCP server (or the DHCP client) on other network segments. In actual practice, the DHCP relay function is usually implemented on the specific interface of a Eudemon. To realize the DHCP function on an interface, you need to assign an IP relay address to the interface for specifying the DHCP server.
6.4.3 DHCP Client

A typical DHCP application usually includes one DHCP server and multiple clients. The DHCP clients exchange different information with the server in different phases to obtain the valid and dynamic IP addresses. The following describes the common application scenarios in actual practice.
l l l
DHCP Client Logging In to the Network for the First Time DHCP Client Logging In to the Network Again DHCP Client Prolongs the IP Address Lease Duration
6-14
DHCP Client Logging In to the Network for the First Time

When the DHCP client logs in to the network for the first time, it sets up a connection with the DHCP server after four phases:
l
DHCP discovery: In this phase, the DHCP client looks for the DHCP server. When the client starts and changes to the initialization status, it sends a DHCPDISCOVER broadcast packet to the DHCP server. DHCP offers: In this phase, the DHCP server provides an IP address. After the DHCP server receives the DHCPDISCOVER packet from the client, it extends an IP lease offer. The DHCP server selects an available IP address (not assigned) from the IP address pool and assigns the IP address to the client by sending a DHCPOFFER packet to the client. The packet contains the IP address leased and other settings. DHCP requests: In this phase, the DHCP client selects an IP address. If several DHCP servers send the DHCPOFFER packets to the client, the client accepts only the first DHCPOFFER packet. The client then broadcasts a DHCPREQUEST packet to each DHCP server and changes to the request status. The DHCPREQUEST packet contains the IP address of the DHCP server that made the offer. DHCP acknowledgement: In this phase, the DHCP server confirms the IP address. After the DHCP server receives the DHCPREQUEST packet from the client, it sends a DHCPACK packet to the client. The packet includes the IP address and other settings. Then, the DHCP client binds the TCP/IP components to the network adapter and then changes to the binding status.
Except the server selected by the DHCP client, the other DHCP servers with unassigned IP addresses can still offer IP addresses for other clients.
DHCP Client Logging In to the Network Again

When the DHCP client logs in to the network again, it sets up a connection with the DHCP server after the following phases:
l
After the DHCP client correctly logged in to the network for the first time, when it tries to log in to the network again, it changes to the restart and initialization status. Under this status, the DHCP clients needs only to directly send the DHCPREQUEST broadcast packet, which contains the IP address obtained during last login. After the DHCP client sends the DHCPREQUEST packet, it waits for the response of the DHCP server. After the DHCP server receives the DHCPREQUEST packet, if the IP address requested by the client is not assigned, the DHCP server sends a DHCPACK packet to the client, telling the DHCP client to go on to use this IP address. After receiving the DHCPACK packet from the DHCP server, the client changes to the binding status. If this IP address cannot be assigned to the DHCP client any more (for example, it is assigned to another client already), the DHCP server sends a DHCPNAK packet to the client. After receiving the DHCPNAK packet, the client changes to the initialization status. In this case, the client resends a DHCPDISCOVER packet to request for a new IP address. The following procedures are the same as those during the first login.
DHCP Client Prolongs the IP Address Lease Duration

The DHCP server specifies a lease duration when assigning a dynamic IP address to a client. After the lease expires, the server retracts the IP address. If the DHCP client needs to keep this IP address, it should renew the IP lease (for example, to prolong the IP address lease).
After the DHCP client obtains an IP address and changes to the binding status, it sets three timers to control lease renewal, perform rebinding, and identify whether the lease expires. When the DHCP server assigns an IP address to a client, it specifies specific values for the timers. If the server does not set the values for the timers, the client uses the default settings. Table 6-1 shows the default settings of the timers. Table 6-1 Default settings of the timers Timer Lease renewal Rebinding Lease expiry Default Setting It should be half of the total lease duration. It should be 87.5% of the total lease duration. Total lease duration
When the Lease renewal timer expires, the DHCP client should renew the IP address. The DHCP client automatically sends an unicast DHCPREQUEST packet to the DHCP server that assigned the IP address, and then the client changes to the renewal status. If the IP address is valid, the DHCP server responds to the client with a DHCPACK packet, telling the client that the new IP lease is granted. Then the client changes to the binding status again. If replying with a DHCPNAK packet and using the current IP address until 87.5% of the lease validity period expires, the DHCP server sends broadcast packets to re-lease the IP address. If the client receives a DHCPNAK packet from the DHCP server, it changes to the initialization status. After the client sends a DHCPREQUEST packet for prolonging the lease duration, it keeps in the renewal status, waiting for a response from the server. If the client does not receive any response from the server till the Rebinding timer expires, the client assumes that the original DHCP server is unaccessible and then sends a DHCPREQUEST broadcast packet. Any DHCP server on the network can respond to the request of the client and send a DHCPACK or DHCPNAK packet to the client. If the client receives a DHCPACK packet, it changes to the binding status and re-sets the Lease renewal and Rebinding timers. If the packets received by the client are all DHCPNAK packets, it changes to the initialization status. In this case, the client should stop using this IP address immediately and change to the initialization status to apply for a new IP address.
If the client does not receive any response before the Lease expiry timer expires, it should stop using this IP address immediately and change to the initialization status to apply for a new IP address.
6.5 Static Route Overview

6.5.1 Static Route 6.5.2 Default Route
6.5.1 Static Route

In a simpler network, you only need to configure the static routes to make the router works normally. The proper configuration and usage of the static routes can not only improve the network performance but also ensure the bandwidth of the important applications. You can set up an interworking network by configuring the static route. The problem of the static route lies in that once the network is faulty, the static routes can not automatically change accordingly without the intervention of an administrator.
Composition of a Static Route

In the system view, you can use the ip route-static command to configure a static route. A static route includes the following elements:
l
Destination Address and Mask In the ip route-static command, the destination IP address is in a dotted decimal format. The subnet mask can be in a dotted decimal format or be represented by the mask length.
Egress Interface and Next Hop Address When configuring a static route, you can specify interface-type interface-number or nexthop-address according to actual situation.
When specifying the transmission interface, note the following:

l
For point-to-point interfaces, the next hop address is specified implicitly in the specified transmission interface. The address of the peer interface connected with this interface is the next hop address. For example, when an E1 link encapsulates PPP, the peer IP address is obtained through PPP negotiation. In this case, you only need to specify the transmission interface without the next hop address. For Non-Broadcast Multiple Access (NBMA) interfaces such as ATM interfaces, they support point-to-multipoint networks. Therefore, in actual application, you need to not only configure IP routing but also set up the secondary route at the link layer, that is, the mapping between the IP address and the link layer address. In this case, you need to configure the next hop IP address. When configuring a static route, if you specify the broadcast interface (Ethernet interface for example) as the sender interface, you are advised to specify a next hop address as well. The Ethernet interface is a broadcast interface. As a result, many next hops exist and a unique next hop cannot be determined. However if you have to specify a broadcast interface (such as an Ethernet interface) as the transmission interface, the next hop address should be specified at the same time.
Attributes of a Static Route

The static route has the following attributes:
l
Reachable route Normal routes belong to this case. IP packets are sent to the next hop according to the route determined by the destination IP address. The static route is commonly used in this way.
Unreachable route When the static route of a certain destination IP address has the "reject" attribute, all IP packets to the destination IP address are discarded and the source host is notified that the destination IP address is unreachable.
Issue 01 (2009-12-01)
6-17
l
Blackhole route When the static route of a certain destination IP address has the "blackhole" attribute, all IP packets to the destination IP address are discarded and the source host is not notified.
The "reject" and "blackhole" attributes are used to control the range of the reachable destination IP address of the router and to help to analyze the network faults.
6.5.2 Default Route

In a word, a default route is a route used only when no routing table entry is matched. That is, the default route is used only when no proper route is found. In a routing table, the default route is the route to the network 0.0.0.0 (with the mask 0.0.0.0). Using the display ip routing-table command, you can check whether the default route is configured. If the destination address of a packet does not match any other entry except the default route in the routing table, the router selects the default route to forward this packet. If there is no default route, and the destination address of the packet does not match any entry in the routing table, the packet is discarded. An Internet Control Message Protocol (ICMP) packet is then sent to inform the source host that the destination host or network is unreachable.
6.6 RIP
6.6.1 RIP Overview 6.6.2 RIP Versions 6.6.3 RIP Startup and Operation
6.6.1 RIP Overview

Routing Information Protocol (RIP) is a relatively simple dynamic routing protocol and is mainly applied to small-sized networks such as campus networks. RIP is a kind of Distance-Vector (D-V) algorithm-based protocol and exchanges the routing information through the UDP packets. It employs the hop count to measure the distance to the destination host, which is called routing cost. In RIP, the hop count from a router to its directly connected network is 0, and that to a network which can be accessed through another router is 1. To restrict the time to converge, RIP prescribes that the cost is an integer in the range of 0 to 15. The hop count equal to or more than 16 is defined as infinite, that is, the destination network or the host is unreachable. RIP sends route refreshment packets every 30 seconds. If the router cannot receive the route refreshment packets from some network neighbor within 180 seconds, it marks all routes in this network neighbor to be unreachable. If the route can still not receive route refreshment packets within 300 seconds, it will clear all routes of this network neighbor from the routing table. To improve performance and avoid the creation of routing loop, RIP supports split horizon and poison reverse. Besides, RIP can also import routes from other routing protocols. Each router running RIP manages a route database, which contains routing entries to all the reachable destinations in the network.

l
Destination address Refer to the IP address of a host or a network. Next hop address Refer to the address of the next router that a router will pass through for reaching the destination.
Egress interface Refer to the interface through which the IP packet should be forwarded. Cost Refer to the cost for the router to reach the destination, which should be an integer in the range of 0 to 15.
Timer Refer to duration from the last time that the routing entry is modified till now. The timer is reset to 0 whenever a routing entry is modified.
Route flag Refer to a label to distinguish routes of internal routing protocols from those of external routing protocols.
6.6.2 RIP Versions

There are two RIP versions: RIP-1 and RIP-2.
l l
RIP-1 supports broadcasting protocol packets. RIP-2 transmits packets in two modes, the broadcast mode and the multicast mode. By default, packets are transmitted in multicast mode using the multicast address 224.0.0.9. The advantages of multicast message transmitting are:
In the same network segment, those hosts that do not run RIP can avoid receive RIP broadcasting message. Multicast message can prevent hosts running RIP-1 from falsely receiving and processing subnet mask route in RIP-2.
6.6.3 RIP Startup and Operation

The whole process of RIP startup and running can be described as follows. 1. When RIP is just enabled on a router, request packet is forwarded to a neighbor router in broadcast mode. After the neighbor router receives the packet, it responds to the request and resends a response packet containing information in the local routing table. When the router receives the response packet, it modifies its local routing table and meanwhile sends a modification triggering packet to the neighbor router and broadcast the route modification information. Upon receiving the modification triggering packet, the neighbor router will send it to all its neighbor routers. After a series of modification triggering broadcast, each router can get and keep the updated routing information. At the same time, RIP broadcasts its routing table to the neighbor routers every 30 seconds. The neighbor routers will maintain their own routing tables after receiving the packets and will select an optimal route, and then advertise the modification information to their neighbor networks so as to make the updated route globally known. Furthermore, RIP uses
2.
3.
Issue 01 (2009-12-01)
the timeout mechanism to handle the timeout routes so as to ensure the real time and validity of the routes. RIP is adopted by most of IP router suppliers. It can be used in most of the campus networks and regional networks of simple structures and strong continuity. For larger and more complex networks, RIP is not recommended.
6.7 OSPF
6.7.1 OSPF Overview 6.7.2 Process of OSPF Route Calculation 6.7.3 Basic Concepts Related to OSPF 6.7.4 OSPF Packets 6.7.5 Types of OSPF LSAs
6.7.1 OSPF Overview

Open Shortest Path First (OSPF) is a link state-based internal gateway protocol developed by IETF organization. OSPF is a dynamic routing protocol that runs within an Autonomous System (AS). At present, OSPF version 2 (RFC 2328) is used widely, which has the following features:
l
Applicable scope It can support networks in various sizes and can support hundreds of routers at most. Fast convergence It can send the update packets as soon as the network topology changed so that the change is synchronized in the AS.
Loop-free Since the OSPF calculates routes with the shortest path tree algorithm based on the collected link states, this algorithm itself ensures that no loop routes will be generated.
Area partition It allows the network of AS to be divided into areas for the sake of management. In this way, the routing information transmitted between the areas is abstracted further, and as a result less network bandwidth is consumed.
Routing hierarchy OSPF has four-class routes, which rank in the order of priority. They are intra-area, interarea, external type-1, and external type-2 routes.
Authentication It supports the interface-based packet authentication so as to guarantee the security of the route calculation.
Multicast transmission It supports multicast address to receive and send packets.
6.7.2 Process of OSPF Route Calculation

The routing calculation process of the OSPF protocol is as follows.

l
Each router in support of OSPF maintains a Link State Database (LSDB) , which describes the topology of the whole AS. According to the network topology around itself, each router generates a Link State Advertisement (LSA) . The routers on the network send the LSAs by sending the protocol packets to each other. Thus, each router receives the LSAs of other routers and all these LSAs compose its LSDB. LSA describes the network topology around a router, while LSDB describes the topology of the whole network. Routers can easily transform the LSDB to a weighted directed map, which actually reflects the topology of the whole network. Obviously, all the routers get the same map. Each router uses the SPF algorithm to calculate the shortest path tree with itself as the root. The tree shows the routes to the nodes in AS. The external routing information is leaf node. A router, which advertises the routes, also tags them and records the additional information of the AS. Obviously, each router obtains different routing tables.
6.7.3 Basic Concepts Related to OSPF

Router ID
To run OSPF protocol, a router must have a Router ID. If not, the system will automatically select one from the IP addresses on the current interfaces for the router.
DR and BDR
Basic concepts related to DR and BDR:
l
Designated Router (DR) In order for each router to broadcast its local state information to the whole AS, multiple neighboring relations should be created between routers. However, the route changes on a router will be transmitted time after time, which wastes the valuable bandwidth resource. To solve the problem, OSPF defines DR. All the routers only need to send information to the DR, which then broadcasts the network link states. Neither neighbor relation is established nor route information is exchanged between routers except DRs, which are called as DR Others. Which router will act as the DR are not specified, but selected by all the routers in the network segment.
Backup Designated Router (BDR) If the DR becomes invalid due to some faults, it must be reelected and synchronized. It takes long time and meanwhile the route calculation is incorrect. In order to speed up this process, OSPF puts forward the concept of BDR. In fact, BDR is a backup for DR. DR and BDR are elected in the mean time. The adjacencies are also established between the BDR and all the routers on the local network segment, and routing information is also exchanged between them. Once the DR becomes invalid, the BDR will turn into the DR instantly.
Area Partition
As the network keeps extending in scale, if more and more routers in a network run OSPF, LSDB will become very huge. As a result, a great amount of memory is occupied and much CPU is consumed to complete SPF algorithm. In addition, network expansion makes it more possible to change topology. As a result, many OSPF packets are forwarded in the network, and bandwidth utility of the network is reduced.
To solve this problem, OSPF divides AS into several areas. Areas divide routers into groups logically. Each area is marked by area ID, as showed in Figure 6-8. One of the most important areas is area 0, which is also named backbone area. Figure 6-8 OSPF area partition
Area4 Area1
Area0
Area2
Area3
The backbone area needs to realize the exchange of route information from non-backbone area. The backbone area must be consecutive. For physically inconsecutive areas, you need to configure virtual links to keep the backbone area logically consecutive. At the border of an area resides a router rather than a link. A network segment (or a link) can only belong to one area, namely, each interface running OSPF must specify explicitly to which area it belongs. The router that connects backbone area and non-backbone area is named Area Border Router (ABR).
Router Types
As Figure 6-9 shows, the OSPF routers fall into the following four categories according to their locations in AS:
l
Internal routers All interfaces of these routers belong to an OSPF area. ABR These routers can belong to two or more areas at the same time, but one of the areas must be a backbone area. An Area Border Router (ABR) is used to connect the backbone area and the non-backbone areas. It can connect to the backbone area physically or logically.
Backbone routers These routers have at least one interface that belongs to the backbone area. Thus, all ABRs and the routers inside Area0 are backbone routers.
ASBR The routers exchanging routing information with other ASs are AS Boundary Routers (ASBRs). ASBR is not necessarily on the AS border. It can be an internal router or an ABR. Once an OSPF router imports some external routing information, it becomes an ASBR.
6-22
Issue 01 (2009-12-01)
Figure 6-9 OSPF router types

RIP ASBR
Area1 Internal Router Area0
Area4 Backbone Router
Area2 ABR
Area3
Stub Area
A stub area is a special area in which the ABRs do not propagate the learned AS external routes. In these areas, the size of the routing table of the routers and the routing traffic are significantly reduced. Configuring a stub area is optional. Not all the areas conform to the configuration requirements. Generally, a stub area is a non-backbone area with only one ABR and it is located at the AS boundaries. To ensure that the route to a destination outside the AS is still reachable, the ABR in an area originates a default route and advertises it to the non-ABR routers in the area. Note the following items while configuring a stub area:
l l
The backbone area cannot be configured to be the stub area. If you want to configure an area to be a stub area, all the routers in this area must configured with the stub command. ASBR cannot exist in the stub area. In other words, AS external routes are not transmitted in the stub area. The virtual link cannot pass through the stub area.
NSSA Area
A new area (NSSA area) and a new LSA (NSSA LSA or Type-7 LSA) are added in the RFC1587 NSSA option. Similar to the stub area, an NSSA area cannot be configured with virtual links.
Route Summary
AS is divided into different areas, each area is interconnected through OSPF ABR. The routing information between areas can be reduced through route summary. Thus, the size of routing table can be reduced and the calculation speed of the router can be improved.
After calculating an intra-area route in an area, the ABR will look up the routing table and encapsulate each OSPF route into an LSA and send it outside the area. The route summary is showed in Figure 6-10. Figure 6-10 Area and route summary
Area 12 19.1.1.0/24 Area 19 Area 0 Virtual Link RTA 19.1.2.0/24 19.1.3.0/24
Area 8
For example, in Figure 6-10, there are three intra-area routes in area 19, which are 19.1.1.0/24, 19.1.2.0/24 and 19.1.3.0/24. If route summary is configured and the three routes are aggregated into one route 19.1.0.0/16, only one LSA, which describes the route after summary, is generated on RTA. OSPF has two types of aggregation:
l
ABR aggregation When an ABR transmits routing information to other areas, it originates Type-3 LSA per network segment. If some continuous segments exist in this area, you can aggregate these segments into a single segment by using the abr-summary command. In this way, ABR only sends an aggregated LSA. Any LSA falling into the specified aggregation network segment of this command is not transmitted separately. This accordingly reduces the LSDB scale in other areas. Once the aggregate segment of a certain network is added to the area, all the internal routes of the IP addresses are not broadcasted separately to other areas. These IP address are in the range of the aggregate segment. The routing information of the entire aggregate network segment is broadcast.
ASBR aggregation After the route aggregation is configured, if the local router is ASBR, it aggregates the imported Type5 LSA. This LSA is within the aggregate address range. After the NSSA area is configured, it aggregates the imported Type7 LSA within the aggregate address range. If the local router is ABR, it aggregates Type5 LSA transformed from Type7 LSA.
Refer to 6.7.5 Types of OSPF LSAs to see the types of the OSPF LSAs.
6.7.4 OSPF Packets

OSPF uses five types of packets:
l
Hello packet It is a kind of most common packet, which is sent to the neighbor of a local router regularly. It contains the values of some timers, DR, BDR and the known neighbors.
Database Description (DD) packet When two routers synchronize their databases, they use the DD packets to describe their own LSDBs, including the summary of each LSA. The summary refers to the HEAD of an LSA, which can be used to uniquely identify the LSA. This reduces the traffic size transmitted between the routers, since the HEAD of an LSA only occupies a small portion of the overall LSA traffic. With the HEAD, the peer router can judge whether it already has had the LSA.
Link State Request (LSR) packet After exchanging the DD packets, the two routers know which LSAs of the peer routers are lacked in the local LSDBs. In this case, they will send LSR packets to request for the needed LSAs to the peers. The packets contain the summary of the needed LSAs.
Link State Update (LSU) packet The packet is used to send the needed LSAs to the peer router. It contains a collection of multiple LSAs (complete contents).
Link State Acknowledgment (LSAck) packet The packet is used to acknowledge the received LSU packets. It contains the HEAD(s) of LSA(s) to be acknowledged (a packet can acknowledge multiple LSAs).
6.7.5 Types of OSPF LSAs

Five Types of Basic LSAs
The OSPF calculates and maintains the routing information mainly based on the LSAs. Five types of LSAs are defined in RFC 2328:
l
Router-LSAs Type-1 LSAs, generated by routers and spread throughout the area where the routers locate. They describe the link state and cost of the routers.
Network-LSAs Type-2 LSAs, generated by DRs on the broadcast network, and spread throughout the area where the DRs locate. They describe the link state of the local network segment.
Summary-LSAs Type-3 LSAs or Type-4 LSAs, generated by ABR and spread into related areas. They describe routes to destinations internal to the AS, yet external to the area (i.e., inter-area routes). Type-3 Summary-LSAs describe routes to networks (with the destination as a network segment), while Type-4 Summary-LSAs describe routes to ASBRs.
AS-external-LSAs
Issue 01 (2009-12-01)
Type-5 LSAs (also written as ASE LSA). Generated by ASBRs, they describe routes to destinations external to the AS. They are spread throughout the entire AS, except stub areas and NSSA areas. A default route for the AS can also be described by an AS-external-LSA.
Type-7 LSA
A new LSA, Type-7 LSA, is added in RFC 1587 (OSPF NSSA Option). As described in RFC 1587, Type-7 LSAs and Type-5 LSAs mainly differ in:
l
Type-7 LSAs are generated and spread throughout Not-So-Stubby Area (NSSA), while Type-5 LSAs are not. Type-7 LSAs can only be spread throughout an NSSA. When Type-7 LSAs reach ABR of NSSA, they will be translated into Type-5 LSAs and spread into other areas. They can not be directly spread into other areas or the backbone area.
Opaque LSAs
To make the OSPF support more service applications, RFC 2370 (The OSPF opaque LSA) defines opaque LSAs to further extend OSPF. There are three types of opaque LSAs with different spread scopes:
l
Type-9 With a link-local scope, type-9 opaque LSAs are not spread beyond the local (sub) network. Type-10 With an area-local scope, type-10 opaque LSAs are not spread beyond the borders of their associated area.
Type-11 With the same spread scope with type-5 LSAs, type-11 LSAs are spread throughout the entire AS except stub and NSSA areas.
Opaque LSAs consist of a standard 20-byte LSA header followed by a field related to application information. The packet structure is shown in Figure 6-11. Figure 6-11 Opaque LSAs structure
0 LS age 16-bit Opaque type 8-bit 16 Options 8-bit Opaque ID 24-bit Advertising Router 32-bit LS Sequence Number 32-bit 24 LS type (9, 10 or 11) 8-bit 32
LS checksum 16-bit Opaque Information
Length 16-bit
6-26
Issue 01 (2009-12-01)
And in Figure 6-11:

l l l
Opaque type byte is used to identify the application type of the LSA. Opaque ID is used to differentiate LSAs of the same type. Opaque information field contains the LSA information. The information format can be defined at the request of applications.
6.8 BGP
6.8.1 BGP Overview 6.8.2 Classification of BGP Attributes 6.8.3 Principles of BGP Route Selection
6.8.1 BGP Overview

BGP Origin
In the ARPANET of the early 1980s, the Internet functions as a single network, and it runs the Gateway to Gateway Protocol (GGP). GGP requires each gateway to know the routes to other reachable gateways. With the increase of the network scale, the size of the routing table and the cost of calculating routes become very large. As the number of gateways increases, the number of maintainers also increases. The low-extensibility of GGP cannot meet the requirements of network development. In RFC 827, the ARPANET network is divided into several levels, from a single network to a network formed by multiple interconnected Autonomous Systems (ASs). Each AS is identified by an AS number. The AS is an interconnected network independently managed by an administrative institution.
l
In an AS, the administrative institution can freely choose the Interior Gateway Protocol (IGP). GGP is the first IGP of ARPANET, and later is replaced by Routing Information Protocol (RIP), Open Shortest Path First (OSPF), and Intermediate-System to IntermediateSystem (IS-IS). ASs share routing information through the Exterior Gateway Protocol (EGP).
With further expansion of the network, the topology is more complex. EGP is replaced by the Border Gateway Protocol (BGP) due to the following defects:
l l l l
It is unable to perform loop detection. It does not have the algorithm that is used to select the optimal inter-area route. It converges slowly when the network changes. It cannot apply the routing policy.
Issue 01 (2009-12-01)
6-27
BGP Version
BGP is a dynamic routing protocol used between ASs. The early three versions are BGP-1 (defined in RFC 1105), BGP-2 (defined in RFC 1163), and BGP-3 (defined in RFC 1267). The current version of BGP is BGP-4 (defined in RFC 4271). In the three early issued versions, BGP system is used to exchange the reachable inter-AS routing information, establish inter-AS paths, prevent the routing loop, and apply the routing policy to ASs. BGP-4 supports the Classless Inter-Domain Routing (CIDR).
NOTE
Unless otherwise specified, BGP stated in this manual refers to BGP-4.
BGP Characteristics
BGP has the following characteristics:
l
It is an EGP protocol. It focuses on the control of the route propagation and selection of optimal routes rather than discovery and calculation of routes. This distinguishes BGP from IGPs such as OSPF and RIP. It uses TCP as the transport layer protocol to enhance the reliability of the protocol. It listens at TCP port 179.
BGP performs inter-domain route selection that proposes high requirements for the reliability of the protocol. TCP with higher reliability, therefore, is used to enhance the stability of BGP. BGP peers must be logically interconnected and establish TCP connections. When a connection request is sent to a peer, the destination port number is 179 and the local port number can be any number.
l l
It supports CIDR. It transmits only the updated routes during the update period. This reduces the bandwidth used by BGP to transmit routes and is suitable for transmitting a large amount of routing information on the Internet. It is a Distance-Vector (DV) routing protocol, and the routing loop is prevented in design.
Inter-AS: BGP routes carry the information on the AS it passes through. The route that carries the local AS number is discarded, so the inter-AS routing loop is prevented. Intra-AS: BGP does not advertise the routes to its neighbors in the same AS from which it learns the routes, so the intra-AS routing loop is prevented.
l l
It provides abundant routing policies to flexibly filter and select routes. It provides the mechanism to prevent route flapping. This effectively increases the stability of the Internet. It extends easily to support new development of the network.
BGP Operating Modes

BGP operates on Eudemons in the following modes, as shown in Figure 6-12:
l l
Internal BGP (IBGP) External BGP (EBGP)

6-28
IBGP runs within an AS. EBGP runs among ASs. Figure 6-12 BGP operating mode
Client AS
IBGP EBGP EBGP
ISP1 Internet
ISP2
BGP Application Scenarios

BGP is used to transmit routing information between ASs. BGP is not used in all cases. BGP is required in the following cases:
l
As shown in Figure 6-12, the user needs to be connected to two or more Internet Service Providers (ISPs). The ISPs need to provide complete or partial Internet routes for the user. Routers, therefore, can determine the optimal route through the AS of an ISP to the destination, according to the AS information carried in BGP routes. Users of different organizations need to transmit AS path information. Users transmit private network routes through Layer 3 VPN. Users use BGP as signaling to transmit routing information in Layer 2 applications (such as VPLS in Kompella mode). Users need to transmit multicast routes to construct the multicast topology.
l l l
BGP is not required in the following cases:

l l l
The user is connected to only one ISP. The ISP does not need to provide Internet routes to users. Default routes are used to connect ASs.
Issue 01 (2009-12-01)
6-29
BGP Processing
The transport layer protocol of BGP is TCP; therefore, TCP connections must be set up between peers before BGP peers are set up. By exchanging Open messages, BGP peers negotiate related parameters used to establish the BGP peer relationship. After the connection is set up, BGP peers exchange the entire BGP routing table. BGP routers do not periodically update the routing table. When the BGP routes change, routers update the BGP routing table through Update messages. BGP routers send Keepalive messages to maintain BGP connections with peers. When BGP routers detect an error in the network, they send Notification messages to report the error. The BGP connection between them is immediately closed.
6.8.2 Classification of BGP Attributes

The BGP route attribute is a set of parameters, and describes a specific route for BGP to filter and select routes. All BGP route attributes are classified as follows:
l
Well-known mandatory: can be identified by all BGP routers. The attribute is mandatory and must be carried in Update messages. Without the attribute, errors occur in routing information. Well-known discretionary: can be identified by all BGP routers. The attribute is discretionary and is not necessarily carried in Update messages. The attribute can be selected according to practical conditions. Optional transitive: indicates the transitive attribute between ASs. A BGP router may not support this attribute, but it still receives the routes with this attribute and advertises them to other peers. Optional non-transitive: If a BGP router does not support this attribute, the Update messages with this attribute are ignored and are not advertised to other peers.
Table 6-2 shows the BGP route attributes and their corresponding types. Table 6-2 Route attributes and their types Attribute Name Origin AS_Path Next_Hop Local_Pref Atomic_Aggregate Aggregator Community Multi_Exit_Disc(MED)
6-30
Type Well-known mandatory Well-known mandatory Well-known mandatory Well-known discretionary Well-known discretionary Optional transitive Optional transitive Optional non-transitive
Issue 01 (2009-12-01)
Attribute Name Originator_ID Cluster_List
Type Optional non-transitive Optional non-transitive
6.8.3 Principles of BGP Route Selection

Policies for BGP Route Selection
In the implementation of Eudemon, when there are multiple routes to the same destination, BGP selects routes according to the following policies: 1. Selecting a locally originated route with a smaller preference value. The preference is the preference value of various protocol routes including direct routes and static routes in the IP routing table. You can run the display ip routing-table command to view the preference value in the IP routing table. The smaller the preference value is, the higher the preference is.
NOTE
The locally originated route refers to the routes imported by BGP with the import and network commands or the routes aggregated with the aggregate and the summary automatic commands. Compared with the routes received from BGP peers, the local routes are defined.
2.
Selecting a protocol route in the following order: OSPF, IS-IS Level-1, IS-IS Level-2, EBGP (including BGP aggregated route), static, RIP, OSPF_ASE and IBGP, if different protocol routes have the same preference value.
NOTE
BGP prefers direct routes when there are direct routes among locally originated routes. This is because that the preference value of the direct route is the smallest one (that is, 0).
3. 4. 5. 6. 7. 8. 9.
Discarding the routes with the unreachable Next_Hop. Preferring the labeled IPv4 routes unconditionally. Preferring the route with the greatest PreVal. Preferring the route with the highest Local_Pref. Preferring the aggregated route. The preference of an local aggregated route is higher than the preference of a local non-aggregated route. Preferring the route with the shortest AS-Path. Comparing the Origin attribute and selecting the routes with the Origin attribute as IGP, EGP, or Incomplete in order.
10. Preferring the route with the smallest MED value. 11. Preferring the route learned from EBGP. The preference of an EBGP route is higher than that of an IBPG route. 12. Preferring the route with the smallest IGP metric in an AS. Load balancing is performed according to the number of configured routes if load balancing is configured and there are multiple external routes with the same AS-Path. 13. Preferring the route with the shortest Cluster_List. 14. Preferring the route with the smallest Originator_ID.
15. Preferring the route advertised by the router with the smallest router ID. 16. Comparing IP addresses of the peers and preferring the route that is learnt from the peer with a smaller IP address.
Route Selection Policy When BGP Load Balancing Is Applied

In BGP, the next hop address of a generated route may not be the address of the peer directly connected to the local router. One of the reasons is that the next hop is not changed when routing information is advertised between IBGP peers. In this case, to ensure that packets can be correctly forwarded, the router must find a reachable address, and then forward packets to the next hop according to the address. In this process, the route to the reachable address is called the dependent route. BGP forwards packets according to dependent routes. The process of finding the dependent route according to the next hop address is called route iteration. The Eudemon supports BGP load balancing based on route iteration. That is, if the dependent route is configured for load balancing (suppose there are three next hop addresses), BGP generates the same number of next hop addresses to guide the forwarding of packets. The iteration-based BGP load balancing need not be configured through commands. This feature is always enabled in the Eudemon.
NOTE
l l
In BGP, the load balancing is performed among the routes with the same AS_Path attribute. BGP load balancing is applied to the ASs in the confederation.
BGP load balancing is different from that of IGP in the following implementation methods:
l
For different routes to the same destination address, IGP calculates the metric values of routes according to its routing algorithm. Load balancing is performed on the routes with the same metric. BGP does not have its own routing algorithm, so it cannot determine whether to perform load balancing among routes according to metric values. BGP have many route attributes that have different priorities in the route selection policy. BGP load balancing is only one part of the route selection policy. That is, BGP load balancing is performed according to the maximum number of equal-cost routes only when all attributes of routes with higher preference are the same.
Policies for BGP Route Advertisement

In the implementation of Eudemon, BGP routers advertise routes according to the following policies:
l
The BGP speaker advertises only the optimal route to its peers when there are multiple active routes. The BGP speaker sends only the routes that it uses to its peers. The BGP speaker advertises the routes learned from EBGP routers to all BGP peers (including EBGP peers and IBGP peers). The BGP speaker does not advertise the routes learned from IBGP routers to its IBGP peers. The BGP speaker advertises the routes learned from IBGP routers to its EBGP peers (when synchronization of BGP and IGP is not enabled). The BGP speaker advertises all BGP routes to the new peers once the connections with new peers are established.
l l
l l
6-32
Synchronization of IBGP and IGP

The synchronization of IBGP and IGP is to prevent misleading external AS routers. If a non-BGP router in an AS provides forwarding service, IP packets forwarded by this AS may be discarded because the destination address is unreachable. As shown in Figure 6-13, EudemonE learns a route 8.0.0.0/8 of EudemonA from EudemonD through BGP, and then forwards the packet to EudemonD. EudemonD searches the routing table and finds that the next hop is EudemonB. EudemonD forwards the packet to EudemonC through route iteration, because EudemonD learns a route to EudemonB through IGP. EudemonC, however, does not know the route to 8.0.0.0/8 and discards the packet. Figure 6-13 Synchronization of IBGP and IGP
8.0.0.0/8
AS20
EudemonA EBGP AS10 EudemonB
EudemonC IGP IBGP
IGP EudemonE EBGP AS30
EudemonD
If the synchronization is configured, Eudemons check the IGP routing table before adding the IBGP route to the routing table and advertising it to the EBGP peers. The IBGP route is added to the routing table and advertised to the EBGP peers only when IGP knows this IBGP route. The synchronization can be disabled surely in the following cases:
l l
The local AS is not a transitive AS (The AS20 in Figure 6-13 is a transitive AS). All Eudemons in the local AS are full-meshed IBGP peers.
NOTE
In the Eudemon, the synchronization function is disabled by default.
6.9 Introduction to Policy-Based Routing

Different from the routing based on the destination address in the IP packets, the policy-based routing is a mechanism in which packets are transmitted and forwarded on the basis of the userdefined policies. The policy-based routing on this device can be flexibly designated on the basis of the various information that in the received packets, such as the source address, the destination address, the odd or even IP address. The policy-based route has higher priority than other routes and routes such as the static route are not used after the policy-based route is matched. The policy-based routing of the Eudemon is used in zones.
6.10 Routing Policy Overview

6.10.1 Applications and Implementation of Routing Policy 6.10.2 Differences Between Routing Policy and Policy-based Routing
6.10.1 Applications and Implementation of Routing Policy

Routing policies are used for route control, including route filtration and route attribute setting. Routing policies can change the paths through which network traffic passes, by changing route attributes such as reachability.
Applications of Routing Policies

Routing policies have flexible and wide applications. The following describes several major applications:
l
Controlling the route advertisement Only the routes that meet the conditions specified in a policy are advertised. Controlling the route reception After a routing policy is configured, only the necessary and eligible routing information is received. This helps to control the capacity of a routing table and improve the network security.
Filtering and controlling the imported routes To enrich the routing information, a routing protocol such as RIP imports eligible routes discovered by other routing protocols, and sets certain attributes for the imported routes to meet the requirements of the protocol.
Setting the attributes for specific routes After passing a filtration, the routes can be set with some attributes through the routing policy.
Implementation of Routing Policies

The implementation of a routing policy consists of the following steps:
l
Defining rules Define the characteristics of routing information to which routing policies are applied, that is, a set of matching rules and setting rules. You can choose different attributes such as destination addresses or router addresses to define the matching rules.
Implementing the rules Apply the matching rules to the routing policies for route advertisement, reception, and import.
The Eudemon provides multiple filters such as IP prefix list and Route-Policy, which can be used to define the matching rules flexibly.
6.10.2 Differences Between Routing Policy and Policy-based Routing

Policy-based routing (PBR) is different from packet forwarding based on the Forwarding Information Base (FIB). PBR is the IP forwarding procedure before FIBs are searched. PBR is a route selection mechanism based on customized policies. PBR can be applied to guarantee data security or to realize load balancing.
In the Eudemon, PBR supports the route selection based on information such as source addresses and packet length. Routing policies and PBR are different mechanisms. Table 6-3 shows the differences between the two mechanisms. Table 6-3 Differences between routing policy and PBR Routing Policy Controls routing information. PBR Forwards packets based on policies. If the forwarding fails, the packets are forwarded according to the FIB. Based on the forwarding plane and used by forwarding policies. Must be manually configured hop by hop to ensure that packets are forwarded based on policies. The configuration command is policy-basedroute.
Based on the control plane and used by routing protocols and routing tables. Works with the routing protocol to form a policy. The configuration command is routepolicy.
6.11 Load Balancing

The Eudemon supports the multi-route mode. That is, users can configure multiple routes with the same destination and the same preference. If the destinations and costs of the multiple routes discovered by a routing protocol are the same, load balancing can be performed among the routes. The load balancing is classified into the following types:
l
Packet-by-packet load balancing When the packet-by-packet load balancing is configured, Eudemons at the network layer forward packets to the same destination through various equal-cost paths. That is,Eudemons always choose the next hop address that is different from the last one to send packets. In this way, the load balancing, that is, packet-by-packet load balancing, is implemented. Figure 6-14 shows the packet-by-packet load balancing. Figure 6-14 Networking diagram of packet-by-packet load balancing
POS1/0/0 EudemonA POS2/0/0
EudemonB P1 P3 P5 P2 P4 P6 EudemonD 10.1.1.0/24
EudemonC
Issue 01 (2009-12-01)
6-35
EudemonA forwards packet to the destination address 10.1.1.0/24. Packets P1, P2, P3, P4, P5, and P6 need to be forwarded to the destination. The procedure for sending these packets is as follows:

Sending P1 through POS 1/0/0 Sending P2 through POS 2/0/0 Sending P3 through POS 1/0/0 Sending P4 through POS 2/0/0 Sending P5 through POS 1/0/0 Sending P6 through POS 2/0/0
EudemonA sends packets to the destination address 10.1.1.0/24 alternatively through the two interfaces.
l
Session-by-session load balancing When the session-by-session load balancing is configured, Eudemons forward packets according to the source address, destination address, source port, destination port, and protocol contained in the packets. When the five factors are the same, Eudemons always choose the next hop address the same as the last one to send packets. Figure 6-15 shows the session-by-session load balancing. Figure 6-15 Networking diagram of session-by-session load balancing
EudemonB POS1/0/0 EudemonA POS2/0/0 10.1.1.0/24 P1 P6 10.2.1.0/24 P1 P6 10.1.1.0/24 10.2.1.0/24 EudemonD
EudemonC
EudemonA forwards packets to the destinations at 10.1.1.0/24 and 10.2.1.0/24 respectively. The routing policy of the session-by-session load balancing is that packets in the same flow are always transmitted along the previous path. The process for EudemonA to forward packet is as follows:
The first packet P1 to the destination address 10.1.1.0/24 is forwarded through POS 1/0/0, so packets to the destination are forwarded through the interface. The first packet P1 to the destination address 10.2.1.0/24 is forwarded through POS 2/0/0, so packets to the destination are forwarded through the interface.
NOTE
By default, the Eudemon adopts the session-by-session load balancing. You can run the load-balance packet command to change the load balancing mode to packet-by-packet load balancing.
6-36
Issue 01 (2009-12-01)
In real application, the protocols that support load balancing are RIP, OSPF, BGP, and IS-IS. Besides, static routes also support load balancing.
NOTE
The number of equal-cost routes among which load balancing is performed varies with the product.
6.12 Introduction to QoS

6.12.1 QoS Overview 6.12.2 Traditional Packets Transmission Application 6.12.3 New Application Requirements 6.12.4 Congestion Causes, Impact and Countermeasures 6.12.5 Traffic Control Techniques
6.12.1 QoS Overview

Quality of service (QoS) is used to assess the ability of the supplier to meet the customer demands. In the Internet, QoS is used to assess the ability of the network to transmit packets. The network provides a wide variety of services and therefore, QoS should be assessed from different aspects. QoS generally refers to the analysis of the issues related to the process of sending packets such as, bandwidth, delay, jitter, and packet loss ratio.
6.12.2 Traditional Packets Transmission Application

It is difficult to ensure QoS in the traditional IP network. Routers in the network handle all the packets equally and adopt First In First Out (FIFO) method to transfer packets. Resources used for forwarding packets are allocated based on the arrival sequence of the packets. All packets share the bandwidth of networks and devices. The quantity of the resources is obtained depending on the arrival time of the packets. This policy is called best effort (BE) . The device in this mode tries its best to transmit packets to the destination. The BE mode however, does not ensure any improvement in delay time, jitter, packet loss ratio, and high reliability. The traditional BE mode applies only to services that have no specific request for bandwidth and jitter, such as, World Wide Web (WWW), file transfer, and E-mail.
6.12.3 New Application Requirements

With the rapid development of the network, increasing number of networks are connected to the Internet. The Internet extends greatly in size, scope, and user numbers. The usage of the Internet as a platform for data transmission and implementation of various applications is increasing. Further, the service providers also want to develop new services for more profits. Apart from traditional applications such as WWW, E-Mail and File Transfer Protocol (FTP), the Internet has expanded to encompass other services such as E-learning, telemedicine, videophone, videoconference, and video on demand. Enterprise users want to connect their
branches in different areas through VPN technologies to implement applications such as accessing corporate databases or managing remote devices through Telnet. The new applications demand special requirements for bandwidth, delay, and jitter. For example, videoconference and video on demand need high bandwidth, low delay, and low jitter. Telnet stresses on low delay and priority handling in case of congestion. With the emergence of new services, the number of requests for the service capability of IP networks has increased. Users expect improved service transmission to the destination and also better quality of services. For example, IP networks are expected to provide dedicated bandwidth, reduce packet loss ratio, avoid network congestion, control network flow, and set the preference of packets to provide different QoS for various services. These conditions demand better service capability from the network.
6.12.4 Congestion Causes, Impact and Countermeasures

Low QoS in the traditional networks is mainly caused by the network congestion. When the current supply resources temporarily fail to meet the requirements of the service transmission, the bandwidth cannot be ensured. As a result, QoS decreases, which causes long delay and high jitter. This phenomenon is called congestion.
Congestion Causes
Congestion often occurs in the complex packet switching environment of the Internet. It is caused by the bandwidth bottleneck of two types of links, as shown in Figure 6-16. Figure 6-16 Schematic diagram of traffic congestion
100M 100M 10M 100M 100M
Traffic congestion on Interfaces operating at different speeds
100M Traffic congestion on Interfaces operating at the same speed
Group flows reach the router from a high-speed link, and then are forwarded over a lowspeed link. Group flows reach the router from several interfaces working at the same rate, and then are forwarded from one interface works at the rate.
If flows reach the router at line rate, congestion occurs because of resource bottleneck. Not only link bandwidth bottleneck causes congestion. Any resource insufficiency, such as processor, buffer, memory insufficiency may result in congestion during normal forwarding
transactions. In addition, when traffic reaching a certain destination at a specific time is out of control, exceeding available network resources, network congestion occurs.
Congestion Effect
Congestion can lead to the following negative effect:
l l l
Increases the delay and the jitter in sending packets. Long delay can cause retransmission of packets. Reduces throughput of the network and causes resources to be assigned unequally on the network. Consumes more network resources particularly storage resources when congestion is aggravated. If resources are not allocated properly, there may be a system deadlock or the system may crash.
Congestion is the main cause of decline in the QoS. It is very common in complex networks and must be solved to increase the efficiency of the network.
Countermeasures
The following are the two commonly used methods to address network congestion:
l
Increasing the network bandwidth is a direct way to solve the shortage of resources. This method however, cannot solve all the congestion problems. Improving the functions of traffic control and resource allocation at the network layer is a more effective method. This requires providing differentiated services (Diff-Serv) for applications that have different demands for QoS. During resource allocation and traffic control, the direct or indirect factors that cause network congestion can be controlled to a greater extent. In case of congestion, resource allocation should be balanced according to the application's demand. The influence of congestion on QoS can thus be reduced to the minimum.
6.12.5 Traffic Control Techniques

The following are the commonly used techniques to control traffic in the network:
l
Traffic classification Identifies the object according to specific rules. It is the basis of Diff-Serv and is used to identify packets with a defined rule.
Traffic policing Measure to control the traffic rate. The rate of the traffic that enters the network is monitored and the traffic exceeding its rate limit is restricted. Only a reasonable traffic range is allowed to pass through the network. This ensures optimization of network resources and protects the interests of the providers.
Congestion management Handles resource allocation during network congestion. It stores packets in the queue first, and then takes a dispatching algorithm to decide the forwarding sequence of packets. Congestion management includes creating queues, classifying packets, sending packets to a specific queue, and scheduling queues. During the process of scheduling queues, packets are processed according to their priorities. The higher the priority, the earlier the packet is sent.
Issue 01 (2009-12-01)
6-39
The common queue scheduling mechanisms are as follows:

First-in, first-out (FIFO) queuing Priority queuing (PQ) Custom queuing (CQ) Weighted fair queuing (WFQ) Class-based queuing (CBQ)
Among these traffic control techniques, traffic classification is the basic one. Traffic classification identifies packets according to certain matching rules. In this sense, traffic classification is a prerequisite to differentiated services. Traffic policing and congestion management control network traffic and resource allocation from different aspects, which reflects the concept of differentiated services. QoS is used to provides assessment on supported service capabilities for core requirements such as the bandwidth, throughput, delay, delay jitter, packet loss ratio, and availability during packet forwarding. Generally, the following functions are used to clear congestion:
l l l
Traffic classification Traffic policing Congestion management
6.13 GPON Line

This topic describes the principles and security mechanism of the GPON line that is used for the upstream transmission of the SRG. 6.13.1 Introduction to the GPON Line Feature This topic describes the principles and the security mechanism of the upstream transmission through the GPON line. 6.13.2 Principles of GPON Upstream Transmission. This topic describes the implementation principles of the GPON upstream transmission. 6.13.3 Principles of GPON Lines This topic describes the implementation principles of the AES128 encryption feature for GPON lines.
6.13.1 Introduction to the GPON Line Feature

This topic describes the principles and the security mechanism of the upstream transmission through the GPON line. The SRG supports the upstream GPON port. As a multi-dwelling unit (MDU), the SRG takes full advantage of the wide coverage, flexible networking, and low maintenance cost of the GPON network. It works with the OLT to provide high-bandwidth broadband access for users. In addition, the SRG helps increase the number of users supported at the OLT end. The GPON system adopts AES128 encryption for line security control, thus effectively preventing security problems such as data embezzlement.
6-40
Issue 01 (2009-12-01)

NOTE
Advanced Encryption StandardFederal Information Processing Standard 197 (AES-FIPS 197) is the latest encryption standard issued by the National Institute of Standards and Technology (NIST) of the USA. The AES algorithm can use 128-bit, 192-bit, and 256-bit encryption keys to encrypt and decrypt 128-bit data blocks, thus protecting electronic data.
l
The SRG supports one GPON upstream port with a downstream rate of 2.488 Gbit/s and an upstream rate of 1.244 Gbit/s. The SRG supports eight transmission containers (T-CONTs) with up to 32 GEM ports. The SRG can be configured and managed from the OLT through the OMCI protocol. The SRG supports the T-CONT queue mapping and scheduling based on CoS.
l l l
6.13.2 Principles of GPON Upstream Transmission.

This topic describes the implementation principles of the GPON upstream transmission. The GPON upstream port of the SRG sends the PLOAM message to report its serial number to the OLT for registration. The OLT determines whether to register the SRG according to the internal serial number database. After the SRG registers with the OLT successfully, the OLT allocates T-CONTs to the SRG. The index of a T-CONT is an allocation ID (Alloc ID) that ranges from 0 to 4095. The SRG supports up to eight T-CONTs. The OLT allocates bandwidth to the T-CONTs and sets bandwidth parameters for these T-CONTs. The packets of the SRG that go upstream from the switch fabric are mapped to the specified GEM port and then to the T-CONT through the packet classifier. The rule of the packet classifier is VLAN+802.1p priority. The mapping actions of each service stream can be configured through the CLI or the NMS.
6.13.3 Principles of GPON Lines

This topic describes the implementation principles of the AES128 encryption feature for GPON lines.
Working Principles
The AES algorithm can use 128-bit, 192-bit, and 256-bit encryption keys to encrypt and decrypt 128-bit data blocks, thus protecting electronic data. The AES algorithm replaces the original DES and 3DES algorithms that are less secure. The AES128 encryption feature can be used to randomly select a key from as many as 3.4 x 1038 unique password keys to encrypt bit streams. Therefore, even precise hacker programs that can decrypt one million encryption keys per second (which is a highly advanced concurrent algorithm already) need 10 million of 1000 billion years to find the encryption key generated by the AES-128 encryption. In the AES128 encryption system, the SRG supports key change and switching. 1. When key change is required, the OLT sends a key change request. After receiving the key change request, the ONU (ONT or SRG) responds and generates a new key.
Issue 01 (2009-12-01)
2. 3.
The length of a PLAOM message is limited. Therefore, the generated key is sent to the OLT in two parts and for three times repeatedly. If the OLT does not receive the key in any of the three times, the OLT resends the key change request. The OLT stops sending the key change request until it receives the same key for three times. After receiving the new key, the OLT starts the key switching. The OLT notifies the ONU (ONT or SRG) of the new key by sending a command containing the frame number of the new key. Generally, this command is sent for three times. As long as the ONU receives the command once, it switches the check key on the corresponding data frame.
4. 5.
6.14 Introduction to Voice Services

In line with the three-in-one trend of data, voice, and video services integration, the SRG functions as the enterprise gateway in the FTTO deployment model not only to provide broadband services (including data, video live, and VOD services), but also to provide end users with high-quality voice service by the built-in voice module directly through twisted pairs. 6.14.1 Overview of Voice Features This topic describes the overall voice service solution of the SRG. 6.14.2 General Specifications This topic describes the general specifications of the voice features. 6.14.3 H.248based Voice Services This topic describes the H.248 protocol and the running mechanisms of the H.248based VoIP, MoIP, and FoIP services. 6.14.4 SIP-based Voice Services This topic provides an introduction to the SIP protocol, and describes in detail the user identification, registration flow, and implementation principles of related services of the SIP protocol. 6.14.5 Key Voice Feature This topic provides the overview of key voice features and then describes working principles of each sub feature in detail. 6.14.6 Voice Reliability This topic describes features related to voice reliability, including dual homing networking, highly reliable transmission (SCTP), and voice QoS.
6.14.1 Overview of Voice Features

This topic describes the overall voice service solution of the SRG. As the SRG access devices in the FTTB deployment model, the SRG not only provides broadband services (including data and video live/on demand service), but also provides highquality voice services by the built-in voice module for the end users directly over twisted pairs. Such SRGs fit in with the trend of data, voice, and video services integration. Figure 6-17 illustrates the overall voice service solution of the SRG.
6-42
Issue 01 (2009-12-01)
Figure 6-17 Overall voice service solution of the SRG

Main board Service board
POTS interface
GE DSP
SLIC
CODEC
C P U
Switching module
Interface module
POTS interface
SLIC
CODEC
DSP GE
Service board
VoIP service channel Signaling channel
In this figure, SLIC is the short form for subscriber line interface circuit. It is used for processing analog signals. It sends the feed and voice frequency to the telephone for generating the ringing and signals such as the offhook detection signal and onhook detection signal. CODEC is used for converting between analog signals and digital signals. DSP is used for processing voice frequency (such as voice encoding, echo cancellation, and DTMF generation and detection), and converting digital signals into VoIP packets. The VoIP service channel and signaling channel are indicated by the dotted lines in different colors in Figure 6-17. Each service board uses its DSP chip to process the service and communicates with the control board through the GE bus. The CPU processes the voice signaling, for example, encapsulates and parses the signaling packets, processes the user offhook, controls instructions such as ringing on the user port, and at the same time controls and manages the service boards.
6.14.2 General Specifications

This topic describes the general specifications of the voice features.
l l l
Supporting the H.248, and SIP voice protocols Supporting a maximum of 32 voice users Supporting VoIP, FoIP, and MoIP (Table 6-4 lists the specific services supported) Table 6-4 Voice services supported Type Service SIP service Basic SIP call services SIP call holding service SIP three-party service
Issue 01 (2009-12-01)
6-43
Type
Service SIP call waiting service SIP conference calling service SIP call transfer service SIP registration and management SIP fax service SIP modem service SIP calling line identification presentation (CLIP) service Notification and display of the charge information of SIP calls (advice of charge at the end of the call only) SIP message waiting indicator (MWI) service SIP malicious call tracing SIP Ua profile subscription Distinctive ringing Common POTS service New POTS services:
l l l l
Calling party release Called party release Last-party release First-party release Call waiting service Call transfer service Call forwarding service Co-group pickup service Designated pickup service Three-party service Conference calling service CLIP service
MGCP/H.248 services
l l l l l l l l
6-44
Issue 01 (2009-12-01)
Type
Service FoIP services:

l l l l
Auto-switching fax service T.30 transparent transmission fax service T.38 fax service Configuring of fax parameters, and V2 and V3 fax flows
MoIP services:
l l l l l l
Transparent transmission modem service Auto-switching modem flow Softswitch-controlled modem flow Direct mode of event report Low-speed modem High-speed modem
## service MWI service Distinctive ringing Advice of charge at the end of conversation Dual tone multi-frequency (DTMF) transmission Supporting the G.711A/Mu encoding/decoding at the packetization periods of 10 ms, 20 ms, and 30 ms Supporting the G.729 encoding/decoding at the packetization periods of 20 ms, 40 ms, and 60 ms Complying with RFC2833 (only H.248) and RFC2198 and supporting voice features such as echo cancellation (EC), voice activity detection (VAD), DTMF,voice quality enhancement (VQE), and modem quality enhancement Supporting circuit test, loop line test, call emulation test, and connectivity test Supporting H.248, and SIP dual-homing Supporting the digitmap with a length of 8 K bytes Supporting 16 G.711 DSP channels or 16 G.729 DSP channels
l l l
l l l l
6.14.3 H.248based Voice Services

This topic describes the H.248 protocol and the running mechanisms of the H.248based VoIP, MoIP, and FoIP services.
Introduction to the H.248 Protocol

This topic describes the definition, purpose, and reference standards and protocols of the H.248 protocol.
Definition
H.248 is a media gateway control protocol through which the media gateway controller (MGC) controls the media gateway (MG) so that interoperability is implemented between different media. ITU-T issued the first version of this protocol in June 2000.
Purpose
Compared with MGCP, H.248 has the following merits:
l
Supports more types of access technologies, and is more thorough and complete in standardization Compensates for the deficiency of MGCP in descriptiveness, is applicable to larger networks and has better extensibility and flexibility Carried on various protocols, such as UDP/SCTP (MGCP message is carried on UDP); the SRG supports only the H.248 message carried on UDP
NOTE
MGCP is defined by IETF. MGCP defines a call control structure. In this structure, call control is separated from service carrying. Call control is independent of the MG and is processed by the MGC. Therefore, MGCP is a master-slave protocol in nature. The MG creates various service connections under the control of the MGC.
Reference Standards and Protocols

RFC3525 H.248 Protocol
Mechanism of the H.248 Protocol

This topic describes the basic concepts and mechanism of the H.248 protocol.
Termination ID
A termination ID identifies a termination that is going to register or deregister a service. The termination ID of each termination is unique. During service configuration, the termination ID corresponding to each termination must be configured on the MG and the MGC. The root termination ID represents an entire MG. The ServiceChange command executed on the root termination ID is effective on an entire MG. The wildcarding principle is that the ALL wildcard (*) can be used but the CHOOSE wildcard ($) cannot be used.
Registration Mechanism of the H.248 Interface

The MG sends the ServiceChangeRequest command to inform the MGC that a user or a group of users are about to register or deregister service. After this command is executed successfully, the termination status is changed to InService or OutOfService. In addition, the MGC can unsolicitedly sends the ServiceChangeRequest command to request the MG to register or deregister service for a user or a group of users.
NOTE
Currently, the MG does not support the MGC to unsolicitedly send the ServiceChangeRequest command requesting the MG to register service for a user or a group of users.
Figure 6-18 shows the registration flow of the MG.

Figure 6-18 Registration flow of the MG

MG Start Servicechange Reply Modify Reply MGC
Description of the flow: 1. The MG sends the ServiceChangeRequest command to the MGC. In the command, TerminationId is Root, Method is Restart, and ServiceChangeReason is 901 (cold boot, registering for the first time after power-on), 902 (warm boot, through command lines), or 900 (in other cases). The MGC sends the Reply message to the MG indicating the successful registration. The MGC sends the Modify command to the MG requesting the MG to detect the offhook of all users (al/of). The MG responds to the MGC with the Reply message.
2. 3. 4.
Heartbeat Mechanism of the H.248 Interface

After the registration is successful, the MG and the MGC maintain communication by sending each other the heartbeat message Notify (it/ito). By default, the heartbeat message is sent every 60s. The sending interval can be set within the range of 5-655s. After the MG sends the first heartbeat message to the MGC, if the MG does not receive the heartbeat response from the MGC before the preset interface heartbeat timer (for example, the length of three sending intervals) times out, the MG sets the interface status to "wait for response". Then, the MG keeps initiating a registration with the MGC. If dual-homing is configured, the MG initiates registration with the two MGCs alternatively. The registration is initiated once every 30s, every three trials of registration are one round, and every registration message is re-transmitted 7 times. Therefore, 24 registration messages in total are transmitted within 90s. Then, the MG starts the next round of registration with the other MGC.
Deregistration Mechanism of the H.248 Interface

Figure 6-19 shows the unsolicited deregistration flow of the MG.
Issue 01 (2009-12-01)
6-47
Figure 6-19 Unsolicited deregistration flow of the MG

MG MGC
Servicechange
Reply
Description of the flow: 1. The MG sends the ServiceChangeRequest command to the MGC. In the command, TerminationId is Root, Method is Forced, and ServiceChangeReason is 905 ("905" indicates that the termination is taken out of service because of maintenance operation, and now the MG uses "905" to initiate a deregistration request through command lines). The MGC sends the Reply message to the MG indicating a successful deregistration.
2.
Figure 6-20 shows the flow of the MGC unsolicitedly deregistering the MG.
Figure 6-20 Unsolicited deregistration flow of the MGC

MG MGC
Servicechange
Reply
Description of the flow: 1. 2. The MGC sends the ServiceChangeRequest command to the MG. In the command, TerminationId is Root, Method is Forced, and ServiceChangeReason is 905. The MG responds to the MGC with the Reply message. The SRG (MG) supports the registration and deregistration of not only an entire MG but also a single termination. The service status of a single user can be changed through the registration and deregistration of a single termination.
6-48
Authentication Mechanism of the H.248 Interface

Authentication is a security mechanism through which the MGC authenticates the legality of the MG user. The purpose of authentication is to prevent unauthorized entities from establishing illegal calls or interfering with legal calls through the H.248 or MGCP protocol. Authentication can be implemented only when it is also supported by the softswitch interconnected with the MG.
l l
In H.248, the implementation of authentication complies with RFC2402. MD5 is adopted as the encryption algorithm.
Figure 6-21 shows the authentication flow.
Figure 6-21 Authentication flow

MG Start ServiceChange(1) Reply(2) Modify(3) Reply(4) Modify(5) Reply(6) Softswitch
The basic flow is as follows: 1. 2. 3. 4. 5. 6. The MG sends the ServiceChange command to register with the MGC. The command contains the digital signature of the MG. After receiving the ServiceChange command, the softswitch verifies the MG and sends a reply. The softswitch sends the Modify message to the MG. The message contains the required algorithm ID and random number. The MG verifies the message sent by the softswitch and sends a reply. The softswitch authenticates the MG periodically. The MG sends replies to the softswitch.
H.248-Based VoIP
This topic describes the principles of the call establishment and release in the H.248-based VoIP service.
Figure 6-22 illustrates the principles of the call establishment and release in the H.248-based VoIP service. Figure 6-22 Principle of the VoIP feature that supports the H.248 protocol
MGC
H. 248
H. 248
MG-0
MG-1
A0
Context RTP Stream Call
A1
The basic flow of a call establishment and release is as follows: 1. 2. 3. 4. 5. MG-0 detects the offhook of user A0, and notifies the MGC of the offhook event through the Notify command. After receiving the offhook event, the MGC sends a digitmap to MG-0, requests MG-0 to play the dial tone to user A0, and at the same time checks for the digit collection event. User A0 dials a telephone number, and MG-0 collects the digits according to the digitmap issued by the MGC. Then, MG-0 reports the result of digit collection to the MGC. The MGC sends the Add command to MG-0 for creating a context and adding the termination and RTP termination of user A0 into the context. After creating the context, MG-0 responds to the MGC. The response contains the session description that provides the necessary information for the peer end to send the packet to MG-0, such as the IP address and UDP port number. The MGC sends the Add command to MG-1 for creating a context and adding the termination and RTP termination of user A1 into the context, and then issues the IP address/ UDP port number of user A0 to user A1. After creating the context, MG-1 responds to the MGC. The response contains the session description that provides the necessary information for the peer end to send the packet to MG-1, such as the IP address and UDP port number. MG-1 detects the offhook of user A1, and then reports the offhook event to the MGC. The softswitch (MGC) sends the Modify command to stop the ring back tone of user A0 and the ringing of user A1.
6.
7.
8.
6-50
9.
The MGC sends the session description of MG-1 to user A0 through the Modify command. Then, the conversation is set up between users A0 and A1.
10. MG-0 detects the onhook of user A0, and notifies the MGC of the onhook event through the Notify command. 11. The MGC sends the Modify command to MG-0 and MG-1 respectively to modify the RTP mode to receive-only. 12. The MGC sends the Modify command to MG-1 requesting MG-1 to play the busy tone to user A1, and at the same time checks for the onhook event. 13. The MGC sends the Subtract command to MG-0, requesting MG-0 to release the resources that are occupied by the call of user A0. 14. MG-1 detects the onhook of user A1, and notifies the MGC of the onhook event through the Notify command. 15. The MGC sends the Subtract command to MG-1, requesting MG-1 to release the resources that are occupied by the call of user A1. 16. The call between users A0 and A1 is terminated, and all the resources occupied by the call are released.
H.248-based MoIP
This topic describes the principles of the connection setup and release of the H.248-based MoIP service. Modem over Internet Protocol (MoIP) refers to providing modem service over the IP network or between the IP network and traditional PSTN network. According to different control devices, MoIP can be classified as softswitch-controlled MoIP and auto-switch MoIP.
Softswitch-Controlled MoIP
The basic flow of the softswitch-controlled MoIP service is as follows: 1. 2. 3. Set up a call. If the MoIP service is configured on the softswitch, the softswitch sends a command to the MG instructing the MG to detect the modem event. The calling party and called party start communicating with each other. During the call, when the MG detects the ANS or ANSAM modem start event (both are low-speed modem signals), or detects the ANSBAR or ANSAMBAR modem start event (both are high-speed modem signals), the MG reports the event to the softswitch. According to the event, the softswitch issues a command instructing the MG to switch the DSP channel of the calling and called parties to the low-speed or high-speed modem mode. According to the command issued by the softswitch, the MG switches the DSP channel to the corresponding modem mode. At this stage, the MG adopts the encoding format and port number specified by the softswitch. The settings of echo cancellation (EC), voice activity detection (VAD), and DSP working mode are as follows: (1) Low-speed modem: ECON, VADOFF, DSP working modemodem mode (2) High-speed modem: ECOFF, VADOFF, DSP working modemodem mode 7. After the modem data is transmitted, if the conversation proceeds, the DSP working mode does not automatically switch from the modem mode to the voice mode, because the modem end event is not issued. As a result, the quality of the voice service may be affected.
4. 5.
6.
Issue 01 (2009-12-01)
Auto-Switch MoIP
The basic flow of the auto-switch MoIP service is as follows: 1. 2. Set up a call. The MGs at both ends check for the modem event on the IP side and the TDM side. When the modem event is detected, if the modem transmission mode is configured as auto-switch, the coding mode is switched to G.711 (the a/ law is configurable), and the DSP parameters are modified according to the modem mode (high-speed/low-speed) detected. When the modem service is completed, the call is released.
3.
H.248-based FoIP
This topic describes the implementation principles of the H.248-based fax over Internet protocol (FoIP) service. FoIP refers to providing fax service on the IP network or between the IP network and traditional PSTN network. The fax machine can be regarded as a special modem. In the FoIP negotiation, the modem negotiation is performed before the fax negotiation. According to the transmission protocol adopted, there are two modes of fax services carried on the IP network: the T.30 transparent transmission mode and the T.38 mode. According to different control devices, FoIP can be classified as softswitch-controlled FoIP and auto-switch FoIP.
Softswitch-Controlled FoIP
The fax service can be divided into high-speed fax and low-speed fax. The softswitch-controlled low-speed fax service supports the T.30 transparent transmission mode and the T.38 mode. The basic service flow is as follows: 1. 2. 3. Configure the fax service and fax flow on the MGs and the softswitch. After the voice channel is set up, the softswitch instructs the MG to detect the fax event and modem event. When detecting the fax event, the MG reports the event to the softswitch. The event can be a high-speed modem event (ANSBAR or ANSAMBAR) or a low-speed fax event (V. 21Flag). According to the preset fax flow, the softswitch instructs the MGs at both ends to change the DSP channel working mode to the T.30 transparent transmission mode or T.38 mode. Start the fax. After the fax is completed, if the MG detects the fax end event, the MG reports the event to the softswitch. The softswitch instructs the MGs at both ends to change the DSP channel working mode to the voice mode. The voice service continues.
4. 5. 6. 7. 8.
The softswitch-controlled high-speed fax service supports the T.30 transparent transmission mode. The basic service flow is as follows: 1. 2. Configure the fax service and fax flow on the MGs and the softswitch. After the voice channel is set up, the softswitch instructs the MG to detect the fax event and modem event.
6-52
3.
When detecting a fax event, the MG reports the event to the softswitch. The event can be a high-speed modem event (ANSBAR or ANSAMBAR) or a low-speed fax event (V. 21Flag; if the peer end is a low-speed fax machine or the network quality is poor, the fax speed is automatically decreased and this event is reported). According to the preset fax flow, the softswitch instructs the MGs at both ends to change the DSP channel working mode to the T.30 transparent transmission mode. Start the fax. After the fax is completed, if the MG detects the fax end event, the MG reports the event to the softswitch. The softswitch instructs the MGs at both ends to change the DSP channel working mode to the voice mode. The voice service continues.
4. 5. 6. 7.
Auto-Switch FoIP
The auto-switch fax service supports the T.30 transparent transmission mode and the T.38 mode. The basic service flow is as follows: 1. 2. 3. Configure the auto-switch fax service on the MGs at both ends. Set up a call and start the conversation. The MG checks for the fax event on the IP side and the TDM side. When detecting the fax event, the MG changes the DSP channel working mode to the T.30 transparent transmission mode or T.38 mode. After the fax is complete, when the MG detects the fax end event, the MG changes the DSP channel working mode to the voice mode. The voice service continues.
4. 5.
Common Fax Protocols

Two protocols are usually used for implementing the fax service on the packet voice network: the ITU-T Recommendation T.30 and ITU-T Recommendation T.38. T.30 is based on the PSTN network. T.30 particularly defines the flow for transmitting fax signals on the PSTN network. It also defines the modulation mode (V.17/V.21/V.27/V.29/V.34) and transmission format (HDLC) of data, and the physical standard for fax signals. The T.30 fax messages and data can be transmitted transparently between MGs. This is called the T.30 transparent transmission mode. The quality of the fax in this mode may not be high due to packet loss, latency, and disorder on the IP network. T.38 is a real-time fax mode based on the IP network. In this mode, the MG terminates the T. 30 signals sent from the fax machine, and transmits the data to the peer MG in the T.38 mode. The peer MG then receives the T.38 packets and converts the packets into T.30 signals. The merit of the T.38 fax is that the fax packets have a redundancy processing mechanism and do not strictly rely on the network quality (the fax service can be processed even when a 20% packet loss occurs on the network). The demerit is that the DSP chip needs to participate in parsing the T.30 signals. There being various types of terminals on the network, the compatibility problem may arise. Figure 6-23 shows the principles of the T.38 fax.
Issue 01 (2009-12-01)
6-53
Figure 6-23 Principles of the T.38 fax

MGC(Call Server)
TMG IP backbone network
Data Encapsulation of T.30 fax packet TDM
Data Encapsulation of T.30 fax packet UDP/IP
Data Encapsulation of T.30 fax packet TDM
FAX
MG
MG
FAX
6.14.4 SIP-based Voice Services

This topic provides an introduction to the SIP protocol, and describes in detail the user identification, registration flow, and implementation principles of related services of the SIP protocol.
Introduction to the SIP Protocol

This topic describes the definition, purpose, and features of the Session Initiation Protocol (SIP).
Definition
SIP is an application protocol for setting up, modifying, and terminating multimedia communication sessions or calls. The multimedia session can be a multimedia meeting, distance learning, or Internet telephony. SIP can be used for initiating sessions or inviting a member to join a session that has been set up otherwise. SIP transparently supports the mapping of names and the redirecting service, which facilitates the implementation of ISDN service, intelligent network, and personal mobile service. Once the session is set up, media streams are directly transmitted at the bearer layer through the Real-time Transport Protocol (RTP). SIP supports the following five features for the multimedia communication: 1. 2. User location: determination of the end system used for the communication User capabilities: determination of the communication media and media parameters to be used
6-54
3. 4. 5.
User availability: determination of the willingness of the called party to join the communication Call setup: establishment of the call parameters of the calling party and called party Call processing: including transfer and termination of calls
SIP is a component of the IETF multimedia data and control architecture. Figure 6-24 shows the structure of the IETF multimedia data and control protocol stack.
Figure 6-24 IETF multimedia data and control protocol stack

H.263 etc. H.323 SIP RTSP RSVP RTCP RTP TCP UDP
IP
PPP
AAL3/4
AAL5
PPP
Sonet
ATM
Ethernet
V.34
SIP can be used with the Resource Reservation Protocol (RSVP) for reserving network resources, with RTP for transporting real-time data and providing the QoS feedback, with the Real-Time Streaming Protocol (RTSP) for controlling the transport of real-time media streams, with the Session Announcement Protocol (SAP) for announcing multimedia sessions through multicast, and with the Session Description Protocol (SDP) for describing multimedia sessions. The functionality and implementation of SIP, however, does not depend on these protocols. SIP can also co-work with other call-establishing protocols and signaling protocols. In this case, an end system can obtain the address and protocol of the peer end through the SIP protocol by a specific address independent of the protocol. For example, through SIP, an end system can learn that the peer end is interoperable through H.323, and the end system can then obtain the H.245 gateway address and user address and set up a call by H.225.0. Or, through SIP, an end system can learn that the peer end is interoperable through PSTN, and SIP can specify the number of the called party and suggests that the call connection be set up through the Internet-to-PSTN gateway. SIP does not provide the conference control services, such as floor control or voting, and does not specify how the conference should be managed. SIP can be used to introduce some other session control protocols for the sessions. SIP does not allocate multicast addresses.
SIP can invite users to join a session that has reserved or unreserved resources. SIP itself does not reserve resources, but it can convey necessary information to the invited party. By using the SIP protocol gateway to realize the interoperability between the Internet and the PSTN/ISDN network, calls can be implemented between the POTS users who are connected through the Internet, and between POTS users and Internet phone users. The SIP protocol gateway interoperable with H.323 can also be designed.
Purpose
SIP will revolutionize the mode of communication service provisioning and the users' habit of communication consumption. An innovating communication mode integrating video phone service, messaging, Web service, e-mail, synchronous browsing, and conference call will be introduced to the telecommunication industry. Adopting SIP as the control layer protocol has the following advantages: 1. Based on an open Internet standard, SIP has inherent benefits in the integration and interoperability of voice and data services. SIP can implement across-media and acrossdevice call control, and supports various media formats. SIP also supports dynamic adding and deleting of media streams, which makes it easier to support richer service features. SIP is intelligently extensible to the service and terminal side, thus reducing the network load and facilitating the provisioning of service. SIP supports mobile functions at the application layer, including the dynamic registering mechanism, location management mechanism, and redirecting mechanism. SIP supports features such as presence, fork, and subscription, which facilitates development of new services. As a simple protocol, SIP has generally acknowledged extensibility.
2. 3. 4. 5.
Protocol Features
SIP is a text-based protocol put forth by IETF for IP phone/multimedia conferencing. It is a light-weight signaling protocol and has the following features: 1. 2. Minimum status: One conference call or phone call can contain one or multiple requests or transactions. The proxy server can work in the stateless mode. Irrelevance with lower layer protocols: SIP has minimum assumption of the lower layer protocols. The lower layer protocols can provide reliable or unreliable services to the SIP protocol layer, which can be packet or byte stream services. On the Internet, the SIP protocol layer can use the UDP or TCP protocol, and UDP is preferred. When UDP is not available, TCP is used. Text-based: SIP adopts the text-based UTF-8 coding format and uses the ISO 10646 character set, which makes it easy to realize programming languages such as Java. This feature brings about merits such as easy commissioning, flexibility, and extensibility. The length of message, however, may also increase. For this reason, the message format is particularly designed so that the SIP messages are easy to parse. Robustness: The robustness of SIP is demonstrated in several facets. For example, the proxy server need not maintain the call status, subsequent requests and re-transmission can adopt different routes, and the response message is transmitted in the self-routing mode. Extensibility: The extensibility of SIP is demonstrated in several ways. Unidentifiable header fields can be ignored, the user can specify the message content that the SIP server
3.
4.
5.
6-56
must understand, new header fields can be introduced easily, and status codes are encoded in the layered coding mode. 6. Readiness to support IN services: Working with the end system, SIP and other call control extended protocols can support most services in Capability Set 1 and Capability Set 2 of ITU-T.

l l
RFC 3262: Reliability Of Provisional Responses in the Session Initiation Protocol (SIP) RFC 3263: SIP Locating SIP Servers
Running Mechanism of the SIP Protocol

This topic describes the user identification, message format, and user registration flow of the SIP protocol.
SIP User Identification

The SIP user ID can be SIP URL or TEL URL, either of which identifies a SIP user uniquely. The user ID configured on the SRG and that on the IMS device must be the same. SIP URL is used in the SIP message, indicating the initiator of request (From), the current destination address (Request-URI), the final receiver (To), and the address of redirection (Contact). SIP URL can also be embedded into the Web page or other hyper links to indicate that a certain user or service can be accessed through SIP. When embedded into a hyper link, SIP URL indicates the INVITE mode. It is presented as follows: SIP-URL="sip:"[ userinfo "@" ]hostport For example: sip:j.doe@big.com sip:+1-212-555-1212:1234@gateway.com;user=phone sip:1212@gateway.com sip:alice@10.1.2.3 sip:alice@example.com sip:alice%40example.com@gateway.com
TEL URL (telephone URI) indicates to occupy the resource of a telephone number. The telephone number can be a global number or a local number. The global number complies with the E164 coding scheme, starting with +. The local number complies with the local proprietary coding scheme. The formats are as follows: tel:+86-755-6544487 tel:45687;phonecontext=example.com tel:45687;phonecontext=+86-755-65
Issue 01 (2009-12-01)
6-57
SIP Message Format

Format The SIP message is encoded in the text format, each line ending with CR or LF. The SIP message has two types: the request message and the response message. The formats are as follows: SIP message = Start-line *Message header field Empty line (CRLF) [Message body] Start-line = Message header = Request line | Status line (General header field| Request header field| Response header field| Entity header field)
Request messages The SRG supports the following SIP request messages: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, PRACK, and UPDATE. Table 6-5 lists the functions of the request messages. Table 6-5 SIP request messages Type of Request Message INVITE ACK OPTIONS BYE CANCEL REGISTER PRACK UPDATE Meaning Invites a user to join a call Acknowledges the response message of the request Requests for the capability information Releases a call that has been set up Releases a call that has not been set up Registers the user location information on the SIP network server Acknowledges a reliable provisional response message Updates the session
Response messages The SIP response messages are used for responding to the SIP request message, indicating whether the call is successful or fails. Different types of response messages can be distinguished by the status code. A status code contains three integers. The first integer defines the type of the response message, and the other two integers further define the details of the response message. Table 6-6 lists the types of response messages.
Table 6-6 SIP response messages 1XX 2XX 3XX 4XX 5XX 6XX Informational Success Redirection Client Error Server Error Global Failure Provisional Final Final Final Final Final
l l l l l
"Provisional" indicates that the call is in process. "Final" is used to terminate the request message. "1xx" indicates that the request message is received and is being processed. "2xx" indicates that the request message is received, processed, and accepted successfully. "3xx" indicates that further actions are required for finishing processing the request message. "4xx" indicates that the request message contains syntax errors or that the SIP server fails to process the request message. "5xx" indicates that the SIP server is faulty and fails to process the request message. "6xx" indicates that the request message cannot be processed by any SIP server.
l l
The SIP protocol requires that the application program must understand the first integer of the response status code, and allows the application program not to process the last two integers of the status code.
User Registration Flow

Before initiating a call, the SIP user must register the user information (such as the domain name IP mapping) on the home network. The registration has two types: the registration through unsafe connection and the registration through safe connection. After the system is powered on or after a user is added, the user registration flow is started. Registration through unsafe connection Figure 6-25 Flowchart of the registration through unsafe connection
SIP AG
IMS Core
Register Response 200
Issue 01 (2009-12-01)
6-59
As shown in Figure 6-25, the SIP AG sends the REGISTER request message to the IMS for each user. The message contains information such as the user ID. After receiving the REGISTER request message, the IMS checks whether the user is already configured on the IMS. If the user is already configured, the IMS responds to the SIP AG with the RESPONSE 200 message. Registration through safe connection Figure 6-26 Flowchart of the registration through safe connection
SIP AG
IMS Core
Register Response 401/407 Register Response 200
As shown in Figure 6-26, the SIP AG sends the REGISTER request message to the IMS for each user. The message contains information such as the user ID. The IMS responds with the RESPONSE 401/407 message, the message containing information such as the key and the encryption mode. The SIP AG encrypts the corresponding user name and password, generates a new REGISTER request message, and sends the message to the IMS. The IMS decrypts the message and verifies the user name and password. If the user name and password are correct, the IMS responds to the SIP AG with the RESPONSE 200 message.
SIP-based VoIP Service

This topic describes the flows of the SIP-based VoIP service.
Call Flow of the Calling Party

Figure 6-27 shows the SIP-based call flow of a VoIP calling party.
6-60
Issue 01 (2009-12-01)
Figure 6-27 SIP-based call flow of a VoIP calling party

USER1 AG Caller offhook dialtone 1st digit P2 Dialtone stopped 2nd digit 3th digit P3 D1:INVITE(SDP) D2:100 Trying P4 P1 P-CSCF-O
D3:180 Ringing 200(callee offhook)
P5 D4:200 OK P6 D5:ACK conversation
l l l
P1: The AG receives the offhook message of the calling party and plays the dial tone to the calling party. P2: The AG receives the first dialed digit, stops playing the dial tone, and starts matching the digit with the digitmaps. P3: After receiving N dialed digits and matching the digits with the digitmaps, the AG finds that the dialed number matches a certain digitmap. Then, the AG generates the INVITE message and sends the message to P-CSCF. P4: The AG receives RESPONSE 100 and is informed that the peer end receives the INVITE message, so the AG stops the INVITE message re-transmitting flow. P5: The AG receives 180, which indicates that the phone of the called party is ringing. Then, the AG plays the ringback tone to the calling party. P6: The AG receives 200, which indicates that the called party answers the phone, so the AG stops playing the ringback tone to the calling party, and changes the stream mode to the bi-directional mode. Then, the AG generates the ACK message and sends the message to P-CSCF.
l l l
The preceding flow is for the call in normal conditions. The scenario may vary. That is, when the calling party initiates a call, P-CSCF determines the situation as follows:
l l
If the calling party is configured but is not registered on P-CSCF, P-CSCF rejects the calling party and responds with 403 to the AG. If the calling party is not configured on P-CSCF, P-CSCF rejects the calling party and responds with 404 to the AG.
Call Flow of the Called Party

Figure 6-28 shows the SIP-based call flow of a VoIP called party. Figure 6-28 SIP-based call flow of a VoIP called party
USER1 AG P-CSCF-T D1:INVITE(SDP) P1 D2:100 Trying ring D3:180 Ringing P2 Callee offhook D4:200 OK D5:ACK
P3 conversation
P1: The AG receives the INVITE message from P-CSCF, generates the RESPONSE 100 message, and sends the message to P-CSCF. According to the P-Called-Party-ID header field, RequestURI, and TO header field that are contained in the INVITE message, the AG locates the called party. If the user is identified by TEL URI, the AG can locate the called party through the telephone number contained in TEL URI instead of through the header fields. After locating the called party, the AG plays the ringing tone to the called party, generates the RESPONSE 180 message, and sends the message to P-CSCF, informing PCSCF that the phone of the called party is ringing. P2: After receiving the offhook message of the called party, the AG stops playing the ringing, generates the 200 message, and sends the message to P-CSCF, informing P-CSCF that the called party answers the phone. P3: The AG receives the ACK message. Then, the calling party and called party are engaged in the conversation.
The scenario may vary. That is, the AG receives the INVITE message and determines the situation as follows:

l
If the called party is configured but is not registered on the AG, the AG rejects the calling party and responds with 403 to P-CSCF. If the called party is not configured on the AG, the AG rejects the calling party and responds with 404 to P-CSCF.
Flow of Call Release

Figure 6-29 shows the flow of call release. Figure 6-29 Flow of call release
USER1 onhook P1 D1:BYE D2:200 OK P2 AG conversation P-CSCF-O
P1: The AG receives the onhook message of the user, generates the BYE request message, and sends the message to P-CSCF. Then, the AG releases the DSP resource that is allocated to the user for the call. P2: The AG receives the 200 message from P-CSCF.
SIP-Based FoIP
This topic describes the implementation mechanism of the SIP-based FoIP service. In terms of transmission protocol, the fax service can be classified into transparent transmission and T.38; in terms of switching mode, the fax service can be classified into auto-switching and negotiated-switching. Hence, there are four combinations of the fax mode: auto-switching transparent transmission, auto-switching T.38, negotiated-switching transparent transmission, and negotiated-switching T.38. The working principle of auto-switching is that the AG detects the fax tone, and then selects the transparent transmission or T.38 mode according to the configuration. In this case, the AG need not send any signaling to the peer device. The working principle of negotiated-switching is that the AG detects the fax tone, and according to the configuration sends the peer end the re-INVITE message that contains the negotiation parameters for negotiating the fax mode. In actual application, fax can also be classified into low-speed fax and high-speed fax in terms of transmission speed. The high-speed fax cannot adopt the T.38 mode. A high-speed fax
machine can actually be regarded as a modem. With the speed reduced, a high-speed fax machine can also adopt the T.38 mode.
Flow of the Negotiated-Switching Transparent Transmission Fax

Currently, this fax mode can be presented in three ways.
l
Presented as a=fax. This is a G.711 transparent transmission fax mode proposed by China Telecom. Presented as a=silenceSupp:off. This is a G.711 transparent transmission fax mode defined in the draft-IETF-sipping-realtimefax-01.txt. Presented as a=gpmd:99 vbd=yes. This is a VBD mode defined in the ITU-T V.152.
Which method to be applied depends on the parameters configured. Figure 6-30 shows the fax flow. Figure 6-30 Flow of the negotiated-switching transparent transmission fax
Other elements are omitted USER1 AG-O P-CSCF-O P-CSCF-T AG-T USER2 Call established FAX tone re-INVITE (SDP VBD) 200 OK (SDP VBD) FAX pass-through re-INVITE (SDP VBD) P1 L1
P2
re-INVITE (SDP VBD) 200 OK (SDP VBD)
200 OK (SDP VBD)
P3 FAX END
re-INVITE (SDP audio) P5 200 OK (SDP audio)
re-INVITE (SDP audio) 200 OK (SDP audio) VOICE
re-INVITE (SDP audio)
P4 L1
200 OK (SDP audio) P6
P1: AG-T first detects the fax tone, and then sends the re-INVITE message to the AG (AGO) to which the calling party is connected. L1: The SDP message contained in the re-INVITE message has three types. The specific fax mode must be configured on the AGs. The initiator of negotiation uses the a parameter of different values, and the recipient of negotiation needs to be compatible with the three parameter values. This means that when the recipient receives the re-INVITE message, the recipient should be able to complete the negotiation process with the initiator regardless of the a parameter value.
6-64
The G.711 transparent transmission fax/modem mode defined in the draft-IETFsipping-realtimefax-01.txt. The G.711 transparent transmission fax/modem mode proposed by China Telecom. The VBD mode defined in the ITU-T V.152.
P2: AG-O receives the re-INVITE message. Then, AG-O generates the 200 OK message and sends the message to AG-T. P3: AG-T receives the 200 OK message, and also enables the DSP channel in the fax mode. P4: AG-T receives the fax end signal, and sends the re-INVITE message to AG-O. L2: The SDP message contained in the re-INVITE message is for setting up a common voice channel. P5: AG-O receives the re-INVITE message and switches the DSP channel to the voice mode. P6: AG-T receives the 200 OK message, and also switches the DSP channel to the voice mode.
l l l
Flow of the Negotiated-Switching T.38 Fax

Figure 6-31 shows the flow of the negotiated-switching T.38 fax. Figure 6-31 Flow of the negotiated-switching T.38 fax
USER1 AG-O P-CSCF-O Other elements are omitted P-CSCF-T Call established FAX tone re-INVITE (SDP T38) 200 OK (SDP T38) FAX T38 re-INVITE (SDP T38) P1 L1 AG-T USER2
P2
re-INVITE (SDP T38) 200 OK (SDP T38)
200 OK (SDP T38)
P3 FAX END
re-INVITE (SDP audio) 200 OK (SDP audio) VOICE
re-INVITE (SDP audio)
P4 L2
200 OK (SDP audio)
P6
Issue 01 (2009-12-01)
6-65
l
P1: AG-T first detects the fax tone, and then sends the re-INVITE message to the AG (AGO) to which the calling party is connected. L1: The SDP message contained in the re-INVITE message carries the T.38 information. P2: AG-O receives the re-INVITE message, learns that the peer device requires the T.38 mode, and enables the DSP channel in the T.38 mode. Then, AG-O generates the 200 message and sends the message to AG-T. P3: AG-T receives the 200 OK message, and also enables the DSP channel in the T.38 mode. P4: AG-T receives the fax end signal, and sends the re-INVITE message to AG-O. L2: The SDP message contained in the re-INVITE message is for setting up a common voice channel. P5: AG-O receives the re-INVITE message and switches the DSP channel to the voice mode. P6: AG-T receives the 200 OK message, and also switches the DSP channel to the voice mode.
NOTE
l l
l l
Figure 6-32 and Figure 6-33 shows the fax flows when the peer device does not support the T.38 mode.
Figure 6-32 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 1)
Other elements are omitted USER1 AG-O P-CSCF-O P-CSCF-T AG-T USER2 Call established FAX tone re-INVITE (SDP T38) re-INVITE (SDP T38) P1 L1
P2
re-INVITE (SDP T38) 415 Unsupported Media Type
415 Unsupported Media Type BYE
BYE P5 Busy tone
P3 415 Unsupported Media Type P4 L2 Busy tone BYE
200 OK
200 OK
200 OK P6
6-66
Issue 01 (2009-12-01)
Figure 6-33 Flow of the negotiated-switching T.38 fax when the peer device does not support the T.38 mode (scenario 2)
Other elements are omitted USER1 AG-O P-CSCF-O P-CSCF-T AG-T USER2 Call established FAX tone re-INVITE (SDP T38) re-INVITE (SDP T38) P1 L1
P2
re-INVITE (SDP T38) 488 Not Acceptable Here or 606
488 Not Acceptable Here or 606 re-INVITE ((SDP VBD) 200 OK (SDP VBD)
488 Not Acceptable Here or 606 P3 re-INVITE (SDP VBD) P4 L2
P5
re-INVITE (SDP VBD) 200 OK (SDP VBD)
200 OK (SDP VBD)
P6
FAX pass-through FAX END re-INVITE (SDP audio) 200 OK (SDP audio) VOICE re-INVITE (SDP audio) P7 L3
200 OK (SDP audio) P9
In scenario 1, if AG-O does not support T.38, it may respond with 415 Unsupported Media Type. After AG-T receives the 415 response, AG-T sends the BYE message and releases the current call. In scenario 2, if AG-O does not support T.38, it responds with 488 Not Acceptable Here or 606 Not Acceptable. After AG-T receives the 488/606 response, AG-T generates another reINVITE message. The SDP message in this message contains the VBD media type. Thus, the negotiation on the T.38 mode fails, and the transparent transmission mode is adopted. The MA5616 supports the T.38 mode, and therefore does not respond with the 415/488/606 message in the T.38 negotiation. The MA5616, however, can process such error codes sent by the peer device.
Issue 01 (2009-12-01)
6-67
Flow of the Auto-Switching Transparent Transmission Fax

Generally, the called fax terminal detects the fax tone on the TDM side first, and the calling fax terminal detects the fax tone sent from the IP side. The fax terminal that detects the fax tone automatically switches to the transparent transmission mode without the SIP negotiation. One problem currently exists in the auto-switching fax flow: If the DSP channel originally works in the G.729 mode for the voice service, and is now switched to the G.711 transparent transmission mode when the fax tone is detected, the G.711 voice packet may not be recognized. This is because the DSP channel of the calling party stills works in the G.729 mode. Therefore, the DSP chip is required to be able to receive G.711 packets when working in the G.729 or other coding modes. The prerequisite remains that the DSP chip should detect and report the fax tone sent from the IP side.
Flow of the Auto-Switching T.38 Fax

The working principle of this fax flow is the same as the working principle of the auto-switching transparent transmission fax. The difference is that, after the fax tone is detected, the DSP channel is enabled in the T.38 mode instead of the transparent transmission mode.
SIP-Based MoIP
This topic describes the SIP-based modem service flow. In terms of service flow, the modem service is similar to the transparent transmission fax service, and can also be classified as auto-switching and negotiated-switching. The modem service in the negotiated-switching transparent transmission mode can be presented in three ways.
l
Presented as a=modem. This is a G.711 transparent transmission modem mode proposed by China Telecom. Presented as a=silenceSupp:off. This is a G.711 transparent transmission modem mode defined in the draft-IETF-sipping-realtimefax-01.txt. Presented as a=gpmd:99 vbd=yes. This is a VBD mode defined in the ITU-T V.152.
The method actually applied depends on the parameters configured.
Flow of the Negotiated-Switching Modem Service

Figure 6-34 shows the flow of the negotiated-switching modem service.
6-68
Issue 01 (2009-12-01)
Figure 6-34 Flow of the negotiated-switching modem service

Other elements are omitted USER1 AG-O P-CSCF-O Call established P-CSCF-T AG-T USER2
P1 re-INVITE re-INVITE P2 200 OK 200 OK Modem pass-through re-INVITE L1
Modem tone
200 OK P3
P1: AG-T first detects the modem tone, and then sends the re-INVITE message to the AG (AG-O) to which the calling party is connected. L1: The SDP message contained in the re-INVITE message has three types, corresponding to the three preceding presentations of the negotiated-switching transparent transmission mode. The specific transparent transmission modem mode must be configured on the AGs. P2: AG-O receives the re-INVITE message. Then, AG-O generates the 200 message and sends the message to AG-T. P3: AG-T receives the 200 OK message, and also enables the DSP channel in the fax or modem mode.
Auto-Switching Modem Mode

In this mode, after the AG detects the modem tone, the AG automatically switches the DSP channel to the VBD mode without notifying the IMS or the peer device. Generally, the called modem detects the modem tone on the TDM side first, and the calling modem detects the modem tone sent from the IP side. The modem that detects the modem tone automatically switches to the VBD mode without the SIP negotiation.
Modem Redundancy Transmission

The modem redundancy transmission is currently implemented through RFC2198. The DSP chip on Huawei device already supports the modem service using RFC2198. Only one redundancy packet is supported, however.
6.14.5 Key Voice Feature

This topic provides the overview of key voice features and then describes working principles of each sub feature in detail.
Introduction
This topic describes key voice features supported by the DSP chip. These features are applicable to all voice protocols.
Definition
Key voice features are a series of technologies adopted to deliver high-quality voice services. Examples of these technologies are the voice codec, Echo Canceller (EC), and Voice Activity Detection (VAD).
Purpose
The purpose is to deliver high-quality voice services.
Codec and Packetization Duration

This topic provides the basic information about the codec and packetization duration (PTime).
Introduction
Codec is a key technology of voice services. Coding means that the DSP encodes the TDMbased voice data, assembles the data into packets, and then sends the packets to the IP network. Decoding means that the DSP decodes the voice packets received from the IP network and plays the voice to the TDM side. Frequently-used codec types are G.711A, G.711Mu, G.729, G.723.1Low, and G.723.1High. G. 711A and G.711Mu are lossless coding schemes. G.729, G.723.1Low, and G.723.1High are lossy compressed coding schemes. The compressed coding schemes require less bandwidth, but the voice quality is poor and the delay is large. (G.711 delivers the best voice quality but requires a bandwidth of 64 kbps. G.723 requires less bandwidth but the voice quality is less satisfying.) PTime is the interval at which the DSP assembles the voice data into packets. It varies according to the codec type. Table 6-7 lists the codec types. Table 6-7 Codec list Codec Type G.711A/Mu G.729a G.723.1High G.723.1Low Coding Rate (kbit/s) 64 8 6.3 5.3 PTime and Packet Size (including the RTP header, UDP header, IP header, and Ethernet header) 20 ms, 214 bytes 20 ms, 74 bytes 30 ms, 78 bytes 30 ms, 74 bytes
Specifications
The 16-line G.711A, G.711Mu, and 16-line G.729a are supported. G.723.1 is not supported.

ITU-T G0.711, ITU-T G0.729, and ITU-T G0.723
Echo Canceller
This topic provides the basic information about the Echo Canceller (EC).
Introduction
Echo is classified into the acoustic echo and electrical echo.
l
Acoustic echo Acoustic echo refers to the echo reflected by an obstacle when the voice encounters the obstacle in the transmission path. For example, if you place the phone at one side and speak at the other side, you can hear your own voice. This is because the voice is transmitted through the table and reflected from the collector to the receiver of the phone. Currently, the VoIP DSP chip does not support cancellation of the acoustic echo because it cannot distinguish the normal voice from the acoustic echo.
Electrical echo Electrical echo is generated by the 2-wire/4-wire converter on the service board, because the impedance matching is not ideal on the 2-wire/4-wire converter. EC generally refers to the cancellation of the electrical echo.
Figure 6-35 shows how the electrical echo is generated. Figure 6-35 Generation of the electrical echo
4-wire transmission network
Hybrid
2-wire subscriber line
echo
In the PSTN network, owing to the small delay, the voice and the echo reach the ears of the speaker almost at the same time. Thus, the echo can hardly be perceived. In the VoIP network,
owing to the large delay, the echo reaches the ears some time after the voice is heard. Thus, the echo can be easily perceived. As described in ITU-T G.131 and ITU-T G.161, the echo can be perceived when the echo delay exceeds 25 ms. Figure 6-36 shows how the EC is implemented. Figure 6-36 Implementation of the EC function
EC
Rin
Rout
Filter
2/4-wire conversion G +
g +
Rout
Sin
Rin is the voice received from the remote end. Rin is the input of the wave filter and the output of the wave filter is the simulated echo g. Rin is converted into the echo G on the 2-wire/4-wire converter. S is the local-end voice, that is, the voice received by the local receiver. The localend voice S is overlaid with the echo G, resulting in the input signal of the EC, Sin. The EC removes the simulated echo g from the input signal Sin to obtain the output signal Sout. Sin = S + G Sout = Sin - g = S + G - g Gg Therefore, Sout S
Specifications
Enabling or disabling the EC and the 64-ms tail delay are supported.

Non-Linear Processor
This topic describes the basic principles of the Non-Linear Processor (NLP).
Introduction
Owing to various reasons, the EC cannot cancel all the echoes. To improve the EC performance, a non-linear processing is performed on the remaining echoes when the power of the remaining echoes is lower than a preset value. This can further reduce the power of the remaining echoes. A simple method is to replace the remaining echoes with the silence when the power of the remaining echoes is lower than the threshold.
Specifications
Enabling or disabling the NLP (user-port based) is supported.
Impact
The NLP function must be disabled in the case of FoIP or MoIP.

VAD
This topic describes the basic principles of the voice activity detector (VAD).
Introduction
The VAD is used to reduce the consumption of the network bandwidth. Input signals of phones are classified into the voice signals and the silence signals. The VAD is used to distinguish the voice signals from the silence signals based on the energy of the signals. The VAD is often used together with the silence compression. For example, after the VAD is enabled, the DSP sends the RTP packets to the remote end when it detects the voice. The DSP does not send the RTP packets to the IP network when it detects the silence. The DSP sends a silence ID (SID) to the remote end only when the background noise changes. Based on the received SID, the remote DSP generates the background noise, thus saving the network bandwidth when the silence signals are transmitted. In a conversation, only 40% of signals are valid voice signals. Therefore, enabling the VAD can substantially reduce the consumption of the network bandwidth when the network resources are insufficient.
Specifications
Enabling or disabling the VAD is supported. Sending and receiving the SID packets are supported.

ITU-T G.711 and ITU-T G.729
Packet Loss Concealment

This topic describes the basic principles of the Packet Loss Concealment (PLC).
Introduction
When a network or a device loses packets, the voice quality deteriorates. In practice, packet loss is inevitable. If the PLC is enabled to compensate the signals, however, the impact of packet loss on the voice quality is reduced and the success rates of FoIP and MoIP services increases in the case of packet loss. Three compensation modes are available:
l l l
Compensate the lost packet with the silence. Compensate the lost packet with the previous packet. Compensate the lost packet with a similar packet that is calculated based on the energies of the previous packet and the subsequent packet (as described in G.711 Appendix I).
The third mode consumes the most DSP resources, but improves the voice quality in the most satisfying manner. The first mode consumes the least DSP resources, but improves the voice quality in the least satisfying manner.
Specifications
Enabling and disabling the PLC and configuration of the compensation mode described in G. 711 Appendix I are supported. By default, the mode of compensating the lost packet with the previous packet is adopted.

G.711 Appendix I
Jitter Buffer
This topic describes the basic principles of the jitter buffer (JB).
Introduction
The transmission quality on the IP network is not guaranteed. The interval at which packets are received from the remote end is not even, and the sequence of packets received may be different from the sequence that these packets are sent. As a result, the voice quality is degraded. Therefore, the JB is introduced to eliminate the jitter of the IP network. The basic idea of JB is to restore the sequence of packets by increasing the delay and reduce the packet loss rate. The JB is classified into the dynamic JB and the static JB. During a conversation, it is possible that the network jitter is not serious or even does not occur in a period of time and is serious in another period of time. The dynamic JB can adjust the depth of the buffer based on the severity of the network jitter. In this way, when the jitter is not serious, the introduced delay is also small. When the jitter is serious, a sufficient buffer depth is available to eliminate the jitter. The static JB must be adopted for data services such as the FoIP and MoIP, because adjustment of the JB may cause packet loss and packet loss has a great impact on data services.
Specifications
The dynamic JB and the static JB are supported. The adjustable range of the JB depth is 0 ms to 200 ms.

None
Dual Tone Multi Frequency

This topic describes the basic principles of dual tone multi frequency (DTMF).
Introduction
DTMF means that the tones of two frequencies are overlaid to represent a number, as shown in Table 6-8. Table 6-8 Mapping between frequencies and numbers Unit: Hz 697 770 852 941 1209 1 4 7 * 1336 2 5 8 0 1477 3 6 9 # 1633 A B C D
When numbers are dialed on the phone, the dialed numbers are converted into the dual-frequency overlay tones. The DSP detects the dialed numbers by checking the DTMF. The supported DTMF-specific functions are as follows:
l
DTMF erasure: After the DSP detects DTMF signals, it erases the DTMF signals from the RTP media stream. DTMF transparent transmission: After the DSP detects DTMF signals, it retains the DTMF signals in the RTP media stream. DTMF RFC2833 transmission: After the DSP detects DTMF signals, it erases the DTMF signals from the RTP media stream and sends the DTMF information in RFC2833 transmission mode.
Specifications
Detection and sending of the DTMF signals is supported. Configuration of DTMF-specific functions (device-based) is supported.

ITU-T Q.24
Tone Playing
This topic describes the basic principles of tone playing.
Introduction
Tone files are stored on the flash memory of the control board. The file name is generally voice.efs. The tone file contains the description about the tone types supported by the DSP. The description covers the information such as the signal tone type, frequency, duration, and strength. After the system initiation is complete, the tone playing parameters are configured on the DSP. When requested to play the tone for a subscriber, the DSP reads the configuration and generates the signal tone that should be played to the subscriber on a real-time basis. Tone files are classified into the parameter tone, waveform tone, and announcement. The parameter tone is a type of simple tones, such as the dialing tone, busy tone, and ringback tone. The information about the frequency, energy, duration, and beat of the parameter tone are sent to the DSP and then the DSP generates the parameter tone accordingly. The waveform tone is a type of simple tones, such as the dialing tone, busy tone, and ringback tone. These tones are recorded, converted into the PCM data, and stored in the logic. The logic cyclically plays the data of a type of tones on a TDM timeslot. When a tone should be played to a subscriber, the timeslot mapping the subscriber is connected to the timeslot , on which the logic plays the tone. The parameter tone takes precedence over the waveform tone. The waveform tone is used only when the DSP is faulty or when the DSP resources are not available. The announcement is a type of messages played to subscribers, such as "The subscriber you dialed is busy. Please call later". The message to be played is recorded and stored on the DSP. When an announcement should be played to a subscriber, the logic or the DSP plays the recorded announcement to the subscriber.
Specifications
l l l
Playing of parameter tones, waveform tones, and announcements is supported. Storage of 1-MB announcement data on the DSP is supported. Simultaneous playing of announcements for 16 subscribers is supported.
Voice Quality Enhancement

This topic describes the basic principles of the voice quality enhancement (VQE).
Introduction
The VQE feature is applicable to voice services in the noisy public areas, such as the roads, docks, scenic spots, and bus stations. Deployment of VQE in these areas can improve the voice quality, user experience, and competitiveness of the products. The VQE consists of two functions, automatic gain control (AGC) and spectral noise suppression (SNS). AGC refers to the automatic adjustment of the output gain based on the preset target value of the gain during the VoIP communication process. In this way, listeners are free from the discomfort causes by the sudden change in the background noise. AGC provides smooth adjustment of the energy and prevents the sudden change in the output energy. SNS refers to the reduction of the energy of the background noise based on the preset target value of background noise suppression through the background noise detection during the VoIP communication process. With the SNS function, listeners feel more comfortable with the conversation and the conversion is better understandable.
Specifications
At present, only the AGC function is supported. The VQE feature is based on the configuration of the user port. After the parameter configuration is complete, the configuration takes effect on the next call. At present, the VQE function takes effect only when the G.711 codec is used. It does not takes effect when other codecs, such as G.729 and G.723, are used. If the VQE function is configured when a codec other than G.711 is used, the configuration does not take effect and the prompt is not given.
RFC2833 Encryption
This topic describes the background information and basic principles of the RFC2833 encryption.
Background
On the NGN network, the voice and DTMF signals are encapsulated as the IP packets before they are sent over the IP network. The DTMF signals are sent in the RTP packets of the voice in two modes:
l
The DTMF signals are sent as the RTP media stream on the NGN network. That is, the sending media gateway (MG) measures the frequencies of the DTMF signals and sends the measurement result to the receiving MG through RTP packets. In this transmission mode, the receiving MG processes the DTMF signals as the voice signals. If the voice signals are damaged, the receiving MG cannot detect the DTMF signals in the media stream. Therefore, this DTMF transmission mode is not recommended when the network quality is poor or when the compressed codecs (such as G.723.1 and G.729) are used. The DTMF signals are sent in RFC2833 mode on the NGN network. In this case, the sending MG must be equipped with the digital signal processor and the related algorithm, so that it can detect the DTMF signals, translate the data into the number, and send the number through the RFC2833 packets. The receiving MG identifies the DTMF signals in the RFC2833 packets and performs further processing.
Regardless of the transmission mode, the DTMF signals are sent in plain text over the IP network. Owing to the openness of the IP network, it is easy for network hackers to intercept the IP packets and analyze the IP packets to obtain the voice and DTMF information carried by the IP packets. For example, the customer information is contained in the DTMF signals during the telephone banking service. If the DTMF packets in the two-stage dialing are sent without being encrypted, it is easy for hackers to intercept the customer information of the bank. The leakage of the customer information is devastating for banks.
Introduction to the RFC2833 Standard

RFC2833 specifies the methods for transmitting the DTMF signals, other telephony tones, and telephony signals through the RTP packets. When the DTMF signals are sent in RFC2833 mode, the MG identifies the DTMF signals, translates them into the corresponding numbers, assembles the number into RFC2833 packets, and then sends the packets to the receiving end. The receiving end restores the DTMF signals based on the numbers in the RFC2833 packets.
Implementation of RFC2833 Encryption

The RFC2833 encryption function of the MG is configured on the softswitch. The softswitch sends the key to the sending and receiving MGs and the two MGs send the key to the DSP. The DSP on the sending MG detects the DTMF signals, erases the DTMF signals from the media stream, assembles the DTMF signals in the RFC2833 packets, and encrypts the RFC2833 packets based on the key sent by the softswitch. The DSP on the receiving MG decrypts the RFC2833 packets based on the key sent by the softswitch, obtains the DTMF information, and restores the DTMF signals. The Huawei proprietary algorithm, NGN Cipher Version 1 (HNC1), is adopted. It supports the 128-bit to 256-bit key. The dynamic key mechanism ensures the security of the key. The key is controlled by the softswitch, updated dynamically at each call, encrypted and sent through the SDP packets in compliance with the H.248/MGCP protocol. With the RFC2833 encryption function, the transmission security of the DTMF information is ensured. This encryption function is implemented jointly by the MA5600T and the Huawei MSOFTX3000.

RFC2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
6.14.6 Voice Reliability

This topic describes features related to voice reliability, including dual homing networking, highly reliable transmission (SCTP), and voice QoS.
Introduction
This topic describes features related to the voice reliability.
Definition
Features related to voice reliability include dual homing networking, highly reliable transmission, and voice QoS.
Purpose
The purpose is to ensure the high reliability of the SRG voice service.
H.248 Dual Homing

This topic describes working principles of dual homing from the MG to the softswitch through H.248. Dual homing is an NGN total solution. Based on this solution, when the active softswitch or the link from the MG to the active softswitch is faulty, the MG need be switched to the standby softswitch immediately to prevent call services of users connected to the softswitch and the MG from being affected. Dual homing requires that one MG is configured with two softswitches, one active and one standby. The connection between the MG and the softswitch is detected through the heartbeat message.
Figure 6-37 illustrates the working principles of dual homing. Figure 6-37 Working principles of dual homing
Active softswitch MG Standby softswitch Loses communication with active softswitch Register
Reply with success Heartbeat Heartbeat

Reply Resumes communication with active softswitch Deregister Register
Reply with success
Reply with success
MG_1 registers with both MGC_1 and MGC_2. When MGC_1 fails, MG_1 can automatically switch to MGC_2. Different carriers may choose the following different dual homing policies:
l
auto-switching When the original active softswitch recovers, the MG automatically switches to the original active softswitch.
no auto-switching The MG does not support the auto-switching. Regardless of whether the MG registers with the active softswitch or the standby softswitch, if the softswitch with which the MG registers is normal, the MG works with this softswitch all along. The SRG can support the preceding two policies through related configuration.
NOTE
By default, the SRG supports the no auto-switching policy.
Dual-Homing with no Auto-Switching

Figure 6-38 shows the operating principle for implementing the dual-homing with no autoswitching.
Issue 01 (2009-12-01)
6-79
Figure 6-38 Operating principle for implementing the dual-homing with no auto-switching
Active MGC 1 MG Disconnect from the active MGC Register Registration message Reply with success Heartbeat Registration message . . . Reply Standby MGC 2
Register with the active MGC Quit from the service Reply with success
The basic process of the dual-homing with no auto-switching is as follows: 1. 2. 3. If the MG sends N consecutive heartbeat detection messages (Notify (it/ito)) to its primary MGC (MGC 1), but gets no response, it indicates that MGC 1 fails. The MG sends the registration message ServiceChange (Method = Failover, Reason = 909 (neighboring MGC fault)) to the preset secondary MGC (MGC 2). If the MG receives the response message (Reply) from MGC 2, it indicates that the MG has registered with MGC 2 successfully and the process is complete. If the MG sends N consecutive ServiceChange messages to MGC 2 but gets no response, it indicates that the MG fails to register with MGC 2. If the registration with MGC 2 fails, the MG sends the registration message ServiceChange (Method = Disconnected, Reason = 909 (neighboring MGC fault)) to the original primary MGC (MGC 1). If the MG receives the response message (Reply) from MGC 1, it indicates that the communication between the MG and MGC 1 recovers and the process is complete. If the MG sends N consecutive ServiceChange messages to MGC 1 but gets no response, it indicates that the registration with MGC 1 fails and the MG returns to step 2.
4.
5.
Dual-Homing with Auto-Switching

Figure 6-39 shows the operating principle for implementing the dual-homing with autoswitching.
6-80
Issue 01 (2009-12-01)
Figure 6-39 Operating principle for implementing the dual-homing with auto-switching
MG (1)Notify(it/ito) Lost Heartbeat (2)ServiceChange(Metho d=Failover,Reason=909) (3)Reply Register Successful Register Failure (4)ServiceChange(Method= Disconnected,Reason=909) (5)Reply MGC1 ctpd/dtone MGC2
The basic process of the dual-homing with auto-switching is as follows: 1. 2. 3. The MG, through the heartbeat message, detects that the communication with the primary MGC 1 is interrupted. The MG registers with the secondary MGC 2. Meanwhile, the MG sends the registration message to the primary MGC 1 at intervals. If the MG receives the response, it indicates that the communication with the primary MGC 1 recovers and the MG goes to step 4. If the MG fails to receive the response, it continues sending the message. In the meantime, service can be set up on the secondary MGC 2. If the MG receives the registration response from the primary MGC 1, it indicates that the MG 1 has been registered with the primary MGC 1 . In this case, the MG sends a message to the secondary MGC 2 for quitting the service and waits for a response from the secondary MGC 2 .
4.
SIP Dual Homing

This topic describes the working principles of SIP dual homing. Figure 6-40 shows the networking of SIP dual homing.
Issue 01 (2009-12-01)
6-81
Figure 6-40 Call releasing flow
Server 1
Server 2
IP Core Network
The working flow of SIP dual homing is similar to the working flow of H.248 dual homing. The SRG detects the proxy server in real time. When the primary proxy server is faulty, services can be switched to the secondary proxy server. Before the switching, the call can be released. After the switching, the call can be initiated.
Voice QoS
This topic describes the implementation mechanism of the voice QoS, mainly the priority identification. The voice service requires high real-time performance, low delay, and fast call connection. Therefore, the voice packets should be forwarded with a high priority. The router, however, forwards the packets based on the VLAN priority (complying with 802.1p) and DSCP/ToS set in the packets.
6-82
SI P
NS IO PT :O SI P
:O PT IO NS
SRG
Issue 01 (2009-12-01)
802.1p Priority (Separately Set for Signaling and Media Streams)

Figure 6-41 802.1q frame format
Destnatio n Address 802.1Q header Length/Ty T pe P TCI I D 4 bytes 2 bytes
Source Address
Data
FCS (CRC-32)
6 bytes
6 bytes
46-1517 bytes
4 bytes
Byte 1
Byte 2
Byte 3
Byte 4
TPID(Tag Protocol Identifier)
TCI (Tag Control Information)

C F i
1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 Priority
VLAN ID
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Figure 6-41 shows the Ethernet frame format defined in 802.1q. The four-byte 802.1q header contains the following contents:
l l
Tag protocol identifier (TPID): Two-byte tag protocol identifier, with the value of 8100. Tag control information (TCI): Two-byte tag control information. It is a new type of information defined by IEEE, indicating a text added with the 802.1q label. The TCI is divided into the following three fields:
VLAN identifier (VLAN ID): 12-bit, indicating the VLAN ID. Up to 4096 VLANs are supported. All the data packets transmitted from the host that supports 802.1q contain this field, indicating the VLAN to which the data packets belong. Canonical format indicator (cfi): one-bit. It is used in the frame for data exchange between the Ethernet network of the bus type and the FDDI or token ring network. Priority: three-bit, indicating the priority of the frame. Up to eight priorities are supported. It determines the data packet to be transmitted first in case of switch congestion.
The local media IP address and signaling IP address of the SRG can be configured in one VLAN or different VLANs according to the networking requirements. The 802.1p priorities (in the range of 0-7) can be set for the media IP address and signaling IP address respectively. By default, the priority for either the media IP address or the signaling IP address is 6.
DSCP/TOS
As defined in the IP protocol, the DSCP and ToS occupy the same field (one-byte) in the IP header. The device on the IP bearer network identifies whether DSCP or ToS is filled in the IP
header, and schedules and forwards the packets with the DSCP/ToS field according to the settings to ensure the QoS for different services. The type of service (ToS) field contains a three-bit precedence subfield (ignored currently), a four-bit ToS sub field, and one reserved bit (it must be set to 0). The four bits in the ToS sub field represent the minimum delay, maximum throughput, maximum reliability, and minimum cost respectively. Only one of the four bits can be set. If all four bits are set to 0, it indicates the common service. The DSCP identification is based on the IPv4 ToS and the IPv6 traffic class. As shown in Figure 6-42, the first six bits in the DS field (bits 0-5) are used to differentiate the DS codepoints (DSCPs) and the last two bits (bits 6 and 7) are reserved. The first three bits in the DS field (bits 0-2) are the class selector codepoint (CSCP), which indicates a class of DSCP. Figure 6-42 DSCP identification format
DS Field
0 1 2 3 4 5 6 7 0 1 2
IPv4 TOS
3 4 5 6 7
DSCP
unused
0
Precedence ToS
CSCP
DSCP is used to select the corresponding per-hop behavior (PHB) on all the nodes of the network. The PHB describes the external visible behaviors when the DS node functions on the data stream aggregation. Currently, IETF defines three types of PHB: expedited forwarding (EF), assured forwarding (AF), and best-effort. For example,
l l l
BE: DSCP = 000000 EF: DSCP = 101110 The AF codepoints are as follows: Low Discard Priority, j = 1 AF (i = 4) AF (i = 3) AF (i = 2) AF (i = 1) 100010 011010 010010 001010 Middle Discard Priority, j = 2 100100 011100 010100 001100 High Discard Priority, j = 3 100110 011110 010110 001110
The first three bits (bits 0-2) for one type of AFs are the same. To be specific, the first three bits of AF1 are 001, AF2 010, AF3 011, and AF4 100. Bits 3-4 represent the discard priority, namely, 01, 10, and 11. The larger the value, the higher the discard priority.
The DSCP/ToS value of local media IP packet and signaling IP packet can be configured on the SRG respectively. First the configuration policy (DSCP or ToS) is selected, and then the corresponding value is set. By default, DSCP is selected on the SRG, with the value of 56 (EF with the highest priority).
Issue 01 (2009-12-01)
6-85
7 Reliability
7
About This Chapter
7.1 Overview of VRRP 7.2 Introduction to Dual-System Hot Backup 7.4 IP-Link Auto-detection Overview
Reliability
7.3 Relations Between the VRRP Backup Group, Management Group, and HRP
Issue 01 (2009-12-01)
7-1
7 Reliability
7.1 Overview of VRRP

7.1.1 Traditional VRRP 7.1.2 Disadvantages of Traditional VRRP in Eudemon Backup Security zones are introduced in the Eudemon. Two Eudemons can implement a route redundancy backup. One serves as the primary Eudemon and the other the secondary Eudemon. Interfaces on the primary and secondary Eudemons are associated with corresponding security zones.
7.1.1 Traditional VRRP

Usually, each host on an intranet is configured with a default route to the next hop that is to the IP address of the egress router, that is, 10.100.10.1/24, as shown in Figure 7-1. Figure 7-1 Networking using the default route
PC 10.100.10.1/24
Server 10.100.10.0/24
Router
The interactive packets between intranet users and Internet users all pass the router. When the router fails, all hosts (whose next hops are the router by default) on the intranet fail to communicate with the Internet. In this case, communication is unreliable in default route mode. The Virtual Router Redundancy Protocol (VRRP) can solve such a problem. As a fault tolerant protocol, VRRP is applicable to a LAN that supports multicast or broadcast, such as Ethernet. VRRP organizes several routers on a LAN into a virtual router, named a backup group. In a backup group, only one device is in active state, which is named Primary. Others are in standby state and are ready to take over the tasks at any time based on the priority, and these inactive devices are named Secondary. Figure 7-2 shows a backup group comprising of three routers.
7-2
Issue 01 (2009-12-01)
7 Reliability
Figure 7-2 Networking of using the VRRP virtual router

Primary 10.100.10.2/24 PC Secondary 10.100.10.3/24 Router B Router A
Server Secondary 10.100.10.0/24 Backup group Virtual IP address 10.100.10.4/24 Router C 10.100.10.1/24
As shown in Figure 7-2:

l
Routers A, B, and C make up a backup group (serves as a virtual router), whose virtual IP address is 10.100.10.1. Router A is the Primary with the IP address 10.100.10.2. Routers B and C are Secondary with IP addresses 10.100.10.3 and 10.100.10.4 respectively. In VRRP, only the active router can forward the packet that takes the virtual IP address as the next hop.
l l l
All hosts on the intranet are aware of the virtual IP address 10.100.10.1, instead of the IP address of the Primary or Secondary. Therefore, the default route of each host is configured to the virtual IP address. Thus, all hosts on the intranet can communicate with the Internet through this backup group. The VRRP module on the primary router monitors the state of the communication interface and sends notification packets to the secondary routers in multicast mode. When the primary router fails, for example, an interface or link fails, the VRRP notification packets are not be sent out as usual. When the secondary router does not receive any VRRP notification packet in a specified interval, the secondary router with the highest priority changes its VRRP state to the active state. In this way, the services running on the primary router can continue to run on the secondary router. If the primary router of the backup group fails, other secondary routers of the group select a new primary router according to their priorities. So the selected router works in active state and provides routing services to the hosts on the network. With the VRRP technology, the hosts on the intranet can communicate with the Internet continuously. Thus, reliability is guaranteed.
7 Reliability
7.1.2 Disadvantages of Traditional VRRP in Eudemon Backup

Security zones are introduced in the Eudemon. Two Eudemons can implement a route redundancy backup. One serves as the primary Eudemon and the other the secondary Eudemon. Interfaces on the primary and secondary Eudemons are associated with corresponding security zones.
Typical Networking of Eudemon Backup

Based on traditional VRRP, each zone needs a VRRP group to monitor the working state of interfaces that are connected to security zones. Namely, interfaces connected to each security zone on the Eudemon form a backup group (the virtual firewall), and each group is assigned with a virtual IP address, as shown in Figure 7-3. Figure 7-3 Typical networking of Eudemon backup
Trust 10.100.10.1 Primary Virtual IP Address EudemonA Backup1
10.100.10.0/24 Backup Virtual IP Address Untrust 202.38.10.1 Backup2 EudemonB Virtual IP Address Secondary 10.100.20.1
10.100.20.0/24 DMZ
As shown in Figure 7-3:

l l
Eudemon A is the Primary and Eudemon B is the Secondary. Interfaces connected to the Trust zone on the primary and secondary Eudemons make up backup group 1 with the virtual IP address 10.100.10.1. Interfaces connected to the DMZ on the primary and secondary Eudemons make up backup group 2 with the virtual IP address 10.100.20.1. Interfaces connected to the Untrust zone on the primary and secondary Eudemons make up backup group 3 with the virtual IP address 202.38.10.1.
State Requirements for Eudemon Backup

As the Eudemon is a stateful firewall, it checks the first session packet and generates a session entry dynamically. Only the subsequent packets (including return packets) that match the session entry can pass through the Eudemon. Therefore, the inbound path and the outbound path of the same session must be consistent; otherwise, unmatched subsequent packets or return packets are discarded, as shown in Figure 7-4.
7 Reliability
Figure 7-4 Eudemon backup state
EudemonA (1) PC1 (8) Trust (7) (2) Primary Session entry (3) (6) (9) Secondary EudemonB (4) PC2 (5) Untrust Actual connection Packets traffic Packets traffic
DMZ
In Figure 7-4, assume that the VRRP status of Eudemon A and Eudemon B are consistent, that is, all the interfaces on Eudemon A are in active state, and all the interfaces on Eudemon B are in standby state. If PC1 in the Trust zone accesses PC2 in the Untrust zone, a packet is sent from the Trust zone to the Untrust zone along the path (1)-(2)-(3)-(4). When the packet passes Eudemon A, a dynamic session entry is generated. The return packet matches the session entry and successfully reaches the host in the Trust zone if it is sent along the path (5)-(6)-(7)-(8). Assume that the VRRP status of Eudemon A and Eudemon B are inconsistent. For example, on Eudemon B, the interface connected to the Trust zone is in standby state, while the interface connected to the Untrust zone is in active state. After the packets from PC1 of the Trust zone pass Eudemon A and reach PC2 in the Untrust zone, a session entry is dynamically generated on Eudemon A. The return packet is sent along the path (5)-(9). At this time, no session entry related to the data flow is available on Eudemon B. If no other packet-filtering rules are available to permit the packet to pass, Eudemon B discards the packet. In this case, the session is disrupted. To summarize, if the VRRP states are consistent, the states of interfaces connected to each zone on the same Eudemon are identical, that is, all are in active state or in standby state at the same time. The Eudemon connects to several security zones and comprises a backup group with other interfaces connected to each security zone.
Disadvantages of Traditional VRRP in Eudemon Backup

Based on the traditional VRRP mechanism, VRRP in each backup group works in an independent state. Therefore, the state of VRRP on each interface on one Eudemon cannot be consistent. That is, the traditional VRRP mechanism cannot achieve VRRP state consistence of the Eudemon. In the current networking application, the Eudemon, as a security device, is usually located at the service access point between a protected network and an unprotected network. In the current networking application, users have higher requirements on reliability. Users specifically require that communications between the following points should be undisrupted:
7 Reliability
l l l l
Important service ingress Access points Enterprise Internet access points Bank database servers
If only one Eudemon is located at the service point, the network may be disrupted due to the single point failure, though the Eudemon is highly reliable. In this case, the redundancy backup mechanism is offered to improve the stability and reliability of the entire system.
7.2 Introduction to Dual-System Hot Backup

7.2.1 HRP Application 7.2.2 Primary/Secondary Configuration Devices
7.2.1 HRP Application

The Eudemon is a stateful firewall, which means there is a session entry for each dynamic session connection on the Eudemon, as shown in Figure 7-5. Figure 7-5 Typical data path in primary/secondary mode
EudemonA
(1)
PC1 Trust
(2)
Primary
Session entry
(3)
(7) (6) (8)
(4) (5) PC2
Secondary EudemonB DMZ
Untrust
Actual connection Packets traffic Packets traffic
In primary/secondary mode, if Eudemon A is the active device, it takes up all data transmission tasks and many dynamic session entries are set up on it; Eudemon B is the standby device, and no data passes it. When errors occur on Eudemon A or on associated links, Eudemon B switches to the active Eudemon and begins to transfer data; however, if there is no backup session entry or
7 Reliability
configuration command on Eudemon B before the switchover, all sessions that have passed Eudemon A are disconnected as a result of mismatch. Then, services are disrupted. In order to make the secondary Eudemon take over tasks from the primary Eudemon smoothly when the primary Eudemon breaks down, you need to backup configuration commands and state information between the primary Eudemon and the secondary Eudemon. Huawei Redundancy Protocol (HRP) is developed for this purpose. HRP is transmitted over VGMP packets in data channels in the VRRP management group.
7.2.2 Primary/Secondary Configuration Devices

In load balancing mode, there are two primary Eudemons on the network. Users can enter a lot of commands on the two primary Eudemons. When one primary Eudemon fails, to avoid confusion during backup, Eudemons are grouped into primary configuration devices to send backup data and secondary configuration devices to receive backup data. A primary configuration device must meet the following specifications:
l
In a VRRP management group, only the Eudemon that is in active state can be the primary configuration device. In load balancing mode, both Eudemons that take part in two-node cluster hot backup are primary Eudemons. In this case, the primary configuration device is selected based on priorities of VRRP groups and actual IP addresses (in descending order) of interfaces.
To assure the stability of the primary configuration device, the primary configuration device always works in active mode unless it fails or quits the VRRP backup group.
NOTE
The concepts of primary/secondary configuration devices are used in load balancing mode rather than primary/secondary mode.
7.3 Relations Between the VRRP Backup Group, Management Group, and HRP
The hierarchical relations between the VRRP backup group, management group, and HRP are shown in Figure 7-6. Figure 7-6 Hierarchical relations between the VRRP backup group, management group, and HRP
HRP module HRP packet VRRPmanagement group VGMP packet VRRPbackup group
7 Reliability
When the state of the VRRP management group changes, the system notifies HRP and the primary or secondary configuration device to change their states. In this way, configuration commands and session state information between two Eudemons can be backed up in time. In addition, the state of the VRRP management group is affected by the HRP state. In other words, based on the result of HRP state switchover, VRRP modifies priorities and changes the VRRP state. When the state of the VRRP backup group changes, the VRRP management group determines whether to change the states of the following elements:
l l l
VRRP management group HRP Primary and secondary configuration devices
7.4 IP-Link Auto-detection Overview

IP-Link detection periodically sends an ICMP or ARP requests to the specified destination IP address, waits for the reply packets from the destination IP address, and then determines the connection status of the network. If no reply packet is received in the specific time, IP-Link auto-detection determines that faults occur on the link and performs related operations. If three reply packets are received consecutively in a specified period, IP-Link auto-detection determines that the faulty link has recovered, and then performs related operations. The detection result (destination host reachable or unreachable) provided by IP-Link autodetection can be referred by other features such as:
l
Static route
NOTE
The IP-link detection is not supported in the dynamic router environment on the Eudemon.
When IP-Link auto-detection discovers faults on the link, the Eudemon adjusts its own static routes correspondingly. If a link used by the static route of higher preference is found faulty, the Eudemon selects a new link for forwarding services. If the link recovers from the fault, the Eudemon adjusts its own static routes, replacing the lower preference route with the higher preference route. Such adjustment ensures that the Eudemon always uses a reachable link of the highest preference available, thus keeping the continuity of services.
l
Dual-system hot backup If the faulty link detected by IP-Link detection affects the active/standby service of the Eudemon, the Eudemon adjusts the priority of VGMP to implement active/standby switch, thus ensuring service continuity.
7-8
Issue 01 (2009-12-01)
A Glossary
A
A AAA ACL
Glossary
It provides a framework for configuring the security functions of authentication, authorization, and accounting. It is a kind of management on network security. A sequential instruction list consisting of a series of permit | deny statements. In the scenario where a Eudemon is deployed on a network, an ACL is applied to the interface of a router, and the router determines which packets can be received and which should be denied according to the ACL. In QoS, ACL are also used for traffic classification. A protocol used to resolve an IP address into an Ethernet MAC address. RFC 826 defines the protocol. A state-based packet filter mechanism applied to the application layer. ASPF can be used to work with a common static Eudemon to implement security policies of an internal network. As ASPF is based on the session information about the application layer protocol, it can intelligently filter TCP and UDP packets. In addition, ASPF can detect sessions originated by any side of the Eudemon.
ARP ASPF
B BGP The Border Gateway Protocol (BGP) is an interautonomous system routing protocol. An autonomous system is a network or group of networks under a common administration and with common routing policies. BGP is used to exchange routing information for the Internet and is the protocol used between Internet service providers (ISP).
Issue 01 (2009-12-01)
A-1
A Glossary
CHAP
A password authentication method. It is a three-way handshake authentication with encrypted passwords. The authenticator first sends to the peer some randomly created packets (Challenge); then the peer encrypts the random packets with its own password and MD5 algorithm and resends the Response packets; finally, the authenticator encrypts the original random packets with the peer's password and MD5 algorithm, compares the Response value with its own calculation of expected value, and returns the response (Acknowledge or Not Acknowledge) based on this comparison.
D DDoS Distributed Denial of Service attack. On the Internet, a distributed denial-of-service (DDoS) attack is one in which a multitude of compromised systems attack a single target, thereby causing denial of service for users of the targeted system. A data encryption standard that encrypts data in 64-bit block and generating 64-bit encrypted text. A shared key protocol proposed by Diffie and Hellman. With this protocol, the communication parties can exchange data without transmitting the shared key and calculating the shared key. DMZ derives from military, DMZ is an intermediate zone between the severe military zone and the incompact public zone. That is, it is partially dominated by military. Here in Eudemon, DMZ indicates a zone that is independent of internal networks and external networks both logically and physically, in which public devices such as WWW Server and FTP Server are placed. It is hard to locate these servers for external access because if placed in external networks, their securities cannot be assured; while placed in internal networks, their security defects might provide opportunity for some external malicious client to attack internal networks. DMZ is developed to solve this problem. DNS A hierarchical way of tracking domain names and their addresses, devised in the mid-1980's. The DNS database does not rely on one file or even one server, but rather is distributed over several key computers across the Internet to prevent catastrophic failure if one or a few computers go down. DNS is a TCP/IP service that belongs to the Application layer of the OSI model.
DES DH
DMZ
E ESP A secure packet encapsulation protocol used in transport mode and tunnel mode. Adopting encryption and authentication mechanisms, it provides IP data packets with such services as data source authentication, data integrity, anti-replay, and data confidentiality services.
A-2
A Glossary
F FTP An application layer protocol used to transmit files between remote hosts. FTP is implemented on the basis of the corresponding file system.
G GRE Tunneling protocol developed by Cisco Systems that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork. By connecting multiprotocol subnetworks in a single-protocol backbone environment, IP tunneling using GRE allows network expansion across a single-protocol backbone environment.
H HTTP Hypertext Transfer Protocol. The protocol used to carry requests from a browser to a Web server and to transport pages from Web servers back to the requesting browser. Although HTTP is almost universally used on the Web, it is not an especially secure protocol.
I ICMP IETF A Layer 2 protocol that reports errors and provides other information relevant to IP packet processing. The Internet Engineering Task Force. An organization that is dedicated to developing and designing TCP/IP protocol stack and Internet standards. A protocol used to exchange keys between Oakley and SKEME through ISAKMP. A protocol that provides connectionless best effort delivery of datagram across heterogeneous physical networks. IP is a network layer protocol in the TCP/IP protocol stack.
IKE IP
L LAC A device attached to the switching network. An LAC has a PPP terminal system and delivers L2TP processing. It usually provides access services.
Issue 01 (2009-12-01)
A-3
A Glossary
LAN
Local Area Network. A network consisting of personal computers and workstations residing in the same building or within several kilometers in circumference. LAN features high speed and low error rate. Ethernet, FDDI, and Token Ring are three main realization technologies of LANs. Link Control Protocol. In the Point-to-Point Protocol (PPP), the Link Control Protocol (LCP) establishes, configures, and tests data-link Internet connections.
LCP
M MAC MD5 The lower of the two sub-layers of the Data Link Layer. The MAC layer is closer to the physical layer. An algorithm that is developed by Ron Rivest to provide a strong one -way hashing function. The algorithm generates a fixed length (128-bit) digest from a message of any length. That can be appended to prove data integrity.
N NAPT NAPT translates transport identifier (for example, TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. A server that provides PSTN/ISDN dial-in users with Internet access services. A mechanism for reducing the need for globally unique IP addresses. NAT allows an organization with private IP addresses to connect to the Internet by translating those addresses into a globally unique and routable IP address. This is the program that switches the virtual circuit connections into place, implements path control, and operates the Synchronous Data Link Control (SDLC) link. An integrated circuit which has a feature set specifically targeted at the networking application domain. Network Processors are typically software programmable devices and would have generic characteristics similar to general-purpose CPUs that are commonly used in many different types of equipment and products. The Network Time Protocol was developed to maintain a common sense of "time" among Internet hosts around the world. Many systems on the Internet run NTP, and have the same time (relative to Greenwich Mean Time), with a maximum difference of about one second.
NAS NAT
NCP
NP
NTP
A-4
Issue 01 (2009-12-01)
A Glossary
O OSI OSI (Open Systems Interconnection) is a standard description or reference model for how messages should be transmitted between any two points in a telecommunication network. Link-state, hierarchical IGP routing algorithm proposed as a successor to RIP in the Internet community. OSPF features include least-cost routing, multipath routing, and load balancing. OSPF was derived from an early version of the IS-IS protocol.
OSPF
P PAM Port to Application Mapping (PAM) allows you to customize TCP or UDP port numbers for network services or applications. PAM uses this information to support network environments that run services using ports that are different from the registered or wellknown ports associated with an application. A protocol that requires twice handshake authentications. The password of PAP is in plain text. The authenticated side first sends the user name and password to the authenticating side. Then the authenticating side checks whether the user exists and whether the password is correct according to user configuration, and then returns response (Acknowledge or Not Acknowledge). A dedicated transmission link between two devices. A protocol that encapsulates PPP in tunneling mode over IP networks. It is supported by products of Microsoft, Ascend, 3COM, and some other companies.
PAP
PPP PPTP
Q QoS Quality of Service. The service performance of IP network delivery group is usually expressed in terms of QoS. QoS estimates core capabilities required by services such as delay, delay variation, and packet loss ratio. Certain supporting technologies are needed to meet these key requirements.
R RADIUS A distributed server/client system developed by Livinggston Enterprise. RADIUS can provide the AAA function. As an authentication and accounting protocol, RADIUS can realize access authentication, authorization, and accounting functions for a great number of users through serial port and Modem. Windows software that allows a user to gain remote access to the network server via a modem.
RAS
Issue 01 (2009-12-01)
A-5
A Glossary
RFC RIP
A document in which a standard, a protocol, or other information pertaining to the operation of the Internet is published. Routing Information Protocol. A routing protocol that calculates routes with the D-V algorithm and selects routes according to the hop number. RIP is widely used in small-sized networks. The Real Time Streaming Protocol is a client-server applicationlevel protocol for controlling the delivery of data with real-time properties.
RTSP
S SIP A protocol developed by IETF MMUSIC Working Group and proposed standard for initiating, modifying, and terminating an interactive user session that involves multimedia elements. Simple Mail Transfer Protocol (SMTP) is the de facto standard for e-mail transmissions across the Internet. Simple Network Management Protocol is part of the TCP/IP suite and is used to control and manage IP gateways and other network functions. A set of network standards and protocols that provide secure Telnet access. Security Socket Layer is a security protocol used to encrypt all the messages communicated on a network such as Internet.
SMTP SNMP
SSH SSL
T TCP TCP/IP A transport layer protocol that provides a connection-oriented, full-duplex, point-to-point service between hosts. A suite of communications protocols used to connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TE encompasses traffic management, capacity management, traffic measurement and modelling, network modelling, and performance analysis. Trivial File Transfer Protocol. A version of the TCP/IP FTP protocol that has no directory or password capability.
TE
TFTP
U UDP Part of the TCP/IP protocol suite. UDP is a standard, connectionless, host-to-host protocol that is used over packetswitched computer communication networks. UDP does not provide the reliability and ordering guarantees that TCP does.
A-6
Issue 01 (2009-12-01)
A Glossary
V VLAN Virtual Local Area Network. A logically independent network. It divides a LAN into multiple logical LANs. Each VLAN is a broadcast domain. The communication between the hosts in a VLAN is similar to that in a LAN.
W WWW World Wide Web. It is a wide-area hypermedia information retrieval initiative to give universal access to large universe of documents.
Issue 01 (2009-12-01)
A-7
B Acronyms and Abbreviations
B
A AAA ACK ACL AES AH ALG ARP ASPF
Acronyms and Abbreviations
Authorization, Authentication and Accounting ACKnowledgement Access Control List Advanced Encryption Standard Authentication Header Application Level Gateway Address Resolution Protocol Application Specific Packet Filter
B BGP Border Gateway Protocol
C CA CHAP Certification Authority Challenge - Handshake Authentication Protocol
D DDoS DHCP DMZ DNS Distributed Denial of Service Dynamic Host Configuration Protocol Demilitarized Zone Domain Name System
Issue 01 (2009-12-01)
B-1
DoS
Denial of Service
E ESP Encapsulating Security Payload
F FIFO FTP First In First Out File Transfer Protocol
G GE GRE Gigabit Ethernet Generic Routing Encapsulation
H HTTP HWCC Hypertext Transfer Protocol Huawei Conference Control protocol
I ICMP ID IETF IGMP IP IPX ISP Internet Control Message Protocol Identity Internet Engineering Task Force Internet Group Management Protocol Internet Protocol Internetwork Packet Exchange Internet Service Provider
L LAN LCP Local Area Network Link Control Protocol
M MAC Media Access Control
B-2
Issue 01 (2009-12-01)
MD5 MGCP MIB MPLS MRU
Message Digest Algorithm 5 Media Gateway Control Protocol Management Information Base MultiProtocol Label Switching Maximum Receive Unit
N NAPT NAS NAT NCP NP NTP Network Address and Port Translation Network Access Server Network Address Translation Network Control Protocol Network Processor Network Time Protocol
O OOB OSI OSPF Out-Of-Band Open Systems Interconnection Open Shortest Path First
P PAM PAP PFS POP PPP PPPoE PPTP PSTN Port to Application Mapping Password Authentication Protocol Perfect Forward Secrecy Point of Presence Point-to-Point Protocol Point-to-Point Protocol over Ethernet Point-to-Point Tunneling Protocol Public Switched Telephone Network
Q QoS Quality of Service
Issue 01 (2009-12-01)
B-3
R RADIUS RAS RFC RIP RSA RTSP Remote Authentication Dial in User Service Remote Access service Request For Comments Routing Information Protocol Rivest,Shamir,Adleman Real-Time Streaming Protocol
S SIP SMTP SNMP SSH SYN Flood Session Initiation Protocol Simple Mail Transfer Protocol Simple Network Management Protocol Secure Shell Synchronization Flood
T TCP TCP/IP TFTP ToS Transmission Control Protocol Transmission Control Protocol/Internet Protocol Trivial File Transfer Protocol Type of Service
U UDP URL User Datagram Protocol Universal Resource Locator
V VLAN VPDN VPLS Virtual LAN Virtual Private Dial Network Virtual Private LAN Segment
W WWW World Wide Web
B-4
Issue 01 (2009-12-01)
Issue 01 (2009-12-01)
B-5

Quidway Eudemon 200E-C&200E-F Firewall Feature Description (V100R002 - 01)

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Quidway Eudemon 200E-C&200E-F Firewall Feature Description (V100R002 - 01)

Transféré par

Droits d'auteur :

Formats disponibles

Quidway Eudemon 200E-C/200E-F Firewall V100R002

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

Huawei Technologies Co., Ltd.

Trademarks and Permissions

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.