Subject: [dnssd] Security through Obscurity

From: RJ Atkinson <[email-masked]>
Date: Wed, 23 Jul 2014 16:51:05 -0400

(NOTE WELL: I am not a WG Chair, IESG member, IAB member,
or authorised spokesperson for anyone other than myself.)

Earlier Doug Otis wrote:
> It is not safe to advertise such addresses in DNS, 
> especially when security depends on address obscurity.

I believe that the the vast majority of security folks
would object to the notion that obscurity is a mechanism 
capable of providing any meaningful security.

If a client were to ask me for advice on protecting their
interior services or interior devices from the global Internet, 
I would suggest at least a firewall (ranging from router ACLs 
to an air-gap: depending upon their local needs and threat model) 
and possibly also other measures (again, depending upon local
needs and threat model).  Operational security is not 
one-size-fits-all, in my experience, but relying upon 
security-through-obscurity seems unwise to me.

> It sounds like Ran wants to configure devices within a data-center.

Incorrect.  To be very clear, my post to DNS-SD WG from earlier 
this week definitely was NOT focused on data centre environments. 

Yours,

Ran

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Jul 2014 23:43:34 +0100

> security-through-obscurity seems unwise to me.

Indeed. Though I’d argue that work such as RFC 7217 still has value.

> this week definitely was NOT focused on data centre environments. 

I certainly didn’t take it that way.

Tim

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jul 2014 21:27:31 -0400

> security-through-obscurity seems unwise to me.

I agree with that statement, but at the same time some of these devices are assigned routable addresses by the vendors.  When assigned out of a 48 bit space, it might be possible to guess the device based on common manufacturers.  When randomly assigned by the owner, it is highly unlikely such an address will ever be guessed.  Add rate limiting, and this unknown should work well at mitigating attack.  But as I said, I agree with your statement and why I think mDNS should be working with ULAs.

Regards,
Douglas Otis

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 23 Jul 2014 21:43:04 -0400

> On Jul 23, 2014, at 9:27 PM, Douglas Otis <[email-masked]> wrote:
> 
> 

mDNS advertisements are link-local. Whether mDNS uses GUAs, ULAs, or link-local addresses is irrelevant.

I'll assume you meant the broader term DNS-SD. If so, then the scope of the address is a matter best left up to the particular use case.
There are arguments for all of them and a mix of them depending on what you're trying to achieve. Bots operate inside private networks and can do as much damage with ULAs as with GUAs.

We need to stop thinking about an internal network and an external network. There is just THE network. Your security should reflect the fact that malfeasants will try to break into every one of your devices and they all need the appropriate level of protection from this. If a device is susceptible, that's not an DNS-SD problem, that's a device problem.

Tom

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 06:37:17 -0400

On 23  Jul 2014, at 21:43 , Tom Pusateri wrote:
> mDNS advertisements are link-local.

Agreed.

> Whether mDNS uses GUAs, ULAs, or link-local addresses is irrelevant.
> 
> I'll assume you meant the broader term DNS-SD. If so, then the scope
> of the address is a matter best left up to the particular use case.
> There are arguments for all of them and a mix of them depending on
> what you're trying to achieve.

Yes.  There are a range of use cases.  These use cases will vary
in multiple dimensions, not just in choice of IP addressing model.

For example, separate from the question of which types of IP addresses 
a particular operational domain uses internally, there will be 
variation in whether/how the ordinary (unicast) DNS is deployed.

Considering the DNS axis of variation, one can imagine reasonable 
deployments where the operational domain might fall into one of 
several very different use cases:
	A) has no deployment of (unicast) DNS
	B) has a single (unicast) DNS instance of example.com,
           where the internal view is identical to the external view
	C) has a split-horizon DNS deployment of example.com
	D) other reasonable use cases probably exist

Case (A) probably describes a large number of home networks
and a fair number of small enterprise networks (e.g. dentist's 
office).

Further, for case (B), a small site with its own domain name
(e.g. example.com) might not have any full-time IT staff and
might not have direct configuration control over the contents 
of its DNS.  It might, for example, have outsourced its DNS 
to a service-provider, which in turn provides a web portal and 
a (very) limited set of configuration options (e.g. ability 
to specify IP addresses for a very small number of pre-defined 
network services such as inbound mail-relay and public web server).

