Well, PNRP has now made VNUNET. So, like all articles, there are a few things good and a few things bad about it. The first thing is that I want to apologize to the world that there was not more MS comment in the article. Unfortunately, the nature of press inquiries is that requests for comment trickle through many layers before they reach those who need to comment, so sometimes it is slower than we would like. For example, I only learned about this request a couple hours before the story was posted. It is, unfortunately, the nature of the beast.
So let me hit some of the good points. Tom does a good job of talking about some scenarios in which PNRP is valuable, such as online gaming. I am pretty stoked that such a mention will help more developers find out about our technology. Tom also nailed the issue of how this affects IDS systems, which is great. Specifically, he explains how this will look like unusual traffic and as such, the IDS systems will raise flags, which is basically a nuisance issue. I would add that betas like this give IDS makers the opportunity to identify new protocols like PNRP for addition to their known behavior sets, stopping issues like this from happening after Vista ships. Finally, he rightly explains that we are not going to have PNRP running by default in the RC releases.
Let me start expanding upon the article a little bit now, starting with the 'enabled by default' issue. This is an interesting issue, and is one that warants discussion. At Microsoft, and particularly in my team, I think we have a great passion for delivering the best software possible. That sounds trite, but it is really true. The issue is that sometimes that leads to conflicts. In this case, we had to balance the default configuration of the beta vs the quality of the final product. By turning PNRP on, we will get a lot of information about how PNRP behaves under different circumstances. We then have the opportunity to improve the protocol before we launch the final product. Fundamentally, what Betas are for is to make sure that we can ship the best possible final product.
There are a couple of other little points about the article that I would like to clarify. The first is the assertion that we are pushing all sorts of information out into the cloud. PNRP itself publishes what it is asked to publish by an app, and no more. Thus, we generally publish the name someone wants to publish (note that this is not necessarily a username, but is whatever the app wants, so it could be a GUID or something like that), the addresses the name should resolve to, maybe a port number, and maybe a short comment set by the app (Usually used for testing). In the case of PNRPAuto which is the service publishing names on LH that has spawned this discussion, we basically just publish a random number for the name and then the machine addresses. Let me reiterate, we are basically publishing a random number into the cloud. As such, we do not post random personal information.
Furthermore on this topic, as of Beta 2 forward, all that PNRP will push to other machines that are not actively resolving for your name (i.e. the stuff we use for routing requests) will just be a hash of your name and the addresses of the machine. At that point, it is quite innocuous info, and again, it is only at the behest of an app.
Another note is regarding security review of the protocol. We are currently in discussions with a couple of security experts about reviewing PNRP. This has been in the works for a while. If there are particular security experts who you would recommend we talk to, please let us know and we will add them to the list of candidates.
There are a lot of other issues in the article that I would like to address, but I think I will save them for some future posts. Stay tuned for more exciting PNRP news!