Shasta 5000 Broadband Service Node, Provisioning Service Policies

Transcription

1 Release 4.5 Part No D Rev 00 April Technology Park Billerica, Massachusetts Shasta 5000 Broadband Service Node, Provisioning Service Policies

2 2 Copyright 2004 Nortel Networks All rights reserved. April The information in this document is subject to change without notice. The statements, configurations, technical data, and recommendations in this document are believed to be accurate and reliable, but are presented without express or implied warranty. Users must take full responsibility for their applications of any products specified in this document. The information in this document is proprietary to Nortel Networks Inc. The software described in this document is furnished under a license agreement and may only be used in accordance with the terms of that license. The software license agreement is included in this document. Trademarks Nortel Networks, the Nortel Networks logo, the Globemark, Unified Networks, Contivity, Shasta, and other Nortel Networks trademarked product names are trademarks of Nortel Networks. Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation. Adobe and Acrobat Reader are trademarks of Adobe Systems Incorporated. Sun, Sun Microsystems, Java, Solaris, iplanet, all trademarks and logos that contain Sun, Solaris, or Java, are trademarks or registered trademarks of Sun Microsystems, Inc. Solid Embedded Engine is a trademark of Solid. HP and OpenView are registered trademarks of Hewlett-Packard Company. LINUX is a registered trademark of Linus Torvalds. Pentium is a registered trademark of Intel Corporation. Red Hat is a registered trademark of Red Hat, Inc. UNIX is a registered trademark of X/Open Company Limited. The asterisk after a name denotes a trademarked item D Rev 00

3 3 Restricted Rights Legend Use, duplication, or disclosure by the United States Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS Notwithstanding any other license agreement that may pertain to, or accompany the delivery of, this computer software, the rights of the United States Government regarding its use, reproduction, and disclosure are as set forth in the Commercial Computer Software-Restricted Rights clause at FAR Statement of Conditions In the interest of improving internal design, operational function, and/or reliability, Nortel Networks Inc. reserves the right to make changes to the products described in this document without notice. Nortel Networks Inc. does not assume any liability that may occur due to the use or application of the product(s) or circuit layout(s) described herein. Portions of the code in this software product may be Copyright 1988, Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms of such portions are permitted, provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that such portions of the software were developed by the University of California, Berkeley. The name of the University may not be used to endorse or promote products derived from such portions of the software without specific prior written permission. SUCH PORTIONS OF THE SOFTWARE ARE PROVIDED AS IS AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. In addition, the program and information contained herein are licensed only pursuant to a license agreement that contains restrictions on use and disclosure (that may incorporate by reference certain limitations and notices imposed by third parties). Nortel Networks Inc. Software License Agreement This Software License Agreement ( License Agreement ) is between you, the end-user ( Customer ) and Nortel Networks Corporation and its subsidiaries and affiliates ( Nortel Networks ). PLEASE READ THE FOLLOWING CAREFULLY. YOU MUST ACCEPT THESE LICENSE TERMS IN ORDER TO DOWNLOAD AND/OR USE THE SOFTWARE. USE OF THE SOFTWARE CONSTITUTES YOUR ACCEPTANCE OF THIS LICENSE AGREEMENT. If you do not accept these terms and conditions, return the Software, unused and in the original shipping container, within 30 days of purchase to obtain a credit for the full purchase price. Software is owned or licensed by Nortel Networks, its parent or one of its subsidiaries or affiliates, and is copyrighted and licensed, not sold. Software consists of machine-readable instructions, its components, data, audio-visual content (such as images, text, recordings or pictures) and related licensed materials including all whole or partial copies. Nortel Networks grants you a license to use the Software only in the country where you acquired the Software. You obtain no rights other than those granted to you under this License Agreement. You are responsible for the selection of the Software and for the installation of, use of, and results obtained from the Software. 1.Licensed Use of Software. Nortel Networks grants Customer a nonexclusive license to use a copy of the Software on only one machine at any one time or to the extent of the activation or authorized usage level, whichever is applicable. To the extent Software is furnished for use with designated hardware or Customer furnished equipment ( CFE ), Customer is granted a nonexclusive license to use Software only on such hardware or CFE, as applicable. Software contains trade secrets and Customer agrees to treat Software as confidential information using the same care and discretion Customer uses with its own similar information that it does not wish to disclose, publish or disseminate. Customer will ensure that anyone who uses the Software does so only in Shasta 5000 Broadband Service Node, Provisioning Service Policies

4 4 compliance with the terms of this Agreement. Customer shall not a) use, copy, modify, transfer or distribute the Software except as expressly authorized; b) reverse assemble, reverse compile, reverse engineer or otherwise translate the Software; c) create derivative works or modifications unless expressly authorized; or d) sublicense, rent or lease the Software. Licensors of intellectual property to Nortel Networks are beneficiaries of this provision. Upon termination or breach of the license by Customer or in the event designated hardware or CFE is no longer in use, Customer will promptly return the Software to Nortel Networks or certify its destruction. Nortel Networks may audit by remote polling or other reasonable means to determine Customer s Software activation or usage levels. If suppliers of third party software included in Software require Nortel Networks to include additional or different terms, Customer agrees to abide by such terms provided by Nortel Networks with respect to such third party software. 2.Warranty. Except as may be otherwise expressly agreed to in writing between Nortel Networks and Customer, Software is provided AS IS without any warranties (conditions) of any kind. NORTEL NETWORKS DISCLAIMS ALL WARRANTIES (CONDITIONS) FOR THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF NON-INFRINGEMENT. Nortel Networks is not obligated to provide support of any kind for the Software. Some jurisdictions do not allow exclusion of implied warranties, and, in such event, the above exclusions may not apply. 3.Limitation of Remedies. IN NO EVENT SHALL NORTEL NETWORKS OR ITS AGENTS OR SUPPLIERS BE LIABLE FOR ANY OF THE FOLLOWING: a) DAMAGES BASED ON ANY THIRD PARTY CLAIM; b) LOSS OF, OR DAMAGE TO, CUSTOMER S RECORDS, FILES OR DATA; OR c) DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), WHETHER IN CONTRACT, TORT OR OTHERWISE (INCLUDING NEGLIGENCE) ARISING OUT OF YOUR USE OF THE SOFTWARE, EVEN IF NORTEL NETWORKS, ITS AGENTS OR SUPPLIERS HAVE BEEN ADVISED OF THEIR POSSIBILITY. The forgoing limitations of remedies also apply to any developer and/or supplier of the Software. Such developer and/or supplier is an intended beneficiary of this Section. Some jurisdictions do not allow these limitations or exclusions and, in such event, they may not apply. 4.General a. If Customer is the United States Government, the following paragraph shall apply: All Nortel Networks Software available under this License Agreement is commercial computer software and commercial computer software documentation and, in the event Software is licensed for or on behalf of the United States Government, the respective rights to the software and software documentation are governed by Nortel Networks standard commercial license in accordance with U.S. Federal Regulations at 48 C.F.R. Sections (for non-dod entities) and 48 C.F.R (for DoD entities). b. Customer may terminate the license at any time. Nortel Networks may terminate the license if Customer fails to comply with the terms and conditions of this license. In either event, upon termination, Customer must either return the Software to Nortel Networks or certify its destruction. c. Customer is responsible for payment of any taxes, including personal property taxes, resulting from Customer s use of the Software. Customer agrees to comply with all applicable laws including all applicable export and import laws and regulations. d. Neither party may bring an action, regardless of form, more than two years after the cause of the action arose. e. The terms and conditions of this License Agreement form the complete and exclusive agreement between Customer and Nortel Networks. f. This License Agreement is governed by the laws of the country in which Customer acquires the Software. If the Software is acquired in the United States, then this License Agreement is governed by the laws of the state of New York D Rev 00

5 5 Contents Contents List of Tables List of Figures Preface About BSN device provisioning Using the BSN CLI while provisioning Before you begin New in this Document Text conventions Related publications Printed technical manuals How to get help Chapter 1 Introduction to Service Policies What are Service Policies? Service policy categories Security policies Traffic Management policies Traffic Redirection policies Accounting policies Service creation Service policy objects Reserved objects Abstract objects Service Object deletion Service Policies Shasta 5000 Broadband Service Node, Provisioning Service Policies

6 6 Contents Rules matching process Service Profiles Services application Service policy logging Chapter 2 Security Policies Firewall Policies Firewall rules Stateful Service Rules Firewall Actions Firewall tickle mode Defense against SYN attacks Examples of firewall policies Residential firewall example Telecommuter firewall example Business firewall example Anti-spoofing Anti-Spoofing policy example Ingress Anti-Spoofing policy example Flow Mirroring Implementation considerations Flow Mirroring policy example Distributed Denial of Service (DDOS) prevention What is Denial of Service? Signature Recognition and Logging of Malformed Packets IP Fragmentation ICMP and UDP Echo Broadcast Syn Flood Detection and Prevention through TCP Proxies and Splicing Delayed Binding When Delayed Binding is turned on When Delayed Binding is turned off Support for TCP Proxies Support for TCP Splicing DDOS policy example D Rev 00

7 Contents 7 Authentication, Authorization, and Accounting Network Address Translation Directly connected NAT NAT Policy Rules M to 1 Source NAT with PAT M to N Source NAT with PAT to 1 Source and Destination NAT to 1 Source NAT to 1 Destination NAT NAT Policy Example Group NAT Subscriber Contexts ISP only context VPN only context VPN + Internet context Group NAT Configuration NAT Groups Access Groups for Group NAT Local Address Pools with Group NAT Group NAT Subscriber Configuration Subscriber Reachability with Group NAT Implicit Rules for Group NAT Chapter 3 Traffic Management Policies Traffic Management Overview Ingress Traffic Management Differentiated Services Defining DiffServ Classes and Drop Precedence DiffServ Policy Rules Traffic Policing Single rate, three-color marker Two rate, three-color marker Ingress Processing Egress Traffic Management Shasta 5000 Broadband Service Node, Provisioning Service Policies

8 8 Contents Egress DiffServ Traffic shaping Flow Shaper (rule-based) traffic shaper Configurable Queues AF class-based traffic shaper Egress Processing Flow Management Configurable Flowcache Lists Subscriber Based Maximum Conversation Threshold Flow management service policy Accounting Policies DiffServ accounting Flow Based Accounting Chapter 4 Traffic Redirection Policies Web Steering Web Steering policy rules Using IP Farms IP Farm Health checks Web Steering Proxy URL Web Steering policy example Policy Based Forwarding Policy Based Forwarding policy example The difference between Web Steering and Policy Based Forwarding Personal Content Portal Chapter 5 Provisioning Service Policies Creating service policy objects Create network objects Create a new host object Create a new gateway object Create a new ip_range object Create a new ip_farm object D Rev 00

9 Contents 9 Create a new abstract object Create a not_applicable object Create a new group object Create service objects Create a new tcp object Create a new udp object Create a new icmp object Create a new ip_protocol object Create a new abstract object Create a not_applicable object Create a new group object Creating Rate objects Create a new rate object Create a new abstract object Create DiffServ Action objects Find policies which use defined Service Objects Create service policies Create service profiles Bind a service policy or profile to a subscriber Resolve an abstract object within a subscriber policy Chapter 6 Creating Individual Service Policies Provisioning Security Policies Create a Firewall Policy Disabling/Enabling the Firewall Tickle Mode Disabling/Enabling the Sync Defender Mode Create an Anti Spoofing Policy Create an Ingress Anti Spoofing Policy Create a Flow Mirroring Policy Create a DDOS prevention policy Provisioning Network Address Translation Policies Create a NAT Policy Assign subscriber reachability Provisioning Group NAT Shasta 5000 Broadband Service Node, Provisioning Service Policies

10 10 Contents Create a NAT Group Object Define an Address Pool using NAT Groups Configure a Subscriber for Group NAT Provisioning Traffic Management Policies Create a DiffServ Policy Create a Policing Policy Create an Egress DiffServ Policy Create a AF Class Based Traffic Shaping Policy Create a Flow Based Traffic Shaping Policy Create a Flow Management policy Create an Accounting Policy Create a Flow Based Accounting Policy Provisioning Traffic Redirection policies Create a Policy Based Forwarding policy Create a Web Steering Policy Create a Personal Content Portal policy Appendix A List of Acronyms Index D Rev 00

11 11 List of Tables Table 1 Security policies Table 2 Traffic Management policies Table 3 Traffic Redirection policies Table 4 Accounting Policies Table 5 Service template types Table 6 Types of service objects Table 7 Reserved Network Objects Table 8 Service Log types Table 9 Firewall Rule Columns Table 10 Firewall Actions Table 11 Firewall policy that could drop a TCP conversation Table 12 Flow Mirroring policy actions Table 13 DDOS attack definitions Table 14 NAT policy types Table 15 HiddenAddroptions Table 16 NAT policy example rule descriptions Table 17 DiffServ Code Points Table 18 srtcm color definitions Table 19 trtcm color definitions Table 20 Rule definitions for Per-Flow Traffic Shaper Table 21 Flowcache resource allocation actions Table 22 Default Aging/Stealing parameters Table 23 Flow Management conversation limits Table 24 Web Steering Rule Columns Shasta 5000 Broadband Service Node, Provisioning Service Policies

12 12 List of Tables D Rev 00

13 13 List of Figures Figure 1 Ingress and egress traffic flows Figure 2 Residential Firewall Figure 3 Telecommuter firewall Figure 4 Business firewall Figure 5 Anti-Spoofing policy Figure 6 Ingress anti-spoofing Figure 7 Flow Mirroring policy example Figure 8 DDOS prevention policy example Figure 9 M to 1 Source NAT Figure 10 M to 1 Source NAT policy example Figure 11 1 to 1 NAT Figure 12 1 to 1 NAT policy example Figure 13 Private networks with overlapping address range Figure 14 NAT policy example Figure 15 NAT Group Object Figure 16 DiffServ Policy Example Figure 17 srtcm bursts Figure 18 Single Rate Three Color Marker example Figure 19 trtcm bursts Figure 20 Rule Based Traffic Shaping example Figure 21 AF class-based Traffic Shaper Figure 22 Flow Management policy example Figure 23 Logical flow for Web Steering redirection Figure 24 Web Steering example Figure 25 Policy Based Forwarding example Figure 26 Personal Content Portal redirection Shasta 5000 Broadband Service Node, Provisioning Service Policies

14 14 List of Figures D Rev 00

