1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T X.1210 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (01/2014) SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY Cyberspace security Cybersecurity Overview of source-based security troubleshooting mechanism
2、s for Internet protocol-based networks Recommendation ITU-T X.1210 ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY PUBLIC DATA NETWORKS X.1X.199 OPEN SYSTEMS INTERCONNECTION X.200X.299 INTERWORKING BETWEEN NETWORKS X.300X.399 MESSAGE HANDLING SYSTEMS X.400X.499
3、DIRECTORY X.500X.599 OSI NETWORKING AND SYSTEM ASPECTS X.600X.699 OSI MANAGEMENT X.700X.799 SECURITY X.800X.849 OSI APPLICATIONS X.850X.899 OPEN DISTRIBUTED PROCESSING X.900X.999 INFORMATION AND NETWORK SECURITY General security aspects X.1000X.1029 Network security X.1030X.1049 Security management
4、X.1050X.1069 Telebiometrics X.1080X.1099 SECURE APPLICATIONS AND SERVICES Multicast security X.1100X.1109 Home network security X.1110X.1119 Mobile security X.1120X.1139 Web security X.1140X.1149 Security protocols X.1150X.1159 Peer-to-peer security X.1160X.1169 Networked ID security X.1170X.1179 IP
5、TV security X.1180X.1199 CYBERSPACE SECURITY Cybersecurity X.1200X.1229 Countering spam X.1230X.1249 Identity management X.1250X.1279 SECURE APPLICATIONS AND SERVICES Emergency communications X.1300X.1309 Ubiquitous sensor network security X.1310X.1339 CYBERSECURITY INFORMATION EXCHANGE Overview of
6、cybersecurity X.1500X.1519 Vulnerability/state exchange X.1520X.1539 Event/incident/heuristics exchange X.1540X.1549 Exchange of policies X.1550X.1559 Heuristics and information request X.1560X.1569 Identification and discovery X.1570X.1579 Assured exchange X.1580X.1589 CLOUD COMPUTING SECURITY Over
7、view of cloud computing security X.1600X.1601 Cloud computing security design X.1602X.1639 Cloud computing security best practices and guidelines X.1640X.1659 Cloud computing security implementation X.1660X.1679 Other cloud computing security X.1680X.1699 For further details, please refer to the lis
8、t of ITU-T Recommendations. Rec. ITU-T X.1210 (01/2014) i Recommendation ITU-T X.1210 Overview of source-based security troubleshooting mechanisms for Internet protocol-based network Summary Recommendation ITU-T X.1210 provides source-based security troubleshooting mechanisms for security issues, as
9、 well as selection criteria and basic security guidelines of troubleshooting mechanisms. Source-based troubleshooting security issues in Internet protocol-based networks involve techniques used to discover technical information concerning the ingress points, paths, partial paths or sources of a pack
10、et or packets causing a problematic network event, generally for the purposes of applying mitigation measures. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T X.1210 2014-01-24 17 11.1002/1000/12043 _ * To access the Recommendation, type the URL http:/handle.itu.int/ in the
11、address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T X.1210 (01/2014) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications,
12、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 tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on
13、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 Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid dow
14、n 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 Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication
15、administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory
16、 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 compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attent
17、ion 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, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others
18、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 required to implement this Recommendation. However, implementers are cautioned that this may not represent th
19、e latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2014 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T X.1210 (01/2014) iii
20、 Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 1 3.1 Terms defined elsewhere 1 3.2 Terms defined in this Recommendation . 1 4 Abbreviations and acronyms 1 5 Conventions 1 6 General overview of source-based security troubleshooting mechanisms . 2 6.1 Source-based security troubles
21、hooting with link testing 2 6.2 Source-based security troubleshooting mechanism with overlay network 2 6.3 Source-based security troubleshooting with probing . 2 6.4 Source-based security troubleshooting with logging and sampling . 2 6.5 Source-based security troubleshooting across autonomous system
22、s 2 7 Basic security guidelines of the source-based security troubleshooting mechanisms 3 8 Criteria for evaluating source-based troubleshooting mechanisms 3 Bibliography. 5 Rec. ITU-T X.1210 (01/2014) 1 Recommendation ITU-T X.1210 Overview of source-based security troubleshooting mechanisms for Int
23、ernet protocol-based network 1 Scope This Recommendation provides an overview of source-based security troubleshooting mechanisms, evaluation criteria and basic security guidelines of troubleshooting mechanisms. Implementers and users of this ITU-T Recommendation shall comply with all applicable nat
24、ional and regional laws, regulations and policies. 2 References None. 3 Definitions 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 denial of service b-ITU X.800: The prevention of authorized access to resources or the delaying of time-critical opera
25、tions. 3.1.2 security domain b-ITU-T T.411: The set of resources subject to a single security policy. 3.1.3 threat b-ITU-T X.800: A potential violation of security. 3.2 Terms defined in this Recommendation None. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and ac
26、ronyms: AS Autonomous System BGP Border Gateway Protocol DoS Denial of Service ICMP Internet Control Message Protocol IP Internet Protocol IPFIX IP Flow Information export IPv4/v6 Internet Protocol version 4/version 6 ISP Internet Service Provider RID Real-time Inter-network Defence TCP Transmission
27、 Control protocol 5 Conventions None. 2 Rec. ITU-T X.1210 (01/2014) 6 General overview of source-based security troubleshooting mechanisms Troubleshooting source-based security issues in Internet protocol (IP)-based networks generally involves a technical and/or an administrative process for reliabl
28、y identifying the source of an IP packet or of IP packets that may or may not carry the correct IP address of the sender, or the paths or part of paths that are inducing security issues. Source-based security troubleshooting mechanisms can be used to identify the physical or logical location of such
29、 security issue events in real time with the help of network elements such as routers or hosts in the network. Troubleshooting mechanisms for security issues in IP-based networks are discussed below. 6.1 Source-based security troubleshooting with link testing Troubleshooting can start from the route
30、r closest to the victim and interactively test its upstream links until the Internet service providers can determine which one of them is being used to carry the offending traffic. Ideally, this procedure is repeated recursively on the upstream router until the source of the security issue is identi
31、fied. This technique assumes that a security issue remains active until the completion of the troubleshooting procedure. As such, this technique is inappropriate for attacks that are detected after the fact, for attacks that occur intermittently, or for attacks that modulate their behaviour in respo
32、nse to security troubleshooting. Input debugging is one implementation of the link testing mechanism. This is a feature that already exists on many routers allowing the administrator to determine incoming network links for specific packets. If the router operator knows the attack traffics specific c
33、haracteristics (called “attack signature“), it is then possible to determine the incoming network link on the router. 6.2 Source-based security troubleshooting mechanism with overlay network A black-holing mechanism b-IETF RFC 3882 is an operational technique that utilizes a sinkhole tunnel which is
34、 implemented at all possible entry points from which attacks can pass into the destination/attacked autonomous system (AS). Using the border gateway protocol (BGP) b-IETF RFC 4271, traffic destined for the attacked/targeted host can be black-holed, i.e., dropped from the network, or re-routed to a s
35、pecial path (tunnel) where a device can capture the traffic for analysis and then drop the traffic. 6.3 Source-based security troubleshooting with probing Internet control message protocol (ICMP), for both Internet protocol version 4 (IPv4) b-IETF RFC 792 and Internet protocol version 6 (IPv6) b-IET
36、F RFC 4443, has been and will continue to remain one of the most useful troubleshooting mechanisms for IP-based networks. A number of tools, including ping and traceroute, come bundled with common operating systems that employ ICMP to conduct end-to-end or link-level troubleshooting. 6.4 Source-base
37、d security troubleshooting with logging and sampling Flow sampling can be a useful troubleshooting mechanism for security issues in IP-based networks. Operators may use sFlow b-IETF RFC 3176, NetFlow b-IETF RFC 3954 or IP flow information export (IPFIX) b-IETF RFC 5655 while taking into account supp
38、orted flow sampling standards in deployed routers. 6.5 Source-based security troubleshooting across autonomous systems In large-scale security issues that span across autonomous systems, operators can rely on troubleshooting tools based on probing (see clause 6.3) and online probes that are availabl
39、e on the Internet, e.g., Looking Glass b-LG. In the future, operators may be able to facilitate information Rec. ITU-T X.1210 (01/2014) 3 exchange for more advanced troubleshooting tools across autonomous systems, e.g., by using real-time inter-network defense (RID) b-IETF RFC 6045. 7 Basic security
40、 guidelines of the source-based security troubleshooting mechanisms The basic security guidelines of source-based security troubleshooting are provided as follows: The source-based security troubleshooting mechanisms should be designed to be scalable, robust and resilient. The source-based security
41、troubleshooting mechanisms should be deployed and operated across multiple domains each of which is managed by a responsible security administrator (i.e., inter-AS troubleshooting). The source-based security troubleshooting mechanisms should be implemented into one of two types of deployment models:
42、 a centralized deployment model or a distributed deployment model. The source-based security troubleshooting mechanisms should provide discovering technical information concerning the ingress points, paths, partial paths or sources of a packet or packets causing a problematic network event, generall
43、y for the purposes of applying mitigation measures. In order to select a suitable source-based security troubleshooting mechanism, the mechanisms should be evaluated according to the criteria described in clause 8. The interface of source-based security troubleshooting mechanisms across autonomous s
44、ystems should provide confidentiality, data origin authentication and integrity of the information exchanged between the various security domains and may provide availability of the troubleshooting mechanism. 8 Criteria for evaluating source-based troubleshooting mechanisms Criteria which can be use
45、d to evaluate troubleshooting mechanisms are specified as follows: Degree of Internet service provider (ISP) involvement: The degree of ISP involvement when troubleshooting is specified by an ISP administrator. Most troubleshooting mechanisms assume that ISPs provide limited facilities to enable tro
46、ubleshooting. An ideal troubleshooting scheme would require a low level of ISP involvement. Number of packets required for troubleshooting: The number of packets used by an administrator to identify the source of the security issue once the security issue has been detected. Effectiveness of partial
47、deployment: The degree of effectiveness of troubleshooting when the troubleshooting schemes are deployed partially within a single ISP. The effectiveness varies from inability to producing meaningful identification. Processing overhead for troubleshooting: The amount of processing overhead at the in
48、termediate network element or a potential victim host. An ideal troubleshooting scheme with minimal processing overhead for the intermediate network element or victim host would be preferred. Degree of bandwidth increase: The additional amount of traffic required for troubleshooting. A desirable tro
49、ubleshooting mechanism should have minimal or no increase of additional bandwidth. Memory requirement: The amount of additional memory required on the network elements or a dedicated troubleshooting server. Additional memory on the network element would be undesirable, whereas additional memory on dedicated servers is tolerable. An ideal 4 Rec. ITU-T X.1210 (01/2014) troubleshooting mechanism would require a limited amount of additional memory at the dedicated server
