Tuesday Jan 25, 2011
Monday Nov 23, 2009
By danmcd on Nov 23, 2009
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 discussions. 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 insights. 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
Monday Mar 09, 2009
By danmcd on Mar 09, 2009
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
By danmcd on Oct 31, 2007
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
By danmcd on Sep 12, 2007
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
By danmcd on Feb 13, 2007
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 routing, Solaris, and OpenSolaris.
By danmcd on Feb 13, 2007
Monday Mar 28, 2005
Monday Jan 03, 2005
By danmcd on Jan 03, 2005
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.
- A final suggested read
- I'm leaving, and switching gears for a bit
- MAC-then-encrypt - also harmful, also hard to do in Solaris
- Thinking about the Birthday Problem on my Birthday, as it applies to my Birthday Present
- Do a "pkg image-update" with multiple zones!!!
- I, for one, welcome our new database-selling overlords.
- Wanna help your Girl Scouts? Not unless you have Windows. :-P
- IKEv2 project page updated
- OpenSolaris works out of the box with Amazon Virtual Private Cloud
- IKEv2 project now on OpenSolaris
Other Solaris Developers
No bookmarks in folder