15 15 Preface The guide, Shasta 5000 Broadband Service Node, Provisioning Service Policies, provides background information about Service Policy provisioning on Shasta BSN devices, and includes provisioning procedures for a user of the Shasta Service Creation System (SCS). This preface includes the following topics: About BSN device provisioning on page 15 Before you begin on page 17 New in this Document on page 17 Text conventions on page 18 Related publications on page 19 Printed technical manuals on page 20 For each task or procedure, this guide also provides: A list of prerequisite tasks for you to accomplish before attempting the procedure. Next steps for you to take upon completion of the procedure. About BSN device provisioning The 4.5 Service Creation System (SCS) software provides tools for configuring Shasta 5000* Broadband Service Nodes (BSNs). The SCS server runs on a UNIX platform. The SCS Client software used for provisioning can be deployed on a Windows or UNIX system. Shasta 5000 Broadband Service Node, Provisioning Service Policies

16 16 Preface The SCS Client GUI is an intricate application that enables users to provision Shasta BSNs and subscribers in both a structured and unstructured manner. Structured provisioning -- Users can configure each resource, object or template as separate entities, independant of individual subscribers. When new subscribers are added, a previously defined resource (e.g., template, policie, etc.) can be assigned as needed. Users provisioning with the structured method will configure objects from within the manager that controls the resource. Unstructured provisioning -- Users can configure resources, objects or templates on an as-needed basis, as part of provisioning each subscriber. New objects are specific to each subscriber. Users provisioning in an unstructured manner will link to the configuration window of a new object directly from the configuration window of the entity that will utilize the object, bypassing the objects Manager windows. The topics in this guide occur in a sequence associated with the structured method of subscriber provisioning. However, each topic also provides navigation information enabling you to provision subscribers using the unstructured method, should you prefer or require that approach. For general information about the Service Creation System, as well as an introduction to manager applications within the SCS software, refer to Online Help. Online Help can be accessed from the SCS client GUI Help menu or from any Help button in windows displayed by the SCS client. Using the BSN CLI while provisioning Some procedures in this guide mention show commands that a Shasta BSN CLI user can run to verify provisioning performed by an SCS user. While some CLI users may verify Shasta BSN provisioning in this way, this guide does not describe how to use Shasta BSN CLI commands directly for provisioning or related tasks, except in cases where a feature can only be provisioned through CLI. Provisioning performed through the BSN CLI may not be reflected in the SCS GUI and may be lost upon a resync or reboot. For more information about conditions associated with the use of CLI commands for provisioning, monitoring, or debugging BSN device performance, see the following guides: D Rev 00

17 Preface 17 Shasta 5000 Broadband Service Node Command Line Interface Guide-- Administration, Release 4 Shasta 5000 Broadband Service Node Command Line Interface Guide -- Protocols, Release 4 Shasta 5000 Broadband Service Node, Troubleshooting Guide, Release 4 Before you begin This guide is intended for users provisioning a Shasta 5000 Broadband Service Node network using the SCS client. Prior knowledge of SCS software is not required. This guide assumes that you have the following background: Experience with window systems or graphical user interfaces (GUIs). Understanding of the transmission and management protocols used on your network. Basic understanding of the technology deployed with the Shasta BSN. New in this Document The following changes have been made to this document for this release: Information and provisioning procedures for the following Service Policies have been added to this guide: Flow Mirroring DDOS Prevention Flow Management Flow Based Accounting Information and provisioning procedures have been added on the Sync-defender-mode. Shasta 5000 Broadband Service Node, Provisioning Service Policies

18 18 Preface Text conventions This guide uses the following text conventions: angle brackets (< >) bold Courier text braces ({}) brackets ([ ]) ellipsis points (... ) Indicate that you choose the text to enter based on the description inside the brackets. Do not type the brackets when entering the command. Example: If the command syntax is ping <ip_address>, you enter ping Indicates command names and options and text that you need to enter. Example: Use the dinfo command. Example: Enter show ip {alerts routes}. Indicate required elements in syntax descriptions where there is more than one option. You must choose only one of the options. Do not type the braces when entering the command. Example: If the command syntax is show ip {alerts routes}, you must enter either show ip alerts or show ip routes, but not both. Indicate optional elements in syntax descriptions. Do not type the brackets when entering the command. Example: If the command syntax is show ip interfaces [-alerts], you can enter either show ip interfaces or show ip interfaces -alerts. Indicate that you repeat the last element of the command as needed. Example: If the command syntax is ethernet/2/1 [<parameter> <value>]..., you enter ethernet/2/1 and as many parameter-value pairs as needed D Rev 00