Case (C) probably is done most often at larger sites where 
full-time IT staff exist and the organisation's DNS instances
are directly managed by their IT staff.

Note well that any of these DNS deployment cases (A-D above)
might use any combination of private-scope IPv4 addresses, 
IPv6 ULAs, and global-scope IP addresses for their unicast 
IP addressing deployments.  As near as I can tell, addressing
options are orthogonal to the DNS deployment options.

> Bots operate inside private networks and can do as much damage
> with ULAs as with GUAs.

Yes.  This means that defense-in-depth usually is the best option,
where one has a firewall and also has other measures.  However,
general operational security concerns properly are topics for 
the IETF's OPsec WG.

Bottom-Line:
------------
DNS-SD needs to work well regardless of the unicast IP addressing
used and regardless of the (unicast) DNS deployment model used.

I believe this is entirely possible -- without changing the large
installed base of systems that support (mDNS + DNS-SD) today.

Yours,

Ran

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Jul 2014 14:07:03 +0100

> I agree with that statement, but at the same time some of these devices are assigned routable addresses by the vendors.  When assigned out of a 48 bit space, it might be possible to guess the devic…

Doug, if you mean a 48-bit MAC address being embedded in the IPv6 address, see http://tools.ietf.org/html/rfc7217.

I agree with Tom’s comments. A question to discuss in your slot today is when a device has a LL, ULA and GUA, which of those should be advertised via the SD protocol and whether/how that choice can/should be influenced. 

Tim

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 09:49:31 -0400

> see http://tools.ietf.org/html/rfc7217.

All,

I think the notion of predictability of IPv6 Interface IDs
is not germane to the DNS-SD discussions, for the reasons
that various folks (e.g. Stuart Cheshire, Tim Chown, and 
Tom Pusateri) have explained already.  

Separately, in many environments, predictability of IP
addressing of printers (or file servers or ...) is 
operationally DESIRABLE.

However, just for the record, there also are a range of other 
RFCs, long predating RFC-7217, for generating IPv6 Interface IDs, 
going back for more than a decade.  [References at bottom]

I believe these various alternative IPv6 IID algorithms are 
widely implemented and deployed today, and that they have been 
widely implemented and deployed for many years now.

Note, in some environments, especially business environments,
the use of DHCP(v6) is operationally preferable to SLAAC
because it provides PREDICTABILITY in IP address assignment. 

Also, in many environments where DHCP is NOT used, for example
due to the costs associated with DHCP, it is STILL operationally 
DESIRABLE for an IPv6-capable device  (e.g. network printer) 
to have the SAME PREDICTABLE IPv6 address each and every time 
the printer (re)boots.  IPv6 SLAAC with an embedded MAC address 
thus is DESIRED in many environments -- especially for devices
providing services that would be advertised using DNS-SD
(e.g. network printer).

Can we PLEASE get past individual hangups over *solved* problems 
that belong to other IETF WGs (e.g. IPv6 Ops, IPv6 Maint, OPsec)
and instead stay on-topic for DNS-SD ?

Thanks,

Ran Atkinson

REFERENCES:

RFC-3041	January 2001
		Privacy Extensions for Stateless IPv6 
                Address Auto-config

RFC-3972	March 2005
		Cryptographically Generated Addresses (CGAs)

RFC-4941	September 2007
		Revision of RFC-3041

RFC-4942	July 2007
		Support for Multiple Hash Algorithms in
		Cryptographically Generated Addresses (CGAs)

RFC-5535	June 2009
		Hash-based Addresses

RFC-7217	April 2014
		Generating Opaque Interface IDs with IPv6 SLAAC

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Thu, 24 Jul 2014 15:54:03 +0000

Hi Ran,

Where you say:

> the printer (re)boots.  

Why in your opinion is it “operationally desirable” for the printer to have a predictable IPv6 address?  I have my own thoughts on this subject but I want to hear yours, hopefully with examples.

Smith

/**
    Smith Kennedy
    Hewlett-Packard Co.
*/

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jul 2014 12:26:59 -0400

> I agree with Tom’s comments. A question to discuss in your slot today is when a device has a LL, ULA and GUA, which of those should be advertised via the SD protocol and whether/how that choice can…

Dear Tim,

