Subject: [dnssd] FW: New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 11 Jun 2014 00:30:55 +0200

Folks,

As I've promised I sent the first version of this threat model. If you would like to contribute (as I have already received one email), I appreciate your help. Just contact me directly, I will give you access to where you can also work on the source of this file.

Best,
Hosnieh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 11, 2014 12:26 AM
To: Hosnieh Rafiee; Hosnieh
Subject: New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt

A new version of I-D, draft-rafiee-dnssd-mdns-threatmodel-00.txt
has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository.

Name:		draft-rafiee-dnssd-mdns-threatmodel
Revision:	00
Title:		Multicast DNS (mDNS) Threat Model and Security Consideration
Document date:	2014-06-10
Group:		Individual Submission
Pages:		11
URL:            http://www.ietf.org/internet-drafts/draft-rafiee-dnssd-mdns-threatmodel-00.txt
Status:         https://datatracker.ietf.org/doc/draft-rafiee-dnssd-mdns-threatmodel/
Htmlized:       http://tools.ietf.org/html/draft-rafiee-dnssd-mdns-threatmodel-00

Abstract:
   This document describes threats associated with extending multicast
   DNS (mDNS) across layer 3.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jun 2014 16:22:49 -0700

Dear Hosnieh,

As was stressed in the draft http://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-03 use of mDSN proxy into DNS requires that link-local be translated into routable IP addresses to offer layer 3 bridging.
  
This difference removes a critical concept of local addressing needed to support reasonable firewall protections.  Many devices currently depend on local network constraints.  There are other solutions not found at layer 3, one being Rbridge, as an example.  Rbridge's support of PPP also offers a reasonable solution for technologies lacking direct Rbridge support. Environments not well suited for mDNS across the entire local network can employ Rbridge to Rbridge filtering for larger deployments.   For such large scale deployments, bridge to bridge filtering should offer a reasonable automatic mitigation strategy which clarifies the services that will need to depend on other routing techniques.

Claims of Rbridge being unsuitable for home networks fail to overlook reasonable deployment strategies.  Claims that mDNS to DNS offers a means to merge different network segments overlooks several serious security limitations, some of which have been reviewed in Rafiee's threat model.  It also overlooks an inability to handle HDCP over layer 3, a prime motivation for the Educause petition.

http://support.apple.com/kb/HT4428
Although this mentions the HDMI portion of the path needing to support HDCP,  the network in essence does not permit layer 3 header changes either.  Recently, it has been a struggle to maintain OSX security due to socially engineered privileges granted by users installing various browser plugins having the effect of obfuscating java-script functions.  Any breach at this level can rapidly become a larger disaster when coupled with insecure mDNS proxies. 

Regards,
Douglas Otis

On Jun 10, 2014, at 3:30 PM, Hosnieh Rafiee <[email-masked]> wrote:

> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Ralph Droms <[email-masked]>
Date: Tue, 17 Jun 2014 11:13:50 -0400

Douglas:

Back on 4/4/2014, we posted e-mail to [email-masked] explaining the position of the chairs regarding the charter of the dnssd WG and the observation that TRILL and Rbridges are not appropriate for consideration as a solution under the charter (http://www.ietf.org/mail-archive/web/dnssd/current/msg00416.html).  Therefore, we specifically tell you not to bring TRILL and Rbridges up for discussion as the solution, replacing discussion of solutions for routed networks.

Discussion along the lines of "given a TRILL deployment or other campus/enterprise-wide L2 networks, how do we control propagation of DNS-SD/mDNS traffic to meet security, privacy and scaling requirements" is appropriate for the WG mailing list.  For example, discussion of security issues raised by merging mDNS and unicast DNS would be quite appropriate and important for the the WG mailing list.

- Tim and Ralph

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 18 Jun 2014 11:47:00 +0000

> For example, discussion of security issues raised by merging mDNS and unicast DNS would be quite appropriate and important for the the WG mailing list.

Ralph,

In the threat model document, I also covered this scenario where mDNS node wants to update a record in unicast DNS. If folks think that it is better that I expand it more, I would do it.

Thank you,
Best,
Hosnieh

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Jun 2014 11:55:39 -0700

Dear Hosnieh,

Please greatly expand the related issues as there have been extremely serious security concerns fully ignored in the consideration sections.

1) Converting link-local to routable addressing removes most firewall protections.

