Скачать презентацию The Internet standards process Ian Brown Overview Скачать презентацию The Internet standards process Ian Brown Overview

66d4576c7855339add5d5c39886ba7a2.ppt

  • Количество слайдов: 25

The Internet standards process Ian Brown The Internet standards process Ian Brown

Overview • • • What standards need setting? Protocols – the IETF and the Overview • • • What standards need setting? Protocols – the IETF and the ITU Approaches to wiretapping Approaches to patents Domain names and addresses

Ideal of open standards • Many different client and server applications give user choice, Ideal of open standards • Many different client and server applications give user choice, competition on features and price, and resistance to catastrophic attacks

Communications protocols • Define the format and sequence of messages that pass between two Communications protocols • Define the format and sequence of messages that pass between two or more communicating processes on one or more processors • Can be closed (many proprietary systems), open (standards-based) or open with proprietary extensions

What does a protocol look like? HELO machinename 250 Looks good to me MAIL What does a protocol look like? HELO machinename 250 Looks good to me MAIL FROM: I. Brown 250 OK RCPT TO: I. Brown 250 OK DATA 354 Enter Mail, end by a line with only '. ' Message text 250 Submitted & queued (0/msg. 28043 -0)

Competition implications • Closed protocols can be used to leverage a monopoly in one Competition implications • Closed protocols can be used to leverage a monopoly in one area (e. g. desktop operating system) into another (e. g. server software) • Protocol analysers and reverse engineering can be used to discover details of protocols – arms race

Internet Engineering Task Force • First met in San Diego in 1986 with 21 Internet Engineering Task Force • First met in San Diego in 1986 with 21 attendees • Forthcoming meeting in Minneapolis is 73 rd in series • Attendance peaked at 3, 000 in 2000 and is still around 2, 000, 3 times a year

IETF working groups • All IETF protocols developed in ~120 working groups in one IETF working groups • All IETF protocols developed in ~120 working groups in one of 8 areas • Groups make decisions by “rough consensus and running code” • Consensus must be found on mailing lists rather than at physical meetings

Example IETF working groups • • • avt Audio/Video Transport behave Behavior Engineering for Example IETF working groups • • • avt Audio/Video Transport behave Behavior Engineering for Hindrance Avoidance dccp Datagram Congestion Control Protocol enum Telephone Number Mapping ieprep Internet Emergency Preparedness ippm IP Performance Metrics ips IP Storage iptel IP Telephony megaco Media Gateway Control midcom Middlebox Communication

IETF process • Protocol documents begin life as “Internet drafts” (currently over 1, 000) IETF process • Protocol documents begin life as “Internet drafts” (currently over 1, 000) • Successful drafts become Requests for Comments (RFCs) • RFCs can be standards-track (proposed, draft or full), Informational, Experimental or Best Current Practice

ITU-T • International Telecommunications Union (Telecoms sector) • Part of United Nations system where ITU-T • International Telecommunications Union (Telecoms sector) • Part of United Nations system where governments and companies coordinate telecoms networks and services • Work done in “study groups” mostly by corporate staff but needs to be agreed by government representatives

ITU process • Much lower volume communication than IETF • Work tends to progress ITU process • Much lower volume communication than IETF • Work tends to progress more slowly and mainly at Geneva meetings

Example ITU study groups • Study Group 13 Multi-protocol and IP-based networks and their Example ITU study groups • Study Group 13 Multi-protocol and IP-based networks and their internetworking Lead Study Group for IP related matters, B-ISDN, Global Information Infrastructure and satellite matters. • Study Group 16 Multimedia services, systems and terminals Lead Study Group on multimedia services, systems and terminals, e -business and e-commerce. • Study Group 17 Data Networks and Telecommunication Software Lead Study Group on frame relay, communication system security, languages and description techniques.

Other relevant bodies • W 3 C – World Wide Web Consortium • ETSI Other relevant bodies • W 3 C – World Wide Web Consortium • ETSI – European Telecommunications Standards Institute • IEEE – Institute for Electrical and Electronics Engineering • ISO – International Standards Organisation

