Re: Denial of Service by Spamware?
On Fri, 29 Dec 2000, Christopher Ambler wrote: Is Exchange broken? Undoubtedly so. Is there a way that a clueful user can overcome the break? Absolutely. Should the software be "banned?" Of course not. If anything, unsubscribe those users who can't take the trouble to ensure that their system, *regardless of the software used,* works properly. And back that up with a note "from the IETF" to the developers of the software, describing its standards avoidance in exhaustive detail. Yes, we've hashed over those details here on the list, but there's no guarantee that the developers of any particular offensive code will be on this list (which, perhaps, should say something, but...) For the record, the offenders I've noted in response to my posts have included Novell Groupwise, Lotus Notes, "Internet Mail Service", and something I couldn't readily identify because it seemed to lack an X-Mailer: or other identifying header. I'm pretty certain Notes comes configured for braindamage "out of the box", though, because of all of the vacation spam I've received over the years from Interop suits when posting to those lists. Which would suggest either that there are more clueful Notes admins running IETF list members' sites, or that there are fewer IETFers behind Notes scramblers^H^H^Hgateways. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ -- "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil"
RE: 49th-IETF conf room planning
On Mon, 18 Dec 2000, Matthew Goldman wrote: I also disagree with you regarding hotel rates. Pre-negotiated block rates for meetings are around the same price as we paid in San Diego for a similar type of hotel (clearly, Vegas hotels are both much better than and much worse than the Sheraton San Diego). The only time hotel rooms are extremely high is for major expositions -- like Comdex, Consumer Electronics Show, etc -- because those rooms are not booked as blocks. The hotels jack up the prices for those weeks. I've been to Vegas on a non-convention week and got a hotel room for $70/night vs. $180/night for the same room during Comdex. It would be up to the IETF to negotiate for 2000-3000 rooms; that's a lot of buying power. If they can't get reasonable rates, then we don't go there. Actually, geek conferences get the shaft in Vegas, because Vegas is wise to the fact that geeks, knowing the odds, are much less likely to gamble. That's why Comdex, Interop, and so forth, get such high hotel rates. Now, if we assured them that IETF stands for "International Eaters of Tasty Food", or similar, we might get a break... And we can point to the frequent mention of "many fine lunches and dinners" in _Exploring the Internet_ as substantiation. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ --
Re: Congestion control
On Fri, 15 Dec 2000, Henning G. Schulzrinne wrote: Then, there's always the Scout Jamboree option: build an Internet tent city. I'd imagine Burning Man has more attendees than the IETF and it seems to draw some of the same crowd. Interop tried this at Vegas shows from, what, '96 through '98, when they outgrew the LVCC :) Marketing called it the HTFE -- "High Tension Fabric Enclosure", but the NOC team preferred "Temporary Enclosure Needing Tension" -- TENT. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ -- "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil"
Re: guidance (re: social event politeness)
On 14 Dec 2000, Sean Doran wrote: I believe at least some of this is unacceptable behaviour that cannot be overlooked simply by virtue of general disorganization or industry competitiveness, and look for guidance about how we should (collectively) police such poorly-socialized people, if at all. Possible solutions, in no particular order: a) "There are few problems in life that can't be adequately addressed by a suitable application of high explosives." b) Whisper "asshole" whenever you're within earshot of the offenders, simultaneously throwing a brief but withering glance at them. Encourage others who were directly or indirectly a party to the offense to do the same. c) Socially engineer their room numbers then let your inner 12 year old loose, unsupervised, in a hotel with room service and a city full of delivery services of all kinds. Depending on the delivery services you enlist, be prepared with photographic equipment. d) Be glad you don't suffer such a pathetic existence as to have to lord your supposed privilege over others in order to feel anything analogous to self-worth. Whenever you're reminded of the offenders or the offense, recall this line and chuckle softly in bemusement. If they can hear you, so much the better, because they'll know you're having a little laugh at the expense of their aforementioned pathetic existence. Of course, in spite of what you might think, reading this, I'm inclined to be a pretty nice guy :) -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ -- "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil"
Anycast and related frobs
I throw myself upon the humble mercy of the gods that I might not make a fool of myself (again) in front of the IETF. Nevertheless, here goes... As I understand it, a goal of IPv6 Anycast is to provide implicit connectivity to the "nearest" netwise instance of a given member of a group of service providers. Now, granted, this is based on an "address", not an address / port tuple, so it's more like a group of machines, than service providers, right? What work has been done to provide a "nearest service" type of implicit addressing? From what I gather, SLP is for service *discovery*, but what I'm really on about is not "what services are available", but "where can I find *this* service, closest to me?" The canonical example of this is (duh) FTP mirrors. CPAN does a pretty good job of multiplexing you to the netwise closest mirror, but it's all done relatively heuristically, if I understand it correctly, and it's done from the CPAN main server side, which means it can't tune the response for *you* in particular. Is there work underway to "canonicalize" such discovery procedures and formalize them into, perhaps, a "Services: Optimization of Reachability to Those Available" (SORTA)? This next bit, please generalize as much as possible. FTP is what I'm thinking of this instant, because it's what triggered the thoughts, but I wouldn't want to shoe-horn a perfectly non-crappy idea into one application alone. Also, note that my thoughts on implementation might suck, so feel free to "improve" them in the inimitable IETF way. What I'm thinking of is something in which a client (say, FTP) is given a list of, e.g., URLs of available instances of the *particular* service (that is, mirrors that actually contain the data you seek). Thus, a list of hostnames and ports, and, implicit in the protocol field of the URL, a protocol intended to be used for the actual desired exchange. The client then plugs all of this into the SORTA mechanism, which queries an upstream SORTA cache, asking it for the nearest, fastest "match" out of that set, based a loose characterization of that service. So, for instance, the SORTA cache might know (based on statistics collected over time) that the mirror at foo.example.com is close to me and very fast for small FTP transactions, but unstable over time. It might furthermore know that bar.example.com is slower, but very stable, so it's better for big files. Based on that knowledge, and the list of potential candidates I gave it, it would respond with foo.example.com for a small file, and bar.example.com for a large file. Of course, that's not to say that an implementation has to be this complex. An upstream cache may pick one at random :) Or it may pick one solely based on ping times. And so on... Some reasons I'm thinking along these lines are: - ping / traceroute routinely get dumped on the floor by congested routers and picky firewalls - having every single client determine reachability to the entire mirror list is a huge duplication of effort and waste of b/w - having the server side determine reachability heuristically is a guessing game, possibly educated (no offense to the CPAN folk) I'm aware that FreeNet might provide much of this functionality implicitly in its core architecture, but I've not yet looked into it too deeply. SORTA also seems like a sort of (no pun intended) "reverse" approach to things like Harvest (and, I suppose, FreeNet). Both Harvest and FreeNet, as I understand it, look to bring the content closer to frequent requestors of it. SORTA would take a less dynamic approach. Content would stay where it is, but clients would be routed to the best instance. Actually, that's not entirely true. Content *could* stay where it is, or it could move, provided the master lists remained up to date (or there was a mechanism for propagating changes throughout the SORTA cachespace). In fact, SORTA could work together with the mirroring tools themselves to move content to near mirrors based on SORTA caching information. Which then *would* be like FreeNet :) Whee! I'm also aware that there are "global load-balancing" tricks for doing this. However, they require that you be in collusion with all mirror instances, more or less. What I'm looking for is something that could easily be joined / left by mirror members simply by adding / removing entries from the master mirror list handed to a client. Thanks for listening! -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- Me: "That was pretty gross, Andy. I can't believe you ate it after I stuck it up your nose." Andy: "It was a big grape and a small nose. It didn't get very far." - outtake from perspex imageworks, inc., design meeting, circa 1994
Re: music at pittsburgh?
On Sun, 7 May 2000, Jon Crowcroft wrote: 2/ is anyone interested in jamming at the next IETF (folk, jazz, rock, thrash, triphop etc - you know, primal scream...) - i can bring a guitar (or bass or flute or something...) but local folks would be easier on the wrists!!! I just got a bodhran I'm itchin' to play... -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "I get a lot of letters like, 'Dear John, I've got a dead alien. What should I do with it?' One word: barbecue!" - John Lovitz, A Yellow Pages commercial
RE: How many IP addresses?
On Tue, 25 Apr 2000, Michael B. Bellopede wrote: wrong idea -- big iron routers don't use "code" to do forwarding, they use silicon, and very fast silicon at that. There are routers in production --Steve Bellovin Software, firmware, its a matter of semantics. Do you think that silicon magically performs routing and logical functions. Hmmm... Uh, "hardware" != "EEPROM + CPU" here. "hardware" == "custom routing ASICs". In the "no options, entry in cache" scenario Steve mentions, the processor "don't enter into it", as it all goes through the raw silicon. Think gates. Not bill gates, logic gates. -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "I get a lot of letters like, 'Dear John, I've got a dead alien. What should I do with it?' One word: barbecue!" - John Lovitz, A Yellow Pages commercial
Re: prohibiting RFC publication
On Sun, 9 Apr 2000, Peter Deutsch in Mountain View wrote: readily accessible. I still see value in having documents come out as "Request For Comments" in the traditional sense, but it certainly wouldn't hurt to find ways to better distinguish between the Standards track and other documents. Here's a novel idea: we could stop calling them all "RFCs". Call them by the designators they get once they're blessed (ie: STD, INF, EXP, etc.), and stop ourselves citing them as RFC [0-9]+. Change begins at home, as they say... -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "I only counted on today's sunlight and snow, on the rain that dampened my face." - L.E. Modesitt, Jr., Adiamante
Re: Proposed working group: IP Storage
On Wed, 23 Feb 2000, John Stracke wrote: The second most common SCSI application (after disk drives, for which we have NFS) seems to be scanners, for which remote use doesn't make much sense; you have to be physically at the scanner to put the paper in. Actually, there are valid scenarios for remote scanning. Specifically, the high-volume document management scanners are often hooked up in such a way that you dump a load of paper in them (ie: several thousand sheets), hit the "go" button, and they're whisked away to somewhere else on the 'net where they're actually processed. It's easier on the vendors if they only have to support one command set (ie: SCSI) with potentially multiple transports, than if they have to throw in new core firmware for each transport. -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "'The Fragile' embodies everything wrong with this decade--hype, letdown, technological fetishism, empty rage, financial bloat, bombast, self- loathing, and indifference to anything truly important and interesting..." - Brent DiCrescenzo in http://www.pitchforkmedia.com/record-reviews/n/nine-inch-nails/fragile.shtml
Re: IP network address assignments/allocations information?
On Tue, 7 Dec 1999, Keith Moore wrote: OTOH, if you combine NAT with 6to4 for home networks, the picture starts to look a bit better. Think of 6to4 as the generic ALG that rids you of the need to have separate ALGs for most of the applications that NAT happens to break. Mine is not a stand in favor of NATs, let me get that out first :-) However, the arguments against NATs in the home all center around end-to-end connectivity to various devices in the home (light bulbs, toasters, VCRs, thermostats, etc). Is this really the "right" model for that sort of interaction? Personally, my home network (in which every light bulb *will* be on the 'net within the year) is not something I want end-to-end connectivity to. I'm not saying that's the right solution for everyone, but I think it's certainly worth thinking about as we're designing VCR control and LBMP (Light Bulb Management protocol). That is, I think it's important to consider that folks (via their vendors) will want to deploy ALGs at the boundary of the house, NAT or not. I know I will be, even after the internal v6 infrastructure meets up with the rest of the world in the far flung future. I don't think NATs are architecturally "correct", but I think they're teaching us an important lesson about the (initially valid) assumptions about end to end connectivity. Even after we eradicate NATs through wholesale migration to v6 (optimist hat on), the paranoid will still deploy ALGs on their firewalls to mediate access to those globally routable lightbulb and security camera addresses. After all, I wouldn't want the world getting illicit shots of me in my underwear in the evenings. Well, perhaps it's the world that wouldn't want to be getting those shots, but you get my point... -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "There are plenty of things out there that people should be offended about. Put your indignation into some more productive and appropriate fight." - Larry Rosensweig in http://www.cnn.com/1999/US/12/03/pokemon.swastika.ap/index.html
Re: IP network address assignments/allocations information?
On 7 Dec 1999, Perry E. Metzger wrote: Tripp Lilley [EMAIL PROTECTED] writes: Is this really the "right" model for that sort of interaction? Yes. I don't want to invent fifteen thousand different protocols to handle things. IP already does what I need most of the time. Perhaps I wasn't clear... IP (v4 or v6 or what have you) is a fine way of determining the end points of the communication. But at higher levels (MEGACO, SIP, LBMP, etc.), I believe it makes sense to allow in the protocol design that people might want to consolidate funcionality in an ALG (more below) I'm not sure that's the right model, actually. IP addresses are too easy to forge. The right way to stop people from doing that sort of thing is to deploy end to end security protocols that strongly authenticate both ends. Realistically, in the home environment (which is quite specifically the domain I'm constraining these statements to, even though they might have broader applicability), it's unreasonable to expect that every light bulb (light fixture) is going to carry the silicon to handle authentication (and/or encryption). I think it makes sense to consider a boundary (firewall+ALG) that defines a "trusted zone" within the house, establishes ACLs for a given "connection", be it a tunnel or otherwise, defined by an authentication event, and mediates the activity over that connection as long as it's active. Treating each and every action into that trusted zone as a separate request, carrying separate overhead for connection setup and teardown (over the WAN), and separate overhad for authentication and encryption puts us in the same boat as HTTP/1.0. I'm not saying we should consider anything other than IP to establish the desired endpoints of the given transacion. I'm not saying we should try to hide topology and addressing behind a NAT. I'm saying that even *with* a connection that's end-to-end for the purposes of designating participants, we might want to consider that someone in the middle will be mediating the conversation, acting on behalf of one or both participants. An example to wit: I want to be able to plug my Extend-A-Home 2000 (tm) intelligent brick into the ethernet jack in my hotel room, then unpack all the rest of my goodies (portable printer, portable scanner, wireless IP phone, Palm Connected Organizer(tm), MP3 player, etc.) and have them "just work". Now, I realize that all of this can be accomplished through a combination of DHCP, DDNS, and IP Mobility. But that requires an awful lot of complexity in each device, when that complexity *could* be hidden inside the Extend-A-Home 2000 (tm). I plug it in and *voila*, my hotel room is an extension of my home. All of my permissions into my home remain intact (with only an authentication exchange between the Extend-A-Home 2000 and the Home-Weiller 2000 Border Establishment Unit(tm)). You also have to consider that just because IP is the "right" answer doesn't mean it's what will end up in the stacks of all of these micro devices (especially light bulbs). There will be gateways and proxies for LON and CANbus and X-10 and so forth for a while to come, possibly forever. All I'm saying is that taking ALGs into account for reasons *other* than NAT doesn't seem like such a bad idea as we're doing new work. -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "There are plenty of things out there that people should be offended about. Put your indignation into some more productive and appropriate fight." - Larry Rosensweig in http://www.cnn.com/1999/US/12/03/pokemon.swastika.ap/index.html
Citation bug in RFC 2425
I couldn't find a "search" function in the offical archives, so I don't know if this has been brought up before. Apologies if it has. RFC 2425 cites as [VCARD], "Internet Mail Consortium, 'vCar - The Electronic Business Card', Version 2.1, http://www.imc.com/pdi/vcard-21.txt" The correct URL appears to be http://www.imc.org/pdi/vcard-21.txt (.org instead of .com). -- Tripp Lilley * [EMAIL PROTECTED] * http://stargate.sg505.net/~tlilley/ -- "Honestly, Baldric, sometimes I feel like a pelican. Whichever way I turn, I've still got an enormous bill in front of me." - Edmund Blackadder, "Amy and Amiability"
