Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ION Hangzhou - About IETF

427 views

Published on

14 July 2016, ION Hangzhou (China). About the Internet Engineering Task Force (IETF).

Published in: Technology
  • Login to see the comments

  • Be the first to like this

ION Hangzhou - About IETF

  1. 1. www.internetsociety.org I speak about the IETF, not for the IETF The IETF Open Standards for an Open Internet Olaf M. Kolkman Kolkman@isoc.org
  2. 2. Working in the IETF On the Publication Process and RFCs Potential Topics of Interest Context IETF Organization
  3. 3. Context
  4. 4. About the IETF | March 20164 The Internetis a Network of Independent Networks That exchange IP traffic Picture by NLnet Labs, Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
  5. 5. About the IETF | March 20165 Image Source: http://en.wikipedia.org/wiki/File:House_Plans_(Blueprints).pdf (CC License)
  6. 6. About the IETF | March 20166 Technical Building Blocks Image Source: NLnet Labs Blender model based on http://en.wikipedia.org/wiki/File:House_Plans_(Blueprints).pdf (CC License) (design)principles
  7. 7. About the IETF | March 20167 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.
  8. 8. 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. RespectfulCooperationBetweenStandards Adherence to the Fundamental Parameters of Standards DevelopmentCollective Empowerment to Strive to Develop Standards that are Chosen and Defined Based on Technical Merit Availability ofStandards Voluntary Adoption by the StandardsMarket
  9. 9. IETF Organization
  10. 10. About the IETF | 23 June 2015 IETF Trust IETF Universe 10 RFC Editor IASA IAD IAOC IESG Area Area Area Area Area Area working group working group working group working group working group working working group working group working group working group working group working working group working group working group working group working group working working group working group working group working group working group working working group working group working group working group working group working working group working group working group working group working group working IETF Secretariat
  11. 11. About the IETF | 23 June 201511
  12. 12. About the IETF | 23 June 201512 INT RTG TSV OPS About Packets About creating the paths for the packets About managing the networks About the use of the paths to provide the end-to- end experience ART About Application Protocols used on the Internet and Real Time Applications SEC About Security Protocols (cross area)
  13. 13. siprec slim stir stox straw urnbis uta webpush xrblock ice insipid jsonbis justfont lager mmusic modern netvc p2psip payload perc precis regex rtcweb scim sipcore IESG Art area B. Leiba,A.Cooper, B. Campbell Transport
 Area M. Stiemerling S. Dawkins Security
 Area K. Moriarty S. Farrell Routing
 Area A. Retana
 A.Atlas, 
 D. Brungard O&M
 Area B. Claise
 J. Jaeggli Internet
 Area B. Haberman T. Manderson GENERAL AREA
 J.Arko appsawg alto aqm abfab anima bmwg dime dnsop grow avtcore avtext bfcpbis 6lo 6man 6tish dhc dmm dnssd caltext dprive hip homenet intarea lwig ntp pcp savi softwire sunset4 tictoc l3sm lime lmap mboned netconf netmod opsawg opsec radext supa bess bfd bier ccamp ace dtn ippm mptcp nsfv4 rmcat taps tcpinc LastUpdateJune102016 IANAplan v6ops detnet i2rs idr isis l2tpext lisp manet mpls nvo3 ospf acme cose cdni tcpm tram tsvwg curdle dane dots httpauth i2nsf ipsecme jose kitten mile oauth openpgp sacm tls tokbind trans pals pce pim roll rtgwg sfc sidr spring teas trill capport cellar clue codec core dbound dispatch dmarc drinks ecrit geojson httpbis
  14. 14. 18 IETF 95 Participants! l  1002 people onsite" l  171 newcomers" l  IETF 92 had 1176 people onsite midweek" " l  55 countries " l  140 here from South America" l  IETF 92 was 57 countries" ! IETF 92 was held in
 Dallas, Texas! IETF 95 Buenos Aires
  15. 15. Source:http://www.arkko.com/tools/docstats.html
  16. 16. On the PublicationProcess and RFCs
  17. 17. About the IETF | 23 June 2015 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 Standards Track documents are maintained by the IETF • IESG approval: based on consensus process 17 draft full proposed Not al RFCs are IETFstandards Internet-Drafts Internet Standard IETF Standards and RFCs Proposed Standard IESG Approval IESG Approval old 3 stepnew 2 step
  18. 18. About the IETF | 23 June 2015 Standard Track 18
  19. 19. About the IETF | 23 June 2015 BCP 19
  20. 20. About the IETF | 23 June 2015 Informational (IETF) 20
  21. 21. About the IETF | 23 June 2015 Informational (IAB) 21
  22. 22. BAR BOF ListWG IETF Individual IESG IESG IESG IESG RFC IESG Different Flow for IETF stream documents
  23. 23. Working in the IETF
  24. 24. How I got involved in the IETF…. (by contributing) (by contributing) How do you get involved in the IETF
  25. 25. datatracker.ietf.org
  26. 26. tools.ietf.org
  27. 27. Potential Topics of Interest
  28. 28. MODERN Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers Drinks Data for Reachability of Inter/tra-NetworK SIP Emergency Context Resolution with Internet Technologies Ecrit Photo credit: Glen Edelson - https://www.flickr.com/photos/glenirah/ Stir Secure Telephone Identity Revisited
  29. 29. IESG Art area B. Leiba,A.Cooper, B. Campbell Transport
 Area M. Stiemerling S. Dawkins Security
 Area K. Moriarty S. Farrell Routing
 Area A. Retana
 A.Atlas, 
 D. Brungard O&M
 Area B. Claise
 J. Jaeggli Internet
 Area B. Haberman T. Manderson GENERAL AREA
 J.Arko appsawg alto aqm abfab anima bmwg dime dnsop grow avtcore avtext bfcpbis 6lo 6man 6tish dhc dmm dnssd caltext dprive hip homenet intarea lwig mif netext ntp pcp savi softwire sunset4 tictoc l3sm lime lmap mboned netconf netmod opsawg opsec radext supa bess bfd bier ccamp ace dtn ippm mptcp nsfv4 rmcat storm taps tcpinc LastUpdateFeb16,2016 IANAplan v6ops detnet i2rs idr isis l2tpext lisp manet mpls nvo3 ospf acme cose cdni cellar clue codec core dbound dispatch dmarc drinks ecrit eppext geojson httpbis ice imapapnd insipid jsonbis justfont lager mmusic modern netvc p2psip payload perc precis rtcweb scim sipcore siprec slim stir stox straw tzdist urnbis uta webpush xrblock tcpm tram tsvwg curdle dane dice dots httpauth i2nsf ipsecme jose kitten mile oauth openpgp sacm tls tokbind trans pals pce pim roll rtwg sfc sidr spring teas trill
  30. 30. DOTS DoS Open Threat Signaling “The DOTS protocols are therefore not concerned with the form of response, but rather with communicating the need for a response, supplementing the call for help with pertinent details about the detected attack.” DPRIVE DNS PRIVate Exchange
  31. 31. IESG Art area B. Leiba,A.Cooper, B. Campbell Transport
 Area M. Stiemerling S. Dawkins Security
 Area K. Moriarty S. Farrell Routing
 Area A. Retana
 A.Atlas, 
 D. Brungard O&M
 Area B. Claise
 J. Jaeggli Internet
 Area B. Haberman T. Manderson GENERAL AREA
 J.Arko appsawg alto aqm abfab anima bmwg dime dnsop grow avtcore avtext bfcpbis 6lo 6man 6tish dhc dmm dnssd caltext dprive hip homenet intarea lwig mif netext ntp pcp savi softwire sunset4 tictoc l3sm lime lmap mboned netconf netmod opsawg opsec radext supa bess bfd bier ccamp ace dtn ippm mptcp nsfv4 rmcat storm taps tcpinc LastUpdateFeb16,2016 IANAplan v6ops detnet i2rs idr isis l2tpext lisp manet mpls nvo3 ospf acme cose cdni cellar clue codec core dbound dispatch dmarc drinks ecrit eppext geojson httpbis ice imapapnd insipid jsonbis justfont lager mmusic modern netvc p2psip payload perc precis rtcweb scim sipcore siprec slim stir stox straw tzdist urnbis uta webpush xrblock tcpm tram tsvwg curdle dane dice dots httpauth i2nsf ipsecme jose kitten mile oauth openpgp sacm tls tokbind trans pals pce pim roll rtwg sfc sidr spring teas trill
  32. 32. ACCORD BOF Alternatives to Content Classification for Operator Resource Deployment BA-BOFShttps://trac.tools.ietf.org/bof/trac/wiki Alternative Resolution Contexts for Internet NamingARCING LURK Limited Use of Remote Keys
  33. 33. IEPG APPSAWG http://www.iepg.org The IEPG is an informal gathering that meets on the Sunday prior to IETF meetings. The intended theme of these meetings is essentially one of operational relevance in some form or fashion - although the chair will readily admit that he will run with an agenda of whatever is on offer at the time! OPSAWG And individual Area meetings
  34. 34. Encryption and the IETF
  35. 35. www.internetsociety.org Context We are talking about more than encryption. Encryption is just a tool for enhancing privacy and trust
  36. 36. Encryption | 23 September 2015 June 2013 - Snowden revelation 37 • 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
  37. 37. Encryption | 23 September 2015 RFC 7258: Pervasive Monitoring is an Attack 38
  38. 38. Encryption | 23 September 201539 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.
  39. 39. www.internetsociety.org Statistics Transport security is being deployed!
  40. 40. Encryption | 23 September 201541 http://httparchive.org/trends.php?s=Top1000&minlabel=Jan+1+2013&maxlabel=Sep+1+2015#perHttps Fraction of HTTPS links on Alexa top 1000 pages Jan 2013-Sep 2015 Source HTTPARCHIVE
  41. 41. Encryption | 23 September 201542 Hosts responding to HTTPS and found certificates (full IPv4 scan) Source:University of Michigan
  42. 42. Encryption | 23 September 201543 From the a network perspective HTTPS traffic grew from 4%(2008) to 17% (2015) Source known to author
  43. 43. Encryption | 23 September 201544 A CDN now sees 35+% of ‘hits’ over HTTPS Source known to author
  44. 44. Encryption | 23 September 201545 https://www.google.com/transparencyreport/saferemail/ Googles traffic from and towards other mail providers (between jan 2014 and oct 2015 incoming traffic doubled)
  45. 45. Encryption | 23 September 2015 Developments in the past few years…. 46 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
  46. 46. Encryption | 23 September 201547 Transport Encryption is not the Only tool to increase trust and privacy
  47. 47. Encryption | 23 September 201548 dprive HTTP2 RFC7435: defining opportunistic encryption RFC7465:deprecating RC4 TLS 1.3 DNS qnameminimizationqnameminimization IRTF CFRG new curves ACME
  48. 48. Encryption | 23 September 2015 • Leads to reassessment of the role of intelligence in the network and the role of the end-users. Ubiquitous Encryption may have a profound effect 49 • Caching • DPI to filter web content (malevolent and benevolent) • Traffic management • Media optimization Example: Filtering of Wikipedia Article Example: feeding movie content to mobile handset Example: fall- back to upstream provider
  49. 49. Encryption | 23 September 2015 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, … 50
  50. 50. Encryption | 23 September 201551 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 https://www.iab.org/activities/workshops/marnew/ “making networks unmanageable to mitigate PM (Pervasive Monitoring) is not an acceptable outcome” RFC 7258

×