Re: [dnssd] Security through Obscurity

On Jul 25, 2014, at 8:05 AM, Kennedy, Smith (Wireless Architect) <smith.kennedy@hp.com> wrote:

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

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

> On 2014-07-25, at 1:21 AM, Albrecht, Harald <harald.albrecht@siemens.com> wrote:
> 
>>> Von: dnssd [mailto:dnssd-bounces@ietf.org] Im Auftrag von Michael
>>> Richardson
>>> Gesendet: Donnerstag, 24. Juli 2014 21:09
>>> Cc: dnssd@ietf.org
>>> Betreff: Re: [dnssd] Security through Obscurity
>>> 
>>> 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.
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd