1、 International Telecommunication Union ITU-T Y.2770TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (11/2012) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS Next Generation Networks Security Requirements for deep packet inspection in next generatio
2、n networks Recommendation ITU-T Y.2770 ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS AND NEXT-GENERATION NETWORKS GLOBAL INFORMATION INFRASTRUCTURE General Y.100Y.199 Services, applications and middleware Y.200Y.299 Network aspects Y.300Y.399 Interfaces
3、and protocols Y.400Y.499 Numbering, addressing and naming Y.500Y.599 Operation, administration and maintenance Y.600Y.699 Security Y.700Y.799 Performances Y.800Y.899 INTERNET PROTOCOL ASPECTS General Y.1000Y.1099 Services and applications Y.1100Y.1199 Architecture, access, network capabilities and r
4、esource management Y.1200Y.1299 Transport Y.1300Y.1399 Interworking Y.1400Y.1499 Quality of service and network performance Y.1500Y.1599 Signalling Y.1600Y.1699 Operation, administration and maintenance Y.1700Y.1799 Charging Y.1800Y.1899 IPTV over NGN Y.1900Y.1999 NEXT GENERATION NETWORKS Frameworks
5、 and functional architecture models Y.2000Y.2099 Quality of Service and performance Y.2100Y.2199 Service aspects: Service capabilities and service architecture Y.2200Y.2249 Service aspects: Interoperability of services and networks in NGN Y.2250Y.2299 Numbering, naming and addressing Y.2300Y.2399 Ne
6、twork management Y.2400Y.2499 Network control architectures and protocols Y.2500Y.2599 Packet-based Networks Y.2600Y.2699 Security Y.2700Y.2799Generalized mobility Y.2800Y.2899 Carrier grade open environment Y.2900Y.2999 FUTURE NETWORKS Y.3000Y.3499 CLOUD COMPUTING Y.3500Y.3999 For further details,
7、please refer to the list of ITU-T Recommendations. Rec. ITU-T Y.2770 (11/2012) i Recommendation ITU-T Y.2770 Requirements for deep packet inspection in next generation networks Summary Recommendation ITU-T Y.2770 specifies the requirements for deep packet inspection (DPI) in next generation networks
8、 (NGNs). This Recommendation primarily specifies the requirements for deep packet inspection (DPI) entities in NGNs, addressing, in particular, aspects such as application identification, flow identification, inspected traffic types, signature management, reporting to the network management system (
9、NMS) and interaction with the policy decision functional entity. Although aimed at the NGN, the requirements may be applicable to other types of networks. History Edition Recommendation Approval Study Group 1.0 ITU-T Y.2770 2012-11-20 13 ii Rec. ITU-T Y.2770 (11/2012) FOREWORD The International Tele
10、communication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and t
11、ariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Reco
12、mmendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recomm
13、endation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interopera
14、bility or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that co
15、mpliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, valid
16、ity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be requi
17、red to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2013 All rights reserved. No part of this publication may be reproduce
18、d, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Y.2770 (11/2012) iii Table of Contents Page 1 Scope 1 1.1 Applicability . 1 1.2 Policy rules . 2 2 References. 3 3 Definitions 3 3.1 Terms defined elsewhere 3 3.2 Terms defined in this Recommendation . 4 4 Abbreviati
19、ons and acronyms 7 5 Conventions 8 6 DPI functional entity requirements . 8 6.1 Flow and application identification 8 6.2 DPI signature management . 9 6.3 Traffic inspection aspects . 11 6.4 Reporting capability . 14 6.5 Interaction with a policy decision function 16 6.6 Traffic control . 16 6.7 Ses
20、sion identification 16 6.8 Inspection of encrypted traffic 17 6.9 Inspection of compressed traffic 18 6.10 Detection of abnormal traffic . 19 7 Functional requirements from the network viewpoint 19 7.1 General requirements 19 7.2 Data plane, control plane and management plane in DPI node 20 8 Interf
21、aces of the DPI-functional entity . 21 8.1 External DPI-FE interfaces . 22 8.2 Internal DPI-FE interfaces 22 8.3 Interface requirements 23 9 Security considerations and requirements 23 9.1 Security threats against DPI entities . 23 9.2 Security requirements for DPI entities . 24 Annex A Specificatio
22、n of a flow descriptor 25 A.1 Protocol syntactical perspective . 25 A.2 Specifying information element values 25 A.3 Relation between flow descriptor, IPFIX flow identifier and IPFIX flow key 26 Bibliography. 28 Rec. ITU-T Y.2770 (11/2012) 1 Recommendation ITU-T Y.2770 Requirements for deep packet i
23、nspection in next generation networks 1 Scope This Recommendation primarily specifies the requirements for deep packet inspection (DPI) entities in NGN, addressing in particular, aspects such as application identification, flow identification, inspected traffic types, signature management, reporting
24、 to the network management system (NMS) and interaction with the policy decision functional entity. This Recommendation also identifies the requirements for DPI of traffic in non-native encoding formats (e.g., encrypted traffic, compressed data, and transcoded information). Any DPI function may be g
25、enerally described by the concept of policy rules (see clause 1.2). Implementers and users of the described techniques shall comply with all applicable national and regional laws, regulations and policies. The mechanism described in this Recommendation may not be applicable to the international corr
26、espondence in order to ensure the secrecy and sovereign national legal requirements placed upon telecommunications, and ITU Constitution and Convention. This Recommendation does not address the specific impact of implementing a distributed DPI functionality. The requirements are primarily about func
27、tional aspects of DPI, but physical aspects are also covered. In the context of functional to physical mapping scenarios, only 1-to-1 mapping and N-to-1 mapping between a DPI-FE and a DPI-PE is within the scope of this Recommendation. In other words, no requirements cover distributed DPI-PEs. 1.1 Ap
28、plicability This Recommendation is applicable to the scenarios identified in Figure 1-1: Y.2770(12)_F1-1Packet-based network typeNGN non-NGNApplicable Possibly applicableIPPacketbearertechnologynon-IP Possibly applicable Possibly applicableFigure 1-1 Applicability of this Recommendation The notion o
29、f “non-IP“ refers to protocol stacks for packet bearer types without any IP protocol layer (IETF RFC 791 and IETF RFC 2460). Though this Recommendation mainly addresses the requirements of DPI for NGN, these requirements may be applicable to other types of networks. This further applicability is for
30、 further study. 2 Rec. ITU-T Y.2770 (11/2012) 1.2 Policy rules This Recommendation assumes a generic high-level format for all policy rules. This high-level format applies to DPI rules as shown in Figure 1-2. The format distinguishes three basic blocks of: i) rule identifier/name (with ranking/order
31、 indication due to possible multiple rules); ii) DPI signature/conditions; iii) actions. There is a logical binding between action(s) and condition(s), see clause 3.1.2. Y.2770(12)_F1-2DPI Policy Rule R =i Rule name = .Rule identifier = .Priority, preference, precedence.DPI signature (DPI policycond
32、ition(s) for a specificapplication = Action(s) = .Figure 1-2 Generic format of DPI policy rules Note that the following aspects are within the scope of this Recommendation: the specification of requirements related to the DPI signature, (i.e., the DPI signatures used for application identification a
33、nd flow identification); the specification of requirements related to the identification and naming of DPI policy rules; and the identification of possible scenarios involving policy actions as potential follow-up activities after the evaluation of DPI signatures. In contrast, the following aspects
34、are outside the scope of this Recommendation: the specification of requirements related to actions concerning the modification of inspected packet(s); the specification of explicit bindings between actions and conditions (Note); the specification of DPI policy rules in full; the specification of a l
35、anguage for DPI signatures; and the specifications of concrete DPI policy conditions (such as behavioural or statistical functions). NOTE For instance, there might be a specification for the action of discarding a packet, and the condition of searching for a packet signature, but there will not be a
36、ny specification that associates an individual action to an actual condition. Rec. ITU-T Y.2770 (11/2012) 3 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of pub
37、lication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of
38、the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T E.107 Recommendation ITU-T E.107 (2007), Emergency Telecommunications Service (ETS) and intercon
39、nection framework for national implementations of ETS. ITU-T X.200 Recommendation ITU-T X.200 (1994) | ISO/IEC 7498-1:1994, Information technology Open Systems Interconnection Basic Reference Model: The basic model. ITU-T X.731 Recommendation ITU-T X.731 (1992) | ISO/IEC 10164-2:1993, Information te
40、chnology Open Systems Interconnection Systems management: State management function. ITU-T Y.1221 Recommendation ITU-T X.1221 (2010), Traffic control and congestion control in IP based networks. ITU-T Y.2111 Recommendation ITU-T Y.2111 (2008), Resource and admission control functions in next generat
41、ion networks. ITU-T Y.2205 Recommendation ITU-T Y. 2205 (2011), Next Generation Networks Emergency telecommunications Technical considerations. ITU-T Y.2701 Recommendation ITU-T Y.2701 (2007), Security requirements for NGN release 1. ITU-T Y.2704 Recommendation ITU-T Y.2704 (2010), Security mechanis
42、ms and procedures for NGN. IETF RFC 791 IETF RFC 791 (1981), Internet Protocol. IETF RFC 2460 IETF RFC 2460 (1998), Internet Protocol, Version 6 (IPv6) Specification. IETF RFC 5101 IETF RFC 5101 (2008), Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic F
43、low Information. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 filter b-IETF RFC 3198: A set of terms and/or criteria used for the purpose of separating or categorizing. This is accomplished via single- or multi-field matching of traf
44、fic header and/or payload data. “Filters“ are often manipulated and used in network operation and policy. For example, packet filters specify the criteria for matching a pattern (for example, IP or 802 criteria) to distinguish separable classes of traffic. NOTE In this Recommendation, the term “traf
45、fic header“ is equivalent to “packet header“. 4 Rec. ITU-T Y.2770 (11/2012) 3.1.2 filter/policy rule b-IETF RFC 3198: A basic building block of a policy-based system. It is the binding of a set of actions to a set of conditions, where the conditions are evaluated to determine whether the actions are
46、 performed. NOTE In this Recommendation, a filter rule is a specific policy rule with the purpose of separating traffic, e.g., in the main categories of “accepted“ and “not-accepted“. 3.1.3 flow IETF RFC 5101: A set of IP packets passing an observation point in the network during a certain time inte
47、rval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1) One or more packet header fields (e.g., destination IP address), transport header fields (e.g., destination port number), or applicatio
48、n header fields (e.g., RTP header fields b-IETF RFC 3550). 2) One or more characteristics of the packet itself (e.g., number of MPLS labels, etc.). 3) One or more of fields derived from packet treatment (e.g., next hop IP address, the output interface). A packet is defined as belonging to a flow if
49、it completely satisfies all the defined properties of the flow. This definition covers the range from a flow containing all packets observed at a network interface to a flow consisting of just a single packet between two applications. It includes packets selected by a sampling mechanism. NOTE The above numbered listed items indicate flow properties in the categories of (1) “Protocol Control Information (PCI) of packets“, (2) “Protocol Data Unit (PDU) properties of