2) Publishing addresses in DNS exposes devices that lack authentication.

3) Resolving name collisions between various network segments where multi-interface devices connected to different segments could potentially generate excessive traffic with mDNS's attempt to offer rapid convergence.

Perhaps something has been overlooked.  There is seemingly no consideration given that prevents this scheme from becoming a larger problem.

Can distributing recognized certificates in a zero-config fashion be accomplished?

Regards,
Douglas Otis

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 18 Jun 2014 16:21:07 -0400

> On Jun 18, 2014, at 2:55 PM, Douglas Otis <[email-masked]> wrote:
> 
> 

Firewalls don't provide protections to packets that use link-local IP addresses. Routers just don't forward them beyond the IP subnet.

> 2) Publishing addresses in DNS exposes devices that lack authentication.

Devices that lack authentication have a problem with or without DNS exposure. Service enumeration doesn't change that.

Tom

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Jun 2014 14:37:18 -0700

Dear Tom,
See comments inline:

> Firewalls don't provide protections to packets that use link-local IP addresses. Routers just don't forward them beyond the IP subnet.

When routable addresses are used to merge networks, as suggested by the mDNS proxy scheme, this removes most local network firewall protections.    

> Devices that lack authentication have a problem with or without DNS exposure. Service enumeration doesn't change that.

IPv6 link-local addressing offers two important protections:  
1) prevents unintended data exfiltration

2) prevents external traffic infiltration

2a) Randomly assigned link-local addresses also thwarts many encapsulation spoofing techniques

An mDNS proxy scheme will have significant negative impacts on network security.

Many devices depend on link-local addressing, lack authentication, and yet don't have a significant security problem.  When enumeration automatically translates link-local into routable addresses, this will have profound and negative security impacts.  Consider the all-in-one printer/scanner/fax/media-reader.  Would you like to have your device be used by unknown parties to send faxes worldwide?

Few if any current consumer printers log the originating IPs.  Most don't even offer a practical means to selectively restrict IPv6 access.  Do you consider this a problem?

Regards,
Douglas Otis

---

From: "Ralph Schmieder (rschmied)" <[email-masked]>
Date: Thu, 19 Jun 2014 05:35:32 +0000

At no point the proposal talks about *converting* a link local address into a routable address. Your printer would have to have a routable address already to be considered for service extension. In other words: if it only has a link local address it won't be visible beyond the local subnet. 

Thanks,
-ralph

> On Jun 18, 2014, at 11:37 PM, "Douglas Otis" <[email-masked]> wrote:
> 
> 
> Dear Tom,
> See comments inline:
>

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 19 Jun 2014 11:04:20 +0300

> When routable addresses are used to merge networks, as suggested by the mDNS proxy scheme, this removes most local network firewall protections.    

Ok, fine. Let’s look at the current non-routable IP addresses..

RFC1918? I suppose, but that’s network deployment detail and non-routability is only within site that is behind the NAT. It can still be attackable by anyone behind the same NAT. Similar grade of protection on IPv6 globals can be achieved by simple ‘drop inbound non-established’ rule in any firewall product you care to look at, given they support IPv6.

IPv6 link-locals? How many printers do you even have that support IPv6? And how many of them by default are link-local only? 

> 2a) Randomly assigned link-local addresses also thwarts many encapsulation spoofing techniques

I have yet to see a device in the wild that doesn’t do EUI64 linklocal by default. Do you have an example of this? And if they do that, they usually do SLAAC too and wind up with globals (at least in my home).

> Few if any current consumer printers log the originating IPs.  Most don't even offer a practical means to selectively restrict IPv6 access.  Do you consider this a problem?

I’d love to find a consumer printer that operates on IPv6 linklocal only first (preferably also without IPv4 to ensure it’s really not routable). Do you have an example?

Cheers,

-Markus

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 19 Jun 2014 10:40:05 +0200

Markus,

Just a few comments on your questions. 

> Ok, fine. Let's look at the current non-routable IP addresses..
> 
> RFC1918? I suppose, but that's network deployment detail and
non-routability
> is only within site that is behind the NAT. It can still be attackable by
anyone
> behind the same NAT. Similar grade of protection on IPv6 globals can be
> achieved by simple 'drop inbound non-established' rule in any firewall
> product you care to look at, given they support IPv6.

