IETF 93 Review Webinar

©!Men!&!Mice!!http://menandmice.com!

IETF!93!Review

30st!July!2015

1


before!we!start

…!please!note:!BIND!9!security!issue!

!

CVE-2015-5477:!An!error!in!handling!TKEY!queries!can!cause!named!to!exit!with!a!REQUIRE!assertion!failure!

all!BIND!9!DNS!Server!should!be!updated!to!the!latest!9.10.2-P3!or!9.9.7-P2!versions!

2


Agenda

IETF!93!in!Prague!!

DNS,!DNSSEC,!DANE,!DHCP,!IPv6!

the!following!information!is!an!excerpt!of!the!IETF!working!group!activities!

for!a!full!overview!of!all!activities!at!IETF!93,!see! https://datatracker.ietf.org/meeting/93/materials.html

3


DNS

4


new!DNS!related!RFCs!published!since!last!IETF

5

RFC Title Category

7505A "Null MX" No Service Resource Record for Domains That

Accept No MailStandards Track

7534 AS112 Nameserver Operations Informational

7535 AS112 Redirection Using DNAME Informational

7553The Uniform Resource Identifier (URI) DNS Resource

RecordInformational

7558Requirements for Scalable DNS-Based Service Discovery

(DNS-SD) / Multicast DNS (mDNS) ExtensionsInformational


RFC!7505!-!A!"Null!MX"!No!Service!Resource!Record!for!Domains!

That!Accept!No!Mail

sending!mail!server!will!lookup!MX-Records!for!the!recipients!domain,!without!MX!it!will!fallback!to!A/AAAA-Address!records!

the!"null!MX"!record!indicates!that!a!host/domain!cannot!receive!SMTP!mail!

Example:!

www.menandmice.com. 3600 IN MX 0 .

6


RFC!7553 The!Uniform!Resource!Identifier!(URI)!DNS!Resource!

Record

maps!a!service!name!and!a!domain!to!an!Uniform!Resource!Identifier!(URI)!

similar!to!SRV,!but!returns!a!full!URI!instead!hostname!+!port!

Example:!_http._tcp.menandmice.com. 3600 IN URI 10 50 "http://www.menandmice.com" _http._tcp.menandmice.com. 3600 IN URI 10 50 "http://www.menandmice.com" _http._tcp.menandmice.com. 3600 IN URI 20 00 "http://www.menandmice.com"

7

priority

weight

URI


DNS!Transport!over!TCP!-!Implementation!Requirements draft-ietf-dnsop-5966bis

update!of!RFC!5966!

make!TCP!a!requirement!for!the!DNS!protocol!

Benefits!of!DNS!over!TCP:!•!prevents!amplification!attacks!

•!privacy/encryption!(TLS)!

•!no!fragmentation!issues!

Clients!should!pipeline!their!queries!over!TCP!

with!keep-alive,!persistent!connections!and!pipelining,!DNS!over!TCP!can!be!as!fast!as!traditional!DNS!over!UDP

8


The!edns-tcp-keepalive!EDNS0!Option!draft-ietf-dnsop-edns-tcp-keepalive

it!is!expected!to!see!more!DNS-TCP!traffic!in!the!future!

enables!DNS!clients,!DNS!resolver!and!authoritative!DNS-Server!to!negotiate!a!keep!alive!for!TCP!sessions!

clients!can!send!multiple!queries!over!an!established!TCP!session!

9


KSK!rollover!in!the!root-zone

the!Internet!DNS!root!zone!has!been!signed!5!years!ago!(July!2010)!

the!root!KSK!should!be!rolled!•HSMs!are!getting!old!and!out!of!support!

several!issues!have!been!identified:!•the!publication!format!of!the!KSK!trust!anchor!is!not!standardised!

•(secure)!bootstrapping!of!DNSSEC!DNS-resolvers!

•devices!might!"miss"!the!KSK!roll!(via!RFC!5011)!while!being!"on!the!shelf",!no!standard!way!to!re-bootstrap

10


Yeti-DNS!project

experimental,!IPv6!only!DNS-root-server system!

Large-scale!testbed!

Yeti!Participants:!

•!Operators!of!Yeti!components,!or!experimenters!

•!DNS!experts,!with!varied!backgrounds!and!interests

11


Yeti-DNS!project

Planned!Experiments!&!Other!Investigations!•Impacts!of!IPv6-only!DNS!

