Tuesday Jan 25, 2011

A final suggested read

David Reed (who co-wrote the paper inspiring the name of this blog) passed along a pointer to this paper by Dan Geer:

A Time for Choosing

Please read it, and understand the founding spirit of the Internet. And with that, I say goodbye to Oracle.

Monday Nov 23, 2009

End-to-end Research Group is ending

Let me quote BBN's Craig Partridge on the Internet Research Task Force's end2end-interest mailing list:

Dear Friends and Colleagues:

After 26 years, the End-to-End Research Group has decided to cease existence
as of January 1st, 2010.  While there is certainly still end-to-end research
to be done, the group had ceased to effectively serve as a forum for those

The E2E group had a great run, serving as a place where many researchers
could bring their ideas for initial, informal, airing.  The meetings could be
bruising.  (At one meeting, a member tried to encourage a speaker by saying
"We're all friends here" only to pause and say, "No, I'm sorry, actually we
eat our young, but proceed anyway").  But the meetings usually also brought

Ideas that were tested in E2E meetings include slow start and improved
round-trip time estimation, Random Early Drop, Integrated and Differentiated
Services, Weighted Fair Queuing, PAWS, and Transaction TCP.

When I learned about the group (and their enlightening e-mail list), my networking professor described it as covering, "End to end, and everything in between..." Now you half-dozen readers know the exact origin of this blog's name.

Luckily, the mailing alias will still be around. Still, the cliche, "End of an era," really applies here. It's yet another sign of the Internet's maturity, and that the really new places for research are probably somewhere not a lot of people are examining.

Anyone else have something to say about the End-to-End Research Group going away?

Sunday Jul 12, 2009

FiOS vs. Comcast?

I'm moving, and now I have a choice. Which do I chose?[Read More]

Monday Mar 09, 2009

DOH! Ekiga.net MAILS your password back to you

Make sure you don't pick a good password for ekiga.net -- they mail it back to you IN THE CLEAR in an e-mail message.

I'm so furious, I can't even begin to describe it. Did I miss fine-print on their page saying they'd do something this stupid?

UPDATE: They also store your password in the clear on-disk. Check out ~/.gconf/apps/ekiga/protocols/%gconf.xml if you wanna see it in all of its cleartext glory!

Wednesday Oct 31, 2007

We'll miss you, Itojun

Jun-Ichiro Hagino, better known to the IETF community as Itojun, died on October 29th at the age of 37.

Please visit this link for a message from his colleages at Japan's WIDE Project.

He led the KAME/WIDE IPv6 work that now appears in all of the BSDs (including MacOS X), and even their user-land tools are in Linux. Having worked on one of the pre-KAME IPv6 implementations (NRL), I can tell you that Itojun pushed things along even further than I'd hoped.

I had the privilege to talk with him when I was attending IETF meetings, and even visited him on his home turf in Tokyo. He was very unassuming, enthusiastic, and an all-around Good Guy (TM). I'll miss him, and a LOT of other people will too. PLEASE follow the link I mentioned above to see what you can do to honor Itojun.

Wednesday Sep 12, 2007

IPsec Tunnel Reform, IP Instances, and other new-in-S10 goodies

Solaris 10 Update 4 (or as marketing calls it, Solaris 10 08/07) contains some backported goodies we've had in Nevada/OpenSolaris for a while.

IPsec Tunnel Reform was one of the first big pieces of code to be dropped into the S10u4 codebase. It shores up our interoperability story, so you can now start constructing VPNs that tell IKE to negotiation Tunnel-Mode (as opposed to IP-in-IP transport mode). Tunnels themselves are still network interfaces, but their IPsec configuration is now wholly in the purview of ipsecconf(1M). Modulo IKE (which we still OEM part of), we developed Tunnel Reform in the open with OpenSolaris.

Also new for S10u4 is IP Instances. Before u4, you could create non-global zones, but their network management (e.g. ifconfig(1M)) had to be done from the global zone. With u4, one can create a unique instance zone which gives the zone its own complete TCP/IP stack. The global zone needs to only assign a GLDv3-compatible interface to the zone (e.g. bge, nge, e1000g) to give it a unique IP Instance. You could have a single box be your router/firewall/NAT, your web server, and who knows what else, all while keeping those functions out of the fully-privileged global zone. It makes me think about upgrading to business-class Internet service at home, building my own box like Bart did and getting a few extra Ethernet ports.

Oh, and if you want to do it all with less ethernet ports, check out OpenSolaris's Crossbow and its VNIC abstraction!

Have fun moving your network bits in new and interesting ways!

Tuesday Feb 13, 2007

Unnumbered interfaces confuse Quagga

The whole reason I was reading e-mail on a Sunday was not to look for telnetd exploits.

I was logged in because Team IPsec runs its punchin IPsec remote-access server (sometimes called a VPN server, but I hate that term because it's pushed by too many middlebox vendors) which was having routing problems.

As stated before, Solaris implements tunnels as point-to-point interfaces. For a remote-access server like we have in punchin, this means every external IP address gets a tunnel interface. (Until we had Tunnel Reform, this meant only one client per external IP address, which messed up NATs for multiple clients.) A tunnel interface has two addresses - a local one and a remote one. The local one can be shared with other tunnels or even with a different local interface (like the local ethernet). Such interfaces are called unnumbered interfaces.

A remote access server does forward packets, and is therefore by definition a router. One of our servers just swapped out Zebra (from older OpenSolaris/Nevada build) to Quagga. We use Quagga's OSPF to learn the topology of the Sun internal network (the SWAN).

As clients "punch out", their tunnel gets destroyed. Now each of these tunnels shares the same local IP address with our ethernet to the SWAN. Unfortunately, these "interface down" events confuse Quagga, and suddenly all of my punchin clients can't move bits to the internal network anymore.

There is a workaround, and that's to assign a different local IP address than the one that is directly connected to the SWAN for use with all of the client tunnels. It's not that painful, as I only lose one out of 256 possible client addresses (our engineering ones only have a /24 from which to allocate client addresses). Still, as an esteemed colleague said, "I hope that's not the \*whole\* solution."

It isn't, and I would like to ask the Quagga community (as I've already asked our local routing folks, Paul Jakma and Alan Maguire) to make sure that Quagga and its routing protocols play nicely with unnumbered interfaces. It'll allow me to plumb tunnels until I'm all out of address space! :)