I presume that NAT in IPv6 doesn't applicable for local link addresses. At
first the assumption for IPv6 was that there is no need for NAT since there
are enough IP addresses. But later some folks thought that It would be also
useful to have NAT, maybe for privacy reason?! Or other reasons but not
because there is not enough valid IP addresses dissimilar to what we have
for IPv4 to assign to the nodes. 

> 
> I'd love to find a consumer printer that operates on IPv6 linklocal only
first
> (preferably also without IPv4 to ensure it's really not routable). Do you
have
> an example?

I was also curious to see whether any printer uses IPv6, I found this link
http://www.internetsociety.org/deploy360/blog/2014/05/case-study-printing-an
d-scanning-over-ipv6-only/
It appears that they do and they use SLAAC. In this case, if they need RA, I
presume that they set both local link addresses which is not routable based
on standards and routable IP addresses that needs to obtain prefixes from RA

Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 19 Jun 2014 13:02:36 +0200

Follow up
<http://download.support.xerox.com/pub/docs/3600/userdocs/any-os/en_GB/En_IP
v6-Supplement.pdf >
I also found Xeron supports IPv6. Here is the configuration for Xeron
printers. This document is for 2009. So it appears that some providers
started supporting IPv6 some years ago. I  was astonished to see this
information.

Best,
Hosnieh

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jun 2014 07:28:14 -0400

I've had a HP laser printer and a web/surveillance camera w/ IPv6 for several years.

- Ralph

---

From: Michael Sweet <[email-masked]>
Date: Thu, 19 Jun 2014 08:06:52 -0400

Markus,

On Jun 19, 2014, at 4:04 AM, Markus Stenberg <[email-masked]> wrote:
> ...

Pretty much all current-year AirPrint printers support IPv6 (we've been pushing hard for that since day one) and most only support link-local out-of-the-box since few support DHCPv6... (all support manual configuration)

>> ...

AFAIK there are no printers that are IPv6-only (and there is strong resistance to dropping IPv4).

Most printers also do not allow IPv4 to be disabled, however IPv6 can be...

Such is the sad state of printer networking...

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Tovey, Dwight (LaserJet R&D FW Eng.)" <[email-masked]>
Date: Thu, 19 Jun 2014 14:01:27 +0000

FWIW: HP LaserJet printers have had IPv6 support for several years, including at least some basic DHCPv6 support.  They come out of the box with IPv4, IPv6, and DHCPv6 enabled, but either IPv4 or IPv6 can be disabled either through the Embedded Web Server or via SNMP.

Dwight Tovey
Laserjet R&D FW Engineer
(208)396-4645

-----Original Message-----
From: dnssd [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Thursday, June 19, 2014 6:07 AM
To: Markus Stenberg
Cc: Hosnieh Rafiee; [email-masked]; Tom Pusateri; Douglas Otis; Ralph Droms
Subject: Re: [dnssd] New Version Notification for draft-rafiee-dnssd-mdns-threatmodel-00.txt

Markus,

> I'd love to find a consumer printer that operates on IPv6 linklocal only first (preferably also without IPv4 to ensure it's really not routable). Do you have an example?

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 19 Jun 2014 17:34:40 +0300

> FWIW: HP LaserJet printers have had IPv6 support for several years, including at least some basic DHCPv6 support.  They come out of the box with IPv4, IPv6, and DHCPv6 enabled, but either IPv4 or I…

Ok, I’m getting actually useful information out of this (last networked printer I bought didn’t have anything else than IPv4). Clearly, the next one I buy _will_ ;)

However, can someone point to a consumer-grade printer that _doesn’t_ do DHCPv6 or SLAAC but _does_ IPv6 link-locals out of the box? I believe Douglas described that as the default IPv6 stance in his world, and that sounds more like an exception than the rule.

Cheers,

-Markus

---

From: Ralph Droms <[email-masked]>
Date: Thu, 19 Jun 2014 10:43:03 -0400

I haven't experimented with my printer.

I can imagine it might do IPv6 link-locals but not global address assignment if it doesn't receive any RAs or hear from a DHCPv6 server.

I do know that many devices will happily use IPv6 link-locals to communicate with devices discovered through DNS-SD/mDNS even if there is no global IPv6 service/addresses available.

- Ralph

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 19 Jun 2014 17:55:52 +0300

> I do know that many devices will happily use IPv6 link-locals to communicate with devices discovered through DNS-SD/mDNS even if there is no global IPv6 service/addresses available.

Certainly.

But if they accept RA (and do SLAAC based on it) or DHCPv6 server-oriented address assignment, Douglas’ claims of being safe against evils of the world do not apply.

So I’m still looking for the link-local-only IPv6 printer ;)