The comment was focused on typical operating modes regarding newer IPv6 ready printers in typical home networks.  There are ways to improve upon SLACC, as noted in RFC7217. When a printer is assigned a globally routable IP address, publishing this address in a way that can be seen by malefactors outside the network would be a bad practice.  In home environments, SLAAC rather than DHCP often provides the printer's IPv6 address.

Where there is no overlay network in a home network having multiple routers, publishing the printer's address would be detrimental. Testing determined, that when not using an overlay network, these devices were highly vulnerable to exploits that allows malefactors an ability to remotely fax, scan, print, from anywhere in the Internet without any logging being generated.  As such, it would be a bad practice to place a printer's mDNS resources into DNS.  

Answering your specific question, the address functional for DNS-SD would be the ULA address, which should be the prefix announced to the printer.  In essence, this represents a security consideration for the use of SSD and not directly an SSD mode of operation.

Regards,
Douglas Otis

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jul 2014 12:28:32 -0400

On 24  Jul 2014, at 11:54 , Kennedy, Smith (Wireless Architect) wrote:
> Why in your opinion is it “operationally desirable” for the printer
> to have a predictable IPv6 address?  

The most common reason that my clients give me is that 
predictable/deterministic IP addressing lowers their 
operating costs.  Larger enterprises often use DHCP 
to obtain this.  Smaller enterprises find DHCP complex
to deploy/configure, but they still want predictable
addressing in their IP network deployments.

And this is not just for printers, but also for other devices
offering shared services -- file servers or whatever else.

Yours,

Ran

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jul 2014 14:11:31 -0400

> addressing in their IP network deployments.

Three printers on the floor.
One is reporting it is broken, so broken that you can't do much more than
see that it exists.  Which one is it?  Match address to mac address on bottom
of unit.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jul 2014 15:08:48 -0400

Three printers on the floor.
One is reporting it is broken, so broken that you can't do much more than
see that it exists.
If the IP(v6) address is predictable, and related in some way to the
EUI-64, then you can find the right unit.
The printer has little privacy concerns, seldom visits internet cafes,
and is never found it airport lounges.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Albrecht, Harald" <[email-masked]>
Date: Fri, 25 Jul 2014 07:21:15 +0000

> Von: dnssd [mailto:[email-masked]] Im Auftrag von Michael
> Richardson
> Gesendet: Donnerstag, 24. Juli 2014 21:09
> Cc: [email-masked]
> Betreff: Re: [dnssd] Security through Obscurity
> 
> One is reporting it is broken, so broken that you can't do much more than see
> that it exists.
> If the IP(v6) address is predictable, and related in some way to the EUI-64,
> then you can find the right unit.
> The printer has little privacy concerns, seldom visits internet cafes, and is
> never found it airport lounges.

In which form do the reporting come in? I would assume that these printers have some labels sticking on them that identify them in a more human-friendly way? Or am I wrong here and missing something? I'm trying to figure out how the reporting process and troubleshooting process will benefit from pre-assigned static LLAs, but I have problems doing so.

By the way -- my home printer has global IPv6 addresses (yes, it has two as Deutsche Telekom assigns temporary PA prefixes). But it has a snuggly firewall in front of it so it is of no concern to me; this printer can't be reached from the outside. These two additional GUAs don't eat up significantly resources, so why do I need to bother? I'm using ULA and LLA internally, so that's what I'm caring about. The GUAs aren't bad in any way ... unless there is general suspicion that GUAs are bad in any case...?

With best regards,
Harald

---

From: Michael Sweet <[email-masked]>
Date: Fri, 25 Jul 2014 08:51:07 -0400

FWIW, many recent (within the last 4 years or so) printers support IPP and an operation called "Identify-Printer" which makes the printer beep or flash to aid in identifying which printer you are talking to...

But more generally most people don't have multiple (identical) printers, and most organizations stick a label on the printer with its name on the network...  Crude but effective... :)

> By the way -- my home printer has global IPv6 addresses (yes, it has two as Deutsche Telekom assigns temporary PA prefixes). But it has a snuggly firewall in front of it so it is of no concern to m…

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 25 Jul 2014 15:05:44 +0000

I’m struggling to see how this is a practical example that justifies pre-assigned / predictable IPv6 addresses.

My primary worry is that this will give people a pseudo-legitimate rationale to continue their tragic antiquated habit of using raw network addresses for things like printer queue creation, which is still all too prevalent today.

