Open Standards for an Open Internet

Size: px

Start display at page:

Download "Open Standards for an Open Internet"

Lora Wright
5 years ago
Views:

1 The IETF Open Standards for an Open Internet Olaf M. Kolkman I speak about the IETF, not for the IETF Kolkman@isoc.org

2 The Internet is a Network of Independent Networks That exchange IP traffic 2 About the IETF 23 June 2015 Picture by NLnet Labs, Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

3 About the IETF 23 June 2015 Image Source: http://en.

3 3 About the IETF 23 June 2015 Image Source: (CC License)

4 Technical Building Blocks (design) principles 4 About the IETF 23 June 2015 Image Source: NLnet Labs Blender model based on (CC License)

5 The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. 5 About the IETF 23 June 2015

6 IETF Universe RFC Editor IETF Secretariat IESG 6 About the IETF 23 June 2015 IASA IAD IAOC IETF Trust Area Area Area Area Area Area group group group group group group group group group group group group group group group group group group group group group group group group group group group group group group

7 7 About the IETF 23 June 2015

8 INT RTG About Packets About creating the paths for the packets OPS About managing the networks TSV About the use of the paths to provide the end-toend experience SEC About Security Protocols (cross area) 8 ART About the IETF 23 June 2015 About Application Protocols used on the Internet and Real Time Applications

IESG Approval IESG Approval Internet-Drafts Proposed Standard proposed draft Standards Track documents are maintained by the IETF IESG

9 IETF standards are published as RFCs Standards track Best Current Practices (operational) Informational and Experimental RFC series also includes IRTF (Internet Research Task Force) IAB (Internet Architecture Board) Independent contributions IETF Standards and RFCs IESG Approval IESG Approval Internet-Drafts Proposed Standard proposed draft Standards Track documents are maintained by the IETF IESG approval: based on consensus process new 2 step Internet Standard full old 3 step Not al RFCs are IETF standards 9 About the IETF 23 June 2015

10 Art area B. Leiba, A.Cooper, B. Campbell appsawg avtcore avtext bfcpbis caltext core clue codec dbound dispatch dmarc drinks ecrit eppext geojson httpbis hybi imapapnd insipid jsonbis lager mmusic modern netvc p2psip payload perc precis rtcweb sipcore siprec stir stox straw tzdist urnbis uta webpush xrblock Transport Area M. Stiemerling S. Dawkins alto aqm conex dtn ippm mptcp nsfv4 ppsp rmcat storm taps tcpinc tcpm tram tsvwg Security Area K. Moriarty S. Farrell abfab ace acme cose dane dice dots httpauth i2nsf ipsecme jose kitten mile oauth openpgp sacm tls tokbind trans IESG Routing Area A. Retana A. Atlas, D. Brungard bess bfd bier ccamp detnet i2rs idr isis l2tpext lisp manet mpls nvo3 ospf pce pim roll rtwg sfc sidr spring teas trill O&M Area B. Claise J. Jaeggli anima bmwg dime dnsop grow l3sm lime lmap mboned netconf netmod opsawg opsec radext supa v6ops Internet Area B. Haberman T. Manderson 6lo 6man 6tish dhc dmm dnssd dprive hip homenet intarea lwig mif netext ntp pcp savi softwire sunset4 tictoc GENERAL AREA J. Arko IANAplan Last Update Oct

12 Source:

1. Cooperation Respectful cooperation between standards organizations, whereby each respects the autonomy, integrity, processes, and intellectual property rules of the others. 2.

No one party dominates or guides standards development. Standards processes are transparent and opportunities exist to appeal decisions.

Processes allow for all views to be considered and addressed, such that agreement can be found across a range of interests. Transparency.

