ATIS 1000046-2011 Data Border Functions and Requirements.pdf

1、 ATIS-1000046 ATIS Standard on - DATA BORDER FUNCTIONS AND REQUIREMENTS ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 co

2、mpanies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, numero

3、us Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connected Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Pro

4、ject (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more informat

5、ion, please visit . Notice of Disclaimer continue to support management functions; and remain available, operational, and functional. ATIS-1000046 9 The DBF shall support the ability to initiate Transmission Control Protocol (TCP) reset, or Internet Control Message Protocol (ICMP) unreachable packet

6、s. A DBE shall add less than a millisecond of latency regardless of policy, utilization, or packet profile. This time does not include any delays due to accessing external systems such a DNS. Unless dictated by security policies in place, the DBE shall maintain no packet loss, at line rate, and unde

7、r a variety of packet size profiles. 8.2 Performance This section describes the computing platform, availability, performance and physical implementation requirements for the DBF. If the DBF is implemented in more than one physical unit (DBE), these requirements apply to each physical unit (DBE). Ap

8、plicable performance specifications can be found in T1.TR.70-2001, A Reliability/Availability Framework for IP-Based Networks and Services, and ATIS-0100524.2004 (R2008), Reliability Related Metrics and Terminology for Network Elements in Evolving Communications Networks. “Availability” is the perce

9、ntage of time the system is capable of being used. It is calculated using the entire systems mean time between failures (MTBF) and the mean time to repair (MTTR): Availability = MTBF / (MTBF + MTTR). Availability can also be represented by the number of minutes a system is down per year excluding sc

10、heduled maintenance periods. The DBF shall be at least 99.99% available. This equates to less than 52 minutes of unscheduled downtime per year. This applies to all Fault-management, Configuration, Accounting, Performance, Security (FCAPS) functionality combined. As an objective, any individual DBE s

11、hould be at least 99.999% available. Each DBF shall be at least 99.99% available. This equates to less than 1 failure in 10,000 FCAPS tasks. As an objective, the DBE shall be at least 99.999% reliable. The DBF shall incorporate built-in mechanisms for process throttling for session management, memor

12、y allocation, and CPU utilization for state and sessions to mitigate the impact of contention and prevent exhaustion of resources for both dynamic and static processes within the device. The DBF shall support the option of using active/active high availability configuration with state transference,

13、or active/hot standby high availability configuration with state transference. The DBF shall support Fail OPEN forwarding after sudden device failure, within 50 milliseconds. The DBF shall support automatic IP packet re-route after link failure. The DBF should support the use of a M:N high availabil

14、ity. Overload conditions shall not cause the complete failure of the DBF. Overload shall only result in a graceful degradation of the system platform performance. The DBF shall discard packets in order to avoid a complete system failure. The DBF shall provide interface and session level statistics g

15、athering and display ability, with configurable resets. ATIS-1000046 10 8.3 Security Functions The DBF shall be capable of enforcing security policies. The DBF shall support the ability to enforce security policy that was in effect prior to any interruption in power subsequent to the power being res

16、tored. The DBF shall support automatic session termination when it determines that packets associated with that session are anomalous. The automatic session termination can be controlled by design or by configurable policy. The DBF shall treat all packets that it identifies as DoS/DDoS packets (inbo

17、und and outbound) according to network provider policy (e.g., drop packets, or direct packets to specific network security services). The DBF shall attempt to splice TCP sessions based on information obtained during the TCP handshake with the intention of validating that the initiator of the propose

18、d TCP conversation is offering a valid session. If it is deemed that it is not a valid session, the DBF shall drop the session and log the event. The DBF shall support stateful analysis and retention of state for IP flows through the DBF. Stateful analysis is important to identify security threats.

19、The DBF shall support “application layer” awareness to the extent that it shall inspect and verify L4-L7 protocols for specific application use in accordance with the applicable IETF-Request for Comments (RFCs) for the protocol. Specific protocols to be supported shall include, but are not limited t

20、o: a. HTTP b. HTTPS c. SSH d. Diameter e. SMTP mail protocols outbound f. TFTP, FTP g. ICMP h. NTP i. SCP j. DNS k. SYSLOG l. IIOP m. SIP n. Parlay-x The DBF shall support the ability to drop packets with TTL=0/1. The DBF shall detect and report network footprint scans by design or policy. The DBF s

21、hall detect and report system finger print scans by design or policy. ATIS-1000046 11 The DBF shall support the use of thresholds for security events to minimize false positives and adjust for baseline conditions. The use of global rules shall be supported in the configuration of the firewall. The D

22、BF shall include the configurable ability to explicitly log application of the “implicit deny” rule associated with every policy. (Note: at the end of every list of allowed actions, there is an implicit rule to deny anything that is not explicitly allowed by the rules. When this “implicit deny” is u

23、sed to block traffic, it shall be possible to log this.) The DBF shall provide detection and policy enforcement functionality using vulnerability-based signatures. The DBF shall support performing deep packet inspection L4-L7 - based on policy - while inspecting packet payload for malicious traffic,

24、 and shall perform this with no packet loss and no increase in latency or jitter. Should packets containing malicious traffic be detected, they shall be treated according to the applicable security policy (e.g., dropped and a security log generated). The DBF shall provide policy enforcement function

25、ality for tunneled applications (unencrypted). The DBF shall support the detection of security threats encapsulated in another service or standard protocol (e.g., packets being carried through an unencrypted IPSec tunnel). The DBF shall support the detection and policy enforcement functionality usin

26、g a statistical protocol or application analysis engine that is preconfigured for common attacks and fully configurable for user defined attack type threshold detection settings. The DBF shall support attack detection based on signature pattern matching. The DBF shall support the capability of disab

27、ling the Intrusion Prevention System (IPS) capabilities of a single virtual instance through configuration parameters. It shall not be possible to change the configuration of the IPS capability for a DBF virtual instance “on the fly”, but shall require the instance to be shut down, re-configured, an

28、d brought back up in the new configuration. The DBF shall be able to report on intrusion detection results (successful, blocked, suspicion, etc.), and capture and analyze all information related to a potential intrusion - including packet logs. The DBF shall be capable of performing deep packet anal

29、ysis of at least the following protocols: a. HTTP b. HTTPS c. SSH d. Diameter e. SMTP mail protocols outbound f. TFTP, FTP g. ICMP h. NTP i. SCP j. DNS ATIS-1000046 12 k. SYSLOG l. IIOP m. SIP n. Parlay-x The DBE shall provide detection and policy enforcement functionality using defined signatures.

30、The DBF shall support the capability to receive updated signatures. It shall be possible to selectively configure each device, signature, policy, or filter for mitigation or monitor mode. The DBF shall have the ability to switch its Intrusion Detection capability from passive tap mode to active inli

31、ne protection mode within seconds, without physical intervention on a per port basis and with no increase in latency. The DBF shall support the application of local policy or filters based on IP options. 8.4 Authentication of Traffic Flows The DBF shall support authentication of sessions being estab

32、lished through the DBE. Authentication shall be configurable on each physical and logical interface on the “un-trusted” side of the DBF. For authentication of sessions being established through the DBF, the authentication mechanism for each session should be based on the assurance level needed for t

33、he specific data application. For example: a. Username/Password b. Challenge/Response (e.g., HTTP MD5 Hash) c. Mutual Certificate authentication Authentication may be performed by the DBF itself, or the authentication request may be directed to an associated authentication server such as an Authenti

34、cation, Authorization, and Accounting (AAA) server. As a configurable option, the DBF shall be able to block traffic for any unauthorized data flow. 8.5 Packet Marking The DBF shall support DSCP Packet Marking for packets flowing from the trusted domain to the un-trusted domain based on policies con

35、figurable for each flow or based on a global default policy. ATIS-1000046 13 The DBF shall support inspection of DSCP packet marking on packets flowing from the un-trusted domain to the trusted domain, and shall have the capability of changing the marking based on policies configurable for each flow

36、 or based on a global default policy. 8.6 Device Operations, Administration, Management and Provisioning (OAM 2. Read only; and 3. Read-write. User Profiles: Each system component shall allow the configuration of different DBE user profiles (or groups) that define the functions a user is authorized

37、to perform, and allow these profiles to be assigned to users. There shall be no arbitrary limitation on the number of user profiles. User Profile Authorizations: Each system component shall enable the definition of user profiles with authorizations based on network resource information, including: 1

38、 Networks (all of the nodes and links contained by a network). ATIS-1000046 20 2. Nodes and the access links that terminate on them. 3. Ports. 4. Customer data, if any. User Profile Functional Authorizations: Each system component shall enable the definition of user profiles with authorizations bas

39、ed on function type (e.g., configuring nodes, provisioning services, viewing faults, and administering the network element server application). 8.7.5 Application Administrator Permissions The ability to administer each system component application shall be included in user profiles. Users authorized

40、 to perform this function are referred to as “Application Administrators” in this document. The DBF shall not allow any user without administrator privileges to execute programs on the DBF. “Root” Authorization: No system component shall require an Application Administrator to be a system administra

41、tor or “root” user at the operating system level of the server. Multiple User IDs for Administators: Each system component shall allow multiple user IDs to be authorized to perform application administrator functions. Minimum Administrator Authorization: Each system component shall ensure that at le

42、ast one user is authorized to perform application administrator functions. Administrator Functions: Each system component shall enable an application administrator (and only an application administrator) to: o Create, modify or delete DBE application user identifications. o Reset passwords. o Set pa

43、ssword expiries, inactivity timeouts and allowed password re-try attempts. o Create, display, modify, or delete DBE user profiles. o Assign user profiles to user IDs. User Termination: Each system component shall allow an application administrator to terminate any active user or system session. User

44、 Session Termination: When a user ID is deactivated by an application administrator, each system component shall automatically terminate any active sessions associated with that user ID in a timely fashion. “Raw” Capability Access: Access to the raw capabilities of the underlying System server opera

45、ting system (e.g., file system access and “shell” or command prompt access) shall be granted only to system component users that are specifically authorized to do so in their user profile or to users that use some other means besides the system component application (e.g., telnet) to access the plat

46、form. Note that the application need not enable any users to access the server operating system, but if it does, it shall only allow those specifically authorized to do so. 9 COMPOSITION OF DBF The DBF may be implemented as a single physical entity or the various functions may be implemented in sepa

47、rate physical devices. This results in a number of possible deployment scenarios for the DBF. ATIS-1000046 21 The following figures illustrate two possible alternative deployments. The first (Figure 2) shows the DBF providing all the border element functions in a single location, whereas Figure 3 il

48、lustrates a situation where the Authentication and Proxy functions are provided by an application server “in front” of the Firewall/IPS security functions. In this latter case, the Application Server itself is protected from the un-trusted domain by a firewall, and the interface between the Auth/Pro

49、xy functions and DBF is a secure connection, such as an IPSec tunnel or dedicated facility. The area between the un-trusted and trusted domain is considered to be “trusted but vulnerable” since it is has been authenticated, but does not have the full protection offered by the DBF. Figure 2: Data BE Providing all security functions ATIS-1000046 22 Figure 3: Authentication and Proxy services located separately from the Security functions ATIS-1000046 23 Appendix A A MAPPING TO ATIS NGN ARCHITECTURE The following diagram shows the ATIS high level NGN archit