•Bigger!minimum!packet!size,!no!IP-fragmentation!

•KSK!rollover,!KSK/ZSK!rollover!frequency,!algorithm,!signature!size!

•Changes!in!DNSSEC!

•Changes!to!root!serversLots/few!of!root!servers,!churn!in!root!server!set!

the!project!is!looking!for!volunteers!running!DNS!resolvers!against!the!Yeti-DNS!root!(informed!users!in!non-critical!environments)

12

http://yeti-dns.org/


RFC!6761!"special!use!domain-names"

request!for!Special!Use!Domain!Names!of!P2P!Systems:!

•!!.bit!=!Namecoin!

•!!.exit!=!Tor!Project!

•!!.gnu!and!.zkey!=!GNUnet!

•!!.i2p!=!I2P!System!

•!!.tor!=!consensus!among!Tor!routes

13


RFC6761bis!Problem!Space Input!to!the!Design!Team

future!of!the!special!names!registry!

namespace!!=!DNS!

one-off!protocol!switch!or!general!solution!(.alt,!.ext,!.external)?!

separate!protocol!design!from!policy?!

heated!debate!during!IETF!93,!no!conclusions,!discussion!will!continue!on!the!mailing!list(s)

14


DANE

15


A!DANE!Record!and!DNSSEC!Authentication!Chain!Extension!for!TLS

!draft-shore-tls-dnssec-chain-extension

new!TLS!extension!for!transport!of!a!DNS!record!set!serialised!with!the!DNSSEC!signatures!needed!to!authenticate!that!record!set!

•without!performing!perform!additional!DNS!record!lookups!(latency)!

•avoid!potential!problems!with!TLS!clients!being!unable!to!look!up!DANE!records!

•allows!a!TLS!client!to!validate!DANE!records!itself!without!a!validating!DNS!resolver

16


A!DANE!Record!and!DNSSEC!Authentication!Chain!Extension!for!TLS

!draft-shore-tls-dnssec-chain-extension

the!TLS!client!requests!the!DNSSEC!validation!chain!be!returned!

the!server!performs!the!appropriate!DNS!queries,!builds!the!validation!chain,!and!returns!it!to!the!client!(as!part!of!the!TLS!handshake)!

The!client!then!authenticates!the!chain!using!a!pre-configured!trust!anchor!

17


Client!Certificates!in!DANE!TLSA!Recordsdraft-huque-dane-client-cert

extension!to!the!existing!TLSA!record!_smtp-client.device1.example.com. IN TLSA ( 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971 )

•Client!has!an!identity!assigned!corresponding!to!a!DNS!domain!name.!!

•Client!has!a!private/public!key!pair!and!a!certificate!binding!the!domain!name!to!the!public!key.!!

•Domain!Name!+!Certificate!has!a!corresponding!signed!DNS!TLSA!record!

•a!new!TLS!extension!is!proposed!to!convey!the!DNS!client!identity

18


SMIMEA!and!OPENPGPKEY

Discussion!of!how!to!store!the!key!holders!email!address!

! hash!vs.!base32!

no!consensus!reached!during!the!meeting,!discussion!on!the!mailing!list!until!1st!of!August!

seperator!label!"_at"!proposed!instead!of!"_smimecert"!and!"_openpgpkey"!

Working!Group!Last!Call!(WGLC)!planned!before!IETF!94!(November)!

19


DPRIVE

20


DNS!over!DTLS!draft-ietf-dprive-dnsodtls

•Advantages!

•avoid!head-of-line!blocking!

•fast!session!resumption!

•supports!Anycast!

•Problems!

•DPI!Firewalls!->!use!different!port!for!DNS/DTLS!

•DNS!Server!authentication!->!x509!cert!•private!server!do!not!have!CA!certs!->!self-signed!cert!fingerprint!

•configured!in!/etc/resolv.conf!(or!similar)!

•!discovery!of!DNSoD!->!downgrade!attack!possible

21


TCP-TLS!for!DNS

•!discussion!about!no!STARTTLS!

•consensus:!use!new!port!for!DNS!over!TLS!

•DNS!over!TLS!should!follow!TLS!BCP!(best!current!practice)!document!

•available!implementations:!!

•Unbound!

•ldns/drill!

•digit!

•getdns-api

22


IPSec!AUTH_NULL!opportunistic!DNS

•client!to!resolver!path!encryption!