13 1. Cooperation Respectful cooperation between standards organizations, whereby each respects the autonomy, integrity, processes, and intellectual property rules of the others. 2. Adherence to Principles Adherence to the five fundamental principles of standards development: Due process. Decisions are made with equity and fairness among participants. No one party dominates or guides standards development. Standards processes are transparent and opportunities exist to appeal decisions. Processes for periodic standards review and updating are well defined. Broad consensus. Processes allow for all views to be considered and addressed, such that agreement can be found across a range of interests. Transparency. Standards organizations provide advance public notice of proposed standards development activities, the scope of work to be undertaken, and conditions for participation. Easily accessible records of decisions and the materials used in reaching those decisions are provided. Public comment periods are provided before final standards approval and adoption. Balance. Standards activities are not exclusively dominated by any particular person, company or interest group. Openness. Standards processes are open to all interested and informed parties. 3. Collective Empowerment Commitment by affirming standards organizations and their participants to collective empowerment by striving for standards that: are chosen and defined based on technical merit, as judged by the contributed expertise of each participant; provide global interoperability, scalability, stability, and resiliency; enable global competition; serve as building blocks for further innovation; and contribute to the creation of global communities, benefiting humanity. 4. Availability Standards specifications are made accessible to all for implementation and deployment. Affirming standards organizations have defined procedures to develop specifications that can be implemented under fair terms. Given market diversity, fair terms may vary from royalty-free to fair, reasonable, and non-discriminatory terms (FRAND). 5. Voluntary Adoption Standards are voluntarily adopted and success is determined by the market. Respectful Cooperation Between Standards Adherence to the Fundamental Parameters of Standards Development Collective Empowerment to Strive to Develop Standards that are Chosen and Defined Based on Technical Merit Availability of Standards Specification Voluntary Adoption by the Standards Market

14 How I got involved in the IETF. (by contributing) How do you get involved in the IETF (by contributing)

16 datatracker.ietf.org

17 tools.ietf.org

18 IETF CodeMatch

19 IETF CodeMatch March 2015 Kathleen Moriarty Lisandro Granville

20 CodeMatch Overview What is CodeMatch? Marketplace which brings together students, researchers, professors, open source development communities, vendors with proprietary implementations, and consumers of code bases Objectives Link existing implementations to standards Showcase opportunities to develop running code for IETF protocols Provide clear benefits to each user type from increased collaboration Grace Hopper Celebration Initial idea came from discussions with students and professors to help provide options for them to engage in the IETF, with ISOC at GHC Scope and objectives expanded with help from the diversity design team members and numerous contributors For more information:

21 CodeMatch Goals Open collaboration platform for running code of IETF protocols Connect drafts/rfcs in a measurable way to running code Open source and proprietary Coordinating activities related to code and IETF work Note, we are not GitHub, we link to open source and proprietary Increased collaboration with under represented communities Engage with Universities, get students interested in the IETF Engage and collaborate with open source communities Engage under-represented regions: ISOC, Latin America for IETF 95 Low barrier entry point to the IETF

22 Benefits for Participants Speed-up implementations of IETF protocols Increase visibilty of implementations Coordination of plugtests Matches between universities & industry to sponsor capstone projects Opportunity to improve resume: students, job transitions Demonstrate multiple interoperable implementations of drafts/rfcs

23 CodeMatch Roadmap Idea Origination & Planning (Oct. 2013) Mockups v1 (Jul. 2014) Data Model v1 (Nov. 2014) Prototype v1 (Dec. 2014) User Interface Testing Card sort & IETF 92 UX testing (Sunday) Adjust prototype from feedback (April 2015) Development (Starting Soon!)

24 CodeMatch Development Phase 1 - Basic functionality to create CodeMatches, enable CodeRequests and Mentor assignments, match published drafts to existing code bases (Yokohama) Phase 2 - Improved Functionality such as organizing Plug Fests, notifying developers of confirmed errata, dashboards for management and statistics, advertise IRTF and ISOC incentives for coders (Buenos Aires) Phase 3 - Advanced Features such as reputation scoring for code bases, ability for coders to request help to create drafts from feature developed, etc. (Seoul) Feature list by phase:

25 Mockups

34 Data Model

35 GUI Prototype

39 CodeMatch Contributors Alejandro Acosta William Atwood Toral Cowieson Kristin Burgh Lars Eggert Lisando Granville Brian Haberman Wanderson Jesus Suresh Krishnan Henrik Levkowetz Carlos Martinez Kathleen Moriarty Jéferson Nobre Christian O Flaherty Vyria Paselk Pete Resnick Michael Richardson Thomas Schmidt Robert Sparks Brian Trammell Matthias Waehlisch Dave Waltermire Lixia Zhang

40 Asks WGs & Individuals: Think about drafts that might be a good target for CodeMatch Mentor required for CodeRequests Estimated development time needed If you are interested to join the team developing the site, subscribe to mailing list: CodeMatch-develop@ietf.org Assistance from Apps are requested to help select appropriate icons Timeline is fluid and depends on volunteers, please consider contributing