Smith

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jul 2014 17:02:23 -0700

> My primary worry is that this will give people a pseudo-legitimate rationale to continue their tragic antiquated habit of using raw network addresses for things like printer queue creation, which i…

Dear Smith,

Agreed.  For example, most printers do not offer user specific security measures for their basic operation.  Such user specific secure printing is normally done indirectly by accessing shared OS resources offered by a server able to establish TLS connections.  The indirectly accessed devices do not themselves authenticate for scanning, printing, or faxing in most cases.  This means publishing their IPv6 public addresses will invite abuse.  This is only one example of devices never intended to be directly accessible on the Internet, and which may be subject to abuse when DNS-SD is used indiscriminately.

This has become a bit muddled, since DNS-SD offers predictable domain assignments conveying IP addresses.  Unless a device is able to authenticate Internet originating sessions, it should not be published in DNS having directly accessible IP addresses.  It’s not a matter of using raw IP addresses - regardless how the address is characterized - it’s a matter of not allowing globally _reachable_ addresses to be published for such devices.  IPv6 firewalls in todays routers are unable to cope with filtering ranges of IPv6 addresses, and devices expected to only connect to a local network will likely have no means of protecting themselves from the large-I Internet.

Insecurely assigned prefixes and randomly assigned Interface-IDs never being publicly published still offers weak security.  Multiple off-the-shelf home routers should be expected to use dynamically assigned prefixes, since some insist dynamic prefix assignment improves privacy.  (Some providers bind prefix assignments with the MACs used by the modem where any MAC change necessitates an approval process.)  Without use of ULA overlay addressing in such a home network, firewalls will remain susceptible when unable to recognize internal IP addresses, and hence unable to block externally initiated sessions.

On the other hand, enterprise networks likely have statically assigned prefixes.  While static assignment or known router prefix assignment information allows greater use of GUA addressing, exploits may still defeat stateful src/dst firewall protections.  Use of tunneling or VPNs into ULA space still provides greater security.  Those who find using ULAs within an Enterprise environment difficult are also likely ill equipped at setting up overlays.  This inability likely means renumbering will be more difficult as well when a prefix nevertheless changes.

Regards,
Douglas Otis

---

From: "Albrecht, Harald" <[email-masked]>
Date: Tue, 29 Jul 2014 07:26:12 +0000

Hello,

could it be, per chance, that there are different views on what "publishing" a device's IP address to DNS means? Maybe about what to publish where?

I have problems understanding what publishing a devices " IPv6 public address" (cit) really means? I have learnt that there are GUAs, ULA, LLAs, but what are public addresses? One could argue that publishing an address in itself constitutes public addresses, but that's most probably not helping either. I don't see that publishing an address also automatically constitute its accessibility. To me, a RR dictionary does not constitute security either. If it would, then something would be severely broken.

> -----Ursprüngliche Nachricht-----
> Von: Douglas Otis [mailto:[email-masked]]
> Gesendet: Dienstag, 29. Juli 2014 02:02
> An: Kennedy, Smith (Wireless Architect)
> Cc: Douglas Otis; Albrecht, Harald; [email-masked]; Michael Richardson
> Agreed.  For example, most printers do not offer user specific security
> measures for their basic operation.  Such user specific secure printing is
> normally done indirectly by accessing shared OS resources offered by a
> server able to establish TLS connections.  The indirectly accessed devices do
> not themselves authenticate for scanning, printing, or faxing in most cases.
> This means publishing their IPv6 public addresses will invite abuse.

Are you talking about abuse by internal users, the users that are connected to the same network? If yes, then this is not even remotely an issue of DNS-SD, this is a network design problem. Either the devices are not suitable for the requirements of safety or the network design is not suitable to cope for end-device misdesign. Either way, DNS-SD and global addresses are wrong trees to bark up.

 >  This is
> only one example of devices never intended to be directly accessible on the
> Internet, and which may be subject to abuse when DNS-SD is used
> indiscriminately.
This is mixing things. Having a global address does not imply global accessability! What does you make believing so? As I'm typing this, my computer has its very own global IPv4 address (ups, shame on me!), yet you won't be ever able to reach it. Yes, I use a unique global IPv4 address ... inside the company intranet. And it's not a private address. So there clearly are secure setups that use global addresses and use DNS-SD and no one drops dead.