Given how predictable EUI-64 based addresses are, SLAAC-configured printers may not even be very hard to find _without_ service discovery if you’re (say) running just one /64, and opponent knows make/~approximate manufacturing date of your printer.

Cheers,

-Markus

---

From: Michael Sweet <[email-masked]>
Date: Thu, 19 Jun 2014 11:03:29 -0400

Markus,

> However, can someone point to a consumer-grade printer that _doesn’t_ do DHCPv6 or SLAAC but _does_ IPv6 link-locals out of the box? I believe Douglas described that as the default IPv6 stance in h…

Most of the current HP OfficeJet printers fall into this category.

I also have an Epson XP-800 printer in my office that does IPv6 but just basic link-local.

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 19 Jun 2014 12:35:40 -0400

> On Jun 19, 2014, at 11:03 AM, Michael Sweet <[email-masked]> wrote:
> 
> Markus,
> 

My 4 year old HP Officejet Pro 8500 defaulted to IPv6 SLAAC enabled.

Tom

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jun 2014 11:55:55 -0700

Dear Ralph,

See comments inline:

> At no point the proposal talks about *converting* a link local address into a routable address. Your printer would have to have a routable address already to be considered for service extension. In…

http://tools.ietf.org/id/draft-cheshire-mdnsext-hybrid-02.html#rfc.section.3
About the sixth paragraph:
,--
In addition it would be desirable to suppress Unicast DNS replies for records that are not useful outside the local link. For example, DNS A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6 link-local addresses [RFC4862] should be suppressed. Similarly, for sites that have multiple private address [RFC1918] realms, private addresses from one private address realm should not be communicated to clients in a different private address realm.
'---

Perhaps "converting" was a poor word choice.  The mDNS hybrid proxy draft recommends suppressing link-local addresses normally conveyed by mDNS and to use only routable addresses to be published in DNS to support routing between different network realms.   DNS-SD SRV records using only routable addresses greatly increases device exposures such as printers and many others lacking authentication.

Security considerations are dreadfully lacking by describing concerns as being a "union" of DNS-SD and mDNS.  Since DNS-SD claims to only define a discovery structure, a fairly serious issue of assigning and publishing routable addresses in DNS instead of link-local otherwise only discoverable via layer 2 is being ignored.

When SLACC is used and the attacker can guess the manufacturer, this still leaves millions of possible assignments.  If the printer is using either DHCPv6 or static addressing (that all printers support), the number of possible assignments becomes virtually unlimited from an attacker's perspective.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Jun 2014 19:07:38 -0700

> Given how predictable EUI-64 based addresses are, SLAAC-configured printers may not even be very hard to find _without_ service discovery if you’re (say) running just one /64, and opponent knows ma…

Dear Markus,

There are several issues related to link-local addressing such as ULA addresses commonly used in things like BTMM http://tools.ietf.org/html/rfc4193. In that service, the ULA addresses exposed are not routable and are accessed via a tunnel restricted by a centralized authenticating service.  In the case of mDNS Hybrid Proxies http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid, this layer of security does not exist and yet deceptively purports current use of the related discovery strategy?  This draft even goes on to describe eventual mergers of .local domains which also necessitates recognizing name collisions caused by multiple interface devices from those needing reassignment. 

In the case of the All-In-One Printer/Fax/Scanner/Media-Reader:

1) How can a device be accessed when only a link-local address is reported?

2) How are routable addresses discovered when link-local is returned by mDNS?

3) How can devices be secured when SLACC or DHCPv6 addresses are being indirectly exposed?

4) How will disparate .local domains be merged?

While one might attempt to guess likely SLACC assignments out of a possible range likely in the millions, users are also free to manually assign addresses.  If a problem is discovered, this strategy would give malefactors a guessing range of about 9 quintillion.  Of course, unusual levels of address probing can be detected and blocked.  Automated DNS-Based Service Discovery http://tools.ietf.org/html/rfc6763 as suggested, precludes malefactors even needing to make a series of guesses.  Of course, IPsec tunneling represents viable strategy that might be used, but this no longer offers zero configuration. It seems unauthenticated exposure of even ULAs has a fair amount of security related risk doesn't it?

