1、 ETSI TR 102 419 V1.1.1 (2005-04)Technical Report Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN);Security analysis of IPv6 application in telecommunications standardsETSI ETSI TR 102 419 V1.1.1 (2005-04) 2 Reference DTR/TISPAN-07001-Tech Keywords IP,
2、 security, telephony ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the p
3、resent document can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In ca
4、se of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this a
5、nd other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authori
6、zed by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2005. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIP
7、HON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 102 419 V1.1.1 (2005-04) 3 Contents Intellectual Property Rights5 Foreword.5 1 Sc
8、ope 6 2 References 6 3 Abbreviations .7 4 Security analysis of IPv67 4.1 Overview 7 4.2 Confidentiality8 4.3 Integrity 8 4.4 Availability.8 5 Internet protocols and OSI .8 5.1 Historical considerations 8 5.2 Seven layer OSI stack.9 5.3 Five layer IP stack 9 6 Summary of IPv6 .10 6.1 Introduction 10
9、6.2 Services in IPv611 6.2.1 Address allocation 11 6.3 Protocol considerations 11 6.4 Field by field comparison of IPv6 and IPv4.11 6.5 Options and their use in IPv6 .12 6.6 TCP, RTP and UDP13 6.6.1 TCP header and its use (from RFC 793).13 6.6.1.1 Reliability14 6.6.2 UDP header and its use (from RFC
10、 768) 14 6.6.2.1 Reliability15 6.6.3 RTP header and its use (from RFC 1889 superseded by RFC 3550)15 6.6.3.1 Reliability16 7 Quality and grade of service.16 8 Security in IPv616 8.1 Overview 16 8.2 Security protocols.17 8.2.1 Overview 17 8.2.2 Authentication Header (from RFC 2402) .17 8.2.2.1 Authen
11、tication Algorithms18 8.2.2.2 Scope of ICV computation18 8.2.3 Encapsulating Security Payload (from RFC 2406).18 8.2.3.1 Encryption Algorithms19 8.2.3.2 Authentication Algorithms20 8.2.4 Comparison of AH and ESP .20 8.3 Security associations 20 8.3.1 Security Associations and Management .20 8.4 Key
12、Management .21 9 Architecture and protocol implications 21 9.1 Security associations and key management21 10 Material for further study .22 10.1 Security association design.22 10.2 Protocol and services22 History 23 ETSI ETSI TR 102 419 V1.1.1 (2005-04) 4 Intellectual Property Rights IPRs essential
13、or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Es
14、sential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETS
15、I. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI Technical Committee Telecommu
16、nications and Internet converged Services and Protocols for Advanced Networking (TISPAN). ETSI ETSI TR 102 419 V1.1.1 (2005-04) 5 1 Scope The present document provides an analysis of the security provisions made in IPv6 and outlines how they may be used to support the objectives of the European Comm
17、ission to support the implementation of PKI solutions and the further deployment of IPv6 and IPsec. 2 References For the purposes of this Technical Report (TR), the following references apply: 1 “Overhead Issues for Local Access Points in IPsec enabled VPNs“, John Ronan, Paul Malone, Mchel Foghl, Pr
18、oceedings of IPS Workshop, Salzburg, February 2003. 2 TORRENT (Technology for a Realistic End User Access Network Test-bed), IST-2000-25187. http:/www.torrent-innovations.org. 3 IETF RFC 2410: “The NULL Encryption Algorithm and Its Use With IPsec“. 4 Andrew Tannenbaum: “Computer Networks (Internatio
19、nal Edition)“; Prentice Hall PTR; ISBN: 0130384887. 5 ETSI SR 002 211: “List of standards and/or specifications for electronic communications networks, services and associated facilities and services; in accordance with Article 17 of Directive 2002/21/EC“. 6 Directive 2002/21/EC of the European Parl
20、iament and of the Council of 7 March 2002 on a common regulatory framework for electronic communications networks and services (Framework Directive. 7 IETF RFC 2460: “Internet Protocol, Version 6 (IPv6) Specification“. 8 IETF RFC 793: “Transmission Control Protocol“. 9 IETF RFC 768: “User Datagram P
21、rotocol“. 10 IETF RFC 2326: “Real Time Streaming Protocol (RTSP)“. 11 IETF RFC 1889: “RTP: A Transport Protocol for Real-Time Applications“. 12 IETF RFC 2474: “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers“. 13 IETF RFC 2475: “An Architecture for Differentia
22、ted Service“. 14 IETF RFC 2205: “Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification“. 15 IETF RFC 2206: “RSVP Management Information Base using SMIv2“. 16 IETF RFC 2207: “RSVP Extensions for IPSEC Data Flows“. 17 IETF RFC 2208: “Resource ReSerVation Protocol (RSVP) - Version 1
23、 Applicability Statement Some Guidelines on Deployment“. 18 IETF RFC 2209: “Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules“. 19 IETF RFC 2210: “The Use of RSVP with IETF Integrated Services“. 20 IETF RFC 2401: “Security Architecture for the Internet Protocol“. 21 IETF RFC
24、2402: “IP Authentication Header“. 22 IETF RFC 2403: “The Use of HMAC-MD5-96 within ESP and AH“. ETSI ETSI TR 102 419 V1.1.1 (2005-04) 6 23 IETF RFC 2404: “The Use of HMAC-SHA-1-96 within ESP and AH“. 24 IETF RFC 2405: “The ESP DES-CBC Cipher Algorithm With Explicit IV“. 25 IETF RFC 2406: “IP Encapsu
25、lating Security Payload (ESP)“. 26 IETF RFC 3550: “RTP: A Transport Protocol for Real-Time Applications“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: ACK Acknowledge AES Advanced Encryption Standard AH Authentication Header DARPA Defence Advanced Rese
26、arch Projects Agency DHCP Dynamic Host Configuration Protocol ESP Encapsulating Security Payload FIN Finished IANA Internet Assigned Numbers Authority ICMP Internet Control Management Protocol ICV Integrity Check Value IKE Internet Key Exchange IP Internet Protocol ISDN Integrated Services Digital N
27、etwork ISO International Standards Organisation IV Initialization Vector MAC Message Authentication Codes NAT Network Address Translation OSI Open Standards Interconnection PSH Push QoS Quality of Service RH Routing Header RST Reset RTP Real time Transport Protocol SA Security Association SAP Servic
28、e Access Point SCN Switched Circuit Network SHA Secure Hashing AlgorithmSPI Security Parameters Index SYN Synchronize TCP Transport Control Protocol UDP User Datagram Protocol URG Urgent 4 Security analysis of IPv6 4.1 Overview The security analysis of IPv6 is performed against the core security att
29、ributes: Confidentiality. Integrity. Availability. ETSI ETSI TR 102 419 V1.1.1 (2005-04) 7 In addition the analysis of security provisions in a network using IPv6 is considered against the Framework Directive 6. 4.2 Confidentiality Providers of ECN connectionless data carried using User Datagram Pro
30、tocol (UDP, defined in RFC 768 9); real time connection oriented data carried using the Real Time Streaming Protocol (RTSP, defined in RFC 2326 10); or, more commonly the real-time transport protocol (RTP a protocol for real-time applications defined in RFC 1889 11). For example, how do the differen
31、ces between IPv4 and IPv6 impact these ULPs? What security mechanisms exist for each above IP and IPsec? What are the ramifications of using IPsec versus higher layer security. For example, a policy of using AH or ESP can provide some protection to TCP (sequence number guessing, port scanning, SYN f
32、looding, forged RSTs, hijacking), whereas TLS or SSH is useless against the first four of these five. But IPsec may be a bigger problem for firewalls. IPv4 is more likely, perhaps, to use NAT, and IPv6 may be more friendly to end-to-end IPsec. 6.6.1 TCP header and its use (from RFC 793) SECURITY IMP
33、ACT: Availability and Integrity Transmission Control Protocol (TCP) provides a reliable and continual data flow between two endpoints on the network. It provides a full duplex service to the application layer, which means that data can flow in both directions. For an application it is similar to a b
34、yte stream. The data is sent into the stream assuming that it will arrive at the other end, byte after byte, in the correct order. However, IP neither guarantees packet delivery nor an arrival of data packets only once and in the right order. Therefore, TCP must have its own mechanism. NOTE: Whereas
35、 IP is nominally stateless the use of TCP makes the connection and connection maintenance stateful. Every TCP packet has a sequence number that allows the recognition of missing packets, packets received in the wrong order or duplicated packets. TCP splits the data intended to be sent into best size
36、d “chunks“. This unit of information is called a segment. For every received segment, an acknowledgement is sent back to the sender. This confirms the reception of the packet. If the packet does not arrive in a certain time interval (the sender does not receive an acknowledgement), the sender retran
37、smits the packet. If packets arrive out of order, they can be reassembled because of the sequence numbers in each TCP packet. The technique that ensures the reliable transmission of data is called sliding window. ETSI ETSI TR 102 419 V1.1.1 (2005-04) 13The header fields needed for this functionality
38、 and all the others are illustrated in table 6. Table 6: TCP header Field Size M/O/C Function/comment Source port 16 M Port number of the process sending data Well, OK, but not exactly. The four-tuple of addresses and ports identify the process on each end. Destination port 16 M Port number of the p
39、rocess receiving data. Sequence number 32 M Offset number of the first data byte of the payload in the byte stream. Acknowledgement number 32 M Points to the sequence number of the octet following received and read data. Data offset 4 M Defines the offset of the data in this TCP segment. Reserved 6
40、M Reserved for future use. Must be zero. Flags 6 M Six flags. Window 16 M Used for the advertisement of the transmission window size. Checksum 16 M Is calculated over TCP header and payload. Urgent pointer 16 M Points to the sequence number of the octet following the urgent data. Options 1 to 32 O V
41、ariable. Padding 0 to 32 O For maintaining a multiple of 32. Number of bits 160 minimum The flags field contains six flags: Urgent (URG): It enables urgent mode. One end signals the other end that some form of urgent data has been placed into the stream. Acknowledge (ACK): It indicates that the ackn
42、owledgement number contained in this TCP packet is valid. Push (PSH): It asks the receiver to pass the data to the application as soon as possible. Reset (RST): It resets the connection. Synchronize (SYN): It is used during the connection establishment to synchronize sequence numbers. Finished (FIN)
43、: Its sender indicates that it wants to terminate the connection. 6.6.1.1 Reliability Reliability is one the raison detre of the Transmission Control Protocol. Generally called a reliable protocol TCP will always get the data through. It does so without regard, generally, to delay or to throughput.
44、If a packet is lost the packet transmission rate is dropped and the missing packet retransmitted. As the success rate increases so does the packet rate. 6.6.2 UDP header and its use (from RFC 768) SECURITY IMPACT: Availability User datagram protocol (UDP) is another transport protocol that uses IP f
45、or its service. It resides in the transport layer 4 of the layered IP stack model of section 4.3. The purpose of UDP is to provide a multiplexed a datagram service between two hosts. This means that individual datagrams, chunks of data, may be sent from one host to the other and delivered to the cor
46、rect process on each end. The UDP header introduces two fields for addressing the ports of the processes that interact. The source-port field and the destination-port field. Important properties of UDP are that there are no mechanisms to guarantee the delivery of a packet or to detect duplicate pack
47、ets. The datagram service of UDP is therefore also referred to as being an “unreliable service“. ETSI ETSI TR 102 419 V1.1.1 (2005-04) 14The fields of the UDP header are listed in table 7: Table 7: UDP header Field name Size Function/comment Source port 16 Port number of the process sending the data
48、gram. Destination port 16 Port number of the process receiving the datagram. Length 16 Length of the UDP header and data. Checksum 16 Checksum over UDP header and data. Number of bits 64 6.6.2.1 Reliability UDP is unreliable and any packet lost by UDP remains lost and UDP makes no attempt to recover
49、. 6.6.3 RTP header and its use (from RFC 1889 superseded by RFC 3550) SECURITY IMPACT: Availability and Integrity This protocol supports end-to-end delivery of data with real-time characteristics, such as video or audio. It is the basis for VoIP telephony protocols. For example SIP and H.323 use it to deliver voice data. To fulfil its purpose RTP uses the services of the transport layer protocol, which is in most cases UDP. UDP does not have integrated mechanisms to reorder packets or retr