> Insecurely assigned prefixes and randomly assigned Interface-IDs never
> being publicly published still offers weak security.  Multiple off-the-shelf
> home routers should be expected to use dynamically assigned prefixes, since
> some insist dynamic prefix assignment improves privacy.  (Some providers
> bind prefix assignments with the MACs used by the modem where any MAC
> change necessitates an approval process.)  Without use of ULA overlay
> addressing in such a home network, firewalls will remain susceptible when
> unable to recognize internal IP addresses, and hence unable to block
> externally initiated sessions.

You are mixing different things here, so it's difficult to understand what your point actually is. First, what are insecurely assigned prefixes?? And yes, IIDs are not for security ... they have one clear purpose: to identify a particular IPv6 interface in a given subnet. So this is as obvious as saying that assigning your subnet routers IPv4 addresses that don't end in .1 or .254 improves security.

ULA addresses are not for security, please show me the RFC that does claim so. Over time, people have come to understand that ULAs offer stable intranet addressing. But what does stable addressing has to do with security? I can't understand why you are mixing up all these different things, it's really hard to understand for me.

> On the other hand, enterprise networks likely have statically assigned
> prefixes.  While static assignment or known router prefix assignment
> information allows greater use of GUA addressing, exploits may still defeat
> stateful src/dst firewall protections.

Should I read this as a plea to move to end-to-end transport security and authentification? If you are arguing for this, then yes, this offers better security. But from your current wording I'm really not clear about what you are trying to argue for. But again, please don't kill the GUAs for something they didn't do.

LG, Harald

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2014 09:47:51 +0100

Hi,

There is some interesting discussion happening here, but we do need to focus the discussion on the elements that are important to defining scalable DNS-based service discovery, as per our group’s charter.  Of course if there are related topics that people think are important, those can be progressed elsewhere, such as 6man or v6ops, though we should remember that dnssd’s charter is IP version agnostic.

It would be useful therefore to capture what is of direct relevance to dnssd from this discussion.

One point is that a comment was made at IETF90 that dnssd should not explictly care about stability of addresses, and it should work however frequently a device is renumbered or changes address. So if someone implements the ‘press a button to renumber my home network’ idea discussed elsewhere, dnnsd should be able to react, and, as per REQ13 should ensure information is up to date and not stale.

It was also said that we should note the distinction between a service running on a device being discoverable (via dnssd), reachable (dependent on ACLs etc) and usable (via authentication). We don’t want to rathole here on default home network CPE firewall settings, or the merits of RFC7217, take that to v6ops. 

There is some discussion of handling the scopes of discoverable devices in draft-cheshire-dnssd-hybrid-01, in Section 3.1. I suspect Stuart would be happy to receive thoughts on that text.  ULAs have been discussed for homenet (in parallel to GUAs), and RFC1918 addresses are of course in wide use for IPv4 homes and enterprises.

Tim

---

From: "Albrecht, Harald" <[email-masked]>
Date: Tue, 29 Jul 2014 08:50:32 +0000

This is also exactly my understanding, thanks for clarifying this.

Von: dnssd [mailto:[email-masked]] Im Auftrag von Tim Chown
Gesendet: Dienstag, 29. Juli 2014 10:48
An: Albrecht, Harald
Cc: Kennedy, Smith (Wireless Architect); [email-masked]; Douglas Otis; Michael Richardson
Betreff: Re: [dnssd] Security through Obscurity

Hi,

There is some interesting discussion happening here, but we do need to focus the discussion on the elements that are important to defining scalable DNS-based service discovery, as per our group's charter.  Of course if there are related topics that people think are important, those can be progressed elsewhere, such as 6man or v6ops, though we should remember that dnssd's charter is IP version agnostic.

One point is that a comment was made at IETF90 that dnssd should not explictly care about stability of addresses, and it should work however frequently a device is renumbered or changes address. So if someone implements the 'press a button to renumber my home network' idea discussed elsewhere, dnnsd should be able to react, and, as per REQ13 should ensure information is up to date and not stale.

It was also said that we should note the distinction between a service running on a device being discoverable (via dnssd), reachable (dependent on ACLs etc) and usable (via authentication). We don't want to rathole here on default home network CPE firewall settings, or the merits of RFC7217, take that to v6ops.

Tim