I need a clue as this seems to be a serious problem.

Regards,
Douglas Otis

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 24 Jun 2014 10:17:03 +0300

> There are several issues related to link-local addressing such as ULA addresses commonly used in things like BTMM http://tools.ietf.org/html/rfc4193. In that service, the ULA addresses exposed are…

That draft forces you to route ULAs outside your organization? 

> 1) How can a device be accessed when only a link-local address is reported?

It cannot be. But I’m still looking for that IPv6 link-local only All-In-One Printer/Fax/Scanner/Media-Reader, please report one to me and I’ll consider this a problem ;)

> 2) How are routable addresses discovered when link-local is returned by mDNS?

They are not.

> 3) How can devices be secured when SLACC or DHCPv6 addresses are being indirectly exposed?

Firewalls are traditional way of protecting _any_ addresses. IPv6 linklocals _and_ ULAs provide added property of not being globally routable, just like RFC1918 IPv4 addresses.

> 4) How will disparate .local domains be merged?

They need not be. Read hybrid draft + RFC6763, especially on the ‘browse domain _list_’ part.

Merging is just (ugly) glue that could deal with broken clients which handle only either pure mdns, or single list of entries-style dns-sd (‘legacy browse domain’ is the term in RFC6763).

> While one might attempt to guess likely SLACC assignments out of a possible range likely in the millions, users are also free to manually assign addresses.  If a problem is discovered, this strategy would give malefactors a guessing range of about 9 quintillion.  Of course, unusual levels of address probing can be detected and blocked.  Automated DNS-Based Service Discovery http://tools.ietf.org/html/rfc6763 as suggested, precludes malefactors even needing to make a series of guesses.  Of course, IPsec tunneling represents viable strategy that might be used, but this no longer offers zero configuration. It seems unauthenticated exposure of even ULAs has a fair amount of security related risk doesn’t it?

Nothing forces you to export those hybrid proxy / DNS-SD zones outside your organization. Split horizon DNS was state of the art in late 90s when (IPsec) VPNs started to first show up, but  I don’t really consider it bleeding edge anymore. 

Cheers,

-Markus

---

From: Ralph Schmieder <[email-masked]>
Date: Tue, 24 Jun 2014 10:33:26 +0200

> It cannot be. But I’m still looking for that IPv6 link-local only All-In-One Printer/Fax/Scanner/Media-Reader, please report one to me and I’ll consider this a problem ;)

In fact, I do have a Canon printer which advertises a link-local address only. It has, however, both: a link local AND a global IPv6 address (which it does not tell about via mDNS). It's certainly an implementation detail of the printer to include global IPv6 addresses in the service advertisement but if it would be IPv6 only it could not be used beyond the local subnet with that link-local address only.

rtp-vpn4-88:Desktop rschmied$ dns-sd -B _ipp._tcp
Browsing for _ipp._tcp
DATE: ---Tue 24 Jun 2014---
10:18:28.792  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
10:18:28.792  Add        2   9 local.               _ipp._tcp.           Canon MX920 series
^C
rtp-vpn4-88:Desktop rschmied$ dns-sd -L 'Canon MX920 series' _ipp._tcp
Lookup Canon MX920 series._ipp._tcp.local
DATE: ---Tue 24 Jun 2014---
10:18:38.967  ...STARTING...
10:18:39.169  Canon\032MX920\032series._ipp._tcp.local. can be reached at Canon.local.:631 (interface 9)
 txtvers=1 rp=ipp/print note=mylocation qtotal=1 priority=15 ty=Canon\ MX920\ series product=\(Canon\ MX920\ series\) pdl=application/octet-stream,image/urf,image/jpeg adminurl=http://Canon.local./mainmenu.html usb_MFG=Canon usb_MDL=MX920\ series usb_CMD=URF UUID=00000000-0000-1000-8000-F481391493A7 URF=V1.2,CP1,PQ4-5,RS600,SRGB24,W8,OB9,OFU0,DM3,IS11-13 Color=T Duplex=T Scan=T Fax=F
