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

106 106 Chapter 4 Traffic Redirection Policies Personal Content Portal Personal Content Portal policies make it possible for the Shasta BSN to redirect subscriber HTTP requests from the web site the subscriber intended to a configured Personal Content Portal Web Server, where additional policies can be applied and content incorporated. Subscribers may visit their intended Web sites only if the software at the Personal Content Portal instructs the Shasta BSN to allow the subscriber to do so. Software at the Personal Content Portal location instructs the Shasta BSN hijacking the HTTP request to switch from captive mode to non-captive mode to allow subscribers to view the intended Web site, as appropriate, through a message signaling protocol. The following figure shows how the Personal Content Portal works. Figure 26 Personal Content Portal redirection Shasta 5000 BSN Captive Mode Switch Subscriber HTTP requests Hijacked HTTP Requests Captive Portal Web Site Intended Web Site D Rev 00 The Shasta BSN Personal Content Portal technology can be used for many purposes. The following are just a few possible uses of Personal Content Portals:

107 Chapter 4 Traffic Redirection Policies 107 Subscriber steering for self-provisioning - The Personal Content Portal enables the service provider to steer customers to a portal for self-provisioning of services and tiered offerings. The self- provisioning allows for faster time to market while still giving the service provider some level of customer control for instance, over their security options. Self-provisioning (or autoprovisioning) is an essential means of deployment of services to mass market customers. For instance, it allows service providers to deploy DSL services with the same speed and ease of provisioning intrinsic to delivery of Internet dial access services. Subscriber steering for Web content purveyance - The Personal Content Portal allows the service provider to give the subscriber access to specific kinds of services and capabilities when that user logs in to the network. Subscriber steering for login security processing - When there are requirements for login security of bridged users or account configuration for bridged and PPP subscribers, the Shasta 5000 BSN can direct user HTTP traffic to a Personal Content Portal at the ISP site. This Personal Content Portal can be configured to provide users with customized Web-based screens that allow user login, provisioning of new services, or changes to existing services. The Personal Content Portal can also provide an interface into back-end authentication, accounting, and billing servers to propagate collected information. Note: Personal Content Portals are discussed in more detail in the Shasta 5000 Broadband Service Node Personal Content Portals Implementation Guide, Release 4.0 (part number A). Please refer to this guide for further concepts and all procedures to build Personal Content Portal policies. Shasta 5000 Broadband Service Node, Provisioning Service Policies

108 108 Chapter 4 Traffic Redirection Policies D Rev 00

109 109 Chapter 5 Provisioning Service Policies The following topics provide procedures for provisioning service policies and binding them to subscribers. Topics in this chapter: 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 See also: For concept information regarding Service Policies, see Introduction to Service Policies on page 23. Shasta 5000 Broadband Service Node, Provisioning Service Policies

110 110 Chapter 5 Provisioning Service Policies Creating service policy objects Service policy objects are used to define provisionable attributes that are used in service policy rules. You create service policy objects that are specific to the subscriber and network upon which you will apply the service policy. The following topics describe how to create Shasta BSN service policy objects. Policy object type Topic Network object Create network objects on page 110 Service object Create service objects on page 118 Rate object Creating Rate objects on page 125 Diffserv Action object Create DiffServ Action objects on page 128 For more information on service policy objects, see Service policy objects on page 30. Create network objects D Rev 00 After you satisfy the following prerequisites, use the procedure below to create a network object to use in service policies. Prerequisites ISP level access to the SCS. See Shasta 5000 Broadband Service Node, Getting Started with the Service Creation System (SCS), Release 4.0 (part number A). Understand the purpose of a network object. See Service policy objects on page 30. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager

111 Chapter 5 Provisioning Service Policies Double-click on the Service Objects folder. 3 Click on Network Objects 4 Select New The Network Object Type Selection dialog box appears. 5 Choose a Network Object type from the list and provision it according to the following sub-procedures: Create a new host object on page 112 Create a new gateway object on page 113 Create a new ip_range object on page 114 Create a new ip_farm object on page 115 Create a new abstract object on page 115 Create a not_applicable object on page 116 Create a new group object on page 117 Next steps Repeat this procedure to create more network objects, or begin to create service policies. You can also refer to the following topics for instructions on how to create other service objects: Create service objects on page 118 Creating Rate objects on page 125 Create DiffServ Action objects on page 128 Shasta 5000 Broadband Service Node, Provisioning Service Policies

112 112 Chapter 5 Provisioning Service Policies Create a new host object Use this procedure to create a host object. Prerequisites Before starting this procedure, complete the steps in Create network objects on page 110. Procedure 1 Navigate to the Network Object Type Selection dialog box as detailed in the procedure Create network objects on page In the Network Object Type Selection dialog box, select Host from the type list and click OK. 3 The Host Object Insert dialog box opens with the General tab displayed. 4 In the Host Name field, type a name for the new host object. 5 In the IP Address field, type the IP address for the physical router. 6 Type a comment in the Remark field (optional). 7 Select one of the following host types: Gateway A device that acts as a translator of data between two systems that do not use the same communication protocols. Host A node on the network that has an IP address and usually runs applications. 8 In the Network Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 9 Click OK. The new host object is added to the network object list D Rev 00

113 Chapter 5 Provisioning Service Policies 113 Create a new gateway object Use this procedure to create a gateway object. Prerequisites Before starting this procedure, follow the steps in Create network objects on page 110. Procedure 1 Navigate to the Network Object Type Selection dialog box as detailed in the procedure Create network objects on page In the Network Object Type Selection dialog box, click Gateway. The Gateway Object Insert dialog box opens with the General tab displayed. 3 In the Host Name field, type a name for the new host object. 4 In the IP Address field, type the IP address for the physical router. 5 Type a comment in the Remark field (optional). 6 Select Gateway, a device that acts as a translator of data between two systems that do not use the same communication protocols. 7 In the Network Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 8 Click the Gateway Interfaces tab. The Gateway Interfaces tab opens. 9 Click New. The Add an interface dialog box opens. 10 In the Interface Name field, type the name of the interface. 11 In the IP Address field, type the IP address of the interface. 12 Select a netmask for the interface. 13 Click OK. Shasta 5000 Broadband Service Node, Provisioning Service Policies

114 114 Chapter 5 Provisioning Service Policies The Gateway Interfaces tab is redisplayed with the new interface. 14 Click OK. The new gateway object added to the network object list. Create a new ip_range object Use this procedure to create an ip_range object. Prerequisites Before starting this procedure, follow the steps in Create network objects on page 110. Procedure 1 Navigate to the Network Object Type Selection dialog box as detailed in the procedure Create network objects on page In the Network Object Type Selection dialog box, click ip_range. The IP_range Object Insert dialog box opens. 3 In the IP Range Name field, type a name for the IP range object. 4 Type a comment in the Remark field (optional). 5 In the IP Address Range area, specify the following parameters: Starting Address The first address of this IP Range Ending Address The last address of this IP Range 6 In the IP Range Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 7 Click OK. Thee new ip_range object added to the network object list D Rev 00

115 Chapter 5 Provisioning Service Policies 115 Create a new ip_farm object Use this procedure to create an ip_farm object. Prerequisites Before starting this procedure, follow the steps in Create network objects on page 110. Procedure 1 In the Network Object Type Selection dialog box, click ip_farm. The IP_farm Object Insert dialog box opens. 2 In the IP Farm Name, type a name for the IP farm object. 3 Click Add to define IP addresses for the IP farm object. 4 Type a comment in the Remark field (optional). 5 In the IP Farm Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 6 Click OK. The new ip_farm object added to the network object list. Create a new abstract object Use this procedure to create an abstract object. Prerequisites Before starting this procedure, follow the steps in Create network objects on page 110. Procedure 1 In the Network Object Type Selection dialog box, click abstract. Shasta 5000 Broadband Service Node, Provisioning Service Policies

116 116 Chapter 5 Provisioning Service Policies The Abstract Object Insert dialog box opens. 2 In the Object Name field, type a name for the abstract object. 3 Type a comment in the Remark field (optional). 4 In the Network Abstract Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 5 Click OK. The abstract object added to the network object list. Create a not_applicable object Use this procedure to create a not_applicable object. Prerequisites Before starting this procedure, follow the steps in Create network objects on page 110. Procedure 1 In the Network Object Type Selection dialog box, click not_applicable. The Not_Applicable Object Insert dialog box opens. 2 In the Object Name field, type a name for the not_applicable object. 3 Type a comment in the Remark field (optional). 4 In the Network N/A Object Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list D Rev 00

117 Chapter 5 Provisioning Service Policies Click OK. The not_applicable object added to the network object list. Create a new group object Use this procedure to create a group object. Prerequisites Before starting this procedure, follow the steps in Create network objects on page 110. Procedure 1 In the Network Object Type Selection dialog box, click group. The Group Object Insert dialog box opens. 2 In the Network Group Name field, type a name for the group object. 3 Type a comment in the Remark field (optional). 4 In the Network Group Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 5 In the Group area, you define which objects you want to apply in your grouping by selecting the object and using the arrow buttons. 6 Click OK. The group object is added to the network object list. Shasta 5000 Broadband Service Node, Provisioning Service Policies

118 118 Chapter 5 Provisioning Service Policies Create service objects After you satisfy the following prerequisites, use the procedure below to create a service object. Prerequisites Have ISP level access to the SCS. Understand the purpose of a service object. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Objects folder. 3 Click on Service Objects 4 Select New The Service Object Type Selection dialog box appears. 5 Choose a Service Object type from the list and provision it according to the following procedures: Create a new tcp object on page 119 Create a new udp object on page 120 Create a new icmp object on page 121 Create a new ip_protocol object on page 122 Create a new abstract object on page 122 Create a not_applicable object on page 123 Create a new group object on page 124 Next steps Repeat this procedure to create more service objects, or begin to create service policies D Rev 00

119 Chapter 5 Provisioning Service Policies 119 You can also refer to the following topics for instructions on how to create other service objects: Create network objects on page 110 Creating Rate objects on page 125 Create DiffServ Action objects on page 128 Create a new tcp object Use this procedure to create a tcp object. Prerequisites Before starting this procedure, follow the steps in Create service objects on page 118. Procedure 1 In the Service Object Type Selection dialog box, select tcp from the type list and click OK. 2 The tcp object insert dialog box opens with the general tab displayed. 3 In the Service Name field, type a name for the new tcp object. 4 In the Port field, type the port number for the tcp protocol. 5 Type a comment in the Remark field (optional). 6 In the tcp Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 7 Click OK. The new tcp object is added to the service object list. Shasta 5000 Broadband Service Node, Provisioning Service Policies

120 120 Chapter 5 Provisioning Service Policies Create a new udp object Use this procedure to create a udp object. Prerequisites Before starting this procedure, follow the steps in Create service objects on page 118. Procedure 1 In the Service Object Type Selection dialog box, select udp from the type list and click OK. 2 The udp object insert dialog box opens with the general tab displayed. 3 In the Service Name field, type a name for the new udp object. 4 In the Port field, type the port number for the udp protocol. 5 Type a comment in the Remark field (optional). 6 In the udp Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 7 Click OK. The new udp object is added to the service object list D Rev 00

121 Chapter 5 Provisioning Service Policies 121 Create a new icmp object Use this procedure to create a icmp object. Prerequisites Before starting this procedure, follow the steps in Create service objects on page 118. Procedure 1 In the Service Object Type Selection dialog box, select icmp from the type list and click OK. 2 The icmp object insert dialog box opens with the general tab displayed. 3 In the Service Name field, type a name for the new icmp object. 4 Type a comment in the Remark field (optional). 5 In the Contents field enter icmp type and icmp code. 6 In the icmp Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 7 Click OK. The new icmp object is added to the service object list. Shasta 5000 Broadband Service Node, Provisioning Service Policies

122 122 Chapter 5 Provisioning Service Policies Create a new ip_protocol object Use this procedure to create an ip_protocol object. Prerequisites Before starting this procedure, follow the steps in Create service objects on page 118. Procedure 1 In the Service Object Type Selection dialog box, select ip_protocol from the type list and click OK. 2 The ip_protocol object insert dialog box opens with the general tab displayed. 3 In the Service Name field, type a name for the new ip_protocol object. 4 In the Ip Protocol type field, type the ip_protocol. 5 Type a comment in the Remark field (optional). 6 In the ip_protocol Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 7 Click OK. The new ip_protocol object is added to the service object list. Create a new abstract object Use this procedure to create a abstract object. Prerequisites Before starting this procedure, follow the steps in Create service objects on page D Rev 00

123 Chapter 5 Provisioning Service Policies 123 Procedure 1 In the Service Object Type Selection dialog box, click abstract. The Abstract Object Insert dialog box opens. 2 In the Object Name field, type a name for the abstract object. 3 Type a comment in the Remark field (optional). 4 In the Service Abstract Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 5 Click OK. The abstract object added to the service object list. Create a not_applicable object Use this procedure to create a not_applicable object. Prerequisites Before starting this procedure, follow the steps in Create service objects on page 118. Procedure 1 In the Service Type Object Selection dialog box, click not_applicable. The not_applicable selection dialog boxopens. 2 In the Object Name field, type a name for the not_applicable object. 3 Type a comment in the Remark field (optional). 4 In the Service N/A Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Shasta 5000 Broadband Service Node, Provisioning Service Policies

124 124 Chapter 5 Provisioning Service Policies Deselect the Default Color option to choose a color from the drop-down list. 5 Click OK. The Service Object Type Selection dialog box is redisplayed with the not_applicable object added to the list. Create a new group object Use this procedure to create a group object Prerequisites Before starting this procedure, follow the steps in Create service objects on page 118. Procedure 1 In the Service Object Type Selection dialog box, click group. The group object insert dialog box opens. 2 In the Service Group Name field, type a name for the group object. 3 Type a comment in the Remark field (optional). 4 In the Service Group Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 5 In the Group area, you define which objects you want to apply in your grouping by selecting the object and using the arrow buttons. 6 Click OK D Rev 00

125 Chapter 5 Provisioning Service Policies 125 Creating Rate objects After you satisfy the following prerequisites, use the procedure below to create a rate object. Prerequisites Have ISP level access to the SCS. Understand the purpose of a service object. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Objects folder. 3 Click on Rate Objects 4 Select New The Rate Object Type Selection dialog box appears. 5 Choose a Rate Object type from the list and provision it according to the following procedures: Create a new rate object on page 126 Create a new abstract object on page 127 Next steps Repeat this procedure to create more rate objects, or begin to create service policies. You can also refer to the following topics for instructions on how to create other service objects: Create network objects on page 110 Create service objects on page 118 Create DiffServ Action objects on page 128 Shasta 5000 Broadband Service Node, Provisioning Service Policies

126 126 Chapter 5 Provisioning Service Policies Create a new rate object Use this procedure to create a rate object. Prerequisites Before starting this procedure, follow the steps in Creating Rate objects on page 125. Procedure 1 In the Rate Object Type Selection dialog box, select rate from the type list and click OK. 2 The rate object insert dialog box opens with the general tab displayed. 3 In the Object Name field, type a name for the new rate object. 4 In the Rate field, select a line rate, or choose the button for Use Connection Rate. 5 Type a comment in the Remark field (optional). 6 In the Rate Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 7 Click OK. The new rate object is added to the rate object list D Rev 00

127 Chapter 5 Provisioning Service Policies 127 Create a new abstract object Use this procedure to create an abstract rate object Prerequisites Before starting this procedure, follow the steps in Creating Rate objects on page 125. Procedure 1 In the Rate Object Type Selection dialog box, click abstract. The Abstract Object Insert dialog box opens. 2 In the Object Name field, type a name for the abstract object. 3 Type a comment in the Remark field (optional). 4 In the Rate Abstract Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 5 Click OK. The abstract object added to the rate object list. Shasta 5000 Broadband Service Node, Provisioning Service Policies

128 128 Chapter 5 Provisioning Service Policies Create DiffServ Action objects After you satisfy the following prerequisites, use the procedure below to create a DiffServ Action object. Prerequisites Have ISP level access to the SCS. Understand the purpose of a service object. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Objects folder. 3 Click on DiffServ Action Objects 4 Select New The ds_action insert dialog box appears. 5 In the Object Name field, type a name for the ds_action object. 6 Type a comment in the Remark field (optional). 7 Add an original value to the object policy rule by selecting the original value of Any with the right mouse button and choosing Add from the menu. Input a value for one of the following: AF/DP IP Precedence DS 8 Add an Alias action by selecting the alias value of None with the right mouse button and selecting edit from the menu. Input an AF/DP value or select None. 9 Add a Marker value by selecting the marker value of None with the right mouse button and choosing Edit from the menu. Input a value for one of the following: D Rev 00

129 Chapter 5 Provisioning Service Policies 129 AF/DP IP Precedence DS None 10 In the Action Icon area, you can change the following attributes (optional): Deselect the Default Icon option to choose from the drop-down list of icons. Deselect the Default Color option to choose a color from the drop-down list. 11 Click OK. The ds_action object added to the DiffServ Action object list. Next steps Repeat this procedure to create more rate objects, or begin to create service policies. You can also refer to the following topics for instructions on how to create other service objects: Create network objects on page 110 Create service objects on page 118 Creating Rate objects on page 125 Shasta 5000 Broadband Service Node, Provisioning Service Policies

130 130 Chapter 5 Provisioning Service Policies Find policies which use defined Service Objects Use this procedure to find a list of the specific policies that use defined service objects. Service objects can be shared between multiple policies and policy types. You cannot delete a service object that is in use by a policy. Prerequisites Before performing this procedure, you should understand the purpose and scope of Service Objects. See Service policy objects on page 30. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Objects folder. 3 Click on the Service Object type you want to search. 4 Select the service object from the list. 5 Click on the Used by Policies button on the right pane. 6 In the List Policies window, navigate through the policy types until you find the policy or policies using the service object. 7 Click Close when you are done searching. Next steps After performing this procedure, you may go to the specific policy and remove or replace the service object. This will enable you to delete the service object if desired D Rev 00

131 Chapter 5 Provisioning Service Policies 131 Create service policies The following procedure provides the basic steps in building a generic service policy. For specific service policy procedures, see Chapter 6, Creating Individual Service Policies, on page 139. After you satisfy the following prerequisites, use the procedure below to create a generic service policy. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. In the below procedure substitute <service policy> with the type of policy you are creating. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select a service policy type from one of the following: Security NAT Anti Spoofing Ingress Anti Spoofing DiffServ Marking Egress DiffServ Marking Traffic Shaping Personal Content Portal Policy Based Forwarding Policing Web Steering Shasta 5000 Broadband Service Node, Provisioning Service Policies

132 132 Chapter 5 Provisioning Service Policies Account Service Flow Mirroring Flow Based Accounting Flow Management DDOS Prevention 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New <service policy> Policy dialog box and select OK. Traffic Shaping and Policing policies also require a further narrowing of policy type. Make your policy type choice before selecting OK. 6 A policy edit dialog box will appear with a default row or rows of policy rules. To build most policies, you will add rows of rules. Some policies only require you to edit existing rules, or cannot be edited. If you are creating one of these policies, skip to step 7. To add a row within a policy: a b Click with the right mouse button in the row number column. Select from the following menu options: Add Row Before Add Row After Copy Row Delete a Row, or Cut a Row can be used later to eliminate rows from an existing policy. Make sure you follow the Rules matching process on page 33 when deciding the order of your rules. 7 After you add a rule, you will change the service objects in the rule to define the individual network parameters required by your subscriber. To add service objects in a rule: Select the service object from the row with the right mouse button. Select Add. Select from a pre-defined object, or select New. For procedures on creating service objects, see Creating service policy objects on page D Rev 00

133 Chapter 5 Provisioning Service Policies 133 Depending on which column your service object is in, you will be asked to choose from a Network, Service, DiffServ Action, or Rate object. Select OK. The object you selected will populate the row cell. To edit service objects in a rule: Select a service object from the row with the right mouse button. Select Edit. The object edit dialog box will open. Edit the object with the parameters specific to your subscriber. For procedures on creating service objects, see Creating service policy objects on page 110. Select OK. The object you selected will populate the row cell. 8 Continue to add rows until you have finished defining the policy. 9 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional service policies. See Create service policies on page 131 Create service profiles. See Create service profiles on page 134 Bind the service policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135 Refer to Chapter 6, Creating Individual Service Policies, on page 139 for information about how to create individual service policies: Shasta 5000 Broadband Service Node, Provisioning Service Policies

134 134 Chapter 5 Provisioning Service Policies Create service profiles A service profile combines policies into packages that can be added to subscribers and marketed as Service Level Agreements. Profiles are created after you create individual service policies. After you create different service profiles, you can bind a specific profile to an individual or group subscriber. After you satisfy the following prerequisites, use the procedure below to create a service profile. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Profiles. See Service Profiles on page 33. Complete creating individual service policies. See Create service policies on page 131 or See Chapter 6, Creating Individual Service Policies, on page 139. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Profiles folder. 3 Select the Add button. 4 Enter a Profile Name in the New Service Profile dialog box. The Service Profile dialog box appears. 5 Select the Add button in the ServProf Policies section of the dialog box. The Policy selection dialog box appears. 6 Select a policy type from the left column. 7 Select an individual service policy. 8 Select OK to include the policy in the profile 9 Repeat steps 5-8 to add additional policies to the profile D Rev 00

135 Chapter 5 Provisioning Service Policies Select OK in the Service Profile dialog box. You will see the new profile listed in the Service Policies window. Next steps You can repeat this procedure to create more service profiles, or you can bind an existing service profile to an individual or group subscriber. (See Bind a service policy or profile to a subscriber on page 135.) Bind a service policy or profile to a subscriber Service Policies and Profiles must be bound to subscribers or subscriber groups to take effect. Use the following procedure to bind policies and profiles to subscribers. Prerequisites Have ISP level access to the SCS. (See Setting the user view profile in Getting Started with SCS.) Understand the purpose of service policies and profiles. See Service Policies on page 32, or Service Profiles on page 33. Complete creating individual service policies and profiles. See Create service policies on page 131 or Chapter 6, Creating Individual Service Policies, on page 139. Have an existing subscriber. Procedure 1 Navigate to the Subscribers Manager by either: Selecting the Subscribers icon in the left column of the SCS GUI window Using the View menu, select Subscriber Manager 2 Select a subscriber and select edit. 3 Choose the Services tab. 4 To add a Service Policy, see step 5 Shasta 5000 Broadband Service Node, Provisioning Service Policies

136 136 Chapter 5 Provisioning Service Policies Service Profile, see step 8 5 In the Individual Policies section of the window, select Add The Policy selection dialog box will appear. 6 Choose a Service Policy type from the left column. 7 Choose an individual policy and select OK. The policy will appear in the Individual Policies list on the subscriber window. 8 To add a Service Profile, select Add from the Service Profiles section of the window. The Service Profile Selection dialog box will appear. 9 Choose a Service Profile from the list and select OK. The profile will appear in the Service Profiles list on the subscriber window. Next steps After adding Service Policies and Service Profiles to your subscriber, you can do one of the following: Add additional Service Policies or Profiles to your subscriber. Resolve unresolved (abstract objects) within subscriber policies. See Resolve an abstract object within a subscriber policy on page D Rev 00

137 Chapter 5 Provisioning Service Policies 137 Resolve an abstract object within a subscriber policy Any unresolved objects must be resolved before a policy can be used by a subscriber. Objects become unresolved when a policy with an abstract objects get bound to a subscriber. Unresolved objects appear in the Unresolved Objects section of the Subscriber-Services tab. Prerequisites Have ISP level access to the SCS. Understand the purpose of Abstract objects. See Abstract objects on page 32. Perform the procedure Bind a service policy or profile to a subscriber before resolving any abstract objects. Procedure 1 In the Unresolved Object field of the Subscriber- Services tab, double click an Unresolved Object. The Network Object Selection Type dialog box opens. 2 Choose an object type, for example, host, and click OK. The Host Object dialog box opens. 3 Click a desired network object type, for example, host, and click OK. The appropriate dialog box opens. In this example, Host Object Insert dialog box opens with the General tab displayed. 4 In the IP Address field, type the IP address of the host. 5 Click OK. The unresolved object is removed from the list. 6 Repeat above steps to resolve all other Unresolved Objects. 7 Click OK. Shasta 5000 Broadband Service Node, Provisioning Service Policies

138 138 Chapter 5 Provisioning Service Policies D Rev 00

139 139 Chapter 6 Creating Individual Service Policies The following topics explain how to provision individual service policies. Topics in this chapter: Provisioning Security Policies Provisioning Network Address Translation Policies Provisioning Group NAT Provisioning Traffic Management Policies Provisioning Traffic Redirection policies See also: For concept information on individual Service Policies, see the following: Security Policies Traffic Management Policies Traffic Redirection Policies Shasta 5000 Broadband Service Node, Provisioning Service Policies

140 140 Chapter 6 Creating Individual Service Policies Provisioning Security Policies Individual security policies can be defined for the following: Security (firewalls) - see Create a Firewall Policy Anti-spoofing - see Create an Anti Spoofing Policy Ingress Anti-spoofing - see Create an Ingress Anti Spoofing Policy Flow Mirroring - see Create a Flow Mirroring Policy Distributed Denial of Service Prevention (DDOS) - see Create a DDOS prevention policy Security policies must be defined in accordance with the specific network requirements of your subscribers. The procedures below only offer generic instructions for the provisioning of each policy. Anti-spoofing and Ingress anti-spoofing policies are created with default settings that cannot be changed. You cannot create or edit rules for Anti-spoofing policies. See also: For more information on Security Policies, see Chapter 2, Security Policies, on page 37, including the following topics: Firewall Policies on page 38 Anti-spoofing on page 46 Flow Mirroring on page 48 Distributed Denial of Service (DDOS) prevention on page 50 Network Address Translation on page 56 Group NAT on page D Rev 00

141 Chapter 6 Creating Individual Service Policies 141 Create a Firewall Policy Use this procedure to create a firewall security policy for your subscribers. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33. Understand Shasta application of Firewalls. See Firewall Policies on page 38. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Security policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Security Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. The default row is the implicit deny rule. This rule allows no traffic to flow to or from your subscriber. Make sure to add all rules above this default row. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber. 9 Continue to add rows until you have finished defining the policy. Shasta 5000 Broadband Service Node, Provisioning Service Policies

142 142 Chapter 6 Creating Individual Service Policies 10 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Disable the Firewall Tickle Mode. See Disabling/Enabling the Firewall Tickle Mode on page 142 Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Disabling/Enabling the Firewall Tickle Mode Use this procedure to disable or enable the Firewall tickle mode option in a firewall policy. The firewall tickle mode prevents return packets in a TCP conversation from being dropped when the timeout limit has been exceeded. The default state for the Firewall Tickle Mode feature is enabled. Prerequisites ISP level access to SCS. Configure a firewall as described in Create a Firewall Policy on page 141. Procedure 1 Open a firewall policy as described in Create a Firewall Policy on page Pull down the options menu 3 Select the tickle-mode(disabled) or tickle-mode(enabled) option. The option will toggle when selected. When tickle-mode(disabled) is displayed, the tickle-mode is in the disabled state. When tickle-mode(enabled) is displayed, the tickle-mode is in the enabled state D Rev 00

143 Chapter 6 Creating Individual Service Policies 143 Disabling/Enabling the Sync Defender Mode Use this procedure to disable or enable the Sync Defender Mode option in a firewall policy. The Sync Defender Mode ensures a valid TCP 3-way handshake before it starts to forward traffic The default state for the Sync Defender mode feature is disabled. Prerequisites ISP level access to SCS. Configure a firewall as described in Create a Firewall Policy on page 141. Procedure 1 Open a firewall policy as described in Create a Firewall Policy on page Pull down the options menu 3 Select the sync-defender-mode(disabled) or sync-defender-mode(enabled) option. The option will toggle when selected. When sync-defender-mode(disabled) is displayed, the sync-defender-mode is in the disabled state. When sync-defender-mode(enabled) is displayed, the sync-defender-mode is in the enabled state. Shasta 5000 Broadband Service Node, Provisioning Service Policies

144 144 Chapter 6 Creating Individual Service Policies Create an Anti Spoofing Policy Use this procedure to create an Anti Spoofing policy for subscribers. An Anti Spoofing policy filter traffic in the Egress direction. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand the concept of Anti Spoofing. See Anti-spoofing on page 46. Understand how to add rules and service objects to policies. See Create service policies on page 131. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Anti Spoofing policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Anti Spoofing Policy dialog box and select OK. 6 A policy edit dialog box will appear with default rows of policy rules. 7 Accept all the default parameters. You cannot make changes to the defaults. The Anti Spoofing policy is preset. 8 Click OK and save the policy. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page D Rev 00

145 Create an Ingress Anti Spoofing Policy Chapter 6 Creating Individual Service Policies 145 Use this procedure to create an Ingress Anti Spoofing policy for subscribers. An Ingress Anti Spoofing policy filter traffic in the Ingress direction. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand the concept of Anti Spoofing. See Anti-spoofing on page 46. Understand how to add rules and service objects to policies. See Create service policies on page 131. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Ingress Anti Spoofing policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Ingress Anti Spoofing Policy dialog box and select OK. 6 A policy edit dialog box will appear with default rows of policy rules. 7 Accept all the default parameters. You cannot make changes to the defaults. The Ingress Anti Spoofing policy is preset. 8 Click OK and save the policy. Next steps Create additional policies. Create Service Profiles.See Create service profiles on page 134 Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Shasta 5000 Broadband Service Node, Provisioning Service Policies

146 146 Chapter 6 Creating Individual Service Policies Create a Flow Mirroring Policy Use this procedure to create a Flow Mirroring policy for your subscribers. A Flow Mirroring policy will redirect a copy of the rule specified traffic to an external server. Prerequisites Have ISP level access to the SCS. Understand the purpose of Flow Mirroring Policies, and the rules matching process. See Rules matching process on page 33 and Flow Mirroring on page 48 Understand how to add rules and service objects to policies.see Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Prior to deploying a Flow Mirroring policy, ensure there is adequate bandwidth for subscribers and replicated 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. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Flow Morroring policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Flow Mirroring Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber D Rev 00

147 Chapter 6 Creating Individual Service Policies 147 Specify the traffic source address, default to any source address if no specification. Specify the traffic destination address, default to any destination address if no specification. Specify the service types that need to apply Flow Mirroring on, default to any service type if there is no specification. Select an action that you want to associate with this rule. If you choose chose Mirror, the connection/ip Address Service Object must be configured for the Mirror Server. Select log options (brief, detail etc). 7 Continue to add rows until you have finished defining the policy. 8 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134 Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Create a DDOS prevention policy Use this procedure to create a DDOS prevention policy for your subscribers. A DDOS prevention policy defines the High and Low water marks, SYN rate, and timer interval for delayed binding to take effect. Prerequisites Have ISP level access to the SCS. Understand the purpose of DDOS prevention policies. See Distributed Denial of Service (DDOS) prevention on page 50 Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Shasta 5000 Broadband Service Node, Provisioning Service Policies

148 148 Chapter 6 Creating Individual Service Policies Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the DDOS prevention policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New DDOS Prevention Policy dialog box and select OK. 6 A policy edit dialog box will appear with a set of default parameters. Adjust the parameters for your subscriber. The parameters inlcude: High water mark Low water mark SYN rate Timer interval 7 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134 Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page D Rev 00

149 Chapter 6 Creating Individual Service Policies 149 Provisioning Network Address Translation Policies NAT policies define rules for the translation or mapping of private addresses to public addresses. The type of NAT policy you configure is dependant on the rules you add to the policy. See Network Address Translation on page 56 for more information on defining NAT Rules. Perform the following procedures to enable NAT on a subscriber: Create a NAT Policy on page 149 Assign subscriber reachability on page 150 Create a NAT Policy Use this procedure to create a NAT policy. Add rules to the policy based on the type of NAT you are performing, and the requirements of your network. See Network Address Translation on page 56 for more details on NAT policy types. Prerequisites ISP level access. Understand the NAT policy types supported by the Shasta BSN. Knowledge of the network and subscriber addressing scheme you are working with. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the NAT policy type. 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New NAT Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. Shasta 5000 Broadband Service Node, Provisioning Service Policies

150 150 Chapter 6 Creating Individual Service Policies 7 A policy edit dialog box will appear with a default row of policy rules. 8 Add rows of rules by selecting the row number with the right mouse button. 9 Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber. 10 Continue to add rows until you have finished defining the policy. 11 Select OK. You will see the policy you created appear in the service policy list. Next steps Perform Assign subscriber reachability on page 150 Create additional policies. Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Assign subscriber reachability After building the NAT policy, you must configure static routing (reachability) for your subscriber. This establishes which IP addresses are hidden and which network is available to the router for translation. Prerequisites ISP level access to SCS. Create subscriber, see Shasta 5000 Broadband Service Node, Provisioning Subscribers, Release 4.0 (part number A). Create a NAT policy. See Create a NAT Policy on page 149. Knowledge of your subscriber and network requirements, and addressing scheme. Procedure 1 In the Subscriber Manager window, select a subscriber. 2 Click Edit. 3 In the Reachability area of the Addressing tab, click Add D Rev 00

151 Chapter 6 Creating Individual Service Policies In the Reachable Subnet Address Configuration dialog box, add the network IP address as the Base Address. 5 Click Hidden from ISP. 6 Add a second reachability statement using the actual network address as the Base Address. This is the address to which you will be translating. 7 Click OK. Next steps There are no Next Steps for this procedure. Shasta 5000 Broadband Service Node, Provisioning Service Policies

152 152 Chapter 6 Creating Individual Service Policies Provisioning Group NAT Group NAT does not require a service policy. Provisioning Group NAT consists of configuring the following areas: NAT Group objects Local Address Pools Access Groups Subscriber addressing and reachability Caution: Note to users attempting to configure a Group NAT 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 Grou pnatpool, in order to allow a subscriber to be accessible from the public network, one must ensure that the address range for the Group NAT 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 Source NAT since that interferes with the Group NAT'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

153 Create a NAT Group Object Chapter 6 Creating Individual Service Policies 153 Use this procedure to create a NAT Group object that can be linked to subscribers through the use of Access groups, and local address pools. Procedure 1 From the SCS Device Manager window, select the Device to which you are applying the NAT Group object. 2 Using the right mouse button, select the device and choose Configure >> Access Properties from the menu. The <device> Configuration - Access Properties window will appear. 3 Select the NAT Groups folder 4 Select Add. The NAT Group Configuration window will appear. 5 Input the following configuration data: NAT Group Name - name of NAT group object. Starting IP Address - starting address of the range of public addresses to be used when hiding members of this group. Number of Addresses - Starting address + the number of address to be used in the range. Access Group - Each NAT group must belong to an existing access group. Use the Select button and choose an existing access group from the list in the Access Group Selection dialog box. 6 Select OK. The NAT Group will appear in the NAT Groups List. Shasta 5000 Broadband Service Node, Provisioning Service Policies

154 154 Chapter 6 Creating Individual Service Policies Define an Address Pool using NAT Groups Use this procedure to provision local Address Pools using hidden addresses. The Address Pool will require you to select an access group. Prerequisites Have ISP level access to SCS. Have previously provisioned an access group. Have previously provisioned a NAT Group Object. Procedure 1 From the SCS Device Manager window, select the Device to which you are applying the Address Pool. 2 Using the right mouse button, select the device and choose Configure >> Access Properties from the menu. The <device> Configuration - Access Properties window will appear. 3 Select the Address Pools folder. 4 Select Add. The Address Pools Configuration window will appear. 5 Input the following configuration data: Address Pool Name - the name of the address pool Starting IP Address - The starting addresses of the range to be used in the pool. Number of Addresses - The starting address plus the number of address in the pool. Netmask - Use the pull down menu to select the netmask for the address pool. Access Group - Select an existing Access Group to bind Address Pool to. Hidden from ISP/ Hidden from VPN / Hidden - Depending on the context of the Access Group (ISP only, VPN only, or VPN+I), you will have the option to select one or more of these check boxes D Rev 00

155 Chapter 6 Creating Individual Service Policies 155 Select a NAT Group Object defined for the hidden context using the Select button, and choosing a NAT group from the list in the NAT Group Selection dialog box. The NAT Group must belong to the same Access Group as the Address Pool. 6 Select OK. The Address Pool will appear in the Address Pools List. Configure a Subscriber for Group NAT This procedure has you provision a subscriber for NAT, using Group NAT objects. This procedure does not include basic subscriber provisioning steps. For subscriber provisioning information, please refer to Shasta 5000 Broadband Service Node, Provisioning Subscribers, Release 4.0 (part number A). Procedure 1 Create a subscriber according to procedures in Shasta 5000 Broadband Service Node, Provisioning Subscribers, Release 4.0 (part number A). 2 Select the Addressing Tab. 3 In the Routing Parameters Box, deselect the check box for Unnumbered (use Default IP Address). 4 Input a local IP address for the subscriber. This is the private address. 5 Select a Netmask 6 Select Hidden from ISP or Hidden from VPN 7 In the Public Address box, input a NAT Group by clicking on Select and choosing a NAT Group from the NAT Group Selection dialog box. The NAT Group you select must be assigned to the same Access Group as the subscriber. 8 Select OK. Shasta 5000 Broadband Service Node, Provisioning Service Policies

156 156 Chapter 6 Creating Individual Service Policies Provisioning Traffic Management Policies D Rev 00 Traffic management is applied in the Ingress direction in the form of: DiffServ policies Policing policies In the Egress direction, traffic management consists of: Egress DiffServ policies Traffic Shaping policies See also: For more information on Traffic Management concepts, see Chapter 3, Traffic Management Policies, including: Traffic Management Overview on page 76 Ingress Traffic Management on page 76 Egress Traffic Management on page 85 Flow Management on page 91 Create a DiffServ Policy Use this procedure to create a DiffServ policy for subscribers. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Egress DiffServ. See Differentiated Services on page 77. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements.

157 Chapter 6 Creating Individual Service Policies 157 Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the DiffServ policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New DiffServ Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber. 9 Continue to add rows until you have finished defining the policy. 10 Select OK. You will see the policy you created appear in the service policy list. Next steps Create Policing policies. See Create a Policing Policy on page 158. Create additional policies. Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Shasta 5000 Broadband Service Node, Provisioning Service Policies

158 158 Chapter 6 Creating Individual Service Policies Create a Policing Policy Use this procedure to create a policing policy for subscribers. You can create either a Single Rate Three Color marker Policy, or a Two Rate Three Color Marker Policy. Prerequisites ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33. Understand Shasta application of Egress DiffServ. See Differentiated Services on page 77. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Policing policy type 4 Select the Add button to add a new policy 5 Input a name for the new policy in the New Policing Policy dialog box and choose from one of the two policer types: Single Rate / Three Color Two Rate / Three Color 6 Select OK. 7 A policy edit dialog box will appear with default parameters for each of the 8 CoS queues D Rev 00

159 Chapter 6 Creating Individual Service Policies Edit the rules by selecting a cell with the right mouse button. 9 Change the rates for: Committed Rate Committed BurstSize Excess Burst Size (srtcm only) Peak Rate (trtcm only) Peak Burst Size (trtcm only) 10 Change the Action for: Red Action Yellow Action Green Action Select actions from the choices provided by the drop down menu associated with the Action service objects. 11 Select OK. You will see the policy you created appear in the service policy list. Next steps Create Egress DiffServ and Traffic Shaping policies. See Create an Egress DiffServ Policy on page 160. Create additional policies. Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Shasta 5000 Broadband Service Node, Provisioning Service Policies

160 160 Chapter 6 Creating Individual Service Policies Create an Egress DiffServ Policy D Rev 00 Use this procedure to create an Egress DiffServ policy for subscribers. Prerequisites ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Egress DiffServ. See Egress DiffServ on page 85. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Egress DiffServ policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Egress DiffServ Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber. 9 Continue to add rows until you have finished defining the policy. 10 Select OK. You will see the policy you created appear in the service policy list.

161 Chapter 6 Creating Individual Service Policies 161 Next steps Create Traffic Shaping policies. See Create a AF Class Based Traffic Shaping Policy on page 161 or Create a Flow Based Traffic Shaping Policy on page 163. Create additional policies. Create Service Profiles. See Create service profiles on page 134 Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Create a AF Class Based Traffic Shaping Policy Use this procedure to create an AF class based Traffic Shaping policy for subscribers. Prerequisites ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Egress DiffServ. See AF class-based traffic shaper on page 89. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Traffic Shaping policy type 4 Select the Add button to add a new policy Shasta 5000 Broadband Service Node, Provisioning Service Policies

162 162 Chapter 6 Creating Individual Service Policies 5 Input a name for the new policy in the New Traffic Shaper Policy dialog box and choose AF Based (DiffServ AF based). 6 Select OK. 7 A policy edit dialog box will appear with default parameters for each of the 8 CoS queues. 8 Input appropriate values for Rate, Weight Limit, and queue length. Use values appropriate to your network requirements. 9 Set the Line Rate by clicking on the LineRate menu in the menu bar. Choose Configure In the Configure Traffic Shaper Rate dialog box, choose the Line Rate service object with your right mouse button, and choose select. 11 Select the New button. The Rate object type selection dialog box appears. 12 In the Object Rate insert dialog, input a name and rate, or choose Use Connection Rate. 13 Select Okay, and choose the Rate object you just created in the Rate object Selection Dialog box. 14 Select OK, and the Line Rate will be reflected in your policy. 15 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134 Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page D Rev 00

163 Chapter 6 Creating Individual Service Policies 163 Create a Flow Based Traffic Shaping Policy Use this procedure to create a Flow Based Traffic Shaper policy for your subscribers. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Traffic Shaping. See Flow Shaper (rule-based) traffic shaper on page 86. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Traffic Shaping policy type 4 Select the Add button to add a new policy 5 Input a name for the new policy in the New DiffServ Policy dialog box and select Flow Shaper (rule based). 6 Select OK. 7 A policy edit dialog box will appear with a default row of policy rules. 8 Add rows of rules by selecting the row number with the right mouse button. 9 Change the Service Objects in the Source, Destination, Service, Action, and Queue columns to reflect the network requirements of your subscriber. 10 In the Action column, you can edit the action to configure: Shasta 5000 Broadband Service Node, Provisioning Service Policies

164 164 Chapter 6 Creating Individual Service Policies Rate Weight Rate Limit Per Flow Rate Limit 11 Continue to add rows until you have finished defining the policy. 12 Set the Line Rate by clicking on the LineRate menu in the menu bar. Choose Configure In the Configure Traffic Shaper Rate dialog box, choose the Line Rate service object with your right mouse button, and choose select. 14 Select the New button. The Rate object type selection dialog box appears. 15 In the Object Rate insert dialog, input a name and rate, or choose Use Connection Rate. 16 Select Okay, and choose the Rate object you just created in the Rate object Selection Dialog box. 17 Select OK, and the Line Rate will be reflected in your policy. 18 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134 Bind a policy to a subscriber.see Bind a service policy or profile to a subscriber on page D Rev 00

165 Create a Flow Management policy Chapter 6 Creating Individual Service Policies 165 Use this procedure to create a Flow Management policy for your subscribers. A Flow Management policy defines the maximum number of allowed simultaneous conversations on a flow. Prerequisites Have ISP level access to the SCS. Understand Flow Management policies. See Flow Management on page 91 Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Flow Management policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Flow Management Policy dialog box and select OK. 6 A policy edit dialog box will appear. Enter the value for the Maximum Flow Limit. The default value is Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134 Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Shasta 5000 Broadband Service Node, Provisioning Service Policies

166 166 Chapter 6 Creating Individual Service Policies Create an Accounting Policy This procedure has you create an accounting policy for your subscribers. Accounting policies work in conjunction with DiffServ. Prerequisites Have ISP level access to the SCS. Create a DiffServ policy to apply to subscribers along with the accounting policy. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Accounting Policies. See Accounting Policies on page 95. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Accounting policy type 4 Select the Add button to add a new policy 5 Input a name for the new policy in the New Accounting Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Change the value for each bucket number by selecting the service object in the value column with your right mouse button and select add D Rev 00

167 Chapter 6 Creating Individual Service Policies You can edit the value type to be either: AF/DP value IP Precedence Value DS value Assign values to the buckets that correspond to the CoS queues you wish to account for. 10 Continue to add rows until you have finished defining the policy. 11 Optionally, use the Service Position menu to have accounting enabled before or after Egress DiffServ Marker. 12 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Create a Flow Based Accounting Policy This procedure has you create a Flow Based accounting policy for your subscribers. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Accounting Policies. See Flow Based Accounting on page 96. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Shasta 5000 Broadband Service Node, Provisioning Service Policies

168 168 Chapter 6 Creating Individual Service Policies Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Flow Based Accounting policy type 4 Select the Add button to add a new policy 5 Input a name for the new policy in the New Flow Based Accounting Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Add rows with defined Source, Destination, and Service fields for the subscribers or services you wish account for. 9 Continue to add rows until you have finished defining the policy. 10 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page D Rev 00

169 Provisioning Traffic Redirection policies Chapter 6 Creating Individual Service Policies 169 Traffic Redirection policies include: Policy Based Forwarding Web steering Personal Content Portal Traffic Redirection policies should be defined for the specific requirements of the subscriber network. Note: For all procedures relating to Personal Content Portal provisioning, please refer to the Personal Content Portal Implementation Guide. See also: For more information on Traffic Redirection Policies, see Chapter 4, Traffic Redirection Policies, on page 97, including: Web Steering on page 98 Policy Based Forwarding on page 103 Personal Content Portal on page 106 Create a Policy Based Forwarding policy Use this procedure to create a Policy Based Forwarding policy for subscribers. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Policy Based Forwarding. See Policy Based Forwarding on page 103. Understand how to add rules and service objects to policies. See Create service policies on page 131. Shasta 5000 Broadband Service Node, Provisioning Service Policies