Approaches to “lawful access” • Wiretapping requirements imposed by legislation (e. g. Communications Assistance Approaches to “lawful access” • Wiretapping requirements imposed by legislation (e. g. Communications Assistance to Law Enforcement Act of 1994 in US, Regulation of Investigatory Powers Act 2000 in UK) • Requirements placed on manufacturers in US, ISPs and phone companies in both countries

Lawful access requirements • Undetectable to subject • Invisible to unauthorised personnel and other Lawful access requirements • Undetectable to subject • Invisible to unauthorised personnel and other interceptors • Any available decryption keys should be provided • Only authorised information should be provided

IETF approach • FBI requested wiretapping capability in Megaco protocol • IETF created mailing IETF approach • FBI requested wiretapping capability in Megaco protocol • IETF created mailing list to debate; 500 participants • Plenary debate at Washington DC meeting; very few in favour, many against, majority silent

IETF decision • “The IETF has decided not to consider requirements for wiretapping as IETF decision • “The IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards” • 1. Inappropriate in global standards – different legal and privacy requirements • 2. Would increase protocol complexity and decrease security • 3. End-to-end security makes unworkable • 4. Otherwise, many facilities already available

Ongoing IETF debate • “the IETF believes that mechanisms designed to facilitate or enable Ongoing IETF debate • “the IETF believes that mechanisms designed to facilitate or enable wiretapping, or methods of using other facilities for such purposes, should be openly described, so as to ensure the maximum review of the mechanisms and ensure that they adhere as closely as possible to their design constraints. ” • Cisco Architecture for Lawful Intercept in IP Networks (RFC 3924)

ETSI approach • “The Technical Committee on Lawful Interception (TC LI) is the leading ETSI approach • “The Technical Committee on Lawful Interception (TC LI) is the leading body for lawful interception standardization within ETSI. Lawful interception standards have also been developed by ETSI technical bodies AT, TISPAN (/SPAN and TIPHON™), TETRA, and by 3 GPP™”

ETSI standards • • • ES 201 671 Telecommunications Security; Lawful Interception (LI); Handover ETSI standards • • • ES 201 671 Telecommunications Security; Lawful Interception (LI); Handover Interface for the Lawful Interception of Telecommunications Traffic (revised version). ES 201 158 Telecommunications Security; Lawful Interception (LI); Requirements for Network Functions TS 102 234 Telecommunications Security; Lawful Interception (LI); Service-specific details for internet access services; TS 102 233 Telecommunications Security; Lawful interception (LI); Service-specific details for e-mail services TS 102 232 Telecommunications Security; Lawful Interception (LI); Handover Specification for IP Delivery TS 101 671 Telecommunications Security; Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic. TS 101 331 Telecommunications Security; Lawful Interception (LI); Requirements of Law Enforcement Agencies TR 102 053 Telecommunications Security; Lawful Interception (LI); Notes on ISDN lawful interception functionality. TR 101 944 Telecommunications Security; Lawful Interception (LI); Issues on IP Interception. TR 101 943 Telecommunications Security; Lawful Interception (LI); Concepts of Interception in a Generic Network Architecture.

Patent issues • Open standards of limited use if they require patent-protected technology • Patent issues • Open standards of limited use if they require patent-protected technology • Very popular with patent owners! • Standards bodies now addressing issue to a greater or lesser extent

IETF IPR policy • • • “This page provides a mechanism for filing Disclosures IETF IPR policy • • • “This page provides a mechanism for filing Disclosures about intellectual property rights (IPR) and for finding out what IPR Disclosures have been filed. ” https: //datatracker. ietf. org/public/ipr_disclosure. cgi “The IETF takes no position regarding the validity or scope of any intellectual property rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF documents or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. ” “The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at [email protected] org. "

W 3 C IPR policy • “Whenever possible, technical decisions should be made unencumbered W 3 C IPR policy • “Whenever possible, technical decisions should be made unencumbered by intellectual property right (IPR) claims. To this end, W 3 C discloses to the entire Membership which organizations have made IPR claims about a particular technology, as well as the details of those claims where they have been provided. Individuals should immediately disclose any IPR claims they know may be essential to implementing a Recommendation track technical report. ” • Goes further than IETF RAND target

Domain names • Domain Name System maps IP addresses (128. 16. 64. 182) to Domain names • Domain Name System maps IP addresses (128. 16. 64. 182) to Fully-Qualified Domain Names (happy. cs. ucl. ac. uk) • Overseen by ICANN, managed by registrars and registrants • International controversy (US control of process and root servers) • Trouble with trademarks