^C
rtp-vpn4-88:Desktop rschmied$ dns-sd -G v4v6 Canon.local.
DATE: ---Tue 24 Jun 2014---
10:18:57.335  ...STARTING...
Timestamp     A/R Flags if Hostname                               Address                                      TTL
10:18:57.335  Add     3  9 Canon.local.                           FE80:0000:0000:0000:1A0C:ACFF:FEEB:938E%en4  60
10:18:57.335  Add     2  9 Canon.local.                           172.16.33.9                                  60
^C
rtp-vpn4-88:Desktop rschmied$ 

otherwise, I wholeheartedly agree with your below assessment. Extending services beyond the local subnet for devices that do have a global IPv6 address does not automatically expose those devices to the world.

The visibility and accessibility of the device is still subject to administration (apply BCPs) and like with split DNS one could certainly make e.g. printers visible globally but one does not have to. Like with Stuart's dns-sd.org domain:

rtp-vpn4-88:Desktop rschmied$ dns-sd -B _ipp._tcp dns-sd.org.
Browsing for _ipp._tcp.dns-sd.org.
DATE: ---Tue 24 Jun 2014---
10:24:44.550  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
10:24:48.930  Add        3   0 dns-sd.org.          _ipp._tcp.           3rd. Floor Copy Room
10:24:48.930  Add        3   0 dns-sd.org.          _ipp._tcp.           Sales
10:24:48.930  Add        3   0 dns-sd.org.          _ipp._tcp.           Marketing
10:24:48.930  Add        3   0 dns-sd.org.          _ipp._tcp.           Engineering
10:24:48.930  Add        2   0 dns-sd.org.          _ipp._tcp.           Stuart's Home AirPrint Printer
^C
rtp-vpn4-88:Desktop rschmied$ dns-sd -L "Stuart's Home AirPrint Printer" _ipp._tcp dns-sd.org.
Lookup Stuart's Home AirPrint Printer._ipp._tcp.dns-sd.org.
DATE: ---Tue 24 Jun 2014---
10:25:47.340  ...STARTING...
10:25:48.357  Stuart's\032Home\032AirPrint\032Printer._ipp._tcp.dns-sd.org. can be reached at airprint.dns-sd.org.:631 (interface 0)
 txtvers=1 qtotal=1 pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf rp=ipp/printer URF=CP99,W8,OB10,PQ3-4-5,ADOBERGB24,DEVRGB24,DEVW8,SRGB24,IS1-2-4,MT1-2-3-5-12,MT1-2-3-5-12,RS600 ty=HP\ LaserJet\ 400\ color\ M451nw product=\(HP\ LaserJet\ 400\ color\ M451nw\) priority=10 adminurl=http://www.dns-sd.org/ServerStaticSetup.html note=At\ Stuart\'s\ house Color=T Duplex=F Scan=F
^C
rtp-vpn4-88:Desktop rschmied$ dns-sd -Gv4v6 airprint.dns-sd.org.
DATE: ---Tue 24 Jun 2014---
10:26:01.411  ...STARTING...
Timestamp     A/R Flags if Hostname                               Address                                      TTL
10:26:01.412  Add     2  0 airprint.dns-sd.org.                   173.164.252.149                              77
10:26:02.266  Add     2  0 airprint.dns-sd.org.                   0000:0000:0000:0000:0000:0000:0000:0000%<0>  77   No Such Record
^C
rtp-vpn4-88:Desktop rschmied$ 

Does the visibility imply that the printers I see are reachable or even existing? No.
Does internal visibility imply external visibility? No.
Is he forced to publish that information and make it visible to me? No.

Thanks,
-ralph

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Jun 2014 18:25:39 -0700

> That draft forces you to route ULAs outside your organization? 

The draft only suggests link-local addresses should not be published via DNS.  It also adds confusing statements regarding token-ring routing which relies on the MAC.
,---
In particular, if
any device forwarding a packet modifies any part of the IP header or
IP payload then the packet is no longer considered to be on the same
link.  This means that the packet may pass through devices such as
repeaters, bridges, hubs or switches and still be considered to be on
the same link for the purpose of this document, but not through a
device such as an IP router that decrements the TTL or otherwise
modifies the IP header.
'---

Can't tell where the document is headed, but it is not hard to imagine a scheme for converting ULA into routable.  The statement "on the same link for the purpose of this document" remains unclear while it also describes packets carried through bridges, repeaters, and hubs with a provisional requirement TTLs are not to be decremented.  It seems this too represents yet another potential security concern as this defeats loop detection and greatly simplifies data exfiltration. 

