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

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. Working in
the IETF
On the
Publication
Process and
RFCs
Potential
Topics of
Interest
Context
IETF
Organization

3. Context

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. About the IETF | March 20165
Image Source: http://en.wikipedia.org/wiki/File:House_Plans_(Blueprints).pdf (CC License)

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. 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. 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. IETF Organization

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. About the IETF | 23 June 201511

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. 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. 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. Source:http://www.arkko.com/tools/docstats.html

16. On the PublicationProcess and RFCs

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. About the IETF | 23 June 2015
Standard Track
18

19. About the IETF | 23 June 2015
BCP
19

20. About the IETF | 23 June 2015
Informational (IETF)
20

21. About the IETF | 23 June 2015
Informational (IAB)
21

22. BAR
BOF
ListWG
IETF
Individual
IESG
IESG
IESG
IESG
RFC
IESG
Different Flow for IETF stream documents

23. Working in the IETF

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

26. datatracker.ietf.org

27. tools.ietf.org

28. Potential Topics of
Interest

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. Encryption and the
IETF

36. www.internetsociety.org
Context
We are talking about more than encryption. Encryption is just a tool for
enhancing privacy and trust

37. 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

38. Encryption | 23 September 2015
RFC 7258: Pervasive Monitoring is an Attack
38

39. 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.

40. www.internetsociety.org
Statistics
Transport security is being deployed!

41. 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

42. Encryption | 23 September 201542
Hosts responding to HTTPS and found certificates (full IPv4 scan)
Source:University of Michigan

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

44. Encryption | 23 September 201544
A CDN now sees 35+% of ‘hits’ over HTTPS
Source known to author

45. 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)

46. 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

47. Encryption | 23 September 201547
Transport Encryption is not the Only tool to increase trust and privacy

48. Encryption | 23 September 201548
dprive
HTTP2
RFC7435: defining
opportunistic
encryption
RFC7465:deprecating RC4
TLS 1.3
DNS qnameminimizationqnameminimization
IRTF CFRG new
curves
ACME

49. 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

50. 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

51. 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