I very much enjoy the Internet Protocol Journal and put it at the top of my reading stack as soon as it is received. In particular, I enjoy the standards and high technical detail and view it as a safe place from overt commercial advertisement and politics.
That is why I was disappointed by the article from Mr. Lynn. My opinion of ICANN is that it is undemocratic in any tradition, uninterested in experimentation, and uninterested in outside views. I took offense at his continued use of the phrase "public trust" and interpreted the article as propaganda. Further, I found the technical content of the article to be zero.
On the other hand, William Stallings article on MPLS was exactly the kind of article I've come to enjoy. I wasn't familiar with MPLS and the article helped me understand the concepts, vocabulary, and high-level issues. I hope that "MPLS" serves as a model of the articles in future IPJ issues.
I keep back issues of IPJ in a binder and continue to hope you uncover more articles like "The Social Life of Routers." My copy of Mr. Krebs article has notes in all the margins—I was excited—but it was a twist on something that I thought I knew and he exposed a different design vocabulary by making an unexpected comparison.
I apologize for complaining about something that is a gift from Cisco; I do understand how crass that is. I hope that you will interpret my note in a complementary manner: I've come to respect the journal and found that it fits an unfilled niche in my reading.
—Brent D. Stewart, Global Knowledge
I appreciate your feedback, as I am sure Mr. Lynn will if you send it to him. The article was, after all, published for public comment.
ICANN has unfortunately tended to polarize people and has become a forum in which a certain amount of politics is played out. I don't think this is entirely ICANN (the board)'s fault. What was set up as an organization to take over the work of one man—the late Jon Postel, is seen by some as an opportunity for "Internet Governance" and "world-wide electronic democracy."
Having watched the ICANN process since its beginnings in 1998, I would say that Mr. Lynns' version of history is pretty much on target. When the IANA was in the hands of Jon Postel, it most certainly was a "public trust" (a limited resource to say the least), and if ICANN does not take that responsibility seriously, it certainly will have failed.
However, I do not think this is the case. Yes, ICANN is now a fairly large and slow moving machinery, and I would have liked to see more new domains deployed sooner, but to some extent the slowness is caused by the structure of Supporting Organizations as much as it is by the board itself. There is a lot to sort out, a lot to comment on, and many divergent views are indeed being expressed in all kinds of ICANN forums, including the public meetings. So, I cannot agree that ICANN is "uninterested in outside views." A perfect democracy it is not, nor was it ever intended to be, and yes, some of the topics on the agenda such as the Uniform Dispute Resolution Process (UDRP) are indeed non-technical. But it is not as if ICANN had much choice in that particular matter. (Although some would argue that it could be moved outside the ICANN process.)
Being part of the ICANN process, through e-mail discussion, public meetings or through the Supporting Organizations is not difficult. Nor do I think that ICANN ignores any of the feedback it gets.
Back to the article. No, it was not particularly technical, but if you read IPJ's Call for Papers you will see that it mentions "Legal, policy and regulatory topics..." Also, in the wake of September 11, I though it was important to provide some background on the thinking of ICANN, and why they chose to refocus the most recent meeting on security etc. IPJ, by the way, also encourages the occasional "Opinion Piece," although the article by Mr. Lynn was not intended as such. The issue of alternate roots is indeed a matter of debate, and while the the IAB has already expressed its view, I appreciate that there might be other (valid) ones.
In any case, thank you for taking the time to write. I certainly don't intend to steer IPJ away from topics such as MPLS and I hope that the occasional policy or even opinion piece won't steer you away from IPJ.
—Ole Jacobsen, Editor and Publisher
William Stallings otherwise-excellent article on MPLS in the Internet Protocol Journal Vol. 4, No. 3 had a serious error in it with respect to Virtual Private Networks (VPNs). He said that MPLS is an efficient mechanism for supporting VPNs and that MPLS provides security; neither is true.
As the rest of the article shows, MPLS provides a transport tunnel for IP packets, meaning that it helps create virtual networks. However, there is no privacy on those virtual networks, so it is inappropriate and probably dangerous to call MPLS tunnels virtual private networks.
To most Internet users, security means preventing snooping of sensitive traffic, preventing malicious changes to content, or both. MPLS does not provide either service. Instead of relying on insecure MPLS, users who want secure tunnels use systems that employ the IPsec protocol.
Many dozens of vendors supply IPsec systems appropriate for everything from tiny home offices to gigantic telco central switches, all with the same high security. Although the article showed that MPLS has many valuable features, IPJ readers should not fall into the trap of thinking that VPN support or security are MPLS features.
—Paul Hoffman, Director, VPN Consortium
Ed: We presented this letter to a panel of experts, and here are some samples of the responses we received:
The term "VPN" has been used in many different contexts. I saw a group once call a VLAN a "VPN" as well. I honestly couldn't say that they were incorrect. It may be appropriate to say that there are IPsec VPNs and that there are MPLS VPNs, but I have a problem calling one "right" and another "wrong" simply because of some perceived, implied definition of the security level that should be provided by a "VPN." Most people support the notion that an MPLS VPN provides about as much "security" as a Frame Relay link. This amount of "security" in a VPN is acceptable to many people.
—Chris Lonvick, Cisco Systems
We have different views on security, I'm sure. One view is that a secure private network: a) ensures that a third party cannot impose a condition on the network such that a customer's traffic is directed to another customer b) ensures that a third party cannot inject traffic into a customers private network, c) a third party cannot alter customer traffic and d) a third party cannot discern that communications is taking place between two parts of a private network.
MPLS uses the same mechanisms as X.25, ATM and Frame, and has similar properties—the objectives above can be met with adequate confidence as long as the network is carefully configured and managed.
Edge to edge IPSec has a different set of security principles—the basic mode of operation is that such networks may be subject to attacks that redirect customer's traffic to third party sites, and allow third parties to inject traffic into the VPN, and allow a third party to discern that communications is taking place within a private context. The essential attribute of edge to edge IPSec is that the encryption is intended to ensure that leakage can be identified: foreign injected traffic or altered traffic can be identified and rejected and leaking traffic cannot be decoded.
Both approaches have vulnerabilities and weaknesses. The first approach places trust in the integrity of the host platform. The second approach is prone to various forms of DOS attacks and traffic profiling.
But I would not concur with a view that labels the MPLS approach as inefficient or insecure, nor would I label X.25 networks, ATM or Frame as intrinsically inefficient and insecure. There are insecure operating practices and there are cautious operating practices.
IPSec networks have similar issues—relating particularly to the vulnerabilities of third party disruption and profiling eavesdropping.
So it's not that I believe that all MPLS networks are well designed and well operated—on the contrary! But as an architectural approach I am not able to agree with a comment that appears to condemn MPLS as intrinsically a poor choice for a VPN host technology.
So if the comment is that the article provides the impression that MPLS is such a robust technology that it creates secure private network applications such as VPNs, and appears to make this assertion so strongly that it gives the impression that this outcome occurs irrespective of MPLS network design and operating practices, and that this impression is ill-founded, then I would agree entirely with Mr. Hoffman. Secure networks, or at least robust networks, are a result of careful choice of technologies coupled with careful design and careful operation.
—Geoff Huston, Telstra
Ed.: We forwarded these comments to Mr. Hoffman, and he responded:
Geoff believes that it a network that does not prevent an active attacker from seeing or modifying traffic, and does not prevent a passive attacker from seeing packets, is secure and private; I do not. The fact that MPLS restricts the flow of traffic to a particular defined network is sufficient for him; it is not for me, given the fact that an attacker breaking into any node on that defined network can compromise the privacy and integrity of the traffic.
It is typical for ISPs to not want to do the work of actually securing the traffic they say they have put in a VPN by using IPsec. That work is not cheap, and takes more management than vanilla MPLS, but it is the only way to really secure the data. I am absolutely not saying that the IPsec community is without blame here: we have a tendency to ignore the valuable features of MPLS and have done almost nothing to make it easier to intelligently tunnel IPsec in MPLS (we also pretty much stone-walled the IPsec under L2TP work that is now finally standardized). But our lack of openness doesn't make MPLS a VPN technology.
—Paul Hoffman, Director, VPN Consortium
Ed.: We would love to hear from you.
Please send your letters to: email@example.com