19 Preface 19 italic text plain Courier text separator ( > ) vertical line ( ) Indicates new terms, book titles, and variables in command syntax descriptions. Where a variable is two or more words, the words are connected by an underscore. Example: If the command syntax is show at <valid_route>, valid_route is one variable and you substitute one value for it. Indicates command syntax and system output, for example, prompts and system messages. Example: Set Trap Monitor Filters Shows menu paths. Example: Protocols > IP identifies the IP option on the Protocols menu. Separates choices for command keywords and arguments. Enter only one of the choices. Do not type the vertical line when entering the command. Example: If the command syntax is show ip {alerts routes}, you enter either show ip alerts or show ip routes, but not both. * In command syntax the asterisk indicates that you can enter multiple instances of the preceding parameter. Related publications For more information about using SCS, refer to the following publications: Shasta 5000 Broadband Service Node, Concept Guide, Release 4.0 (part number A) Shasta 5000 Broadband Service Node Hardware Installation and Maintenance, Release 4.0 (part number A) Shasta 5000 Broadband Service Node Software Installation and Migration, Release 4.0 (part number A) Shasta 5000 Broadband Service Node Service Creation System (SCS), Release Notes, Release 4.0 (part number A Shasta 5000 Broadband Service Node, Provisioning Service Policies

20 20 Preface Shasta 5000 Broadband Service Node IP Services Operating System (isos), Release Notes, Release 4.0 (part number A) Shasta 5000 Broadband Service Node, Getting Started with the Service Creation System (SCS), Release 4.0 (part number A) Shasta 5000 Broadband Service Node, SNMP Configuration Guide, Release 4.0 (part number A) Shasta 5000 Broadband Service Node, Provisioning Subscribers, Release 4.0 (part number A) Shasta 5000 Broadband Service Node, Provisioning Service Policies, Release 4.0 (part number A) Shasta 5000 Broadband Service Node, Provisioning VPNs, VLANs, and Tunnels, Release 4.0 (part number A) Shasta 5000 Broadband Service Node Command Line Interface Guide-- Administration, Release 4 Shasta 5000 Broadband Service Node Command Line Interface Guide -- Protocols, Release 4 Shasta 5000 Broadband Service Node CORBA API Applications Installation Guide(part number A) Shasta 5000 Broadband Service Node Service Creation System CORBA API Applications Guide(part number A) Shasta 5000 Broadband Service Node Personal Content Portals Installation Guide, Release 4.0 (part number A) Shasta 5000 Broadband Service Node Personal Content Portals Implementation Guide, Release 4.0 (part number A) Shasta 5000 Broadband Service Node, Troubleshooting Guide, Release 4 Printed technical manuals You can print selected technical manuals and release notes free, directly from the Internet. Go to the URL. Find the product for which you need documentation. Then locate the specific category and model or version for your hardware or software product. Use Adobe* Acrobat Reader* to open the manuals and release notes, search for the sections you need, and print them on most standard printers. Go to Adobe Systems at the URL to download a free copy of the Adobe Acrobat Reader D Rev 00

21 Preface 21 How to get help If you purchased a service contract for your Nortel Networks product from a distributor or authorized reseller, contact the technical support staff for that distributor or reseller for assistance. If you purchased a Nortel Networks service program, contact Nortel Networks Technical Support. To obtain contact information online, go to the URL, then click on Technical Support. From the Technical Support page, you can open a Customer Service Request online or find the telephone number for the nearest Technical Solutions Center. If you are not connected to the Internet, you can call NORTEL ( ) to learn the telephone number for the nearest Technical Solutions Center. An Express Routing Code (ERC) is available for many Nortel Networks products and services. When you use an ERC, your call is routed to a technical support person who specializes in supporting that product or service. To locate an ERC for your product or service, go to the erc/index.html URL. Shasta 5000 Broadband Service Node, Provisioning Service Policies

22 22 Preface D Rev 00

23 23 Chapter 1 Introduction to Service Policies The following topics explain how to create system-wide service policies within the Service Creation System (SCS) and describe what services are, how they are created, and how they are applied to subscribers. Topics in this chapter: What are Service Policies? on page 24 Service policy categories on page 25 Service creation on page 29 Services application on page 34 See also: For procedures on provisioning Service Policies, see Chapter 6, Creating Individual Service Policies, on page 139, including: Creating service policy objects on page 110 Create service policies on page 131 Create service profiles on page 134 Bind a service policy or profile to a subscriber on page 135 Resolve an abstract object within a subscriber policy on page 137 Shasta 5000 Broadband Service Node, Provisioning Service Policies

24 24 Chapter 1 Introduction to Service Policies What are Service Policies? Service policies monitor and act upon subscriber packets passing through a Shasta BSN device. The Service Policy Manager (SPM) within the Shasta Service Creation System provides users with a template-based approach to provision subscriber service policies efficiently within a Shasta BSN network. Policies are used to provide value added services to ISP subscribers, and to protect an ISP from malicious attacks. Services are also used by a Device Owner to implement security on the BSN. Provisioning of services can be customized for an individual subscriber, or applied in bulk to multiple subscribers. The SPM provides the ability to create service profiles that combine individual policies, enabling ISPs to offer Service Level Agreements to subscribers. For more information on service policies and profiles, see the following: Topic For information, see: Service policy categories Service policy categories on page 25 How services are created Service creation on page 29 How services are applies Services application on page 34 Logging within Service Service policy logging on page 35 Policies Security policies Chapter 2, Security Policies, on page 37 Traffic Management policies Chapter 3, Traffic Management Policies, on page 75 Traffic Redirection policies Chapter 4, Traffic Redirection Policies, on page 97 Provisioning service policies Chapter 5, Provisioning Service Policies, on page 109 Provisioning individual policies Chapter 6, Creating Individual Service Policies, on page D Rev 00

25 Chapter 1 Introduction to Service Policies 25 Service policy categories The Shasta 5000 Broadband Service Node supports four categories of service policies. Security policies on page 25 Traffic Management policies on page 26 Traffic Redirection policies on page 28 Accounting policies on page 29 Security policies The Shasta BSN integrates an advanced policy-based state aware firewall capability and anti-spoofing security services in its IP Services Operating System (isos), together with Remote Authentication Dial-In User Service (RADIUS) authentication support, activity logging, encryption, and support for content filtering. The security services can be provided to subscribers as a complete package or individually on a per-subscriber basis. The following table defines the different security policy types. Table 1 Security policies Policy icon Policy Type Description For more information, see: Security Rules-based traffic filtering for security and access limitation. Firewall Policies on page 38 and Provisioning Security Policies on page 140 Anti- Spoofing Ingress Anti- Spoofing Impersonation and spoofing protection based on known subscriber addresses. Impersonation and spoofing protection based on known subscriber addresses. Anti-spoofing on page 46 and Provisioning Security Policies on page 140 Anti-spoofing on page 46 and Provisioning Security Policies on page 140 Shasta 5000 Broadband Service Node, Provisioning Service Policies

26 26 Chapter 1 Introduction to Service Policies Table 1 Security policies NAT Rules-based address reuse solution that takes advantage of the small percent of hosts in a stub network that are communicating outside of the network at any given time. Network Address Translation on page 56 and Provisioning Security Policies on page 140 Flow Mirroring Copies IP traffic originating or destined for specific subscribers to external servers. Flow Mirroring on page 48 and Provisioning Security Policies on page 140 Distributed Denial of Service (DDOS) prevention Provides recognition and prevention of DDOS attacks in subscriber networks. Distributed Denial of Service (DDOS) prevention on page 50 and Provisioning Security Policies on page 140 Traffic Management policies Traffic Management policies supported on Shasta BSNs permit ISP control over available subscriber bandwidth, packet latency, and jitter, including: Policing packets entering the providers network, based on the current TOS/ DiffServ marking value in each packet. Resetting TOS/DiffServ markings to modify the processing priorities for incoming packets. Traffic shaping that controls the amount of traffic accepted by a subscriber from the provider s network. The following table briefly describes the different traffic management policy types D Rev 00

27 Chapter 1 Introduction to Service Policies 27 Table 2 Traffic Management policies Policy icon Policy type Description For more information, see: DiffServ Marking Egress DiffServ Marking Traffic Shaping Rules Based on DSCP Values for CS, EF, AF (with DP) and DE classes which allow designating traffic priority. Rules Based on DSCP Values for CS, EF, AF (with DP) and DE classes which allow designating traffic priority on the egress side. Differentiated Services on page 77 and Provisioning Traffic Management Policies on page 156 Egress DiffServ on page 85 and Provisioning Traffic Management Policies on page 156 Rules-based traffic shaping policy. Traffic shaping on page 85 and Provisioning Traffic Management Policies on page 156 Policing Rules-based traffic policing policy. Traffic Policing on page 79 and Provisioning Traffic Management Policies on page 156 Flow Management Provides configurable aging and stealing timeouts for flowcache lists and the maximum flows allowed for the subscriber. Flow Management on page 91 and Provisioning Traffic Management Policies on page 156 Shasta 5000 Broadband Service Node, Provisioning Service Policies

28 28 Chapter 1 Introduction to Service Policies Traffic Redirection policies The Shasta BSN enables service providers to redirect traffic to a Personal Content Portal or web cache. The following table briefly describes the different traffic redirection policy types. Table 3 Traffic Redirection policies Policy icon Policy type Description For more information, see: Personal Content Portal Policy Based Forwarding Web Steering Rules-based traffic steering policy. Personal Content Portal on page 106 and Provisioning Traffic Redirection policies on page 169 Rules-based packet redirection. Policy Based Forwarding on page 103 and Provisioning Traffic Redirection policies on page 169 Redirects port 80 HTTP targeted traffic to a proxy cache server at port 80. Web Steering on page 98 and Provisioning Traffic Redirection policies on page D Rev 00

29 Chapter 1 Introduction to Service Policies 29 Accounting policies Accounting policies are built on rules that enable you to capture and log different parameters associated with subscriber ingress/egress traffic. The following table briefly describes the accounting services policy type. Table 4 Accounting Policies Policy icon Policy type Description For more information, see: Accounting Services Flow Based Accounting Provides statistics on the number of bytes and packets sent and received by your subscriber. Establishes priority levels to packets that come through different fields. Flow Management on page 91 and Provisioning Traffic Management Policies on page 156 Flow Management on page 91 and Provisioning Traffic Management Policies on page 156 Service creation Subscriber Services are templates that are defined by the ISP or Device Owner. They are applied to subscribers on an individual or group basis. The three service template types are: Table 5 Service template types Template type Description For more information, see: Service Objects Service Policies Service Profiles Network objects or services that are applied within a service policy. Objects are created as required, and can include IP Protocols, subscriber addresses, or groups. Defined services that can be customized on a per subscriber basis. For instance, a firewall policy or an accounting policy. Groups of policies that are bound together to provide service packs to subscribers. Service policy objects on page 30 Service Policies on page 32 Service Profiles on page 33 Shasta 5000 Broadband Service Node, Provisioning Service Policies

30 30 Chapter 1 Introduction to Service Policies Service policy objects Service policy rules are defined using service policy objects. Service policy objects are service-specific parameters and values, such as IP protocols, addresses, or packet fields that you select to build the rules of any service policy. SCS provides a set of canned Shasta-defined objects to help simplify the configuration tasks. Objects can also be user defined for network specific parameters. The following table defines the types of supported service policy objects. Table 6 Types of service objects Object type Description For provisioning information, see: Network Objects Reserved objects that are resolved in the Shasta BSN, for example, private addresses for subscribers, remote addresses, and broadcast addresses for subscriber interfaces, and a list of subscriber addresses. Create network objects on page 110 Service Objects Well-know services, such as FTP, DNS, or BootP Create service objects on page 118 Rate Objects Defined line rates Creating Rate objects on page 125 DiffServ Action Objects Predefined values in the TOS/DiffServ field Create DiffServ Action objects on page D Rev 00

31 Chapter 1 Introduction to Service Policies 31 Reserved objects Reserved objects are predefined objects that automatically resolve to subscriber information when a policy is applied to a subscriber. Predefined service policy objects consist of various well known protocols or services. The following table defines predefined objects. Table 7 Reserved Network Objects Reserved Object _SubAddr _VPNAddr _PeerAddr _ISPAddr _ISPDefaultAddr _HiddenAddr _PublicAddr _SubBroadcastAddr Definition All addresses of the subscriber, i.e. directly connected address, reachability, and addresses discovered via routing if routing is enabled for the subscriber. This also includes all the hidden subscriber reachability. All the addresses in the VPRN FIB, i.e. the addresses of all the subscribers in the VPRN across the network. Remote address of subscriber interface, valid only for PPP and routed encapsulations. This is the value of the remote_address in the subscriber GUI. This is used in cases where the remote box is a CPE router and the ISP wants to have special rules for traffic to the CPE router. All the addresses of the box, ISP default address, all trunk local addresses, and access local address ISP default address. List of private addresses for the subscriber Range of address used for translation in NAT policy. This can be used in the action of a NAT service and a template NAT policy can be applied to multiple subscribers. In the Subscriber Addressing Tab, there is a section to specify the public address if you have any hidden addresses. The directed broadcast addresses for each reachability address of the subscriber. For information on provisioning service objects or service policies, see Create service objects or Create service policies. Shasta 5000 Broadband Service Node, Provisioning Service Policies

32 32 Chapter 1 Introduction to Service Policies Abstract objects In order to facilitate template creation, objects may be defined as unresolved, using the object type of Abstract. Abstract objects are used in place of specific subscriber information. Using an abstract object allows a service policy to be used as a template and applied to multiple subscribers. When a service with an abstract object is applied to a subscriber, the abstract object is listed as unresolved. This unresolved object must then be associated with a configured service object, with the correct parameters for that subscriber. For information on resolving abstract objects, see Resolve an abstract object within a subscriber policy on page 137. Service Object deletion Service policy objects cannot be deleted when they are used by a policy. A Service Object can consist of a Network Object, Service Object, Rate Object, or Diffserv Action object, and is used to define a specific network parameter used in one or more service policies. When a defined Service Object that is implemented in a policy is deleted, it can have an adverse effect on that policy. The SCS will check to see if an object is used in a policy or policies before it can be deleted. The user will be provided with a warning and a printable list of the policies in which the object is being used. Service Policies Service policies are the application of processing rules to a packet flow. Each set of rules describes the required behavior of the service. All rule fields in service policies are specified using Service Objects. Each rule is comprised of a combination of network objects, services, actions, and logging mechanisms. Service rules allow the designation of source and destination, as well as IP service (application). A rule then designates a service specific action to be taken for traffic that matches the rule. For information on provisioning service policies, see Create service policies on page D Rev 00

33 Chapter 1 Introduction to Service Policies 33 Rules matching process Service policies apply conditional processing rules to a packet flow. You use the Service Policy Manager to define these rules. The rule conditional match process works as follows: Rule matching is performed in the order specified in the policy, starting with Row 1. The first match of a rule stops the rules match process. The Source, Destination, and Service fields of each rule are applied against the corresponding fields of an incoming or outgoing (egress or ingress) packet. If all the three fields match, then the BSN performs the rule defined Action, which is service-specific. For information on provisioning service policies, see Create service policies on page 131. Service Profiles A service profile is a collection of policies that creates multiple conditions for how the Shasta BSN will respond to a subscriber. For example, you can configure the Shasta BSN to permit only certain kinds of traffic to be transmitted to a subscriber, to drop certain packets based on a weighting system, and to report the presence of a non-authorized packet (known as an intruder) coming into the subscriber. All these policies would make up one composite profile. Service profiles are used by service providers to offer various classes of Service Level Agreements (SLAs) to customers. Service policies can be bundled into service profiles and sold at different pricing levels to meet individual customer requirements. For information on provisioning service profiles, see Create service profiles on page 134. Shasta 5000 Broadband Service Node, Provisioning Service Policies

34 Ground Strap 34 Chapter 1 Introduction to Service Policies Services application Services are applied to a subscribers packet flow in both the ingress and egress direction. Some services are designated to only match rules in a single direction of flow, such as Ingress Anti-spoofing, or Egress Diffserv. Other services will match rules in both the ingress and egress directions, such as Firewalls. Egress traffic is flowing from the public network or Internet to the subscriber. From the perspective of the BSN, traffic received on a trunk port and routed out an access connection would be Egress traffic. Ingress traffic is flowing from the subscriber to the public network or Internet. From the perspective of the BSN, traffic received on an access port and routed out a trunk connection would be Ingress traffic. The following figure shows ingress and egress traffic flows. Figure 1 Ingress and egress traffic flows Subscriber Ingress Ingress Internet DSLAM (UE 9000) Egress Egress D Rev 00

35 Chapter 1 Introduction to Service Policies 35 Service policy logging You can generate services logging data for a policy by the use of brief, detail and verbose options in the log parameter. When this is enabled the policy will record the individual conversation details as outlined in the table below. Table 8 Service Log types Mode Description Information in File Brief Detail Verbose Each new connection will generate a single entry to the log file. The first 5 tuple of the initiator s conversation is logged. IP Services which are logged in brief mode are viewable in the SCS Client. Consumes approximately 75 bytes per entry in a log file. Each new connection or flow causes two entries: The first five tuple of each direction is logged. IP Services which are logged in detail mode are viewable in the SCS Client. Consumes approximately 100 bytes per entry in a log file. Each new connection or flow causes two entries: The first five tuple of each direction is logged. SCS Client will show detail level of information, including layer 3 and 4 header information. Consumes approximately 150 bytes in a log file Single direction: IP Source IP Destination Source Port Destination Port Protocol Action Rule number Flow Source Address Flow Destination Address Flow Source Port Flow Destination Port Flow Protocol Username FQDN Subscriber Instance Log ID Time Stamp Area, Device, ISP ID Same as brief mode only in two directions. Same as detail mode plus layer 3 and layer 4 headers. Content will vary by protocol. Shasta 5000 Broadband Service Node, Provisioning Service Policies

36 36 Chapter 1 Introduction to Service Policies D Rev 00

37 37 Chapter 2 Security Policies The following topics explain the Shasta 5000 Broadband Service Node s security features and describe the different security policies. Security is an integral part of every network. Mass-market users are migrating from traditional dialup internet access to broadband technologies such as DSL and cable. Due to the transitory nature of dialup access, hacking was limited, but broadband technologies provide a security risk due to an always-on environment. Users are permanently connected to the network and the same IP address is assigned to the user s system for the duration of the connection, exposing the system to hackers. Topics in this chapter: Firewall Policies on page 38 Anti-spoofing on page 46 Flow Mirroring on page 48 Network Address Translation on page 56 See also: For procedures relating to Security Policies, see Chapter 6, Creating Individual Service Policies, on page 139, including: Provisioning Security Policies on page 140 Provisioning Network Address Translation Policies on page 149 Provisioning Group NAT on page 152 Shasta 5000 Broadband Service Node, Provisioning Service Policies

38 38 Chapter 2 Security Policies Firewall Policies A firewall prevents unwanted or unauthorized traffic from leaving or entering a subscriber network. The Shasta BSN s network-based firewall capability allows service providers to provide managed firewall services at the point-of-entry into the network rather than at the customer s premises. Besides implementing packet filtering rules, the Shasta BSN is a state-aware firewall that functions by inspecting the payload and dynamically allowing packets destined to certain ports. This allows the Shasta BSN firewall to follow complex applications, such as FTP, H323, and SIP. For information on provisioning firewalls, see Provisioning Security Policies on page 140. Firewall rules Firewall policies are implemented on a per-subscriber basis. A subscriber with no applied security policy can transmit and receive all traffic. Traffic is examined in both the ingress and egress directions, and run against each rule in the policy. Policy rules identify traffic based on the source, destination, and service type defined in the packet header, then defines an action to be taken for any traffic that matches the rule. The rules are matched in the order they are listed in the policy. If a rule is matched in Row One, the action is applied to the packet, and it is not run against the remainder of the rules. If a packet does not match any of the rules in a policy, it is dropped per an implicit deny. The default firewall policy statement is an implicit deny, meaning all traffic from any source to any destination is dropped. If you apply the default policy without adding additional rules, all incoming and outgoing traffic on your subscriber connection is dropped. A firewall rule is made up of the columns defined in the following table D Rev 00

39 Chapter 2 Security Policies 39 Table 9 Firewall Rule Columns Rule # Source Destination Service Action Log Remark The order of the traffic matching rules The source IP prefix of the traffic The destination IP prefix of the traffic The application of the traffic The action to be taken for the matched traffic How to log the rule Any notes pertaining to the rule Stateful Service Rules All service rules are interpreted based on an IP conversation, not on individual IP packets. This conversation based filtering method is called a stateful or state aware firewall. The BSN intercepts packets at the network layer and begins analysis on the protocols. It extracts state-related information required from all application layers for the security decision, associating packets to conversations. An IP conversation is a logical session between two IP addresses. It is an application level flow, which may contain many 5-tuple flows. For example one FTP session or H.323 call may contain many flows. A conversation is bi-directional. Therefore, once a traffic flow is identified and allowed, the correponding return packets are automatically allowed. This mechanism, based on a hashed list of flows, is much more efficient then traditional access lists based on filters. A state-aware firewall can recognize and track the following: Application flows that use Static TCP and UDP ports such as Telnet or HTTP Applications that create and use dynamic ports such as FTP and Real Audio. One example of a stateful firewall rule is http. A subscriber has a policy with a rule allowing http traffic from his subscriber address to a an ISP network. The first packet sent by the subscriber to the ISP matches the rule and initiates the conversation. Since this is TCP, packets in the reverse direction (from the ISP network port 80 to the originating port on the subscriber side) would be considered part of the same conversation. Therefore, when a reply comes back from the ISP, they are also matched to the rule and allowed. Shasta 5000 Broadband Service Node, Provisioning Service Policies

40 40 Chapter 2 Security Policies Firewall Actions A firewall action determines how a packet is handled once a rule is matched. There are four actions allowable within a rule, as defined in the following table. If a packet does not match a rule, it is automatically dropped. Table 10 Firewall Actions Icon Action Definition Accept Allows a packet matching the rule to pass through the firewall. Accept via VPN Drop Allows a packet that matches the rule to pass through the firewall, but forces the BSN to use the subscribers VPN FIB as opposed to the ISPs global FIB. Drops any packet that matches the rule with no notification to the source Reject Rejects a packet that matches the rule, except in the case of a TCP protocol packet, in which a reset packet is sent back to the source of the rejected packet. Firewall tickle mode A TCP conversation that is alive on both end nodes can be aged out when it exceeds certain timeout limits. If the next packet in the conversation comes from a host that did not initiate the original conversation, it might be dropped, even though the original initiator has maintained an open connection. For example, a firewall policy of the form shown in the table below, with the tickle mode disabled, would drop the conversation in such a scenario D Rev 00

41 Chapter 2 Security Policies 41 Table 11 Firewall policy that could drop a TCP conversation Rule Destination Source Service Action 1 _Subaddr Any Any Allow 2 Any Any Any Drop Consider the following scenario, in which the tickle mode is enabled. The subscriber s address is , the TCP packet comes back from a remote host at address , and the packet is a part of a legitimate, existing conversation. The packet s 4-tuple is: Source IP: Destination IP: Source Port: 23 Destination Port: 1993 The firewall of the Shasta BSN performs a first round of rule matching and matches the packet with rule 2. The action is drop. Because the TCP packet has the ACK flag set, indicating that it is part of an existing conversation, the firewall performs a second round of rule matching with the packet's 4-tuple swapped (address and destination are reversed). The firewall matches the reversed address and destination with rule 1, and the action is allow. Following a match of this kind, the firewall in tickle mode checks: Whether the connection at the other end is still alive. Whether the sequence number spaces of the two sides match. Whether the SYN and RST flags in the packet are both clear. If those three items are confirmed, the packet is allowed to pass. The default state of the firewall tickle mode for security policies is enabled. Shasta 5000 Broadband Service Node, Provisioning Service Policies

42 42 Chapter 2 Security Policies Defense against SYN attacks Shasta firewall implementation uses predefined rules to match the first packet of each flow to get an action. Each packet of that flow will use the same action that resulted from the first packet rule match. But this implementation has one drawback, it does not try to validate the TCP 3-way handshake before it starts to forward the traffic. As a result, some illegal traffic may pass through the firewall. To make sure the BSN firewall does not forward traffic before a 3-way hand-shake is done, a special check for the SYN flag is added to the firewall code. Before the firewall code sees a SYN packet go through, it will drop all the packet for that flow. Additionally, when one side of the conversation sends a RST packet, the other side should not send out a packet. So when a BSN detects a RST packet for a conversation, it will start to drop all the following packets of that conversation. This will only take effect when the action resulting from the firewall rule match is allow. SYN packet processing - For each TCP flow, the Shasta firewall keeps a special state (here called sync state) for this feature. Its value is initialized to un-sync. At this state, any packet without a SYN flag will be dropped. Once a packet with the SYN flag is received, the state of that flow will be changed to synced. And all the following packets of that flow will be forwarded. RST packet processing - When the current sync state is synced, each packet will be checked for the RST flag. If such flag is detected, the sync state for the current flow and the other hconv will be changed to un-synced. Interaction with Tickle Mode - If the tickle mode is enabled, it takes effect when the result of rule match is drop. This new feature will only take effect when the result of rule match is allow. So no direct interaction will be involved. But when tickle mode allows a conversation, it should set the sync state of both direction flows to synced, so this new feature will not drop the packets. The only configuration for this feature is to enable/or disable it per firewall policy. Provisioning is done by means of the options menu in a firewall policy. Select the sync-defender-mode(disabled) or sync-defender-mode(enabled) option to enable/ disable the feature. The default state is disabled D Rev 00

43 Chapter 2 Security Policies 43 Examples of firewall policies As with all Shasta policies, security policies can be customized and applied to individual subscribers, or created as templates to be applied to many subscribers. The pre-defined network object _SubAddr is used throughout most firewall rules. The _SubAddr object resolves automatically to the IP address assigned to the subscriber. This applies to dynamic address (from pool, DHCP or RADIUS) or static address assigned upon provisioning. Using the _SubAddr object allows you to create a policy once, and apply it to multiple subscribers over different BSNs. Note: The following policies are meant as examples only and are not meant to cover every security contigency. Build security policies in accordance to your network requirements and/or individual subscribers. Figure 2 Residential Firewall Residential firewall example A residential firewall is generally a simple firewall designed to allow subscriber initiated traffic while blocking any incoming traffic or port scans. The following figure shows an example of a residential firewall. Look at the remarks column in the policy for an explanation of each rule. Shasta 5000 Broadband Service Node, Provisioning Service Policies

44 44 Chapter 2 Security Policies Telecommuter firewall example Telecommuter or Small Office - Home Office (SOHO) policies can allow for subscriber access to a VPN. This allows telecommuters to access a corporate network, or small businesses to network together remote sites. The following figure shows an example of a telecommuter firewall. Look at the remarks column in the policy for an explanation of each rule. Figure 3 Telecommuter firewall Business firewall example A business firewall requires a more complex rule configuration. A business user must have access to internal resources such as mail servers and web servers. The following figure shows an example of a business firewall. Look at the remarks column in the policy for an explanation of each rule D Rev 00

45 Chapter 2 Security Policies 45 Figure 4 Business firewall Shasta 5000 Broadband Service Node, Provisioning Service Policies

46 46 Chapter 2 Security Policies Anti-spoofing Spoof attacks involve sending acceptable looking traffic to the firewall but that can cause serious damage if allowed to enter the subscriber s network. Traffic from the spoof attacks appear to have a legitimate source IP address, which is acceptable to the firewall packet-checking process. However, typically the IP address has been obtained illegally or hijacked. Hijacking occurs when an attacker takes over an existing connection between two computers. Once the attacker determines the connection sequence numbers, the hacker can generate traffic that appears to come from one of the communicating parties. Anti-spoofing ensures protection from Internet attacks by preventing a malicious subscriber from masquerading as a third party. This is accomplished by filtering incoming traffic based on the expected source address or addresses of the subscriber s link. Anti-spoofing policies allow you to send sensitive data securely and to detect a possible intruder and prevent further tampering from the intruder. There are two types of anti-spoofing policies that you can build: anti-spoofing and ingress anti-spoofing. Both policies contain very specific rules. Other then to enable logging, the default policies cannot be changed. Anti-Spoofing policy example Anti-spoofing prevents a third party from impersonating a subscriber by ensuring that traffic going towards the subscriber from the internet is not misrepresented as traffic from a host on the subscribers network. This is accomplished by filtering the traffic to ensure that the source address of the traffic to the subscribers link does not match the subscribers address D Rev 00

47 Chapter 2 Security Policies 47 Figure 5 Anti-Spoofing policy Ingress Anti-Spoofing policy example Ingress anti-spoofing prevents a subscriber from impersonating someone else by ensuring that the traffic coming from the subscriber going to the Internet is not disguised as traffic coming from a host somewhere else in the Internet. This is accomplished by filtering outgoing traffic to ensure that the source address of the traffic from the subscriber link matches the subscribers address. The ingress anti-spoofing policy is used to ensure that packets received on the subscriber side interface have a source address that coincides with the set of addresses known to be located on the subscriber side of the BSN. Figure 6 Ingress anti-spoofing Shasta 5000 Broadband Service Node, Provisioning Service Policies

48 48 Chapter 2 Security Policies Flow Mirroring Flow Mirroring provides a copy of IP traffic to external servers. These servers perform security analysis on the replicated frames. The results of this analysis can be used to reconfigure other security related BSN services, such as the state-aware firewall, to block intruders. The external servers that would make use of the Flow Mirroring service at this time are Lawful Intercept (LI) and Intrusion Detection System (IDS) servers. Rules can be configured within the Flow Mirroring policy to replicate traffic in the Egress direction (traffic destined for a specific subscriber) and in the Ingress direction (traffic originating from a specific subscriber). The replicated IP frames can be forwarded over either Layer 3 IP address or Layer 2 connection. The choice of the forwarding method to use depends upon the level of required security and the ease of reachability. IP Address Based Forwarding - When the IP address based forwarding approach is used the LI and IDS servers can be located anywhere on the network. The IDS and LI servers must be reachable through IP forwarding and have an FIB entry in the ISP or Subscriber domain. The connection through which the IP packet is to be forwarded should be readily available by looking up the destination address in the FIB. The next hop address would be entered to the FIB either through static or by dynamic routing. If the configured forwarding address is not reachable, is not found in the FIB or the interface is down, the mirrored frame will be dropped. This approach will allow for both broadcast (Ethernet) and point to point (ATM VC) media to reach the servers. The main drawback of this forwarding approach is that the IP and MAC address of the LI and IDS servers has to be known making it less secure. Layer 2 Connection Based Forwarding - Compared to the IP Address based forwarding, the Layer 2 approach doesn't require any routing and the IDS and LI servers can listen in promiscuous mode. This forwarding approach is more secure as the servers are not visible on the network and operate on stealth mode. However, it would also limit the servers to listen only on broadcast medium such as Ethernet. A connection over which the IP frames are forwarded has to be provisioned and configured as a trunk connection D Rev 00

49 Chapter 2 Security Policies 49 Implementation considerations When deploying this service, you must engineer your platform to ensure adequate bandwidth both for subscribers as well as replicate traffic. Applying this policy will effectively double the amount of traffic for the monitored subscriber at the SSP. You must also ensure there is adequate bandwidth available at the connection to which the replicated traffic is being sent. Flow Mirroring policy example The Flow Mirroring has the same rule format as other services on the Shasta BSN, but with a different action. For the Flow Mirroring Policy, the action is to forward a copy of the traffic to a defined Next Hop. Different types of traffic can be replicated to different next hops dependant on the rules created. You can choose to perform one of the following three actions to a rule: Table 12 Flow Mirroring policy actions Action Dont_Mirror Mirror _Connection Mirror_IPAddress Description Allows specified traffic not to be replicated. Replicated traffic is sent to an IDS or LI server via a specified connection. This action requires you to select a predefined connection, or to create a new connection Replicated traffic is sent to an IDS or LI server via a specified connection. This action requires you to select a pre-defined host object, or create a new host object. Shasta 5000 Broadband Service Node, Provisioning Service Policies

50 50 Chapter 2 Security Policies The following figure is an example of a Flow Mirroring policy. Figure 7 Flow Mirroring policy example Distributed Denial of Service (DDOS) prevention The main scope of this feature takes two forms, the first being the ability to recognize when a DOS/DDOS attack is in effect to an end subscriber, and the second being able to take an action to control the attack once it's correctly identified. The former is often referred to as signature detection. The action taken may vary depending on the type of attack that is detected. What is Denial of Service? Denial of Service is characterized as a rogue attack on a network device by hogging the resources on the device thereby preventing, presumably legitimate users access to the said device. The distributed version of the attack refers to the simultaneous traffic generated by multiple machines to a single device on the network. This attack may be coordinated through a master program or through a specified time built into the programs used in the attack D Rev 00

51 Chapter 2 Security Policies 51 There are several versions of denial of service attacks: flooding a network with garbage data, preventing normal traffic exchange disrupting connections between machines, preventing access to service/s prevent a particular user from accessing a service/network entity Both the distributed denial of service attacks and its singular source of attack versions focus on disrupting network service. Preventing the occurrence of disruptions in a Shasta BSN-serviced network will greatly improve reliability of the network and also provide a new service for the Shasta BSN. Signature Recognition and Logging of Malformed Packets This section identifies the types of attacks that are detected. It is important to note that the Shasta 5000 BSN is able to block some of these attacks types via other security functionality (Anti-spoofing, dropping directed broadcasts, rate limiting etc), however the user receives no indication as such in most instances. Some common DOS/DDOS attacks are listed in table below. Table 13 DDOS attack definitions Attack Name/Tool Bonk/Boink/ Jolt/Jolt2/ TearDrop Type of Attack DOS Description IP Fragmentation attack Nestea DOS A variation of the IP fragmentation code and exploits the off-by-one IP header. Similar to the TearDrop attack. NewTear DOS An improvement on TearDrop on erroneous UDP packets still using the IP fragmentation bug exploited by TearDrop. The modified teardrop attack works by sending pairs of deliberately constructed IP fragments that are reassembled into an invalid UDP datagram. Overlapping offsets cause the second packet to overwrite data in the middle of the UDP header contained in the first packet in such a way that the datagrams are left incomplete. Land/ Latierra DOS The land attack aka latierra (latierra is a later version of land) will send a spoofed packet with the SYN flag set from a host, on an open port (such as 113 or 139), setting as source the SAME host and port (i.e.: :139 to :139). This will cause the target machine to lock up. Shasta 5000 Broadband Service Node, Provisioning Service Policies

52 52 Chapter 2 Security Policies Table 13 DDOS attack definitions Attack Name/Tool Ping of Death Smurf/ Fraggle Trinoo/TFN/ TFN2K/ Stacheldraht Type of Attack DOS DDOS DDOS Description Uses a ping system utility to create an IP packet that exceeds the maximum 65,536 bytes of data allowed by the IP specification. The oversize packet is then sent to an unsuspecting system. Systems may crash, hang, or reboot when they receive such a maliciously crafted packet. This attack is not new, and all OS vendors have fixes in place to handle the oversize packets. An ICMP echo (ping) traffic surge directed at IP broadcast addresses, with a spoofed source address. This potentially causes the routing device delivering the traffic to take the ICMP echo request and return an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, there could potentially be hundreds of machines to reply to each packet." Fraggle is the UDP version of Smurf. A root shell attack combination (SYN flood, ICMP flood, UDP flood and Smurf etc) with Stacheldraht the most sophisticated using encrypted communication between the master and the client machines used for attack. We concluded the detection of such complicated attacks is the job of intrusion detection device, not feasible for BSN. IP Fragmentation The denial of service attacks (Bonk, Boink, Jolt, Jolt2, TearDrop, NewTear and Nestea) are variations of exploits relying on the IP protocol stack mishandling the IP fragmentation and reassembly code. The DDOS feature counts the number of instances when the IP fragments processed have the signature of the listed attacks above. The reassembly code will also be verified for the fixes necessary for the prevention of the attacks. The simplest version of these attacks is implemented by simply sending 2 specially fragmented IP datagrams. The first is the 0 offset fragment with a payload of size N, with the MF bit on (data content is irrelevant). The second is the last fragment (MF == 0) with a positive offset < N and with a payload of < N. The reason why it cripples systems is that the reassembly will end up copying too much data and overwriting the buffer for the packet that is being reassembled D Rev 00

53 Chapter 2 Security Policies 53 ICMP and UDP Echo Broadcast Currently the BSN does not forward direct broadcast to its local interfaces. Therefore the subscribers are already protected from Smurf/Fraggle based attacks. The DDOS feature will further prevent the BSN from forwarding any broadcasting ICMP (echo) and UDP (echo, daytime, qotd, chargen) traffic. Because the BSN has no foreknowledge of the remote node's network mask, we only stop the aforementioned broadcasting traffic if it is destined to standard A/B/ C class broadcasting addresses. Statistics will be kept for this attack. Syn Flood Detection and Prevention through TCP Proxies and Splicing The DDOS feature focuses on detecting and stopping SYN flood attacks by handling the delayed binding of SYN requests. Users are allowed to set up a number of SYNs that can be in the connection queue and also the time-out period for these connections. The SYNs are acknowledged using the TCP Proxy and Splicing APIs. The detection of denial-of-service attacks' signature is the second component of the DDOS service. It also includes keeping statistics of the recognized attacks and dropping the packets recognized as part of the attack. This enhancement is not configurable and is always on. Delayed Binding Delayed binding prevents SYN flood by using a two-stage connection scheme. The first stage ensures that the SYNs are correctly followed by valid ACKs. The second stage completes the connection by sending a SYN to the server-side of the connection. The TCP connection is marked as spliced when this SYN is acknowledged By decoupling the client and server side verification, delayed binding can prevent numerous SYNs from flooding the server side. Shasta 5000 Broadband Service Node, Provisioning Service Policies

54 54 Chapter 2 Security Policies When Delayed Binding is turned on Delayed binding is triggered through two mechanisms: 1) over a configured time period, the total incoming SYNs is compared with a high-water mark. If it is greater than what is specified, delayed binding is turned on, and 2) if during incrementing the SYNs received, the rate is greater than the specified SYN rate, delayed binding is also turned on. If the high-water mark is configured to be lower than the low-water mark, the SCS should flag this as an error and will also be checked by the policy parsing code for DDOS. When Delayed Binding is turned off Delayed binding is turned off when the SYN counter task recognizes that the number of incoming SYNs in the last 30 seconds is less than the low-water mark. Support for TCP Proxies A set of functions to terminate a TCP connection, temporarily buffer and acknowledge packets, modify data in packets and transmit (and retransmit) packets to the server. Support for TCP Splicing A set of functions to support splicing of two TCP connections. These functions will set up a splice and after that the header manipulation functions will be used to pass packets from one connection to the others. It is again emphasized that TCP Splicing will not be implemented as a service. A service may call these functions. After an initial setup, this library is simply used to manipulate packets. The is also support for the transition from proxy phase to splicing phase. DDOS policy example Unlike other service policies, the DDOS policy configuration dialog does not contain a table and has no rules. The parameters configured via this policy are as follows: High water mark D Rev 00