•why!not!encrypt!all!traffic!instead!of!only!DNS?!

•IPSec!encryption!without!authentication!

•coffee-shop!scenario!

•optionally!limited!to!DNS!traffic!only!

•proposed!alternative!to!"in-DNS-protocol"!solution!

•already!available!and!working!with!current!implementations

23


DHCP

24


published!new!RFCs!since!last!IETF

25

RFC Title Category

RFC 7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options Standards Track


Update!!of!Secure!DHCPv6!&!Secure!!DHCPv4

draft-ietf-dhc-sedhcpv6!

draft-jiang-dhc-sedhcpv4!

DHCPv6!client/server!authentication!mechanism!based!on!sender's!public/private!key!pairs!

!!!or!certificates!with!associated!private!keys!

IETF!hackathon!did!an!(successful)!interoperability!test!of!two!implementations!(ISC!KEA!and!WIDE!DHCPv6,!support!for!ISC!DHCP!is!"work!in!progress")

26


DHCP!Anonymity!Profile

draft-ietf-dhc-anonymity-profile!

DHCPv4!and!DHCPv6!clients!disclose!many!identifiers!that!can!be!used!to!track!clients.!This!work!seeks!to!eliminate!that!information!leak!by!defining!an!anonymity!profile,!a!set!of!DHCP!behaviours!

•Randomising!MAC!address!+!client-id/DUID!

•Not!disclosing!client!hostname!

•Changing!identity!

•Limiting!information!disclosure!when!changing!networks!

Prototype!implementation:!Windows!10!(Microsoft)!

! implementation!choice:!does!not!send!hostname!option!

Microsoft!did!a!field!trial!using!the!prototype!implementation,!only!minor!issues!found

27


DHCP!v4/v6!Relay!Initiated!Release

draft-gandhewar-dhc-relay-initiated-release-00!

draft-gandhewar-dhc-v6-relay-initiated-release-00!

Issue:!clients!sometimes!do!not!release!a!lease!when!leaving!the!network!

(in!some!networks)!the!DHCP!lease!is!used!to!keep!state!beyond!the!IP-address:!

•various!routes!e.g.!access,!framed!routes!

•various!services!e.g.!data,!voice,!video!

•policy!

•QoS!setup!

DHCP!relay!might!be!able!to!detect!client!leaving,!releasing!the!lease!on!behalf!of!the!client

28


IPv6/IPv4-sunset

29


published!new!RFCs!since!last!IETF

30

RFC Title Category

RFC 7445 Analysis of Failure Cases in IPv6 Roaming Scenarios Informational

RFC 7506 IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM)

Standards Track

RFC 7526 Deprecating the Anycast Prefix for 6to4 Relay RoutersBest Current

Practice

RFC 7527 Enhanced Duplicate Address Detection Standards Track

RFC 7559 Packet-Loss Resiliency for Router Solicitations Standards Track

RFC 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) Experimental

RFC 7608 IPv6 Prefix Length Recommendation for ForwardingBest Current

Practice


IPv6!to!"internet!standard"