170 170 Chapter 6 Creating Individual Service Policies Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Policy Based Forwarding policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Policy Based Forwarding Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber. 9 Continue to add rows until you have finished defining the policy. 10 Select OK. You will see the policy you created appear in the service policy list. Next steps Create Service Profiles. See Create service profiles on page 134. Bind a policy to a subscriber.see Bind a service policy or profile to a subscriber on page D Rev 00

171 Create a Web Steering Policy Chapter 6 Creating Individual Service Policies 171 Use this procedure to create a Web Steering policy for subscribers. Prerequisites Have ISP level access to the SCS. Understand the purpose of Service Policies, and the rules matching process. See Rules matching process on page 33 Understand Shasta application of Web Steering. See Web Steering on page 98. Understand how to add rules and service objects to policies. See Create service policies on page 131. Understand the individual requirements of the subscriber(s) for which you are creating the policy, and be ready to create policy rules in accordance with those requirements. Procedure 1 Navigate to the Service Policy Manager by either: Selecting the Service policies icon in the left column of the SCS GUI window Using the View menu, select Service Policy Manager 2 Double-click on the Service Policies folder. 3 Select the Web Steering policy type 4 Select the Add button to add a new policy. 5 Input a name for the new policy in the New Web Steering Policy dialog box and select OK. 6 A policy edit dialog box will appear with a default row of policy rules. 7 Add rows of rules by selecting the row number with the right mouse button. 8 Change the Service Objects in the Source, Destination, Service, and Action columns to reflect the network requirements of your subscriber. 9 Continue to add rows until you have finished defining the policy. Shasta 5000 Broadband Service Node, Provisioning Service Policies

172 172 Chapter 6 Creating Individual Service Policies 10 Optionally, modify the proxy-url option to change the default from proxy-url(enable) to proxy-url(disable). This option is modified using the Option menu. 11 Select OK. You will see the policy you created appear in the service policy list. Next steps Create additional policies. Create Service Profiles.See Create service profiles on page 134. Bind a policy to a subscriber. See Bind a service policy or profile to a subscriber on page 135. Create a Personal Content Portal policy For all procedures relating to Personal Content Portal provisioning, please refer to the Personal Content Portal Implementation Guide D Rev 00

173 Appendix A List of Acronyms 173 ABR ACK ACPS ADSL AF AH AIS ALC ANSI API ARP AS ATM BER BGP BOOTP BSN CA Available Bit Rate Acknowledge message AC Power Shelf Asymmetric Digital Subscriber line Assured Forwarding Authentication header Alarm Indication Signal ATM Line Card American National Standards Institute Application Programming Interface Address Resolution Protocol Autonomous Systems Asynchronous Transfer Mode Bit Error Rate Border Gateway Protocol Boot Protocol Broadband Service Node Certificate Authority Shasta 5000 Broadband Service Node, Provisioning Service Policies

174 174 List of Acronyms CBR CGI Cid CIDR CLEC CLI CMC CMTS CNM CORBA CPE CT3 DARPA DES, 3DES DH DHCP DIMM DNIS DNS DoS DP DSCP DSL Constant Bit Rate Common Gateway Interface Connection Identifier Classless Inter-Domain Routing Competitive Local Exchange Carrier Command Line Interface Control and Management Card Cable Modem Termination System Customer Network Manager Common Object Request Broker Architecture Customer Premise Equipment Channelized T3 Department of Defence Advanced Research Projects Agency Data Encryption Standard, Triple DES Diffie Hellman (Group) Dynamic Host Configuration Protocol Dual in-line Memory Module Dialed Number Identification Service Domain Name Server Denial of Service Drop Priority DiffServ Code Point Digital Subscriber Line D Rev 00

175 List of Acronyms 175 DSLAM E1 EF EGP ELC EMS ESP FA FCS FDDI FELC FIB FQDN FTP GELC GFR GRE GUI HA HDLC HiFn HMAC HN Digital Subscriber Line Access Multiplexer E-carrier digital transmission at Mb/s Expedited Forwarding Exterior Gateway Protocol Ethernet Line Card Element Manager System Enhanced Security Payload Foreign Agent Field Check Sequence Fiber-Distributed Data Interface Fast Ethernet Line Card Forwarding Information Base Fully Qualified Domain Name File Transfer Protocol Gigabit Ethernet Line Card Guaranteed Frame Rate Generic Routing Encapsulation Graphical User Interface Home Agent High Speed Digital Subscriber Line A processor circuit used for encryption Keyed Hashing for message encryption Home Network Shasta 5000 Broadband Service Node, Provisioning Service Policies

176 176 List of Acronyms HTML HTTP ICMP ICP ID IDL IEC IETF IGMP IGP IIOP IKE ILEC ILMI inarp IOR IP IP demux ISAKMP/Oakley IPSec ISDN IS-IS ISO Hypertext Mark-up Language Hypertext Transfer Protocol Internet Control Message Protocol Intelligent Cell Parser Identifier Interface Definition Language. Interexchange carrier Internet Engineering Task Force Internet Group Management Protocol Interior Gateway Protocol Internet Inter-ORB Protocol Internet Key Exchange Incumbent local exchange carrier Interim Local Management Interface Inverse ARP Interoperable Object Reference Internet Protocol Internet Protocol demultiplexer Internet Security Association and Key Management Protocol/Oakley Key Determination Protocol IP Security Integrated Service Digital Network Intermediate System - Intermediate System International Standards Organization D Rev 00

177 List of Acronyms 177 isos ISP Kb KB L2TP LAC LAN LCP LDAP LNS LSA MAC Mb MB MD-5 MIB MLPPP MN MPLS MRU MTU NAT NEBS IP Services Operating System Internet Service Provider Kilobits Kilobytes Layer 2 Tunneling Protocol L2TP Access Concentrator Local Area Network Link Control Protocol Lightweight Directory Access Protocol L2TP Network Server Link State Advertisement Media Access Control Megabits Megabytes Message Digest 5 (A one-way hash function) Management Information Base Multilink PPP Mobile Node Multi-protocol Label Switching Maximum Receive Unit Maximum Transmit Unit Network Address Translation Network Equipment Building Standards Shasta 5000 Broadband Service Node, Provisioning Service Policies

178 178 List of Acronyms NFS OMG ORB OSPF PCMCIA PCP PDSN PHB PID PING POP PPP PPPoE PPTP PUPS PVC QoS QoTD RADIUS RFC RIP RPT RSVP Network File System Object Management Group Object Request Broker Open Shortest Path First Personal Computer Memory Card International Association Personal Content Portal Packet Data Serving Node Per-Hop Behavior Process ID Packet Internet Groper Point of Presence Point-to-Point Protocol Point-to-Point Protocol over Ethernet Point-to-Point Tunneling Protocol Point of Use Power Supply Permanent Virtual Circuit Quality of Service Quote of the Day Remote Authentication Dial-in User Service Request for Comment Routing Information Protocol RADIUS Proxy Task Resource Reservation Protocol D Rev 00

179 List of Acronyms 179 SA SCS SFC SHA-1 SLA SMTP SNMP SONET SPI SPM SQL SRTCM SSC SSM SSP SVC T1 T3 TCP ToS TRTCM TTL UBR Security Association Service Creation System Switch Fabric Card Secure Hash Algorithm-1 Service Level Agreement Simple Mail Transfer Protocol Simple Network Management Protocol Synchronous Optical Network Security Parameters Index Subscriber Policy Manager Structured Query Language Single Rate Three Color Marker Subscriber Service Card Subscriber Service Module Subscriber Service Processor Switched Virtual Circuit T-carrier system digital tranmission at Mb/s T-carrier system digital transmission at Mbps Transmission Control Protocol Type of Service Two Rate Three Color Market Time to Live Unspecified Bit Rate Shasta 5000 Broadband Service Node, Provisioning Service Policies

