Monday November 23, 2009
End-to-end... and everything in betweenDan McDonald's Sun blog, covering IPsec, general networking goodness, and other stuff too. 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 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? (2009-11-23 18:22:11.0) Permalink Comments [1]Hello you half-dozen readers! The simple question is stated above. The full question is a bit more complicated. I currently am a mostly-satisfied Comcast business-class customer in a place with no other options. I will be moving to a place where I can choose between Verizon FiOS and Comcast business-class. My initial forays suggest I can keep my 6Mbit/1Mbit with /29 prefix of static IPs, or pay $20-30/month more and push it up to 20Mbit/5Mbit. Having 5Mbit out is very tempting, but apart from making my family download pictures from www.kebe.com faster, I'm not sure it's worth it. Comcast won't bundle consumer TV and Phone with business-class Internet, will FiOS? And I have some technical issues with my /29 static IP block with Comcast. Will I have these the same with FiOS? Will I even be able to get a /29 with FiOS? Any clues are, as always, welcome! (2009-07-12 19:38:17.0) Permalink Comments [3]Endian-independence -- NOT just for kernel hackers Yesterday on Facebook, OpenSolaris community member Stephen Lau said:
thought i was done caring about endianness when i left kernel programming... oops
I quickly replied:
You put bits on a {network,disk} that transcend architectures, you worry about byte-order.
I've often wondered why people with apps for Solaris on SPARC are often concerned about getting it to work on Solaris for x86 and vice-versa. Seeing Stephen equate byte-order-sensitivity to kernel-hacking suddenly made me realize the problem: byte-order sensitivity is everyone's problem. Any time your program puts a multi-byte value in a network packet, or a disk block, it is highly likely another program on a different byte-order platform will attempt to read that packet or disk block. Never mind the historical holy wars about byte-order, even today, there are enough different platforms that run both big and little-endian byte orders out there. It's really not tough to write endian-independent code. The first thing you need to decide is how to encode your disk/network data. Most Internet apps use a canonical format (which is big-endian for things in RFCs). There have been some schemes to have a universally-encoded format (XDR or ASN.1), but these can often be big-and-bulky. OS research in the early 90s proposed a scheme of "receiver makes right", where a producer tags the whole data with an encoding scheme, and it is then up to the receiver to normalize the data to its native representation. Regardless of encoding scheme, if you are reading data from network or disk, the first step is to normalize the data. Different architectures have different aids to help here. x86 has bswap instructions to swap big endian to x86-native little endian. SPARC has an alternate space identifier load instruction. A predefine alternate space (0x88) is the little-endian space, which means if you utter "lduwa [address-reg] 0x88, [dst-reg]" the word pointed to by [address-reg] will be swapped into [dst-reg]. The sun4u version of MD5 exploits this instruction to overcome MD5's little-endian bias, for example. Compilers and system header files should provide the higher-level abstractions for these operations, for example the hton{s,l,ll}() functions that Internet apps often use. After manipulating data, encoding should follow the same steps as decoding. Also, in some cases (e.g. TCP or UDP port numbers), the number can often just be used without manipulation Some have called for compiler writers to step up and provide clean language-level abstractions for byte-ordering. I'm no language lawyer, but I've heard the next revision of Standard C may include endian keywords:
/*
* Imagine a UDP header with language support!
*/
typedef struct udph_s {
big uint16_t uh_sport; /* Source port */
big uint16_t uh_dport; /* Destination port */
big uint16_t uh_ulen; /* Datagram length */
big uint16_t uh_sum; /* Checksum */
} udph_t;
Today, these fields need htons() or ntohs() calls wrapping references to them. Of course, there would be a lot of (otherwise correctly-written) existing code that would need to be rewritten, but such a type-enforced scheme would reduce errors. Finally, one other cause of non-portable code is doing stupid tricks based on how multi-byte integers are stored. For example, on little-endian boxes:
/* This won't work on big-endian boxes. */
uint32_t value = 3;
uint32_t *ptr32 = &value;
uint8_t *ptr8 = (uint8_t *)&value;
assert(value == *ptr8); /* Barfs on big-endian... */
People micro-optimize based on such behavior, which limits such code to little-endian platforms only. A compiler can exploit the native platform's representation to make such optimizations redundant, and any compiler guys in the half-dozen readers can correct or confirm my assertion. (2009-06-18 10:52:45.0) Permalink Comments [2]Hello again. Pardon any latency. This whole Oracle thing has been a bit distracting. Never mind figuring out the hard way what limitations there are on racoon2 and what to do about them. Anyway, Solaris 10 Update 7 (aka. 5/09) is now out. It contains a few new IPsec features that have been in OpenSolaris for a bit. They include:
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.
Dear
Any clues are, as always, welcome. Looks like one of those test boxes is finishing up. Time for test setup... (2009-02-03 14:17:11.0) Permalink Comments [0] Way to go, Disney! I just read an article stating that Disney will be including a regular DVD with several Blu-Ray releases. As both a new Blu-Ray owner, and a parent of two five-year-old Disney fans, I'm pretty thrilled about this. Our SUV/crossover has a DVD player for long trips (our rule: one-way Trips of >= 1 hour only), and we were curious about what we were going to do if/when we started moving to Blu-Ray for our purchases. I don't know if this will affect Pixar releases (our Wall-E, for example, has no DVD copy), but it'll be nice knowing that at least for some purchases, we get the hi-def version AND one we can play on those >= 1 hour car trips. (2009-01-07 17:36:39.0) Permalink Comments [0]
How to tell when a performance project succeeds? The Volo project is an effort to improve the interface between sockets and any socket-driven subsystems, including the TCP/IP stack. During their testing, they panicked during some IPsec tests. See this bug for what they reported. Addendum - IKEv2 does not have this problem because its equivalent to v1's Quick Mode is a simpler request/response exchange, so the responder is ready to receive when it sends the response back to the initiator. (2008-12-09 08:42:22.0) Permalink Comments [0] Racoon2 on OpenSolaris - first tiny steps NOTE: A version of this was sent to the racoon2-users alias also. I've been spending some of my time bringing up racoon2 (an IKEv2 and IKEv1 daemon) on OpenSolaris. Because of vast differences in PF_KEY implementations between OpenSolaris and other OS kernels, I've spent my racoon2 time actually getting IKEv1 to work first, instead of IKEv2. Right now, what's working is:
That's it! IKEv1 responder needs work, as does all of IKEv2, as does work for multiple-choice of algorithms. But there's enough change in there to say something now.
ARCHITECTURAL DIFFERENCESThe most noteworthy change in the OpenSolaris work so far is that literally there's no spmd (a separate IPsec SPD daemon racoon2 uses) required for now. This is because:
If spmd serves another purpose, we will revisit it. As it stands, however, I cannot see us using it. CODE DIFFERENCESIn OpenSolaris, we use the "webrev" tool to generate easy-to-review web pages with diffs of all varieties. The webrev for what I have so far in racoon2 is available at: http://cr.opensolaris.org/~danmcd/racoon2-opensolaris/ Feel free to make comments or suggestions about what I've done. (2008-08-15 13:20:39.0) Permalink Comments [1]How to rescue data from an iBook with thermal problems My wife Wendy has had her iBook G4 for not-quite four years now. We had to return it once before via AppleCare due to thermal problems. Well, the thermal problems are back, and this time, there's no AppleCare for us to invoke. I managed to get the machine to behave itself only after leaving it powered off for a bit, but then it would lock again. I'd heard stories about putting computers in refrigerators to keep them cool enough to run. I never thought I'd try it myself. We do, however, have a freezer in the basement. So check this out:
I managed to get Wendy's home-directory off, and that's what mattered. I'm heading off to the Apple Store to get a new MacBook (thank goodness for the just-arrived George-and-Nancy "Will you be my friend with this stimulus?" check). I hope to do the frozen data transfer one more time to bootstrap the new MacBook. (2008-05-18 06:54:44.0) Permalink Comments [0]
Can't let this one slip by I'm not sure if this picture represents extreme stupidity in the protestor, or if it's merely a clever use of Photoshop to make a joke. If the latter, it's pretty funny. If the former... I have NO idea what to say.
Kebe's Home Data Center (or f''(Bart's new home server)) A little over a year ago, Bart Smaalders blogged about his new home server. Subsequently Bill built a similarly-configured one. (I thought that he had blogged about his too, but he hadn't.)
So why four ethernet ports (covering three drivers)? Well, like Indiana, Crossbow is exciting, but not yet integrated into the main OpenSolaris tree. I do, however, very much like the idea of Virtual Network Machines and I'll be using these four ports to build three such machines on this server using prerequisite-to-Crossbow IP Instances. Two ports will form the router zone. The router will also be a firewall, and maybe an IPsec remote-access server too. With Tunnel Reform in place, I can let my or my wife's notebook Macs access our internal home network from any location. One port will be the public web server, and assuming Comcast doesn't screw things up too badly on their business-class install, the new home of www.kebe.com. The last port will be the internal-server and global-zone/administrative station. All of that ZFS space needs to be accessible from somewhere, right? I'd like to thank Bart and Bill for the hardware inspiration, and to my friends in OpenSolaris networking for offering up something I can exploit immediately to create my three machines in one OpenSolaris install. I'll keep y'all informed about how things are going. (2008-03-03 08:21:22.0) Permalink Comments [4]
Who am I rooting for this weekend? Michigan! If the oddsmakers and pundits are to be believed, my two favorite NFL teams (my current-home Patriots and my childhood-home Packers) will be facing each other in a couple of weeks at the Super Bowl. Remember I said *if* the oddsmakers and pundits are right. If they are, I'm going to have to hide my Packers sweatshirt for the rest of January. And worse (well, worse for the football fan in me), I'm going to miss the game 'cause I'm on vacation with my family!
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.
No HD happiness. Who do I blame? DirecTV? TiVo? Both of 'em? Telcos? Okay... I'm mad. I see that TiVo is offering another lifetime subscription transfer if you buy a new HD TiVo between now and the 8th of November. Pretty cool, huh? I've determined I'm more TiVo-happy than DirecTV-happy. I've heard multiple-independent accounts that other DVR services and software leave a lot to be desired, especially if one had TiVo at one point. I've also continued to hear verification that the cable companies still suck, and my own recent experiences with the Cable Company have been less than stellar. I even started using Verizon for local phone service... something I swore I'd never do after then-Bell-Atlantic botched a simple two-phone-line installation so badly that I had to violate the network interface boundary to fix it. So I see several opportunities for improvement, but I'm assuming any of the companies in question will bite. I doubt it'll happen, but if the Red Sox can win a second World Series in four years (GO SOX!), anything's possible. Hey telcos --> pay attention, here's one geek's wishlist:
Any takers? (I somehow doubt it, but a guy can hope...) (2007-10-30 22:14:08.0) Permalink Comments [1] |
Calendar
RSS Feeds
All /Entertainment /IPsec /Miscellany /Networking SearchLinks
NavigationReferersToday's Page Hits: 241 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||