55 Chapter 2 Security Policies 55 Low water mark SYN rate Timer interval For user defined DDoS policy, either the high water mark or the SYN rate has to be greater than zero. Timer interval should always be greater than 0. Currently, all traffic coming from and going to the subscriber is checked for DDOS attacks. In the future, this may be modified to support rules so that only certain src/destination pairs or particular TCP-based protocols have to undergo delayed binding. The following figure showes a DDOS prevention policy with the default parameters. Figure 8 DDOS prevention policy example Authentication, Authorization, and Accounting Service providers verify the identity of users requesting access to their networks. Information used for this identification process is commonly stored in an Authentication, Authorization, and Accounting (AAA) server, such as a RADIUS server. This information can include usernames and passwords, and SecureID tokens. Shasta 5000 Broadband Service Node, Provisioning Service Policies

56 56 Chapter 2 Security Policies The Shasta BSN supports several forms of authentication, depending on the access method and protocol used. For instance: Point-to-Point Protocol (PPP) end-user authentication PAP and CHAP password authentication. Captive portal and PPP authentication PAP and CHAP password authentication as well as SecureID cards. The Shasta BSN provides a single point of integration with existing back-office systems. For instance: PPPoE, PPPoA, and L2TP the Shasta BSN acts as a RADIUS proxy bridged and routed environments subscriber sessions are redirected to a captive portal server on the service provider premises. Through the user s http connection, the Shasta BSN directs authentication to a Web page in which the user can enter user ID and password or SecureID card values. The captive portal server signals to the Shasta BSN successful authentication. Virtual Private Networks (VPN) authentication previously shared keys are used for Internet Key Exchange (IKE) authentication. Note: Procedures for provisioning AAA for subscribers can be found in Shasta 5000 Broadband Service Node, Provisioning Subscribers, Release 4.0 (part number A) Network Address Translation Network Address Translation (NAT) allows private networks to be directly configured as subscribers on the Shasta BSN, thereby conserving private IP addresses and providing additional security by hiding internal IP addresses. NAT provides multiple benefits, including: The ability to network multiple sites with overlapping private address ranges Added security for servers on a private network Conservation of public IP address space D Rev 00