>> 2) How are routable addresses discovered when link-local is returned by mDNS?

Perhaps this limitation should be CLEARLY stated, such as the recommended suppression of link-local excludes suppression of ULAs http://tools.ietf.org/html/rfc4193 which seems likely derived outside of mDNS resolutions.  Hard to judge an undefined mechanism. 

> Firewalls are traditional way of protecting _any_ addresses. IPv6 linklocals _and_ ULAs provide added property of not being globally routable, just like RFC1918 IPv4 addresses.

While link-local addressing is often critical in establishing firewall protection, such addressing may also inhibit adjacent link access.  The language in mDNS Hybrid-Proxy document is fairly opaque with references to Token-Ring for example.  It also lacks meaningful security considerations clarifying how secure adjacent link communications is established and possible details that might relate to a split DNS configuration.  By failing to include suppression of ULAs (used in BTTM), should one assume a site-specific policy will cause preferences for locally directed ULAs?  If so, how is that preference secured?

> They need not be. Read hybrid draft + RFC6763, especially on the ‘browse domain _list_’ part.

Once again this overlooks mDNS returns link-local addressing which is not to be placed into DNS per draft-cheshire-mdnsext-hybrid.  While logical, this lacks details that are necessary to properly establish possible security concerns.

> Merging is just (ugly) glue that could deal with broken clients which handle only either pure mdns, or single list of entries-style dns-sd (‘legacy browse domain’ is the term in RFC6763).

This is not about dealing with pure mDNS or legacy DNS-SD browsing. 

3.  Hybrid Proxy Operation
,---
[..] a Hybrid Proxy gets its data by performing a Multicast DNS
query (e.g., "_printer._tcp.local.  PTR ?") on its local link, and
then, from the Multicast DNS replies it receives, it generates a
corresponding Unicast DNS reply.
'---

Details should be offered regarding the reply construction with specifics and even examples.  

> Nothing forces you to export those hybrid proxy / DNS-SD zones outside your organization. Split horizon DNS was state of the art in late 90s when (IPsec) VPNs started to first show up, but  I don’t…

We have been struggling at providing even a modicum of security when browser plugins are used in conjunction with various websites.  With the abundance of obfuscated javascript, it seems unlikely sensitive portions of DNS can remain hidden.  In such cases, there should be an effort to enumerate security implications of DNS related exfiltration that defeats efforts at securing devices that depend on remaining isolated from direct Internet access.  These might represent embedded devices having vulnerable firmware that the user is unable to update or even the All-in-One printer.  Similar issues concern defenses based on which end originates a session.

Again, details are lacking regarding specifics of the creation of a DNS reply for a protected device and how related information is secured. 

Regards,
Douglas Otis

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 25 Jun 2014 10:24:34 +0300

This is my last email in this thread, I promise. 

On 25.6.2014, at 4.25, Douglas Otis <[email-masked]> wrote:
> ‘---

I can’t usually tell where any document is headed, especially not being an author. However, it defines link boundary as not changing IP header _or_ payload, and that it operates only on one link. So if you want ‘better guarantees’, ask the author to write some sort of solemn promise not to change the contents of IP header or something.

> Perhaps this limitation should be CLEARLY stated, such as the recommended suppression of link-local excludes suppression of ULAs http://tools.ietf.org/html/rfc4193 which seems likely derived outsid…

Quoting section 3.1:

   Generating the corresponding Unicast DNS reply involves, at the very
   least, rewriting the "local" suffix to the appropriate Unicast DNS
   domain (e.g., "Building 1.example.com").

   In addition it would be desirable to suppress Unicast DNS replies for
   records that are not useful outside the local link.  For example, DNS
   A and AAAA records for IPv4 link-local addresses [RFC3927] and IPv6
   link-local addresses [RFC4862] should be suppressed.  ..

Second paragraph states that fairly clearly to me (somewhat elided).

> Once again this overlooks mDNS returns link-local addressing which is not to be placed into DNS per draft-cheshire-mdnsext-hybrid.  While logical, this lacks details that are necessary to properly…

See above, the naming (lack of) merging is handled in first paragraph and the link-local logic in the second one.

‘Get reply. If it’s link-local only, drop. If not, pass along to client.’

If you have better text, contact mr. Cheshire ;)

Cheers,