RFC!2460(and!many!other RFCs!are!still!a!"draft!standard"!

•RFC!6410!"Requirements!for!Internet!Standards"!

•!forward!"draft"!to!"proposed!standard"!

•!WG!discussion!of!"re-write!update!RFC!vs.!pushing!RFC!unchanged"

31


Randomised!MAC!Addresses!and!IPv6!Address!Assignment

enhance!privacy!of!users!

•users!can!hide!from!the!network!

•prevent!location!tracing!

•implemented!using!standard!IEEE!802!rules!(Preferred!!Format:!U/L=1,!G=0,!46!random!bits)!

•!conflict!with!RFC!7217!(A!Method!for!Generating!Semantically!Opaque!Interface!Identifiers!with!IPv6!Stateless!Address!Auto-configuration!(SLAAC))!

•!conflict!with!SAVI!"Source!Address!Validation!Improvement!(SAVI)!Solution!for!DHCP"

32


IPv6!news!from!Apple

all!iOS!apps!MUST!support!native!IPv6!(starting!with!iOS!9)!

Happy!Eyeballs!in!iOS!9!and!MacOS!X!10.11!will!prefer!IPv6!99%!of!the!time!

NAT64!internet!sharing!uses!2001::/64!(Teredo!prefix)

33


IPv6!news!from!Apple

NAT64/DNS64!"IPv6-only"!network!via!MacOS!X!Internet!Sharing!in!MacOS!X!10.11!"El!Capitan"NAT64/DNS64!can!break!local! DNSSEC!validation!!

34


Some!Design!Choices!for!IPv6!Networks

draft-ietf-v6ops-design-choices!

includes!now!Enterprise!environments!and!their!use!cases!(in!addition!to!service!providers)!

new!IGP!choice!section!

!now!covers!EIGRP!and!RIPng!

new!section!on!address!choices

35


draft-yc-v6ops-solicited-ra-unicast

multicast!router!advertisements!in!large!wireless!networks!

•every!device!joining!the!network!sends!a!router!solicitation!

•router!sends!multicast!RA,!all!devices!in!the!network!awake!

•drains!device!battery!

Recommendations!

•Router!manufacturers!SHOULD!allow!network!administrators!to!configure!the!routers!to!respond!to!Router!Solicitations!with!unicast!Router!Advertisements.!

•Networks!that!serve!large!numbers!(tens!or!hundreds)!of!mobile!devices!SHOULD!enable!this!behaviour.

36


Host!address!availability!recommendationsdraft-colitti-v6ops-host-addr-availability

Addressing!practices!that!make!sense!in!IPv4!may!not!be!appropriate!in!IPv6!

•/64!per!link!allows!“unlimited”!host!addressing!

•No!longer!forced!to!assign!one!address!per!host!due!to!address!scarcity!

•Many!benefits!provided!by!assigning!multiple!addresses!to!each!host!

Recommendations!•Provide!multiple!IPv6!addresses!from!each!prefix!to!general-purpose!hosts!when!they!attach!to!the!network!

•Don’t!impose!a!hard!limit!on!the!size!of!the!address!pool!assigned!to!a!host!

•If!the!network!requires!explicit!requests,!assign!a!/64!via!DHCPv6!PD

37


RFC!7511Scenic!Routing!for!IPv6

•incorporates!the!green-ness!of!a!network!path!into!the!routing!decision!

•routing!algorithms!SHOULD!!calculate!the!optimal!paths!providing!the!most!fresh-air!time!for!a!packet!

•should!therefore!choose!paths!based!on! Avian!IP!Carriers![RFC1149]!and/or!wireless!technologies!

room!for!"live"!implementation:!CCC!Camp! 13-17!Aug!2015!https://events.ccc.de/camp/2015/wiki/Main

38

Zelte!und!ein!„Datenklo“!auf!dem!Chaos!Communication!Camp,!Finowfurt!2007!"RobotSkirts"/Eliot!Phillips,!CC-by-sa-2.0


don't!miss!our!next!webinar

•"PowerDNS",!Monday,!31st!August!2015!

•overview:!the!PowerDNS!open!source!DNS!server!

•manage!a!DNS!zone!via!SQL!backend!

•manage!a!DNS!zone!via!BIND!backend!

•remote!zone!Backend!

•DNSSEC!signing!with!PowerDNS!

•the!Men!&!Mice!Suite!controller!for!PowerDNS!

•Signup!@!https://www.menandmice.com/resources/educational-resources/webinars/

39


upcoming!Men!&!Mice!trainings•Upcoming!Trainings:!

•September!8!–!11,!2015,!Special!4!days:!IPv6!Introduction!+!Advanced!Topics!Hands-On!Workshop,!San!Francisco!area!(CA),!USA!!

•September!28!–!29,!2015,!Introduction!to!DNS!&!BIND!Hands!on,!Arlington!(VA),!USA!

•September!30!–!October!2,!2015,!DNSSEC!Technical!Workshop!–!Implementation!and!Deployment,!Arlington!(VA),!USA! !

•September!28!–!October!2,!2015,!Introduction!&!Advanced!DNS!and!BIND!Hands!on,!Arlington!(VA),!USA!

•November!16!–!17,!2015,!Introduction!to!DNS!&!BIND!Hands!on,!Redwood!City!(CA),!USA!

•November!16!–!20,!2015,!Introduction!&!Advanced!DNS!and!BIND!Hands!on,!Redwood!City!(CA),!USA more!training!classes!on!!!!!https://www.menandmice.com/support-training/training/

40


Q/A

41

?2015!Schedule,!Slides,!Links,!Recording!and!errata!

can!be!found!@https://www.menandmice.com/resources/educational-resources/webinars/

Technology

IETF 93 Review Webinar