57 Chapter 2 Security Policies 57 Using NAT, an ISP can create a pool of registered IP network addresses that the router maps to your unregistered local addresses. Where a company does not have enough globally unique IP addresses for each host on its network, NAT can assign a global IP address to hosts as needed. Similarly, a company using unregistered addressing on its internal network can use NAT to translate those unregistered addresses into registered addresses for making external connections. A NAT gateway exists between a private network and a public network, to ensure that traffic crossing the boundary will be routed correctly in each network. Directly connected NAT Private networks can be directly configured as subscribers on the BSN, and have their IP addresses hidden from the internal BSN FIB. For ISP only subscribers, the addresses can be hidden from the ISP context. For VRN + Internet subscribers, the subscribers address can be selectively hidden from the ISP context or VPN. The same private address range can be added multiple times on the same BSN, as long as they are marked hidden. Each subscriber can be added to the Shasta BSN as a complete private subnet. For this method of deployment, individual bridge subnet subscribers are added. The subscriber address is simply added to match the customer s private network and the address marked as hidden. The subscriber does not need to be added to an existing bridge group with specific address ranges for the interface. NAT Policy Rules NAT policies are defined with rules for mapping between public and private networks. Each subscriber that supports a private network that needs to be hidden has to be linked to a NAT policy. This NAT policy defines how to map between the subscriber s hidden private addresses and public addresses. NAT policies follow the standard rule matching process. Shasta supports different types of NAT based on the rules that are defined for each policy. Rules defined in a NAT policy apply only to the first packet of a new session. Shasta 5000 Broadband Service Node, Provisioning Service Policies

58 58 Chapter 2 Security Policies NAT policies can be created with reserved objects such as _HiddenAddr, _PublicAddr, and _subaddr. The values of the reserved objects in the NAT policy are automatically propagated once the policy is linked to a subscriber. Abstracts can also be used to represent a public address of the NAT policy if required. The following NAT rules can be defined for subscribers: Table 14 NAT policy types NAT Rules M to 1 Source NAT with PAT M to N Source NAT with PAT Definition Rules are defined to translate many hidden private addresses to one public address. These rules only apply to sessions generated from the subscribers private network. These rules apply Port Address Translation. Similar to M to 1 Source NAT with PAT, the difference being that rules are defined to translate many hidden private addresses to many public addresses, instead of just one. These rules only apply to sessions generated from the subscribers private network, and they apply Port Address Translation. 1 to 1 NAT Rules are defined to translate one private address to one public address. No Port mapping is required. Two rules should be defined: one rule defines the source address from the private server to the public network, and the other rule defines the destination address of sessions initiated from the public network to the private server. For more inforamtion, see: M to 1 Source NAT with PAT on page 58 M to N Source NAT with PAT on page 62 1 to 1 Source and Destination NAT on page 62 M to 1 Source NAT with PAT This method of NAT can map multiple private IP addresses to a single public address, conserving public IP addresses. Along with translating the IP address, this method requires Port Address Translation (PAT). Two actions take place in the NAT gateway when sessions are initiated from the private network: The private IP address is mapped to the public IP address D Rev 00

59 Chapter 2 Security Policies 59 The private source port is mapped to a unique port number for the public IP address. Any return traffic for this session (from the public network to the private network) will use a combination of the public IP address and the public port to identify the private IP address and the private port. The following figure shows M to 1 NAT in a network. Figure 9 M to 1 Source NAT Private Network Public Network Src :1258 Dst :80 Src :80 Dst :1258 Src :1500 Dst :80 Src :80 Dst :1500 NAT-Table Private IP / Port Public IP / Port : :1500 Source NAT is used for sessions initiated from the subscribers private network to the public network. In a Source NAT policy, if an outgoing session has a source address that matches a rule in the policy, then the source address of the first rule in the policy us translated to the corresponding public address, and a public port is dynamically selected for the session. Return traffic from the same session will have the inverse rule applied to the destination address. The following figure shows an example of a NAT policy with M to 1 NAT rules. Shasta 5000 Broadband Service Node, Provisioning Service Policies

60 60 Chapter 2 Security Policies Figure 10 M to 1 Source NAT policy example Rules should be defined with the source, destination, service, and action fields according to the following parameters: Source - The Source field represents addresses in the private network and can be defined as any one of: A private network: the base IP address ad netmask must be defined in the policy. A range of IP addresses: the start and end of the range must be defined in the policy. A _HiddenAddr: This is a reserved object. The value is automatically propagated with the reachability information which is added in the subscriber configuration addressing tab, and marked as hidden. If there are no hidden reachabilities defined for the subscriber, then this object is undefined for the subscriber, and there will never be a match for this rule. The _HiddenAddr object allows you to define private address ranges within a VPN, and only provide NAT functionality for traffic to the Internet. When reachability information is added for a VPN + Internet subscriber, the route can be marked with one of the following combinations: D Rev 00

61 Chapter 2 Security Policies 61 Table 15 HiddenAddroptions HiddenAddr option Description Not hidden from VPN or Internet The address range is not hidden and therefore requires no NAT function. Hidden only from Internet The address range is hidden only from the Internet, so the NAT function acts on traffic from this range to the Internet. Traffic from this address range to the VPN requires no NAT function. Hidden only from VPN Hidden from both the VPN and the Internet The address range is only hidden from the VPN, so NAT function only acts on traffic from this address range to the VPN. Traffic from this address range to the Internet requires no translation. This address range is hidden from both the VPN and Internet, so NAT function works on all traffic from the subscriber. Destination - The Destination field can be defined as: Any (meaning any destination outside the subscriber) A specific network or range The reachable addresses within a VPN Service - The Service field can be defined as: Any Defined for specific protocols Action - The Action is defined as translate_src_to(). This action can be defined with: A specific IP address, with which the policy can be applied to only one subscriber, as public address defined in NAT policies must be unique. An abstract object, in which the value of the public IP address is only required when the policy is applied to a subscriber. The use of an abstract allows the same policy to be used for multiple subscribers with the same private IP ranges, but different public IP addresses. Shasta 5000 Broadband Service Node, Provisioning Service Policies

62 62 Chapter 2 Security Policies M to N Source NAT with PAT M to N Source NAT with PAT (NAPT) is similar to M to 1 Source NAT with PAT. The only difference is that the address specified in the "translate_src_to" (NAPT) is a range of addresses instead of one address. For example, a user can define a range, to , as a scope object. Then, in the subscriber configuration, the Public Addresses should be entered as Start Address: and Number of Addresses: 5. For the NAT policy rules, the rule could be entered as: Source = _HiddenAddr Destination = Any Service = Any Action = translate_src_to (NatPubRange5_ ) 1 to 1 Source and Destination NAT This is the simplest form of NAT in which one public address is used to map each private address. Only the IP address are mapped during this NAT function, no port mapping is required. 1 to 1 NAT is used to map individual servers on a private network to a public address. Each private address to public address mapping entry must be defined for each server on the private network that needs to be accessible from the public network. 1 to 1 Source NAT is used for traffic from the private network to the public network. The NAT gateway translates the source IP address from the private IP address to the public IP address. 1 to 1 Destination NAT is used for traffic from the public network to the private network. The NAT gateway translates the destination IP address from the public IP address to the private IP address. For traffic from the private server to the public network, the source IP address is mapped from the private IP address to the corresponding public IP address. For traffic from the public network to the private server, the destination IP address is mapped from the public address to the private IP address of the server. The port number is never changed. The following figure demonstrates 1 to 1 NAT in a network D Rev 00

63 Chapter 2 Security Policies 63 Figure 11 1 to 1 NAT Private Network Public Network Src :1258 Dst :80 Src :80 Dst :1258 Src :1258 Dst :80 Src :80 Dst :1258 NAT-Table Private IP / Port Public IP / Port :* :* The rules defined in the NAT policy are only used for the first packet of any new session. Therefore, for each server on the private network that requires access from the public network, there should be two rules defined: one rule defines the source address translation of sessions initiated from the private server to the public network (1 to 1 Source NAT), and the second rule defines the destination address translation of sessions initiated from the public network to the private server (1 to 1 destination NAT). The following figure shows an example of a NAT policy with 1 to 1 Source and Destination NAT rules. Shasta 5000 Broadband Service Node, Provisioning Service Policies

64 64 Chapter 2 Security Policies Figure 12 1 to 1 NAT policy example Rules should be defined with the source, destination, service, and action fields according to the following parameters: 1 to 1 Source NAT Source - The Source field must be defined as the private IP address of the server that needs to be accessed from the public network. Destination - The Destination field can be defined as: Any (meaning any destination outside the subscriber) A specific network or range The reachable addresses within a VPN Service - The Service field can be defined as: Any Defined for specific protocols Action - The Action is defined as map_src_to(). When this action is selected, the public IP address corresponding to the private server must be defined D Rev 00

65 Chapter 2 Security Policies 65 1 to 1 Destination NAT Source - The Source field can be defined as Any (meaning any destination outside the subscriber). Destination - The Destination field must be defined as the public IP address corresponding to the private server that needs to be accessed from the public network. Service - The Service field can be defined as: Any Defined for specific protocols Action - The Action is defined as map_dst_to(). When this action is selected, the private IP address of the server must be defined. NAT Policy Example The following figure is an example of two private networks with the same address range, connected to a single BSN via 1483 Bridge connections. Figure 13 Private networks with overlapping address range Company A xxx/24 Server A Workstation A HTTP 1 : Port 80 FTP : Port 21 Company B xxx/24 Server B Workstation B HTTP 1 : Port 80 HTTP 2 : Port 8080 FTP : Port 21 Telnet : Port 23 Workstation A3 Bridge Workstation A / Bridge /29 Workstation B3 Workstation B Shasta 5000 Broadband Service Node, Provisioning Service Policies

66 66 Chapter 2 Security Policies The policy in the following figure is defined for Company A to allow Server A and PC workstation A1 to be accessible from the public network, as well as to allow other devices on the private network to initiate outgoing sessions to the public network. Following is a description of each rule: Table 16 NAT policy example rule descriptions Rule Number Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 description Allows PC A1 to access the public network as public IP address Port addresses are not changed. Allows PC A1 to be accessed from the public network as public IP address Port addresses are not changed. Allows Server A to access the public network as public IP address Port addresses are not changed. Allows Server A to be accessed from the public network as public IP address Port addresses are not changed. Explicit rules with specific port numbers can also be configured for the HTTP and FTP servers. Allows all devices in Company A to access the public network as public IP address Port address translation is dynamically selected for each outgoing session D Rev 00

67 Chapter 2 Security Policies 67 Figure 14 NAT policy example Group NAT Group NAT provides the capability to hide a group of subscribers with private IP addresses behind a group of public addresses. The same public address or range can be shared across multiple subscribers, even if the subscribers exist on different SSPs. This method of NAT maps multiple private address to multiple public addresses. The number of private addresses (M) is greater then the number of public addresses (N). This method also requires PAT. Group NAT provides the following capabilities and benefits: M to N Source Network Address and Port Translation (NAPT). The ability to share the same public address across multiple NAT subscribers. The ability to maximize efficiency of public address space (i.e. avoid having to allocate dedicated public addresses to small subscriber sites). Shasta 5000 Broadband Service Node, Provisioning Service Policies

68 68 Chapter 2 Security Policies The ability to minimize operational/configuration overheads for subscribers with private addresses that only require Source NAT (No need link a NAT policy of public address to a subscriber). The ability to partition groups of public and private IP Address Pools into Access Groups. This provides the ability to allocate each Address Pool to specific contexts for better address management. The ability to apply NAT to template subscribers such as dynamic IPDemux children, PPPoE and PPP/L2TP. For subscribers and networks that connect to the Shasta BSN using public addresses, the subscriber addresses and reachability is propagated onto the FIBs for the contexts of the ISP and/or VPN. When a subscriber is configured as hidden, the subscribers private address should not be visible external to the system, and therefore not propagated into the FIB or routing tables. Caution: Note to users attempting to configure a GroupNAT pool and a Destination NAT policy together on a subscriber. If you want to add a Destination NAT policy onto a subscriber associated with a GroupNATpool, in order to allow a subscriber to be accessible from the public network, one must ensure that the address range for the GroupNAT does not overlap with the subscribers _PublicAddr (public address) defined for the NAT policy in the subscriber addressing window. In addition, the NAT policy cannot be setup to perform SourceNAT since that interferes with the GroupNAT's source NAT function. The NAT policy must be setup only to perform the Destination NAT with a rule such as the following: Source = any Destination = PublicAddr Service = ftp Action = map_dst_to(private_addr_x) If this is not followed then it will result in packet drops for the subscriber D Rev 00

69 Chapter 2 Security Policies 69 Subscriber Contexts There are different types of contexts that a subscriber can belong to. The type of context a subscriber belongs to will affect how Group NAT is configured for the subscriber. The following context FIBs are populated for the different types of subs: ISP only context When an ISP only subscriber is marked as hidden, all addresses of the subscriber and all hidden reachability defined for the subscriber will be hidden from the ISP context, and all traffic from the subscriber to the ISP context will have NAT performed. There are two ways of marking the subscriber as hidden, depending on the type of subscriber. The two options are: Configure the subscriber as Hidden from ISP under the Addressing tab of the Subscriber configuration GUI. A NAT Group object will have to be linked to the subscriber. Allow the subscriber to be allocated an IP address from a local Address Pool marked as Hidden from ISP and linked to a NAT Group object. VPN only context When a VPN only subscriber is marked as hidden, all addresses of the subscriber and all hidden reachability defined for the subscriber will be hidden from the VPN context, and all traffic from the subscriber to the VPN Context must have NAT performed. There are two ways of marking the subscriber as hidden. The two options are: Configure the subscriber as Hidden from VPN under the Addressing tab of the Subscriber configuration GUI. A NAT Group object will have to be linked to the subscriber. Allow the subscriber to be allocated an IP address from a local Address Pool marked as Hidden from VPN and linked to a NAT Group object. Shasta 5000 Broadband Service Node, Provisioning Service Policies

70 70 Chapter 2 Security Policies VPN + Internet context For a VPN + I subscriber there is the option of hiding the subscriber addresses and reachability from the ISP context or from the VPN context. Both of these options are independent. In the case where the subscriber is hidden from both the VPN and ISP context, different NAT Group objects can be used for traffic to the ISP and for traffic to the VPN context. When an VPN + I subscriber is marked as Hidden from ISP, all addresses of the subscriber will be hidden from the ISP context, and all traffic from the subscriber to the ISP Context will have NAT performed. There are two ways of marking the subscriber as Hidden from ISP, depending on the type of subscriber as described in previous sections. The two options are: Configure the subscriber as Hidden from ISP under the Addressing tab of the Subscriber configuration GUI. A NAT Group object will have to be linked to the subscriber specifically for traffic to the ISP. Allow the subscriber to be allocated an IP address from a local Address Pool marked as Hidden from ISP and linked to a NAT Group object specifically for traffic to the ISP. When an VPN + I subscriber is marked as Hidden from VPN, all addresses of the subscriber must be hidden from the VPN context, and all traffic from the subscriber to the VPN Context will have NAT performed. There are two ways of marking the subscriber as Hidden from VPN, depending on the type of subscriber as described in previous sections. The two options are: Configure the subscriber as Hidden from VPN under the Addressing tab of the Subscriber configuration GUI. A NAT Group object will have to be linked to the subscriber specifically for traffic to the VPN. Αllow the subscriber to be allocated an IP address from a local Address Pool marked as Hidden from VPN and linked to a NAT Group object specifically for traffic to the VPN D Rev 00

71 Chapter 2 Security Policies 71 Group NAT Configuration Group NAT configuration does not require a service policy as does legacy NAT. To configure group NAT, you build Group NAT objects and assign then to access groups in the corresponding context of ISP, VPN, or VPN+I. The configurable parameters for Group NAT are: Access Groups for Group NAT on page 72 NAT Groups on page 71 Local Address Pools with Group NAT on page 72 Group NAT Subscriber Configuration on page 72 NAT Groups NAT groups objects specify a name and single range of addresses that is used when hiding all the members of that group, specifically, subscribers with private addresses. Each NAT group object is linked to a specific Access Group to define which VPN or ISP context the group of public addresses belongs to. NAT groups are configured via the Device level Access Properties as shown in the following figure. Figure 15 NAT Group Object Shasta 5000 Broadband Service Node, Provisioning Service Policies

72 72 Chapter 2 Security Policies Access Groups for Group NAT Access Groups provide the means to apply profiles (RADIOUS, DHCP, IGMP, etc.) to groups of subscribers. Access Groups can belong to any of the context of ISP only, VPN only, or VPN+I. Access Groups provide the capability to partition groups of private and public addresses. Subscribers are assigned to an Access Group, which is bound to a NAT Group object. Local Address Pools with Group NAT Address Pools can be configured to allow addresses to be hidden from the ISP context for VPN +I and ISP only subscribers, or hidden from the VPN context for VPN+I or VPN only subscribers. This allows private IP addresses to be configured in the Address Pools by allowing these addresses to be hidden. If the Address Pool is hidden from either the ISP or VPN, it must be linked to a NAT Group object. A single address pool can be configured with NAT Group objects for Hidden from ISP and Hidden from VPN. This allows different public addresses to be used to NAT traffic to the ISP context, and to NAT traffic to the VPN context. These NAT group objects must belong to the same Access Group as the Address pool. Address pools are used for template subscribers. Group NAT Subscriber Configuration For non-template subscribers, the Addressing tab of the subscriber configuration GUI provides the capability to selectively hide the subscribers address from either the ISP context, or the VPN context. A NAT Group object can be linked to a subscriber with a hidden address. Different NAT Group objects can be linked for Hidden from ISP, or Hidden from VPN. This allows different public address ranges to be used to NAT traffic to the ISP context, and to NAT traffic to the VPN context. These NAT Groups must belong to the same Access Group as the subscriber D Rev 00

73 Subscriber Reachability with Group NAT Chapter 2 Security Policies 73 When a subscriber is configured as hidden, the addresses assigned to the subscriber are hidden from the FIB, and propagated into the _HiddenAddr reserved object of the implicit NAT policy applied to the subscriber. Traffic from the subscriber to the network with a source address matching the _HiddenAddr object will have NAT performed. Traffic from the subscriber with a source address not matching this reserved object will NOT have NAT performed. Reachability configured for a subscriber can optionally be configured as hidden. If the reachability is configured as hidden, it will be hidden from the context FIB and propagated into the _HiddenAddr object. All traffic with a source address matching this hidden reachability will have NAT performed. If reachability is not configured as hidden, it will be propagated into the FIB, and NAT will not be performed on traffic with a source address matching this reachability. If Group NAT is configured for a subscriber it cannot be assumed that all traffic from the subscriber will have NAT performed. NAT will only be performed on traffic from the subscriber with a source address matching the _HiddenAddr reserved object. This object only contains addresses and reachability for a subscriber configured as hidden. Traffic from a subscriber with a source address not matching this _HiddenAddr reserved object will not have NAT performed. Implicit Rules for Group NAT With Group NAT, an implicit policy is added to a subscriber that is linked to a NAT object, whether the link is configured in the Subscriber GUI, or by allocation of an IP address from a local Address Pool. The rules differ dependant on whether the subscriber is ISP only, VPN only, or VPN +I. The rules also differ based on whether the subscriber is hidden from the ISP context, hidden from the VPN context, or hidden from both. Theses implicit rules do not need to be configured in the Service Policy Manager, they are added automatically to a subscriber configured as hidden. The implicit rules are as follows: ISP only subscriber linked to NAT Group object: Source Destination Type Action _HiddenAddr Any Any translate_src_to (NAT Group Object) Shasta 5000 Broadband Service Node, Provisioning Service Policies

74 74 Chapter 2 Security Policies VPN only subscriber linked to NAT Group object: Source Destination Type Action _HiddenAddr Any Any translate_src_to (NAT Group Object) VPN + I subscriber, hidden from ISP context, not hidden from VPN context Source Destination Type Action _HiddenAddr ISP Context Any translate_src_to (NAT Group Object) *in which the NAT Group object corresponds to Hidden from ISP VPN + I subscriber, hidden from both ISP and VPN context Source Destination Type Action _HiddenAddr * addresses configured as hidden from VPN context _HiddenAddr * addresses configured as hidden from ISP context VPN Context Any translate_src_to (NAT Group Object) *in which the NAT Group object corresponds to Hidden from VPN ISP Context Any translate_src_to (NAT Group Object) *in which the NAT Group object corresponds to Hidden from ISP VPN + I subscriber, not hidden from ISP context, hidden from VPN context Source Destination Type Action _HiddenAddr VPN Context Any translate_src_to (NAT Group Object) *in which the reserved object corresponds to addresses configured as hidden from the VPN context D Rev 00

75 75 Chapter 3 Traffic Management Policies The following topics explains the traffic management capabilities within the Shasta 5000 BSN, and describe how to implement them in your network. The need for traffic management comes with network oversubscription, in which voice, video, and data traffic compete for bandwidth. Service Providers that can effectively manage traffic through their network can offer Quality of Service (QoS) guarantees to subscribers in the form of Service Level Agreements (SLAs). Quality of Service in a network means providing end-to-end traffic prioritization and queuing that guarantees both delay and bandwidth. Shasta implements QoS at the subscriber edge, with application-based subscriber specific policies. Topics in this chapter: Traffic Management Overview on page 76 Ingress Traffic Management on page 76 Egress Traffic Management on page 85 Flow Management on page 91 See also: For procedures on provisioning Traffic Management policies, see Provisioning Traffic Management Policies on page 156, including the following procedures: Create a DiffServ Policy on page 156 Create a Policing Policy on page 158 Create an Egress DiffServ Policy on page 160 Create a AF Class Based Traffic Shaping Policy on page 161 Create a Flow Based Traffic Shaping Policy on page 163 Shasta 5000 Broadband Service Node, Provisioning Service Policies

76 76 Chapter 3 Traffic Management Policies Traffic Management Overview The Shasta BSN provides tools that allow for prioritization of the traffic flow to and from the service providers backbone network. Efficient use of these tools enables the service provider to prioritize applications and subscribers, offering some control over bandwidth, latency, jitter, and packet loss. The Shasta BSN implements Quality of Service (QoS) by providing support for the Differentiated Service (DiffServ) architecture. A DiffServ architecture enables service discrimination of traffic flows or microflows by offering network resources higher classes of service at the expense of lower classes of service. This architecture lets you prioritize a microflow or aggregate flow and provides scalable IP QoS. In the ingress direction, DiffServ can be applied with Policing policies to enforce bandwidth according to a subscribers Service Level Agreement (SLA). Egress DiffServ is applied with Traffic Shaping policies to guarantee subscribers bandwidth. For more information, see: Ingress Traffic Management Egress Traffic Management Flow Management Ingress Traffic Management Ingress Traffic Management is applied to the traffic flow from the Shasta BSN out to the service providers network. The following features are implemented in the ingress direction: Mapping the various DSCP classes into different ATM virtual circuits (VCs), or weights on Ethernet connections Weighted Random Early Detection (WRED) Policing, including metering, marking (DiffServ), and tagging D Rev 00

77 Chapter 3 Traffic Management Policies 77 Differentiated Services Differentiated Services, or DiffServ, is a means to manipulate the ToS byte in the IP Header to allow for prioritization of traffic into separate queues. Diffserv Marking permits stamping different traffic flows with a DiffServ code point (DSCP) in the IP header to determine the Per-Hop Behavior (PHB) of an IP Packet. Once the DiffServ Type of Service (TOS) byte is set, routers within the network core use this information to queue and or discard traffic in different ways. Based on the Ingress DiffServ marking policy specifications, the packets are marked and classified into one of the eight possible DSCP/IP Precedence packets. The DiffServ architecture is based on a simple model where traffic entering a network is conditioned at the edges of the network, and assigned to a different behavior aggregate. Each behavior aggregate is identified by a set of DiffServ Code Points. Within the core of the network, packets are forwarded according to the Per-Hop Behavior (PHB) associated with the DiffServ Code Point. This allows a service provider to provision a subscriber for time sensitive traffic such as voice and video, along with data traffic. A DiffServ marking policy applies to traffic traveling from the ISP where the Shasta BSN resides out to the service provider network and is used in conjunction with Policing to manage traffic congestion. Note: Assured Forwarding classes and Non-Assured Forwarding classes Per Hop Behavior (PHB) are achieved only in conjunction with other QoS modules like AF Policer and Traffic Shaper, not simply by having egress/ ingress marking. Defining DiffServ Classes and Drop Precedence Shasta DiffServ works in accordance with the IETF specification for a DiffServ architecture by defining eight Class of Service (CoS) classes as follows: Shasta 5000 Broadband Service Node, Provisioning Service Policies

78 78 Chapter 3 Traffic Management Policies Table 17 DiffServ Code Points DiffServ Code Points Class Selector 7 (CS7) Class Selector 6 (CS6) Expedited Forwarding (EF) Assured Forwarding Class 4 (AF4) Assured Forwarding Class 3 (AF3) Assured Forwarding Class 2 (AF2) Assured Forwarding Class 1 (AF1) Default Forwarding (DE) The four Assured Forwarding (AF) classes, AF 1-4, allow for three Drop Precedences, DP 1-3. Assured Forwarding Classes - Assured Forwarding classes are defined on the Trunk connection. The heavier the assigned weight to a queue, the higher the precedence of that queue in relation to the others. Weighting gives each queue a relative percentage of the bandwidth during any congested period of service. Apply a DiffServ policy in conjunction with setting the AF weights on your trunk connection. In accordance to industry standards, make sure AF4 is weighted with the highest priority, and AF1 with the lowest. Drop Precedence - The Drop Precedence defines how likely the traffic is to be dropped in times of congestion. Non-AF Classes - When packets are marked into classes other than AF, the packets are dropped if they fall in the RED region. The packets are allowed or dropped randomly if they are in the YELLOW region. The packets are allowed if they are in the GREEN region. DiffServ Policy Rules DiffServ policy rules follow the rule matching policy described in Rules matching process on page 33. Policy rules consist of Source, Destination, Service, Action, Log, and Remark columns D Rev 00