-Markus

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jun 2014 12:44:18 -0700

Dear Markus,

Thank you for your response.  See comments inline:

> Second paragraph states that fairly clearly to me (somewhat elided).

This document would be clearer by not remaining silent on use of ULAs.  But ignoring that, even assuming link-local AND ULAs addresses are not conveyed, the overly simplified description of mDNS Hybrid Proxy operation will result in a significant security exposure.  This is illustrated in a comparison of how a similar scheme works with BTTM.  Only devices able to authenticate with a ULA endpoint tunnel is exposed within DNS where any non-authenticating device's resources are suppressed whether or not mDNS offers a routable IP address.  The published authenticating devices are then able to forward traffic to non-authenticating devices such as printers.  Do you see the problem?  It is a major security concern assuming split horizon DNS offers a reasonable level of security to protect much simpler devices. 

> ‘Get reply. If it’s link-local only, drop. If not, pass along to client.’

As said before, this scheme has a significant security flaw relying on split-horizon DNS services.  No direct path should be published for devices unable to authenticate external sessions.  This may not be of great concern for Stuart since his company is already doing the "right thing".  The "right thing" should also be expressed in this mDNS Hybrid specification.  This should include an explanation of possible ULA use and an added requirement to suppress DNS publication of devices unable to authenticate external sessions.

I have included Mr. Cheshire in this thread.

Regards,
Douglas Otis

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 25 Jun 2014 21:43:57 -0400

Douglas,

The basis of your unsupported accusations is that publishing the existence of services in DNS is somehow a "significant security flaw" but you continue to ignore my initial point that the security of services is independent from the announcement and relies solely on the security of the network node providing the service.

You ignore the fact that most services are attacked as a result of port scans and not because of published DNS entries.

Machines are taken over all the time and bots attack link local neighbors. The whole addressing argument is a straw man.

You have not shown in any way that Hybrid Proxies create security flaws.

Tom

> On Jun 25, 2014, at 3:44 PM, Douglas Otis <[email-masked]> wrote:
> 
> Dear Markus,
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jun 2014 21:27:04 -0700

Dear Tom,

It's true that IPv4 is port-scannable.  With IPv6, a major hurdle is discovering network interfaces without being detected.  It's also true many devices have IPv4 relevant security options (like filters, etc).  Unfortunately, most of these approaches are simply impractical with IPv6.  

It's also true that we (as a whole) ignored security with IPv4 until abuse was rampant.  Today, we have a chance to get ahead of potential abuse in particular with this protocol.

What I am suggesting, again, is that we _clarify_ in the security section that this *is* a security risk.

Printers, many cameras, and other consumer devices designed to be attached to a local network are unable to withstand Internet-sourced attacks.  At a minimum, we need to include a section letting administrators know that publishing a globally reachable IPv6 address in DNS can be a problem. This needs to be clearly explained in hope of being understood along with offering a practical coping strategy.

Or, we can (again) simply choose to ignore it, and suffer from abuse later.

Apple's approach, with use of ULA and gateway devices, and the secure exchange of credentials offers a great example as how to deal with these potential problems.  We should be able to follow their example in this regard.

I'll remind you, as well, that I _did_ specifically show that remote access via IPv6 to a DNS-populated-from-mDNS printer enabled me to remotely initiate a fax from the Internet with nothing logged as to where the fax exchange originated.  The only indication might be a potentially massive phone bill when sent long distances late at night. Similarly, it would be possible to access media on the printer, and do simple DDoS (exhaust ink and paper, for example).  Scanning for these devices would not be possible in my lifetime, even knowing the target network.  

Is this the fault of the printer (which has no access controls on IPv6)?  Not really.  In general, common printers and the like were never designed to offer direct access from the Internet.  This means we must be ultra careful not to help malefactors by publishing specific locations of these devices thereby permitting direct Internet access.  Doing so would represent a significant security flaw as it would be wrong to blame a problem on devices having known limitations that were simply ignored.  We should strive to do better.  

Can it be _fixed_ in the printer?  Maybe, but this will impose a massive change.  Should it be fixed in the router?  Very few routers today, and fewer printers have an ability or resources to do extensive IPv6 filtering.  Should the administrator be aware of this?  Absolutely.  Should this weakness be an aspect of design considerations.  Absolutely.  IMHO, there are already well considered system level solutions available.

Regards,
Douglas Otis