This entry brought to you by the Technorati tags , , and .

How OpenSolaris did its job during this telnet mess

Open development --> faster turnaround.[Read More]

Monday Mar 28, 2005

US Navy and Open Source - how last decade! :)

An old friend/colleague sent me this url:


And in particular wanted me to read this response to the posting in question.

The response is pretty good, and right up front talks about two projects (see here and here respectively) that I had the pleasure to work on.

The work we did at NRL lives on today in many places either directly or indirectly. We have our war stories (no pun intended), including locking horns with GPL-bigots who did not like that we were going to put out our software with a BSD license, in spite of our funding sources' requirements that our work be directly transferable into commercial products.

So raise your glasses to the new, folks, but don't forget the old. And also don't forget that just because you remember history, it doesn't mean that you can't make the good parts repeat!

Monday Jan 03, 2005

I hate middleboxes...

Ever since I worked on one of the early IPv6 implementations, I've had a sour taste in my mouth for any node in the middle of a network that did more than forward packets (or maybe one or two other things, which I'll talk about later).

Nodes that are in the middle of the network and do not merely forward packets I will call middleboxes in this entry. The granddaddy middlebox was the firewall. These were designed to prevent classes of packets (often very large classes of packets) from reaching a network that was connected to the Internet. Given the poor state of end-node implementations (anyone remember when sendmail was the biggest source of vulnerabilities?) at the time, firewalls were a sensible solution to the problem.

To cope with people demanding Internet services while still being behind their safe firewall, the proxy came into play. These boxes pretend to be servers for machines on the inside of a firewall, and clients to machines outside the firewall.

To cope with address space "shortages" (especially when the addresses in question might never be seen on the Internet, thanks to firewalling), the Network Address Translator (NAT) was invented. To the outside world, the NAT presents a small number of Internet addresses (often that number is one). Behind the NAT, there is a whole network (usually carved out of addresses that are reserved just for this purpose) of nodes.

These nodes often cause as many problems as they solve. A server cannot depend on IP addresses (whether or not that's good design is a discussion for another time) any more (even if they're secured with IPsec). IPsec itself does not work without the NAT-Traversal hack (now available in Solaris 10). Anything using a proxy is prone to failure if the proxy is flaky - my outbound ssh sessions often disappear because the proxy times them out. With most middleboxes, state that should only be on the two the end-nodes is now distributed to a third, or more. And often, that third node is out of the user's control.

There are some good cases for having some set of middlebox functionality. Alec Muffet has convinced me with defense-in-depth arguments that some set of firewall functionality is useful in various environments. I can understand (but still despise) NAT in places where stingy ISPs only allow one address per subscriber, or worse, do NAT for you. We are where we are today because a lot of this was a market-driven reaction to poor implementations of network service applications (and in some cases the OS as well). We in OS and network-service development can, of course, fix this if we try hard enough. I'd suggest looking at recent articles about what historical development practices have wrought.

I think we all finally understand what our responsibilities are as end-node engineers. The sooner we act on those responsibilities, the sooner we can remove any excuses for the new classes of bridge trolls to exist. (Did I mention anyone who likes this blog should visit David Reed's excellent site?) And if any folks out there are dissatisfied with their current choice, I hope that they realize that the market will provide other choices.



« April 2014