79 Chapter 3 Traffic Management Policies 79 DiffServ actions require the use of a DiffServ Action Object. See Chapter 1, Introduction to Service Policies, on page 23 for an explanation of Service Objects. The following actions are defined for DiffServ. Marking Change the packet s actual DSCP value, choose from a range of predefined AF code point objects, configure an IP precedence value, configure any DSCP codepoint value from the CS7, CS6, EF and DE classes. Aliasing Used only by Shasta BSN QoS modules, packet s original DSCP value is not modified, but the actions on the packets are exactly the same as if they were marked in all the Shasta BSN QoS modules like Traffic Policer, AF shaper and Trunk VC QoS Mapping. The following figure shows an example of a DiffServ policy. Higher priority traffic such as voice and video are marked into higher priority queues. Figure 16 DiffServ Policy Example Traffic Policing Traffic Policing lets you define the type and relevant amount of traffic a subscriber can transmit and receive and is applied to a subscriber in the ingress direction only. The policing function protects the network core from traffic in excess of the subscriber s contracted rate. The policing function relies on the results of the DiffServ marking in conjunction with bandwidth limits to set different drop priorities. Shasta 5000 Broadband Service Node, Provisioning Service Policies

80 80 Chapter 3 Traffic Management Policies Rules are applied as to what happens with excess traffic in these categories. The committed rate, committed burst size, peak rate, and peak burst size thresholds are set with corresponding actions. For each of the action categories, designated as red, yellow, or green, the actions include setting the drop or IP precedence, and dropping the packet. A packet is marked red if it exceeds the set PIR. Otherwise it is marked yellow or green depending on whether it exceeds or does not exceed the CIR. There are two type of policers: Single rate, three color marker (RFC 2697) Two rate, three color marker (RFC 2698) Rate markers mark packets based on two rates, the peak information rate (PIR) and the committed information rate (CIR). The rates and actions are associated with each of the eight DSCP/IP Precedence classes. Single rate, three-color marker The Single Rate Three Color Marker (srtcm) meters an IP packet stream and marks its packets either green, yellow, or red. Marking is based on a Committed Information Rate (CIR) and two associated burst sizes, a Committed Burst Size (CBS) and an Excess Burst Size (EBS). A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise. The srtcm is useful, for example, for ingress policing of a service, where only the length, not the peak rate, of the burst determines service eligibility. The srtcm is configured by setting its mode and by assigning values to three traffic parameters: a Committed Information Rate (CIR), a Committed Burst Size (CBS), and an Excess Burst Size (EBS) Table 18 srtcm color definitions Color Green Condition The packet is within CBS over CIR D Rev 00

81 Chapter 3 Traffic Management Policies 81 Table 18 srtcm color definitions Color Yellow Red Condition The packet exceeds the CBS over CIR, but not EBS over CIR The packet exceeds CBS and/or EBS (whichever is greater) over CIR The following figure shows the allowable burst rates compared to the committed rate. Figure 17 srtcm bursts Over Excess Burst Red Excess Burst Yellow Committed Burst Green Committed Rate The CIR is measured in bytes of IP packets per second, i.e., it includes the IP header, but not link specific headers. The CBS and the EBS and are measured in bytes. The CBS and EBS must be configured so that at least one of them is larger than 0. It is recommended that when the value of the CBS or the EBS is larger than 0, it is larger than or equal to the size of the largest possible IP packet in the stream. Shasta 5000 Broadband Service Node, Provisioning Service Policies

82 82 Chapter 3 Traffic Management Policies Figure 18 Single Rate Three Color Marker example Two rate, three-color marker The Two Rate Three Color Marker (trtcm) meters an IP packet stream and marks its packets either green, yellow, or red. A packet is marked red if it exceeds the Peak Information Rate (PIR). Otherwise it is marked either yellow or green depending on whether it exceeds or doesn't exceed the Committed Information Rate (CIR). The trtcm is useful, for example, for ingress policing of a service, where a peak rate needs to be enforced separately from a committed rate. The trtcm is configured by setting its mode and by assigning values to four traffic parameters: a Peak Information Rate (PIR) and its associated Peak Burst Size (PBS) and a Committed Information Rate (CIR) and its associated Committed Burst Size (CBS) D Rev 00

83 Chapter 3 Traffic Management Policies 83 Table 19 trtcm color definitions Color Green Yellow Red Condition The packet is within CIR plus CBS. The packet exceeds the CIR plus CBS, but within PIR plus PBS. The packet exceeds the CIR and CBS. The following figure shows the allowable burst rates compared to the committed rate. Figure 19 trtcm bursts Over Peak Burst Red Peak Burst Yellow Committed Burst Green Committed Rate Peak Rate The PIR and CIR are measured in bytes of IP packets per second, i.e., it includes the IP header, but not link specific headers. The PIR must be equal to or greater than the CIR. Shasta 5000 Broadband Service Node, Provisioning Service Policies

84 84 Chapter 3 Traffic Management Policies The PBS and the CBS and are measured in bytes and both of them must be configured to be greater than 0. It is recommended that they be configured to be equal to or greater than the size of the largest possible IP packet in the stream. Ingress Processing Subscriber traffic coming into the network undergoes the following traffic management and QoS processing: 1 After subscriber traffic passes through an anti-spoofing policy, which discards any traffic sourced from the subscriber with an IP network address different from that officially assigned, it enters the traffic management process. 2 The DiffServ ToS byte is set to mark (or re-mark) traffic to distinguish different traffic types from one another for instance, ftp, smtp, and H.323. This process allows the network service provider to price different service classes depending on how it treats the subscriber s traffic. When the DiffServ ToS byte is set, routers within the network core use the information to queue and/or discard the traffic in different ways. 3 The policing function is used to set drop priorities. This function protects the network core from traffic in excess of the subscriber s contracted rate. It uses DiffServ markings in conjunction with bandwidth limits to set these priorities. Drop priorities set at the edge are acted upon by routers and switches in the network core. The combination of DiffServ marking and traffic policing allow for protection of real-time traffic, such as voice and video, and enable the service provider to offer SLAs. 4 If the service provider implements VPNs, the traffic enters a VPN steering function. This process directs the data to a VPN or to the default ISP forwarder. In the former case, two sets of firewall policies are applied one relating to the subscriber and the other assigned to the VPN. For ISP forwarding, only the subscriber firewall policy is applied D Rev 00

85 Chapter 3 Traffic Management Policies 85 Egress Traffic Management Egress Traffic Management is applied to traffic flows from the BSN to the subscriber. The following features are implemented in the egress direction. Selective Discard (SE) Hierarchical WFQ (application based) Shaping (aggregate) L3/L2 mapping Egress DiffServ An Egress DiffServ policy applies to traffic traveling from the ISP where the Shasta 5000 BSN is located toward the subscriber. At the egress node, packets are examined to determine if their IEEE802.1p bits will be re-marked before leaving the DiffServ network. Shasta implements a class based weighted fair queueing mechanism to deliver traffic from the assigned DSCP classes in accordance with the IETF DiffServ specifications. Note: The higher the value of the weight, the more precedence the traffic is given. Traffic shaping Traffic shaping is a service that forces network traffic to conform to a specified behavior and is applied only in the direction towards the subscriber. By knowing precisely how the traffic is going to behave, it is possible to allocate resources inside the network to ensure available bandwidth and minimize delays. Traffic shaping lets you set a target for an average transmission rate for specific types of traffic. For example, you can also define a rate limit per each rule as well as per connection. In the case where per connection rate limit is specified, separate buffer pool per flow is created and rate limited based on that. If not specified, it goes by the rate limit specified by the rule to which the packet belongs. Shasta 5000 Broadband Service Node, Provisioning Service Policies

86 86 Chapter 3 Traffic Management Policies You can create a policy that limits Web traffic to 200 Kb/s. The process shapes the traffic flow so that the rate does not exceed the value. This puts a cap on the bandwidth available to that traffic, ensuring that the remainder of the interface s bandwidth is available to other kinds of traffic. In this example, if Web traffic does not use the available bandwidth of 200 Kb/s, other kinds of traffic can use the remaining bandwidth. Traffic shaping uses a buffer to hold packets while it transmits the flow at the target rate. You can also define a burst size and an exceed burst size to further define the flow. These values determine how much data traffic shaping can send from the buffer per time interval. Once the buffer is full, packets are dropped. Shasta offers two basic shapers: an AF-Shaper, and a Rule-based Shaper. The AF shaper is a separate shaper queuing model created per subscriber. In the AF Shaper, the shaper has 8 queues, to which the 8 DiffServ classes are mapped. So subsequently, each subscriber has 8 AF queues for the shaper. The shaper queues are configured as a function of weights defined on the trunk connection. The Per-Flow or Rule-based Shaper implements a Weighted Fair Queuing ++ mechanism with optional rule-based and connection-based rate limits. Flow Shaper (rule-based) traffic shaper The Per-Flow or Rule-based Shaper implements a Weighted Fair Queuing ++ mechanism with optional rule-based and connection-based rate limits. The following figure shows an example of how the per-flow shaper would be configured on a per subscriber or group of subscribers basis. The figure below shows an example of a Residential Traffic Shaping policy, applied to an individual subscriber D Rev 00

87 Chapter 3 Traffic Management Policies 87 Figure 20 Rule Based Traffic Shaping example Rule 1: Limit total RealAudio traffic between the subscriber and a server farm to 1,024K bps. Limit each individual RealAudio session to 256Kbps. Rule 2: Limit SNMP traffic from a Network Management host to the subscriber to 16Kbps (admittedly, managing subscriber PCs through SNMP many not be too realistic in a mass-market residential service). Rule 3: Limit any other type of traffic (initiated by the subscriber) to 256Kbps. Rate Weights: In case of congestion, SNMP traffic to the subscriber (Rule 2) will have 5 times (50/10) priority over ordinary subscriber traffic, and 50/15 priority over RealAudio traffic. Note that this SNMP traffic will always be limited to 16Kbps. This mechanism ensures that critical traffic always gets through while staying within its bandwidth limits. Shasta 5000 Broadband Service Node, Provisioning Service Policies

88 88 Chapter 3 Traffic Management Policies The following table defines the policy items definable for per flow Traffic Shaper rules. Table 20 Rule definitions for Per-Flow Traffic Shaper Column item Source/Destination Service Action Definition Source who is the initiator of the flow, and Destination IP Address who is the target or non-initiator of the flow. All valid Shasta Network Objects can be used here: SubAddress (Subscriber Address), VpnAddr (VPN Address), PeerAddr (point-to-point link to subscriber if applicable), IP_Farm, Host, Gateway, Network, IP Range, Group, Abstract (Place-holder to be resolved when applying the rule to a subscriber) Used to identify the application. All valid Shasta Service Objects can be used here. The following parameters can be defined for each action: Rate_Limit Rate limit applied to all the traffic flows that meet a given rule. For example Rule 1, allows 1 Mbps to all Real Audio traffic between the Local_Content_Servers and the Subscriber (initiated by the subscriber). Per_Connection _Rate_Limit Per-Connection Rate limit applied to each individual traffic flow that matches a given rule. In Rule 1, each RealAudio session would be allowed a maximum of 256Kbps. Rate_Weight Define the ratios with which the packets are let in through the Shaper. The bandwidth that a given flow is allowed can be calculated using the following formula: Queue Log weighted_flow_bandwidth=[(rate_weight/ sum_of_all_weights)*instantaneus_rate] Maximum number of packets in a queue If checked, will log every individual packet that meets the rule conditions Remark Comments to the Rule Note: Rate_Weight does not define per se a hard limit on the bandwidth a flow can have. The allowed bandwidth of a given flow should be calculated using the following formula: flow_bandwidth=min(line_rate, weighted_flow_bandwidth, Rate_limit) D Rev 00

89 Chapter 3 Traffic Management Policies 89 Configurable Queues Each queue has a set of stats maintained to keep track of the number of packets queued and packets dropped when the queue is full. Packets are dropped when the number of packets queued exceed the maximum number assigned to each queue. The Flow Shaper has a configurable number of buffers per rule in a policy.the configurable number of buffered packets can range from AF class-based traffic shaper The AF shaper is a separate shaper queuing model created per subscriber. In the AF Shaper, the shaper has 8 queues, one for each of the DSCP classes for that particular subscriber. So subsequently, each subscriber has 8 DSCP queues for the shaper. Based on the Class of Service (CoS), packets are queued into separate queues from within a pool of queues allocated for the subscriber to which packets are addressed. Each queue can be associated with a PHB, based on the recommended codepoint -> PHB mapping. A PHB on a BSN for DiffServ shaping is governed by parameters of weight and rate limit. Weight as a factor is used for deciding the priority of a class and rate limit is used to control the rate of flow of packets through an interface as part of the total bit rate possible through that interface. Shasta 5000 Broadband Service Node, Provisioning Service Policies

90 90 Chapter 3 Traffic Management Policies Figure 21 AF class-based Traffic Shaper The AF shaper, even when configured for each subscriber, has a more course granularity than the rule/flow shaper. This AF shaper should be used in scenarios where shaping/limiting the subscriber s traffic is not required at the flow level. The AF shaper aggregates all flows, which belong to a specific DSCP class. As such, this shaper maintains eight queues, or one corresponding to each DSCP class. Packets belonging to a given DSCP class are queued in the corresponding queue. Each DSCP class is configured with a specific weight as mentioned earlier. The absence of traffic for a given DSCP class will result in the fair share bandwidth of this class getting redistributed to the other traffic classes. The fair share bandwidth for each DSCP class is arrived at using the configured weight and rate for the given DSCP class and the line rate configured for the subscriber. The desired granularity of traffic shaping can be achieved by applying proper Egress Diffserv Marking to the various flows. It is also possible to have the egress diffserv policy applied by aliasing packets belonging to various flows and achieve the desired shaping, while not altering the original DSCPs of the packets D Rev 00

91 Chapter 3 Traffic Management Policies 91 Egress Processing Subscriber traffic coming into the BSN from the network core undergoes the following Traffic Management and QoS processing: 1 Traffic passes through the subscriber firewall policy. 2 Traffic enters the shaping function responsible for protecting the access link. The traffic is assigned a weight and flow bandwidth depending on the source, destination, and traffic type. 3 Traffic passes through an anti-spoofing policy, which protects the subscriber s network. To protect against external entities masquerading as the subscriber, the anti-spoofing policy usually discards any traffic with a source network address equal to the subscriber s own network. Flow Management Flow aging and stealing timeout values for flowcache lists are configurable through CLI. These lists are allocated during init time. During conversations, these flowcache entries are taken off free lists (allocated during init time) and put in other flowcache lists. The flowcache lists are placed back on a free list either when reclaimed/stolen by other conversation or when the flowcache entry has aged. Aging is accomplished using periodically fired timers that free any flowcache resources that have been idle for more than their configured aging timeouts. The freed flowcache entries are placed on the free list. When a subscriber requires a flow and it is not available on the free list then a flow can be reclaimed or stolen from another subscriber as described in the following table. Table 21 Flowcache resource allocation actions Action Reclaim Steal Definition Happens if the desired resource is on an aged/drop list (conv_drop_list, conn_drop_list, prflow_aged_list, prflow_matched_list and pkt_wait_list). Happens if the desired resource is on an active list but has been inactive for a certain amount of time (stealing timeout), such lists are conv_list, conv_complex_list, conn_list, conn_syn_list, conn_fin_list, prflow_wait_list, prflow_matched_list. Shasta 5000 Broadband Service Node, Provisioning Service Policies

92 92 Chapter 3 Traffic Management Policies The Shasta 5000 BSN uses the following process to allocate a flow: If a flow is available on the flow's free list (which is pre-allocated during system bootup), acquire the flow from the free list. If there are no flows on the free list, the BSN tries to reclaim a flow. Reclaiming takes the flow that have been unused for the longest period of time from the reclaimable flowcache list (shown in Table 21). Otherwise, the BSN steals from other flows. This is done by checking the least-recently used conversation/connection of the stealable flowcache lists shown in Table 21 and comparing its inactive time versus flow's steal time. If the inactive time is higher, the BSN destroys the conversation/ connection flow and uses its flow's entry. See also: Configurable Flowcache Lists on page 92 Subscriber Based Maximum Conversation Threshold on page 93 Flow management service policy on page 94 Configurable Flowcache Lists Following are the configurable lists and their default aging/stealing timeout values in seconds. Amongst the lists in the following table, not all require steal time, and this is indicated by NA (Not Applicable). NC (Not Configurable) means that the value cannot be changed. Table 22 Default Aging/Stealing parameters Flowcache lists Default Age Default Steal conn_drop_list 10 0 (NC) conn_fin_list 3 0 conn_list 7200 (120 min) 300 conn_syn_list 60.3 (300 msec) conv_drop_list 10 0 (NC) conv_list conv_complex_list 7200 (120 min.) 900 (15 min) D Rev 00

93 Chapter 3 Traffic Management Policies 93 Table 22 Default Aging/Stealing parameters Flowcache lists Default Age Default Steal Prflow_matched_list 15 NA pkt_wait_list.4 (400 msec) NA prflow_wait_list tcprecon_wait_list 3 NA The minimum value for stealing can be 0 (steal any time) and for age the minimum must be at least 1 tick. (1 tick = 1/120 seconds.) The maximum value for stealing will be limited to 24 hours. The maximum stealing value for the pkt_wait_list will be set to 1 second while the maximum value for the other lists will be set to 24 hours. Subscriber Based Maximum Conversation Threshold This is the primary functionality provided by the Flow Management service. It is the ability to enforce a maximum number of allowed simultaneous flows for a specific subscriber/connection to which the policy is applied. Flows may be the result of TCP, UDP or ICMP type traffic. The default value for a new policy would be unlimited, designated by a -1. In this configuration a subscriber can potentially obtain all of the flows for its own use on the SSP where it is plumbed. The maximum threshold parameter operates both in the ingress and egress traffic directions of the subscriber. The system detects whether a given system/subscriber is using a SSC-I and/or a SSC-II card and specifies the maximum allowable entry for this parameter either at entry time or when the policy is applied to the subscriber/connection. In the latter case an error, or session error should be generated to indicate that a policy error has occurred. The table below lists all the possible values and their allowable ranges. Shasta 5000 Broadband Service Node, Provisioning Service Policies

94 94 Chapter 3 Traffic Management Policies Table 23 Flow Management conversation limits Card Type Max Conversation Limit Range Flowcache Behavior SSC-I/SSC-II -1 Unlimited SSC-I/SSC-II 0 No flowcache resources allocated SSC-I Flowcache resources allocated to specified limit SSC-II Flowcache resources allocated to specified limit In a situation where the Flow Management policy is applied to a subscriber with active traffic, the flows in the conv_list, conn_list and conv_complex_list would in total exceed the configured value. When the policy is applied and committed to the subscriber, the system will move over-quota traffic to the corresponding drop lists (conv_drop_list, conn_drop_list) so that they can be reclaimed by other traffic should flowcache shortages occur. In the meantime, that traffic will still be served by the BSN as long as their flowcache entries are not reclaimed by others. For those denied traffic, their sessions will be timed out and eventually closed by their end applications. Flow management service policy A policy for configuring the max flow is defined via SCS. This policy can be applied to a subscriber to manage his usage of the system flowcache resources. Currently, the flow management service is limited to the configuration of the maximum flows. The following figure shows an example of the Flow Management policy with the default parameter of D Rev 00

95 Chapter 3 Traffic Management Policies 95 Figure 22 Flow Management policy example Accounting Policies DiffServ accounting Accounting provides statistics about how many bytes and packets are sent and received by your subscriber. If a subscriber has DiffServ applied, and is marking traffic, the ISP can differentiate that traffic and count the packets based on the level of service. Accounting categorizes the packet counts into 64 possible buckets, based on the marking (the TOS value of the IP packet) applied to that traffic. Any traffic that does not match the accounting policy is counted by bucket 0 as the default. If a subscriber s traffic is marked with a DiffServ policy, you can separate it into different accounting buckets, based on the markings. If the subscriber traffic is unmarked, it defaults to AF Class1, drop precedence (DP) 1 within a Shasta BSN. If you do not have an accounting policy set for this default marking, traffic is counted in bucket 0. Buckets can be configured with absolute TOS value or a combination of AF and DP values. Accounting lets you: Create new services and pricing plans quickly and easily Provide detailed Internet usage records based on billing types Shasta 5000 Broadband Service Node, Provisioning Service Policies

96 96 Chapter 3 Traffic Management Policies Flow Based Accounting The Flow Based Accounting (FBA) service is a service policy applied to subscribers much like the diffserv Accounting policy. It is designed to provide periodic accounting records on a per subscriber basis without the need to have the traffic mapped to a predetermined DSCP, IP Precedence and AF class as in the bucket based accounting service on the platform. The FBA service supports source, destination and service fields as in the other services policies. There is no action field as the sole action will be to generate periodic accounting updates once the policy is applied to a specific subscriber. The FBA service provides the following enhancements to the users above the existing bucket based accounting service. Allow flow based (source, destination, service) accounting of traffic without having to first rely on mapping/aliasing of the IP Precedence/TOS fields of traffic types. Allow up to 128 rules per policy, increased from 64 due to the 6 bit length of the TOS field bucket based accounting service. Support stats per rule, including aggregate stats (ingress/egress bytes and packets), conversation counts and unmatched traffic per policy; The FBA service allows service provider customers to better account for access/ services offered on any given connection type easily on the platform D Rev 00

97 97 Chapter 4 Traffic Redirection Policies The following topics explain traffic redirection policies, and describe how to implement them. Traffic redirection is a means of forwarding packets from an original destination to a destination specified by a redirection policy. Service providers use the different redirection policies to provide value added services to their customers. Traffic can be redirected based on the source of the traffic, the destination of the traffic, or the type of traffic. Topics in this chapter: Policy Based Forwarding on page 103 Web Steering on page 98 Personal Content Portal on page 106 See also: For procedures relating to Traffic Redirection, see Chapter 6, Creating Individual Service Policies, on page 139, including: Create a Policy Based Forwarding policy on page 169 Create a Web Steering Policy on page 171 Note: Personal Content Portals are further described in the Personal Content Portal Implementation Guide. Please refer to this guide for further concept information and all procedures to provisioning Personal Content Portal Policies. Shasta 5000 Broadband Service Node, Provisioning Service Policies

98 98 Chapter 4 Traffic Redirection Policies Web Steering Web Steering enables a service provider to manage network traffic by redirecting HTTP requests to a localized proxy server instead of out to the Internet. The proxy server, or Web Cache, will return cached pages to a subscriber, or retrieve non-cached pages from the Internet. Web steering redirects HTTP traffic to a Web Cache server instead of the original packet destination IP Address. Any port HTTP traffic can be transparently redirected to a proxy cache server at port 80, without the knowledge of the web client. Web steering is not supported for HTTPS. NAT is used in Web Steering to redirect traffic, therefore the web cache can be located anywhere in the network. It is not restricted to directly connected networks. There is no routing software required on the Web cache, and it can be located any number of hops away from the BSN. A web cache is defined in a Web Steering policy as an IP Farm. An IP Farm is a user defined network object that lists the proxy server IP addresses. Destination IP address based hashing is used to choose the destined proxy server to steer to within an IP Farm. The following figure shows the logical decision flow for Web Steering redirection D Rev 00

99 Chapter 4 Traffic Redirection Policies 99 Figure 23 Logical flow for Web Steering redirection Shasta BSN Send Packet back to user HTTP request Substitute Source IP Address on the Packet by Origin Return Web page Server IP Address Substitute Destination IP Send packet Address on the Packet by to cache device Cache IP Address Hashing function chooses which cache to send the traffic Yes No Is Traffic Fetch page HTTP? from internet Web Cache Yes Is Web page cached? No Fetch page from Internet Internet Subscriber Shasta 5000 Broadband Service Node, Provisioning Service Policies

100 100 Chapter 4 Traffic Redirection Policies Web Steering policy rules The Web Steering policy has the standard rule-based format, in which rules are read starting with row one. If a packet matches a rule, the action is applied without attempting to match further rules. Rules are added to a policy specifying which IP conversations (specified by source and destination address) should be steered and which should continue to the default destination. Web steering rules consist of columns for packet source, destination, service, action, log, and remark. Rule matching is applied to ingress traffic only. A Web Steering rule is made up of the columns defined in the following table. Table 24 Web Steering Rule Columns Rule # Source Destination Service Action Log Remark The order of traffic matching rules The source IP prefix of the traffic The destination IP prefix of the traffic The application of the traffic The action to be taken for the matched traffic How to log the rule Any notes pertaining to the rule There are two actions that can be applied in a rule: Default - forwards the traffic to the default destination IP address in the IP Header. Steer - redirects the packet to an IP farm defined in the rules destination column. Using IP Farms An IP Farm is required as a destination for a Steer action. An IP Farm is a list of IP addresses that refer to proxy cache servers. An IP Farm object can list up to 255 IP Addresses. Each HTTP connection that matches a steer rule will be redirected to one of the servers listed in the corresponding IP Farm object. IP Farms should be configured with the proper number of servers to handle the anticipated peak load. The Shasta BSN does not make determinations on proxy cache server overloads D Rev 00

101 Chapter 4 Traffic Redirection Policies 101 Member servers can be added or deleted from an in-use IP Farm object. This will change the corresponding hash table so that hash entries are evenly distributed among the member servers. IP Farm Health checks The Shasta BSN will perform periodic health checks on all member servers within an IP Farm that is in use by a web steering service. When a health check fails on an existing member server, that servers IP address is removed from the hash table in all referenced nodes so that no new HTTP request will be sent there. The remaining IP Farm members will take over the hash entries for the failed server, provided they don t exceed the maximum threshold for the remaining servers. When a failed server comes back on line, it is reinstated in its original place in the has table. Requests that were previously hashed to the server will be redirected to it. This enables cache entries saved in secondary storage to persist across outages. ICMP Ping health checks are performed every 15 seconds by default for every member of each in-use IP Farm. Three consecutive failures cause an IP Farm to be transitioned into a down state, and two consecutive successes are required to bring it back to an up state. Web Steering Proxy URL The web steering proxy URL option gives the system administrator the option of inserting the hostname or IP address to the requested URL. If the user has web cache servers that do not require the absolute URL, then the Proxy-URL (Disable) should be set. The default mode of this option is to proxify the URL, that is Proxy-URL(Enable). When the Proxy-URL(enable) mode is set, the web steering policy always proxifies the URL. This means that the web steering service will modify the client's URL to include the absolute URL if the original request was not in the full URL format. Implicitly inserting the URL function, however, could result in the client request not reaching the requested virtual web site. Therefore, the user has the option to set the Proxy-URL(disable) mode. Shasta 5000 Broadband Service Node, Provisioning Service Policies

102 102 Chapter 4 Traffic Redirection Policies This mode is designed to ensure that the web steering service works with all web cache servers by allowing the system administrator to choose whether to proxify the URL. Web Steering policy example The policy in the following figure is an example of Web Steering. The last rule is the default policy rule. Make sure to add any additional rules above the default rule. Note: The following policy is meant as an example only. Build Web Steering rules in accordance to your network requirements and/or individual subscribers D Rev 00

103 Chapter 4 Traffic Redirection Policies 103 Figure 24 Web Steering example Policy Based Forwarding Policy Based Forwarding (PBF) is used to bypass normal route-lookup of ingress traffic and determine the next hop based on policy rule match. The destination of the packet must be only a single hop away from the current location where the packet is being forwarded. Policy Based Forwarding is only applied to ingress traffic. Policy rules allow for the selection of the packet source, destination, service and action, along with log and remark columns. Policy actions consist of: Shasta 5000 Broadband Service Node, Provisioning Service Policies

104 104 Chapter 4 Traffic Redirection Policies Steering - allows for the selection of a forwarding IP address that is different from the packets original destination. Causes a route lookup on the host or gateway defined in the action rather then on the packets destination IP address. Default - forwards the packet to the original destination. Normal route-lookup occurs. If a route-lookup of a host or gateway designated by the rule action is not found, the packet will be dropped. The next packet matching the rule will perform route-lookup again. Host objects specifying a local BSN IP address are dropped as a special case. If a packet does not match a policy rule, it will follow the implied rule of Any source, Any destination, Any service, Default action. Policy Based Forwarding policy example The policy in the following figure is an example of Policy Based Forwarding. The last rule is the default policy rule. Make sure to add any additional rules above the default rule. Note: The following policy is meant as an example only. Build Policy Based Forwarding rules in accordance to your network requirements and/ or individual subscribers D Rev 00

105 Chapter 4 Traffic Redirection Policies 105 Figure 25 Policy Based Forwarding example The difference between Web Steering and Policy Based Forwarding As opposed to Web Steering, Policy Based Forwarding allows only one forwarding destination in a rule, instead of steering to IP Farms. If PBF is used to redirect traffic to a web cache, a L4 switch must front end the web cache in order to steer the redirected traffic to the cache engines. The L4 switch can be no more then one hop away from the Shasta BSN. Web steering actually pings each cache server to make sure it is alive, and won't send traffic to a cache that is down. Policy Based Forwarding does not have this ability, so if your cache server goes down, you'll keep on sending traffic. Shasta 5000 Broadband Service Node, Provisioning Service Policies