41 Thank you! CodeMatch Development Team

43 Context We are talking about more than encryption. Encryption is just a tool for enhancing privacy and trust

44 June Snowden revelation Undermined User trust; Generated awareness Invoked strong community and industry action Greater dialogue and cooperation on key issues Review of privacy of data relative to a pervasive monitoring: Uptake in Encryption New Atlantic cables etc etc 44 Encryption 23 September 2015

45 RFC 7258: Pervasive Monitoring is an Attack 45 Encryption 23 September 2015

46 The term "attack" is used here in a technical sense that differs somewhat from common English usage. In common English usage, an attack is an aggressive action perpetrated by an opponent, intended to enforce the opponent's will on the attacked party. The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. 46 Encryption 23 September 2015

47 Statistics Transport security is being deployed!

Fraction of HTTPS links on Alexa top 1000 pages Jan 2013-Sep 2015 Source HTTPARCHIVE http://httparchive.

48 Fraction of HTTPS links on Alexa top 1000 pages Jan 2013-Sep 2015 Source HTTPARCHIVE 48 Encryption 23 September 2015

49 Hosts responding to HTTPS and found certificates (full IPv4 scan) Source:University of Michigan 49 Encryption 23 September 2015

50 From the a network perspective HTTPS traffic grew from 4%(2008) to 17% (2015) Source known to author 50 Encryption 23 September 2015

51 A CDN now sees 35+% of hits over HTTPS Source known to author 51 Encryption 23 September 2015

52 Googles traffic from and towards other mail providers (between jan 2014 and oct 2015 incoming traffic doubled) 52 Encryption 23 September 2015

53 Developments in the past few years. Google s SPDY, which contains TLS IAB: Turn on Encryption by default RFC7540 HTTP2.0 Firefox and Chrome default to encrypted HTTP2 Windows and Apple move http2 to desktop and mobile OSes 53 Encryption 23 September 2015

54 Transport Encryption is not the Only tool to increase trust and privacy 54 Encryption 23 September 2015

55 HTTP2 RF depr C7465: ecat ing RC i dpr ve ning i f e d 5: RFC743 unistic opport ion t p y r c en ACME qna minim me izati 55 4 Encryption 23 September 2015 DNS q minim name izati on on 3 TLS 1. RG n F C F T IR curves ew

56 Ubiquitous Encryption may have a profound effect Caching DPI to filter web content (malevolent and benevolent) Traffic management Media optimization Example: fallback to upstream provider Example: Filtering of Wikipedia Article Leads to reassessment of the role of intelligence in the network and the role of the end-users. Example: feeding movie content to mobile handset 56 Encryption 23 September 2015

57 The realities. Everything is in the clear approach is clearly unworkable Encryption will reduce the number of parties that see traffic But not eliminate them content provider, browser vendor, CAs, proxy provider, corporate IT department, World still moves ahead on a voluntary basis on what technology is chosen and on what technology a particular party can adopt Surveillance shifts, not eliminated Useful technical things done in different ways, not eliminated Some potential bad outcomes to avoid - MITMs, regulation limiting security, fragmentation, device control, 57 Encryption 23 September 2015

58 When we look at the increased encryption, we should not prepare ourselves to merely deal with its effects. We need to prepare for a period of increasingly fast evolution in the Internet traffic patterns and technology. Such evolution may include new transport solutions, HTTP version 3 and beyond, the introduction of new parties (such as caching, CDN, or P2P entities), new types of security (such as content-based security), and other things that we cannot foresee at this point Jari Arkko & Göran Eriksson in their contribution to the Manrew Workshop making networks unmanageable to mitigate PM (Pervasive Monitoring) is not an acceptable outcome RFC Encryption 23 September 2015

59 59 About the IETF 23 June 2015

60 60 About the IETF 23 June 2015

61 fin 61 About the IETF 23 June 2015

The IETF. Open Standards for an Open Internet. Olaf M. Kolkman. I speak about and not for the IETF. Saturday, April 13, 13

The IETF. Open Standards for an Open Internet. Olaf M. Kolkman. I speak about and not for the IETF. Saturday, April 13, 13 The IETF Open Standards for an Open Internet Olaf M. Kolkman I speak about and not for the IETF olaf@nlnetlabs.nl Outline Open Internet Open Standards The IETF as a Open Standards Body Org Chart Working