Tuesday, April 01, 2008
The tragedy of the wifi commons
Ahh, multicast - the holy grail of distribution networks - is like wet paint. Once you decide that "hey, multicast would be the best way to do this", you are compelled to touch it. You are led down a twisty trail of rfcs, all different, and complex protocols like IGMP...It's no wonder that skype and bittorrent went their own way, and adopted simpler protocols (udp,tcp) to achieve their purposes. Figuring out how to use multicast properly is a black art. The amount of open source code that actually uses it is limited to a few odd corners of the internet, and is very hard to understand.
The one major client side application of multicast - multicast DNS - is so badly broken that it makes me cringe to see the packets go by. The following is a dns scan taken from a public wireless access point (the names and mac addresses have been changed to protect the innocent), using mdns-scan:
root@dancer:~# mdns-scanAt the time, the access point in question was saturated - maybe capable of 3KB/sec out to the internet. Now, I don't think multicast was at fault for that in this case, but given how 802.11 wireless works (coherent explanation to be typed in later), multicast is bad. BAD. BAD. It does not scale.
+ dancer [MA:C :AD:DD:RE:SS]._workstation._tcp.local
+ Jen Christou’s Computer [MA:C :AD:DR:ES:SS]._workstation._tcp.local
+ Malcolm Jone’s Computer [MA:C :AD: D:RE:SS]._workstation._tcp.local
+ pecutmac [MA:C :AD:DR:ES:S ]._workstation._tcp.local
+ Shogunate Macbook._smb._tcp.local
+ Very Annoyed Wombat._ssh._tcp.local
+ Very Annoyed Wombat._sftp-ssh._tcp.local
+ Trophie [MA:C :AD:DD:RE:SS]._workstation._tcp.local
+ Trophie._pds._udp.local
+ Trophie._pds1._udp.local
+ Trophie._msgsys._tcp.local
+ Trophie._cba8._tcp.local
+ Trophie._ldgateway._tcp.local
+ Ryan’s Computer [MA:C :AD:DD:RE:SS]._workstation._tcp.local
+ Malcolm Jones’s Computer._sftp-ssh._tcp.local
+ Malcolm Jones’s Computer._ssh._tcp.local
+ Malcolm Jones’s Computer._ftp._tcp.local
+ Malcolm Jones’s Computer._net-assistant._udp.local
+ Malcolm Jones’s Computer._rfb._tcp.local
+ Human._ssh._tcp.local
+ Human._sftp-ssh._tcp.local
+ pecutmac._net-assistant._udp.local
+ pecutmac._rfb._tcp.local
+ pecutmac._sftp-ssh._tcp.local
+ penutmac._ssh._tcp.local
+ iTunes_Ctrl_stringofdigitsthatdontlooklikeamacaddr._dacp._tcp.local
+ Nicolas Bob’s Computer [MA:C :AD:DR:ES:SS]._workstation._tcp.local
+ mbears-mbp._smb._tcp.local
But it's not just multicast. The uselessness of some of the dns announcements above in mapping back to conventional DNS boggle the mind.
Nicolas Bob's computer.local Great. Not only do we have spaces in this name, but punctuation! Try parsing that dns name with tools like grep - or sticking it into named - etc.. You can't even type it into a web browser or ssh. What's the point?
[MA:C :AD:DR:ES:S ] as a part of the announcement. Cooool. Now I know who you are - forever....
mbears-mbp._smb._tcp.local: Thanks for letting me know you have windows filesharing turned on. I look forward to introducing your girlfriend to your wife.
pecutmac._ssh._tcp.local: I'm willing to bet that none of the people on this network broadcasting that they have ssh available have ever used it. Why should they tell people about its availability?
5 multicast announcements from this one machine alone...
Itunes: Why the heck does itunes have to have its very own announcement with a huge unique identifier?
Programmers coding for multicast ought not to be allowed to code for it until they can recite the relevant RFCs chapter and verse, the same goes for their QA people. Would it have been so hard for Apple to enforce a DNS compatible naming scheme with a single regex? IDN, even, would have been fine. Or did they put the same people that loosed filenames with spaces and punctuation on the world on the multicast DNS project?
I'm told that the linux.conf.au network basically suffered congestion collapse. Was it due to the 70+ olpcs merrily broadcasting their services under both IPv4 and IPv6? I don't know...
I saw that the latest iphones support ssh, via a mdns-scan, the other day. That was kind of cool... but seeing the public wifi airspaces of the world clogged with devices saying "Hi! I'm ME! I do this, this, and this! My owner is clueless! I am insecure! CRACK ME! ME! ME!" really gets to me.
People can wander around naked at home all they want, but I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
Although I just used multicast dns as a talking point, it is far from being the worst offender.
As it is a relatively new protocol, the designers should have done better. Perhaps it can be fixed in the field before it becomes more pervasive.
The rest of the local networks services is much worse.
I don't want to talk about all the other announcements like SSDP, and SMB - or the bittorrent traffic, worms, insecure IM exchanges, bogus DNS servers, dhcp announcements, and TCP retransmits, etc, I saw on this poor overloaded public access point. It depressed me. All I wanted to do was get my email, (via IMAPS, thank you very much) but I couldn't.
I turned off my laptop, had a long black coffee, and moved on. I don't know how to fix public internet access points. I just don't. We could use a unique frequency band per user and people would still screw it up. Maybe the amateur radio guys and the FCC have it right, that certification should be required in order to broadcast anything on any frequency band.
I now know what it must have been like for someone that understood germ theory during the black plague era, seeing all the rats scuttle around.
I'd like to add a clause to The world of ends.
The Internet:
a) Nobody owns it.b) Everyone can use it.
c) Anyone can improve it.
...
d) Everyone is messing it up!
Apply wireshark to a network that shouldn't be slow, but is, and see your awareness change.
Bonus Link: Ongoing discussion on Ipv6 in the home.
Labels: commons, dns, ipv6, multicast, networking, olpc, wifi
¶ 4:22 PM
Comments:
<< Home
You know, I was almost--it was between me and one other candidate--the guy at Apple in charge of maintaining their multicast DNS product.
(They decided to hire the other guy because he had more DNS experience, and that's how I ended up with my current job as maintainer of BIND.)
(They decided to hire the other guy because he had more DNS experience, and that's how I ended up with my current job as maintainer of BIND.)
Well Evan;
I bow to you. I *love* BIND. Great Stuff. In fact, I have great fondness for all things isc.
I run nntp just to run nntp. no one here uses it anymore, but I run it anyway. Another dusty unused and forgotten corner of cyberspace.
let's see, this series of postings has been to say that multicast is not to blame, but IPv4 is. That hammering the available network with as many packets as the hardware will support, that don't really carry any useful information is good, but that clearheaded, purposeful communiction is, well, something less than optimal, because, , well, , because it isn't 'user friendly' of some such.
Don't really get it myself.
I bow to you. I *love* BIND. Great Stuff. In fact, I have great fondness for all things isc.
I run nntp just to run nntp. no one here uses it anymore, but I run it anyway. Another dusty unused and forgotten corner of cyberspace.
let's see, this series of postings has been to say that multicast is not to blame, but IPv4 is. That hammering the available network with as many packets as the hardware will support, that don't really carry any useful information is good, but that clearheaded, purposeful communiction is, well, something less than optimal, because, , well, , because it isn't 'user friendly' of some such.
Don't really get it myself.
PS;
I know this speaks of my deep cluelessness, but *if* something is going to be browsable remotely, or is going to broadcast/multicast, then it should *never* be of tld .local.
If it's .local. then it should remain local to that machine, and I don't want to know, see, hear, or suffer from it.
I know this speaks of my deep cluelessness, but *if* something is going to be browsable remotely, or is going to broadcast/multicast, then it should *never* be of tld .local.
If it's .local. then it should remain local to that machine, and I don't want to know, see, hear, or suffer from it.
PPS;
Over the last month, I've rolled out a fair number of new Apple Leopard machine on my network.
At Mtaht's behest, I took a nice long drink with wireshark of the network traffic.
/me sighs
Over the last month, I've rolled out a fair number of new Apple Leopard machine on my network.
At Mtaht's behest, I took a nice long drink with wireshark of the network traffic.
/me sighs
I hate to say it, but there is a compelling use of multicast DNS. I carry my own personal cloud of devices that I like to be able to talk to - specifically, laz and lor, my two nokia handhelds.
A while back I setup sshfs to let me drag and drop files from my laptop to them, so no matter where I go, I can talk to devices in my cloud, over whatever wireless network I'm on.
It doesn't work perfectly (if laz and lor come up on the same IP address that some other machine I've talked to, ssh won't authenticate), but it works well enough to be useful
Everybody has a "personal cloud" nowadays of devices that should - probably - be able to communicate with each other - this is a good thing. How they do so, well... I don't think mDNS is the answer, but others don't exist yet. (I'm thinking about it, though)
My laptop used to be able to act as an access point, which is saner and more secure than using someone elses, but thanks to the ongoing rush of progress, ad-hoc mode and ap mode don't work on my latest and greatest card.
802.11 is basically the lowest common denominator for personal connectivity.
Bluetooth is too slow and not available on everything.
I have high hopes, and high fear, on what the wireless world will look like on a mesh network, when everything can act as a router.
While IPv6 (specifically mobile IPv6) solves the ssh authentication problem, it introduces others. Recently I fired up my laptop which automatically tunnels out to get an ipv6 and a /56 allocation - and shares it - only to find that several machines on the network I was using, autoconfigured on that net, and were routing ipv6 packets through me....
Ubiquitous , and a group of linux dudes is very close to making all wireless cards that have an openmac speak 802.11s. I look forward to no longer needing an AP... and dread what will happen when the general public starts using it.
A while back I setup sshfs to let me drag and drop files from my laptop to them, so no matter where I go, I can talk to devices in my cloud, over whatever wireless network I'm on.
It doesn't work perfectly (if laz and lor come up on the same IP address that some other machine I've talked to, ssh won't authenticate), but it works well enough to be useful
Everybody has a "personal cloud" nowadays of devices that should - probably - be able to communicate with each other - this is a good thing. How they do so, well... I don't think mDNS is the answer, but others don't exist yet. (I'm thinking about it, though)
My laptop used to be able to act as an access point, which is saner and more secure than using someone elses, but thanks to the ongoing rush of progress, ad-hoc mode and ap mode don't work on my latest and greatest card.
802.11 is basically the lowest common denominator for personal connectivity.
Bluetooth is too slow and not available on everything.
I have high hopes, and high fear, on what the wireless world will look like on a mesh network, when everything can act as a router.
While IPv6 (specifically mobile IPv6) solves the ssh authentication problem, it introduces others. Recently I fired up my laptop which automatically tunnels out to get an ipv6 and a /56 allocation - and shares it - only to find that several machines on the network I was using, autoconfigured on that net, and were routing ipv6 packets through me....
Ubiquitous , and a group of linux dudes is very close to making all wireless cards that have an openmac speak 802.11s. I look forward to no longer needing an AP... and dread what will happen when the general public starts using it.
I miss netnews. I wish there was a way to ensure that rants like these were more widely read, (or translated into less of a rant and more widely read) and acted upon by the right people. I do hope people forward my urls around, and google listens, but that faith is nothing near as unshakeable as my faith in netnews was.
Perhaps I will go back to trying that. I've been enjoying several mailing lists lately, far more than the web.
As for where you are evan - I'm glad you are there, in part because - on my bad days (and I've had a few recently) - I think at Apple you would have been one day visited by "Men in Black" who would explain that screwing up DNS multicast made for an easier law enforcement environment, that the chaos it causes provided jobs, and that users could not be expected to adhere to petty naming conventions simply because they made interacting with computers easier.
At the moment, what I forsee is having to graft yet another compatability layer, along the lines of %20, on top of DNS, to keep the apple users safe in their cluelessness.
(I've seen people struggle with how to get a file with spaces on it into a web page so many times, it hurts)
(note, I'm not able to recite any of the relevant RFCs chapter and verse)
I seem to recall that _ didn't use to be a valid DNS character...
Perhaps I will go back to trying that. I've been enjoying several mailing lists lately, far more than the web.
As for where you are evan - I'm glad you are there, in part because - on my bad days (and I've had a few recently) - I think at Apple you would have been one day visited by "Men in Black" who would explain that screwing up DNS multicast made for an easier law enforcement environment, that the chaos it causes provided jobs, and that users could not be expected to adhere to petty naming conventions simply because they made interacting with computers easier.
At the moment, what I forsee is having to graft yet another compatability layer, along the lines of %20, on top of DNS, to keep the apple users safe in their cluelessness.
(I've seen people struggle with how to get a file with spaces on it into a web page so many times, it hurts)
(note, I'm not able to recite any of the relevant RFCs chapter and verse)
I seem to recall that _ didn't use to be a valid DNS character...
My reason for publishing the wireshark link was that, according to the world of ends, "the internet is an agreement".
It's an agreement to share that nobody seems to have read. I found wireshark recently to be a compelling argument to a bunch of people as to why running bittorrent was bad - showing the TCP retransmits - (which wireshark conveniently shows in red for the uninitiated)
And showing one of them what his worm did and how to fix it, seems to have raised awareness a lot
It's an agreement to share that nobody seems to have read. I found wireshark recently to be a compelling argument to a bunch of people as to why running bittorrent was bad - showing the TCP retransmits - (which wireshark conveniently shows in red for the uninitiated)
And showing one of them what his worm did and how to fix it, seems to have raised awareness a lot
Wow, such ignorance! Do you even know what zeroconf is for? If so, would you like to propose a better solution?
Hamish:
did you even read what I wrote and the commentary?
I am quite aware of what zeroconf is, and what it's for, my complaints above were more about how it is abused, and how it and related protocols and luserness make wireless networks not scale, or fail.
I even suggested some solutions. What's your specific beef with what I wrote?
I'm told that the linux.conf.au network basically suffered congestion collapse. Was it due to the 70+ olpcs merrily broadcasting their services under both IPv4 and IPv6? I don't know...
I saw that the latest iphones support ssh, via a mdns-scan, the other day. That was kind of cool... but seeing the public wifi airspaces of the world clogged with devices saying "Hi! I'm ME! I do this, this, and this! My owner is clueless! I am insecure! CRACK ME! ME! ME!" really gets to me.
People can wander around naked at home all they want, but I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
did you even read what I wrote and the commentary?
I am quite aware of what zeroconf is, and what it's for, my complaints above were more about how it is abused, and how it and related protocols and luserness make wireless networks not scale, or fail.
I even suggested some solutions. What's your specific beef with what I wrote?
I'm told that the linux.conf.au network basically suffered congestion collapse. Was it due to the 70+ olpcs merrily broadcasting their services under both IPv4 and IPv6? I don't know...
I saw that the latest iphones support ssh, via a mdns-scan, the other day. That was kind of cool... but seeing the public wifi airspaces of the world clogged with devices saying "Hi! I'm ME! I do this, this, and this! My owner is clueless! I am insecure! CRACK ME! ME! ME!" really gets to me.
People can wander around naked at home all they want, but I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
David,
I have had to split this reply into two! Here's the first half:
What's your specific beef with what I wrote?
Very well!
The one major client side application of multicast - multicast DNS - is so badly broken that it makes me cringe to see the packets go by. The following is a dns scan taken from a public wireless access point (the names and mac addresses have been changed to protect the innocent), using mdns-scan:
The following is taken from the README for mans-scan:
"mdns-scan is a tool for scanning for mDNS/DNS-SD published services on the local network. It issues a mDNS PTR query to the special RR _services._dns-sd._udp.local for retrieving a list of all currently registered services on the local link."
In other words, your beef is not with mDNS, but with DNS-SD. The fact that you don't differentiate between the two throughout your whole article doesn't fill me with confidence that you know what Zeroconf is.
The README continues:
"mdns-scan is not a good mDNS citizen since it queries continuously for services and doesn't implement features like Duplicate Suppression. It is intended for usage as a debugging tool only."
I suggest you use Duplicate Suppression as your starting point for further reading about how Zeroconf is designed to minimise traffic. Perhaps your issue is with zero configuration networking per se, in which case you might as well stop reading here, and go back to the ivory tower with people who think Gopher was perfectly good enough and that the Web spoiled the internet. But given that zero configuration networking is useful, I'll ask again: how would you do it using less bandwidth? Don't be shy of giving details, as I'm quite familiar with the Zeroconf and DNS family of RFCs.
At the time, the access point in question was saturated - maybe capable of 3KB/sec out to the internet. Now, I don't think multicast was at fault for that in this case, but given how 802.11 wireless works (coherent explanation to be typed in later), multicast is bad. BAD. BAD. It does not scale.
So go ahead and stick with your token ring network, given that the same argument was made against ethernet as a whole many years ago.
But it's not just multicast. The uselessness of some of the dns announcements above in mapping back to conventional DNS boggle the mind.
Nicolas Bob's computer.local Great. Not only do we have spaces in this name, but punctuation! Try parsing that dns name with tools like grep - or sticking it into named - etc.. You can't even type it into a web browser or ssh. What's the point?
Here's where your ignorance becomes explicit. "Nicolas Bob's Computer [MA:C :AD:DR:ES:SS]._workstation._tcp.local" is the name of a service. There is no "Nicolas Bob's Computer.local".
Furthermore, if your knowledge of the tools you use is predicated on arguments without certain characters in them, then that's your problem. Have you even tried typing spaces into the address bar of a modern browser?
[MA:C :AD:DR:ES:S ] as a part of the announcement. Cooool. Now I know who you are - forever….
mbears-mbp._smb._tcp.local: Thanks for letting me know you have windows filesharing turned on. I look forward to introducing your girlfriend to your wife.
I agree that putting a MAC address in the name of a service is not a good idea, but you might as well attack TCP/IP because people use it for doing dumb things. Does the vulnerability of a certain application-layer protocol mean that the internet is broken? No, and nor does the name of a service, or the underlying protocol it advertises, mean Zeroconf is broken.
pecutmac._sash._tcp.local: I'm willing to bet that none of the people on this network broadcasting that they have ssh available have ever used it. Why should they tell people about its availability?
I'll take that bet. On the Mac, you have to explicitly enable sshd, and on the iPhone, it only appears on jailbroken devices and isn't installed by default.
I have had to split this reply into two! Here's the first half:
What's your specific beef with what I wrote?
Very well!
The one major client side application of multicast - multicast DNS - is so badly broken that it makes me cringe to see the packets go by. The following is a dns scan taken from a public wireless access point (the names and mac addresses have been changed to protect the innocent), using mdns-scan:
The following is taken from the README for mans-scan:
"mdns-scan is a tool for scanning for mDNS/DNS-SD published services on the local network. It issues a mDNS PTR query to the special RR _services._dns-sd._udp.local for retrieving a list of all currently registered services on the local link."
In other words, your beef is not with mDNS, but with DNS-SD. The fact that you don't differentiate between the two throughout your whole article doesn't fill me with confidence that you know what Zeroconf is.
The README continues:
"mdns-scan is not a good mDNS citizen since it queries continuously for services and doesn't implement features like Duplicate Suppression. It is intended for usage as a debugging tool only."
I suggest you use Duplicate Suppression as your starting point for further reading about how Zeroconf is designed to minimise traffic. Perhaps your issue is with zero configuration networking per se, in which case you might as well stop reading here, and go back to the ivory tower with people who think Gopher was perfectly good enough and that the Web spoiled the internet. But given that zero configuration networking is useful, I'll ask again: how would you do it using less bandwidth? Don't be shy of giving details, as I'm quite familiar with the Zeroconf and DNS family of RFCs.
At the time, the access point in question was saturated - maybe capable of 3KB/sec out to the internet. Now, I don't think multicast was at fault for that in this case, but given how 802.11 wireless works (coherent explanation to be typed in later), multicast is bad. BAD. BAD. It does not scale.
So go ahead and stick with your token ring network, given that the same argument was made against ethernet as a whole many years ago.
But it's not just multicast. The uselessness of some of the dns announcements above in mapping back to conventional DNS boggle the mind.
Nicolas Bob's computer.local Great. Not only do we have spaces in this name, but punctuation! Try parsing that dns name with tools like grep - or sticking it into named - etc.. You can't even type it into a web browser or ssh. What's the point?
Here's where your ignorance becomes explicit. "Nicolas Bob's Computer [MA:C :AD:DR:ES:SS]._workstation._tcp.local" is the name of a service. There is no "Nicolas Bob's Computer.local".
Furthermore, if your knowledge of the tools you use is predicated on arguments without certain characters in them, then that's your problem. Have you even tried typing spaces into the address bar of a modern browser?
[MA:C :AD:DR:ES:S ] as a part of the announcement. Cooool. Now I know who you are - forever….
mbears-mbp._smb._tcp.local: Thanks for letting me know you have windows filesharing turned on. I look forward to introducing your girlfriend to your wife.
I agree that putting a MAC address in the name of a service is not a good idea, but you might as well attack TCP/IP because people use it for doing dumb things. Does the vulnerability of a certain application-layer protocol mean that the internet is broken? No, and nor does the name of a service, or the underlying protocol it advertises, mean Zeroconf is broken.
pecutmac._sash._tcp.local: I'm willing to bet that none of the people on this network broadcasting that they have ssh available have ever used it. Why should they tell people about its availability?
I'll take that bet. On the Mac, you have to explicitly enable sshd, and on the iPhone, it only appears on jailbroken devices and isn't installed by default.
Here's the second half:
5 multicast announcements from this one machine alone…
If it takes 5 multicast announcements to convey that information, that's because mans-scan is broken, not DNS-SD. Again, you really need to read up on how it works before you cry foul.
Itunes: Why the heck does itunes have to have its very own announcement with a huge unique identifier?
So that iTunes remote controls (such as the iPhone app) and iTunes instances can find one another. DNS-SD scans for services, not machines, and if you really do understand what it's for, you'll know why.
Programmers coding for multicast ought not to be allowed to code for it until they can recite the relevant RFCs chapter and verse
This'll be good. Please point to an (un-superceded) RFC that prohibits anything Zeroconf is doing.
the same goes for their QA people. Would it have been so hard for Apple to enforce a DNS compatible naming scheme with a single regex?
Again, the fact that you think there's a machine called "Nicolas Bob's Computer.local" makes me think you don't understand what Apple are doing, let alone enforcing.
IDN, even, would have been fine. Or did they put the same people that loosed filenames with spaces and punctuation on the world on the multicast DNS project?
Of course they did, and rightly so. Buddy, it's been twenty-five years now. For the most part, you guys seem to have got the hang of the advantages of the GUI side of HCI; why not get with the rest of the program?
I'm told that the linux.conf.au network basically suffered congestion collapse. Was it due to the 70+ olpcs merrily broadcasting their services under both IPv4 and IPv6? I don't know…
Why cast aspersions, then?
I saw that the latest iphones support ssh, via a mdns-scan, the other day. That was kind of cool... but seeing the public wifi airspaces of the world clogged with devices saying "Hi! I'm ME! I do this, this, and this! My owner is clueless! I am insecure! CRACK ME! ME! ME!" really gets to me.
Again, people whose iPhones support SSH have jailbroken their iPhones and installed SSH.
People can wander around naked at home all they want, but I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
Now, this is a sensible idea, but it's a software issue. The operating system ought to have a notion of trusted versus public networks and enable (and therefore advertise) different services accordingly. I take it that Linux does this? Serious question: if you're concerned about security, why do you run Linux rather than OpenBSD?
Although I just used multicast dns as a talking point, it is far from being the worst offender.
As it is a relatively new protocol, the designers should have done better. Perhaps it can be fixed in the field before it becomes more pervasive.
Or perhaps it's not broken, and you need to think through what you would propose as an alternative to understand why not.
Apply wireshark to a network that shouldn't be slow, but is, and see your awareness change.
I'd like to see these Wireshark reports. I have yet to see DNS-SD over mDNS take up more than a tiny fraction of a percent of the bandwidth of a WiFi network.
Hamish
5 multicast announcements from this one machine alone…
If it takes 5 multicast announcements to convey that information, that's because mans-scan is broken, not DNS-SD. Again, you really need to read up on how it works before you cry foul.
Itunes: Why the heck does itunes have to have its very own announcement with a huge unique identifier?
So that iTunes remote controls (such as the iPhone app) and iTunes instances can find one another. DNS-SD scans for services, not machines, and if you really do understand what it's for, you'll know why.
Programmers coding for multicast ought not to be allowed to code for it until they can recite the relevant RFCs chapter and verse
This'll be good. Please point to an (un-superceded) RFC that prohibits anything Zeroconf is doing.
the same goes for their QA people. Would it have been so hard for Apple to enforce a DNS compatible naming scheme with a single regex?
Again, the fact that you think there's a machine called "Nicolas Bob's Computer.local" makes me think you don't understand what Apple are doing, let alone enforcing.
IDN, even, would have been fine. Or did they put the same people that loosed filenames with spaces and punctuation on the world on the multicast DNS project?
Of course they did, and rightly so. Buddy, it's been twenty-five years now. For the most part, you guys seem to have got the hang of the advantages of the GUI side of HCI; why not get with the rest of the program?
I'm told that the linux.conf.au network basically suffered congestion collapse. Was it due to the 70+ olpcs merrily broadcasting their services under both IPv4 and IPv6? I don't know…
Why cast aspersions, then?
I saw that the latest iphones support ssh, via a mdns-scan, the other day. That was kind of cool... but seeing the public wifi airspaces of the world clogged with devices saying "Hi! I'm ME! I do this, this, and this! My owner is clueless! I am insecure! CRACK ME! ME! ME!" really gets to me.
Again, people whose iPhones support SSH have jailbroken their iPhones and installed SSH.
People can wander around naked at home all they want, but I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
Now, this is a sensible idea, but it's a software issue. The operating system ought to have a notion of trusted versus public networks and enable (and therefore advertise) different services accordingly. I take it that Linux does this? Serious question: if you're concerned about security, why do you run Linux rather than OpenBSD?
Although I just used multicast dns as a talking point, it is far from being the worst offender.
As it is a relatively new protocol, the designers should have done better. Perhaps it can be fixed in the field before it becomes more pervasive.
Or perhaps it's not broken, and you need to think through what you would propose as an alternative to understand why not.
Apply wireshark to a network that shouldn't be slow, but is, and see your awareness change.
I'd like to see these Wireshark reports. I have yet to see DNS-SD over mDNS take up more than a tiny fraction of a percent of the bandwidth of a WiFi network.
Hamish
Hamish:
The majority of your points re zeroconf I will concede at the outset. I am delighted to be chatting with someone that has an in depth understanding of the protocols involved.
Maybe you'll enjoy the series I'm currently writing about my attempts to implement ipv6.
I will quote myself here, again:
Although I just used multicast dns as a talking point, it is far from being the worst offender.
The rest of the local networks services is much worse.
Moving on to your specific comments, in backward order.
Netnews is so much better than blog comments.
I:
Apply wireshark to a network that shouldn't be slow, but is, and see your awareness change.
You:
I'd like to see these Wireshark reports. I have yet to see DNS-SD over mDNS take up more than a tiny fraction of a percent of the bandwidth of a WiFi network.
As I made clear above, my beef with this network being clogged was not with mDNS. I expressed my rage while being unable to do what I had intended to do at that particular coffee shop on that day.
I:
Perhaps it can be fixed in the field before it becomes more pervasive.
You:
Or perhaps it's not broken, and you need to think through what you would propose as an alternative to understand why not.
My specific beefs with multicast DNS are:
Adding support for punctuation in dns names is not an improvement. I was somewhat dubious of IDN, too.
I don't know if this is the case or not. Recently I worked with a more recent release of the macos and it explicitly remapped the name the owner gave it to one lacking the punctuation.
Again, it sounds like I am wrong here now - and in this blog post.
All the same, having punctuation in *service* names still strikes me as a bad idea.
I don't care for the whatever.local convention, either. I would prefer that machines have a global name, managed via public key authentication, eg, davesbox.sjds.teklibre.org. would be me no matter where I am.
A truly distributed and authenticated DNS system would have been better than .local.
Did they put the same people that loosed filenames with spaces and punctuation on the world on the multicast DNS project?
Of course they did, and rightly so. Buddy, it's been twenty-five years now. For the most part, you guys seem to have got the hang of the advantages of the GUI side of HCI; why not get with the rest of the program?
Heh.
Life was so much simpler to automate with a few characters reserved to programer-only use. I daydream of a unix.UTF-8 character set that would make stream based programming straightforward once again.
I would have liked a little more CHI - to have taken place - to have asserted more rigor on how humans interfaced with computers than what exists today. It would - for example - make speech interfaces more effective and useful.
It would make my life easier.
I:
I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
You:
Now, this is a sensible idea, but it's a software issue.
Concur.
The operating system ought to have a notion of trusted versus public networks and enable (and therefore advertise) different services accordingly.
Totally, utterly agree.
I take it that Linux does this? Serious question: if you're concerned about security, why do you run Linux rather than OpenBSD?
No OS does this by default that I'm aware of. The OLPC came close in a few regards, macs, too.
If it hadn't been for an accident of history, back when parts of BSD were possibly encumbered back in 1993, I may have ended up with BSD.
Linux has mostly won the popularity contest on the range of devices I have worked on since. I admit I am tempted to join the mac world fairly often.
The majority of your points re zeroconf I will concede at the outset. I am delighted to be chatting with someone that has an in depth understanding of the protocols involved.
Maybe you'll enjoy the series I'm currently writing about my attempts to implement ipv6.
I will quote myself here, again:
Although I just used multicast dns as a talking point, it is far from being the worst offender.
The rest of the local networks services is much worse.
Moving on to your specific comments, in backward order.
Netnews is so much better than blog comments.
I:
Apply wireshark to a network that shouldn't be slow, but is, and see your awareness change.
You:
I'd like to see these Wireshark reports. I have yet to see DNS-SD over mDNS take up more than a tiny fraction of a percent of the bandwidth of a WiFi network.
As I made clear above, my beef with this network being clogged was not with mDNS. I expressed my rage while being unable to do what I had intended to do at that particular coffee shop on that day.
I:
Perhaps it can be fixed in the field before it becomes more pervasive.
You:
Or perhaps it's not broken, and you need to think through what you would propose as an alternative to understand why not.
My specific beefs with multicast DNS are:
Adding support for punctuation in dns names is not an improvement. I was somewhat dubious of IDN, too.
I don't know if this is the case or not. Recently I worked with a more recent release of the macos and it explicitly remapped the name the owner gave it to one lacking the punctuation.
Again, it sounds like I am wrong here now - and in this blog post.
All the same, having punctuation in *service* names still strikes me as a bad idea.
I don't care for the whatever.local convention, either. I would prefer that machines have a global name, managed via public key authentication, eg, davesbox.sjds.teklibre.org. would be me no matter where I am.
A truly distributed and authenticated DNS system would have been better than .local.
Did they put the same people that loosed filenames with spaces and punctuation on the world on the multicast DNS project?
Of course they did, and rightly so. Buddy, it's been twenty-five years now. For the most part, you guys seem to have got the hang of the advantages of the GUI side of HCI; why not get with the rest of the program?
Heh.
Life was so much simpler to automate with a few characters reserved to programer-only use. I daydream of a unix.UTF-8 character set that would make stream based programming straightforward once again.
I would have liked a little more CHI - to have taken place - to have asserted more rigor on how humans interfaced with computers than what exists today. It would - for example - make speech interfaces more effective and useful.
It would make my life easier.
I:
I'd really like to see computer manufacturers implement a standard policy of clothing their hardware by default on unknown access points.
You:
Now, this is a sensible idea, but it's a software issue.
Concur.
The operating system ought to have a notion of trusted versus public networks and enable (and therefore advertise) different services accordingly.
Totally, utterly agree.
I take it that Linux does this? Serious question: if you're concerned about security, why do you run Linux rather than OpenBSD?
No OS does this by default that I'm aware of. The OLPC came close in a few regards, macs, too.
If it hadn't been for an accident of history, back when parts of BSD were possibly encumbered back in 1993, I may have ended up with BSD.
Linux has mostly won the popularity contest on the range of devices I have worked on since. I admit I am tempted to join the mac world fairly often.
Hi David,
Thank you for sticking with our conversation long enough for it to start generating light rather than heat :)
RFC2181 is well worth a read, and section 11 is particularly illuminating:
"Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default."
However, RFC1034 mandated that when a DNS resource record is used to refer to a host, the restrictions from RFC952 are followed, i.e., it "must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen". RFC1123 relaxed this to include a leading digit, but AFAIK no RFC has superseded these restrictions.
This is why a Mac called "Hamish's Computer" is advertised as hamishs-computer.local, but the service descriptions can contain arbitrary characters. SRV records are not intended to be typed in, but rather discovered and displayed; and they are deliberately distanced from hostnames by the inclusion of underscore characters (e.g. "iTunes on Hamish's Computer._daap._tcp"). So I disagree that adding support for punctuation is not an improvement, because support for punctuation (and spaces) makes service descriptions more readable. I consider it part of my job as a programmer to make things easier for users, even if it makes my job harder. Maybe that's a cultural difference between Mac OS X and Linux ;)
IDN is a whole different kettle of fish. The main problem, to my mind, is that even though the DNS is required to use canonical forms, there are still many unicode sequences that are compatibility-equivalent, and even more that are visually similar. This problem existed prior to IDN (see e.g. http://rnicrosoft.com/) but IDN vastly increases the attack vector for social engineering.
Anyway, sure, life would be simpler if we could continue the assumptions from when 640K was enough for anyone: that everyone who uses computers is a sysadmin or programmer, and that they can jolly well use English or at least our unadorned version of the Latin alphabet. But actually, if we'd designed everything from the ground up to allow for internationalisation, we'd be in much better shape nowadays. Similarly, if shells had been designed so that some other character (e.g. tab) were the separator for command line arguments, filenames with spaces in them wouldn't cause the headaches they do today. (Of course, nobody cared, because who in their right mind would want to use spaces when there were only 6+3 characters available for naming files?!)
I look forward to reading your IPv6 articles, and welcoming you to the Mac world :)
Post a Comment
Thank you for sticking with our conversation long enough for it to start generating light rather than heat :)
RFC2181 is well worth a read, and section 11 is particularly illuminating:
"Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose.
The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default."
However, RFC1034 mandated that when a DNS resource record is used to refer to a host, the restrictions from RFC952 are followed, i.e., it "must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen". RFC1123 relaxed this to include a leading digit, but AFAIK no RFC has superseded these restrictions.
This is why a Mac called "Hamish's Computer" is advertised as hamishs-computer.local, but the service descriptions can contain arbitrary characters. SRV records are not intended to be typed in, but rather discovered and displayed; and they are deliberately distanced from hostnames by the inclusion of underscore characters (e.g. "iTunes on Hamish's Computer._daap._tcp"). So I disagree that adding support for punctuation is not an improvement, because support for punctuation (and spaces) makes service descriptions more readable. I consider it part of my job as a programmer to make things easier for users, even if it makes my job harder. Maybe that's a cultural difference between Mac OS X and Linux ;)
IDN is a whole different kettle of fish. The main problem, to my mind, is that even though the DNS is required to use canonical forms, there are still many unicode sequences that are compatibility-equivalent, and even more that are visually similar. This problem existed prior to IDN (see e.g. http://rnicrosoft.com/) but IDN vastly increases the attack vector for social engineering.
Anyway, sure, life would be simpler if we could continue the assumptions from when 640K was enough for anyone: that everyone who uses computers is a sysadmin or programmer, and that they can jolly well use English or at least our unadorned version of the Latin alphabet. But actually, if we'd designed everything from the ground up to allow for internationalisation, we'd be in much better shape nowadays. Similarly, if shells had been designed so that some other character (e.g. tab) were the separator for command line arguments, filenames with spaces in them wouldn't cause the headaches they do today. (Of course, nobody cared, because who in their right mind would want to use spaces when there were only 6+3 characters available for naming files?!)
I look forward to reading your IPv6 articles, and welcoming you to the Mac world :)
<< Home