180 180 List of Acronyms UDP UNI VBR VC VCC VCI VLAN VoIP VP VPC VPDN VPI VPN VPRN WAN WFQ WINS WRED WWW XAUTH User Datagram Protocol User-to-Network interface Variable Bit Rate Virtual Circuit Virtual Circuit Connection Virtual Connection Indicator Virtual LAN Voice over IP Virtual Path Virtual Path Connection Virtual Private Dialed Network Virtual Path Indicator Virtual Private Network Virtual Private Routed Network Wide Area Network Weighted Fair Queueing Windows Internet Name Service Weighted Random Early Detection World Wide Web Authentication software used for Contivity VPN Client termination D Rev 00

181 181 Index A AAA 55 Abstract objects about 32 creating 115, 127 resolve within a subscriber policy 137 Accounting policies about 29, 95 accounting services 29 create a flow based accounting policy 167 create an accounting service policy 166 flow based accounting 29 Anti-spoofing policies about 46 create 144 example 46, 47 Assured Forwarding Classes 78 Authentication, Authorization, and Accounting 55 B Bi-cast (aka Flow Mirroring) 48 C Class of Service (CoS) 77 Contents 5 conventions, text 18 Creating abstract network objects 115 abstract rate object 127 abstract service object 122 accounting service policies 166 AF class based traffic shaping policies 161 anti-spoofing policies 144 diffserv action objects 128 diffserv policies 156 egress diffserv policies 160 firewall policy 141 flow based accounting policies 167 flow based traffic shaping policies 163 flow mirroring policies 146, 147, 165 gateway object 113 group NAT policies 152 group object 117 group service object 124 host object 112 icmp service object 121 individual service policies 139 ingress anti-spoofing policies 145 ip_farm object 115 ip_protocol service object 122 ip_range object 114 NAT policies 149 Network objects 110 not_applicable object 116 not_applicable service object 123 personal content portal policies 172 policing policies 158 policy based forwarding policies 169 rate object 126 rate objects 125 service objects 118 service policies 131, 140 service policy objects 110 service profiles 134 tcp service object 119 traffic management policies 156 traffic redirection policies 169 udp service object 120 Shasta 5000 Broadband Service Node, Provisioning Service Policies

182 182 Index web steering policies 171 customer support 21 D DDOS - See Distributed Denial of Service Defense against SYN attacks about 42 Interaction with tickle mode 42 RST packet processing 42 SYN packet processing 42 Differentiated Service - see DiffServ DiffServ about 77 AF classes 78 aliasing 79 create 156 create diffserv action objects 128 defining DiffServ classes and drop precedence 77 drop precedence 78 Egress DiffServ - see Egress DiffServ example 79 marking 79 non-af classes 78 policy rules 78 diffserv action objects about 30 diffserv action objects create 128 DiffServ Classes 77 DiffServ code point (DSCP) 77 Distributed Denial of Service (DDOS) about 50 prevention 50 Drop Precedence 77, 78 E Egress DiffServ about 85 create 160 Egress traffic flow 34 Egress Traffic Management about 85 Egress DiffServ Egress processing 91 Traffic Shaping 85 F Firewall policies about 38 create 141 defense against SYN attacks about 42 enable/disable 143 examples about 43 business firewall 44 residential firewall 43 telecommuter firewall 44 firewall rules about 38 example 38 firewall actions 40 stateful service rules 39 IP conversation 39 state-aware 38, 39 sync-defender-mode enable/disable 143 tickle mode about 40 enable/disable 142 Firewall Tickle Mode about 40 disable/enable 142 Flow Based Accounting 29 Flow Management 91 Flow Mirroring about 48 example 49 Implementation considerations 49 IP Address Based Forwarding 48 Layer 2 Connection Based Forwarding D Rev 00

183 Index 183 Flow Mirroring policies create 146, 147, 165 Flow Shaper (rule-based) traffic shaper 86 G Group NAT about 67 access groups for group NAT 72 configuration 71 local address pools with group NAT 72 NAT groups 71 subscriber configuration 72 implicit rules for group NAT 73 subscriber reachability with group NAT 73 subscriber contexts 69 Group NAT policies configure a subscriber for group NAT 155 create 152 define an address pool using NAT groups 154 I Ingress Anti-spoofing about 46 create policy 145 Ingress Anti-spoofing policies example 47 Ingress traffic flow 34 Ingress Traffic Management about 76 DiffServ 77 Ingress processing 84 Traffic policing 79 Ingress/Egress traffic flow 34 IP conversation 39 L Logging 35 log types 35 N NAT - see Network Address Translation Network Address Translation 1 to 1 Source and Destination NAT 62 1 to 1 Destination NAT 65 1 to 1 Source NAT 64 about 56 create policy 149 directly connected NAT 57 Group NAT 67 M to 1 source NAT with PAT 58 M to N source NAT with PAT 62 policy example 65 policy rules 57 1 to 1 NAT 58 M to 1 source NAT with PAT 58 M to N source NAT with PAT 58 network objects about 30 create 110 creating a gateway object 113 creating a group object 117 creating a host object 112 creating an abstract object 115 creating an ip_farm object 115 creating an ip_range object 114 creating an not_applicable object 116 Non-AF Classes 78 P PBF - see Policy Based Forwarding policies Per-Hop Behavior (PHB) 77 Personal Content Portal policies about 106 create 172 Policing about 79 create policy 158 single rate, three-color marker about 80 create 158 Shasta 5000 Broadband Service Node, Provisioning Service Policies

184 184 Index two rate, three-color marker about 82 create 158 Policy Based Forwarding create 169 Policy Based Forwarding policies about 103 difference between Web Steering and Policy Based Forwarding 105 example 104 product support 21 Proxy-URL 101 publications hard copy 20 related 19 Q Quality of Service 75, 76 R rate objects about 30 create 125 reserved objects about 31 definitions 31 Resolve an abstract object 137 Rules matching process 33 S Security policies - see the following Anti-spoofing policies Firewall policies Flow Mirroring Network Address Translation Security policies general info 25 Selective Discard 85 Service Creation 29 Service Level Agreements (SLAs) 33 Service objects about 29, 30 create 118 creating a group object 124 creating a not_applicable object 123 creating a tcp object 119 creating a udp object 120 creating an abstract object 122 creating an icmp object 121 creating an ip_protocol object 122 Service policies about 24, 29, 32 bind to a subscriber 135 create 131 logging 35 rules matching process 33 Service policy logging 35 Service Policy Manager (SPM) 24 service policy objects creating 110 definitions 30 Service profiles about 29, 33 bind to a subscriber 135 create 134 Services application 34 Single rate, three-color marker 80 Spoofing - See Anti-spoofing State-aware firewall 38, 39 Stateful service rules 39 support, Nortel Networks 21 SYN attacks defense against 42 sync-defender-mode about 42 enable/disable 143 T technical publications D Rev 00

185 Index 185 technical support 21 text conventions 18 traffic flow 34 Traffic Management about 26, 76 egress 85 ingress 76 Traffic Management policies - see the following DiffServ Egress DiffServ Flow Management Policing Traffic Shaping Traffic Policing - see Policing Traffic Redirection policies - see the following Personal Content Portal Policy Based Forwarding Web Steering Traffic Redirection policies general information 28 Traffic Shaping about 85 AF class-based traffic shaper about 89 create 161 example 89 Flow Shaper (rule-based) traffic shaper about 86 create 163 example 86 policy items defintions 88 Two rate, three-color marker 82 Type of Service 77 difference between Web Steering and Policy Based Forwarding 105 example 102 IP Farm Health checks 101 policy rules 100 proxy URL 101 using IP Farms 100 U unresolved object 32 W Web Steering policies create 171 Shasta 5000 Broadband Service Node, Provisioning Service Policies

186 186 Index D Rev 00