sprintsvc.com mailops contact please?
As the subject says. Please email me offlist regards -srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: DHCP and aliases
I am using a FreeBSD 4.11 IPFW firewall on a ADSL connection. Is there a better way to allow this internal machine to have its own IP but still be firewalled? But then if I am doing this, am I really firewalling anything anyway if all of the ports are redirected to the internal machine anyway? More specifics on getting an answer to your support issue is on http://www.freebsd.org/support.html under the heading Mailing Lists.
mobile user strawman argument
Directed at no specific person because I've seen several people use it in their examples recently... I'm seeing alot of arguments in the form of I have mobile users and they aren't going to be able to send email if you use injection IP mail filtering approach X (where X is SPF, MX+, or what have you); which take the same form as the arguments people made against closing open relays. For those that don't remember, prior to around 1995 or so most all mail servers would relay may for anybody by default. People that got tired of being abused made it so only their customers could use their mail servers to relay mail by methods such as: POP AUTH, only relaying mail for their customer IPs, only accepting mail to be relayed from domains that were hosted on that server, etc. At that time some people swore up and down it was unworkable because all of their mobile users wouldn't be able to send mail using their mail servers because the remote users use random dynamic IPs from all over the Internet. After a large amount of gnashing of teeth and whining, and the spread of knowhow of the several different methods to close an open server yet still allow your users to send mail, these objections were overcome and the open relays were closed. Ok... fast forward to the present in which we can now assert that service providers don't use open relays to provide service to their customers. So now I'm supposed to believe that its impossible for service providers to coordinate which mail server a user is supposed to use to send their mail through (with the information about authorized sending IPs for a domain communicated to receipient SMTP servers according to the method of your choice) when they already force their users to use only SMTP servers that they have authorized access to relay through. Ya, ya, ya... you are going to say 1) its impossible to get people to use designated servers for outgoing email. Or you will say 2) even if you do this there will still be *spam*! (egads shock horrror!) Ugh please. 1) Getting customers to use designated servers is already done and standard operating procedure. 2) Most people would agree that closing the open relays as they were was worthwhile and a sound security decision. The fact that spam still exists doesn't make the decision wrong, it just means that you should not be so naive or disingenuous as to expect various limited practical precautions to solve all the world's spam problems. So much deja vu I feel like I'm on a merry-go-round. Mike. +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: ISP phishing
On Wed, 29 Jun 2005, Brad Knowles wrote: SPF is not a panacea. In fact, it is pretty much totally worthless, unless you are the sole owner of a given domain and you can guarantee that all mail you ever send will always be routed through the machines that you own and control, and you know that you don't ever forward e-mail for any of your other accounts. Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
Re: mobile user strawman argument
On 29/06/05, Mike Leber [EMAIL PROTECTED] wrote: I'm seeing alot of arguments in the form of I have mobile users and they aren't going to be able to send email if you use injection IP mail filtering approach X (where X is SPF, MX+, or what have you); which take the same form as the arguments people made against closing open relays. So, try to authorize the sending host rather than the path (mail from / sender etc) You neatly work around that problem
Re: ISP phishing
On Wed, 29 Jun 2005, Tony Finch wrote: On Wed, 29 Jun 2005, Brad Knowles wrote: SPF is not a panacea. In fact, it is pretty much totally worthless, unless you are the sole owner of a given domain and you can guarantee that all mail you ever send will always be routed through the machines that you own and control, and you know that you don't ever forward e-mail for any of your other accounts. See my other email in regards to this mobile user strawman argument. Look in the archives for the same arguments against closing open relays. Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. This is incorrect. SPF is an inbound filter. This is in the recipients control, not yours. Assume you send email to [EMAIL PROTECTED] and Alice forwards that email address to [EMAIL PROTECTED] If the inbound mail server for alumni.miskatonic.edu has SPF or MX+ enabled for [EMAIL PROTECTED] and and you pass the test and your mail is accepted by alumni.miskatonic.edu then that is the end of your responsibility. If Alice then decides to forward to [EMAIL PROTECTED] and Alice wishes to use SPF or MX+ for the mailbox [EMAIL PROTECTED] as well then Alice would whitelist the IP of the outbound mail server for alumni.miskatonic.edu. You don't have control over what forwarding, filtering, or whitelisting Alice does with her personal mailbox. If Alice wants to forward [EMAIL PROTECTED] to [EMAIL PROTECTED] and use SPF or MX+ with [EMAIL PROTECTED] presumably she won't block email from her other account and she can check if she got it right really easy by sending email to [EMAIL PROTECTED] +- H U R R I C A N E - E L E C T R I C -+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: ISP phishing
On 29/06/05, Mike Leber [EMAIL PROTECTED] wrote: You don't have control over what forwarding, filtering, or whitelisting Alice does with her personal mailbox. Actually Alice doesnt have control over her ISP who believes that kool aid about path authentication being a silver bullet and rejects wholesale based on spf failures (sometimes treating ~all or ?all as equivalent to -all) -srs
Re: ISP phishing
On Wed, 29 Jun 2005, Mike Leber wrote: See my other email in regards to this mobile user strawman argument. Look in the archives for the same arguments against closing open relays. Current mobile-user arguments against SPF do indeed remind of the anti open-relay battles 5-8 years ago. Not only that but often enough its the same people who are doing this arguing ... (just look at the main ietf mail list and you'll see what I mean). If Alice wants to forward [EMAIL PROTECTED] to [EMAIL PROTECTED] and use SPF or MX+ with [EMAIL PROTECTED] presumably she won't block email from her other account and she can check if she got it right really easy by sending email to [EMAIL PROTECTED] Unfortunately per-user filters for SMTP transmission are notoriously difficult to implement (especially on large scale). Plus you may not be able to say that email came in forwarded just from SMTP transmission (forwarders often do not leave its own marker, you can try to identify forwarder by EHLO name but that may not be forwarder by some kind of outbound relay server on the forwarding network site). Another issue is that are doing the forwarding are the ones that are most often least maintained as far as upgrading software and enabling new SMTP features. As a result an idea that we will ask all forwarders to change and identify themselves in forwarded mail can not happen as quickly as path authentication proponents want. Now I did propose one solution to this - a way to bypass forwarders by having origin mail servers add crypto signatures with their own hostname serving as base and then tie in further path authentication to cryptographically verified hostname (see paper, I previously posted, quick link at http://purl.org/NET/pacap), and I have more hope in another system that I'll get to later this year. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: ISP phishing
Tony Finch [EMAIL PROTECTED] wrote: [...] Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. How do you figure that? The failure mode in this case is if somebody arranges dumb mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail. The problem is quite clearly of the recipient's making rather than any fault of the sender's. -- When I told the people of Northern Ireland that I was an atheist, a woman in the audience stood up and said, 'Yes, but is it the God of the Catholics or the God of the Protestants in whom you don't believe? - Quentin Crisp
Re: ISP phishing
Suresh Ramasubramanian [EMAIL PROTECTED] wrote: [...] Actually Alice doesnt have control over her ISP who believes that kool aid about path authentication being a silver bullet and rejects wholesale based on spf failures (sometimes treating ~all or ?all as equivalent to -all) Sure Alice has control. Last week, I told my ISP where to stick their shoddy service and took my business elsewhere. -- PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key Please contribute to the beer fund and a tidier house: http://search.ebay.co.uk/_W0QQfgtpZ1QQfrppZ25QQsassZpndc
Re: ISP phishing
On 29/06/05, william(at)elan.net [EMAIL PROTECTED] wrote: Another issue is that are doing the forwarding are the ones that are most often least maintained as far as upgrading software and enabling new SMTP features. As a result an idea that we will ask all forwarders to change and identify themselves in forwarded mail can not happen as quickly as path authentication proponents want. Please name a few names on just who is not enabling new smtp features And what smtp features you'd like enabled. RFC 2822 / ESMTP hasnt changed all that much, and then there's SES, which if you call an SMTP feature, I'd beg to differ on that ..
Re: ISP phishing
On Wed, 29 Jun 2005, Peter Corlett wrote: Tony Finch [EMAIL PROTECTED] wrote: [...] Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. How do you figure that? The failure mode in this case is if somebody arranges dumb mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail. The problem is quite clearly of the recipient's making rather than any fault of the sender's. Most forwarding services do nothing but change the envelope recipient address, and this has been standard practice for many many years. Sites that do SPF checking on incoming email must take this into account if their users forward email from elsewhere. However most sites do not do so, partly because the SPF documentation doesn't make it clear that they must, and partly because it's basically impossible - for every user that forwards email to your site you must whitelist the IP addresses of the forwarding mail servers, and you can't find out what those IP addresses are or when they change. So if a site that checks SPF can't work around the forwarding problem, can a site that publishes SPF? No, because a sender at a publishing site can't find out if a recipient is suffering from this breakage. The only solution is for the SPF checking recipient site to make it clear to their users that they must not forward email from elsewhere. However most sites do not do this. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
Re: ISP phishing
On Wed, 29 Jun 2005, Suresh Ramasubramanian wrote: On 29/06/05, william(at)elan.net [EMAIL PROTECTED] wrote: Another issue is that are doing the forwarding are the ones that are most often least maintained as far as upgrading software and enabling new SMTP features. As a result an idea that we will ask all forwarders to change and identify themselves in forwarded mail can not happen as quickly as path authentication proponents want. Please name a few names on just who is not enabling new smtp features And what smtp features you'd like enabled. RFC 2822 / ESMTP hasnt changed all that much, and then there's SES, which if you call an SMTP feature, I'd beg to differ on that .. DSN are not supported and that is important as far as forwarding goes. 8BITMIME and BINARYMIME are rarely supported. Also don't confuse SES with SRS. SES is specification of crypt signatures in RFC2821 MAILFROM and should not be added by forwarders. As to who, I don't want to put names but many (I'd go as far as to say majority, but we'd need statistical study) university forwarding servers for alumni forwarding run smtp software 5+ years old (they don't really need much more then just to look at aliases of forwarding db and send email further - once setup this system works for long time). Many small companies with email forwarding setup forwarding setup for few old employers or for subdivisions they previously bought also have problems. BTW - I happened to know person who has setup email forwarding for his department in major university in st.louis on sparc2 12 years ago. It is still working as far as I know! Last mail software update on it I believe was made 5 or 6 years ago when open relaying was disabled. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: ISP phishing
On Wed, 29 Jun 2005, Peter Corlett wrote: Actually, what you have to guarantee is that you never send email to anyone who forwards their email elsewhere. This is impossible. How do you figure that? The failure mode in this case is if somebody arranges dumb mail forwarding that doesn't do envelope rewriting, and also applies a SPF filter on their incoming mail. Actually, that's not quite right. The failure mode is if someone arranges no-rewrite mail forwarding, and mail is sent through that forwarding host from a domain with a published SPF record ending in -all. Or, to put it in steps: 1. [EMAIL PROTECTED] sends a mail to [EMAIL PROTECTED] one.example.com has a SPF record ending in -all, but the mail at this point is coming from a SPF-pass host. 2. [EMAIL PROTECTED] is a dumb forward to [EMAIL PROTECTED] The mail from [EMAIL PROTECTED] is now coming from an SPF-fail host. 3. [EMAIL PROTECTED] has SPF filtering turned on. It receives the mail attempt from [EMAIL PROTECTED], but the SPF test fails authoritatively. The mail is blocked. This is the single external dependency problem with SPF, such that forwarding accounts that do not employ SRS or similar botch the whole scheme. As a result, many end hosts have started putting in local SPF exceptions for some forwarding hosts that do not implement sender rewriting. However, many popular forwarding account systems (particularly large ones like pobox.com and mail.com) have awakened to the failure mode in step 2. These hosts have either implemented SRS, or changed the envelope-from on forwarded mail to be something like the forwarding account itself (with loop detection) or [EMAIL PROTECTED] -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ATM
I plan to design a hub and spoke WAN using ATM. The data traversing the WAN is US equities market data. Market data can be in two flavors multicast and TCP client/server. Another facet of market data is it is bursty in nature and is very sensitive to packet loss and latency (like voice). What type of ATM AAL format would be best for this topology? Is there any other concerns I should be aware of. Thx, Philip __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
VoIP-in-a-can: Sysco IP Phone Model TC-04 by BubbaTel
Sorry. Couldn't resist a little humor. :-) http://www.boingboing.net/2005/06/28/voipinacan_sysco_ip_.html - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: VoIP-in-a-can: Sysco IP Phone Model TC-04 by BubbaTel
At 03:08 PM 29-06-05 +, Fergie (Paul Ferguson) wrote: Sorry. Couldn't resist a little humor. :-) http://www.boingboing.net/2005/06/28/voipinacan_sysco_ip_.html Now all they need to do is use the WiFi Speed Spray: http://www.j-walk.com/other/wifispray/index.htm I'm sure some clever startup will manage to meld these two wonderful products. -Hank - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/ +++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Re: ISP phishing
On 29/06/05, william(at)elan.net [EMAIL PROTECTED] wrote: BTW - I happened to know person who has setup email forwarding for his department in major university in st.louis on sparc2 12 years ago. It is still working as far as I know! Last mail software update on it I believe was made 5 or 6 years ago when open relaying was disabled. We dont do sender rewriting / envelope rewriting for forwarded email, just pass it on We'll prepend Resent: headers though .. that should be enough But well, we run linux and postfix, and a reasonably recent (non bleeding edge) version of both. We're not running on sendmail 8.8.8 or whatever your university department friend was running, I assure you -- Suresh Ramasubramanian ([EMAIL PROTECTED])
FCC to probe DSL regulations
Via Red Herring: Now that the U.S. Supreme Court has upheld the cable operatorsÂ’ right to bar competitors from their lines, the U.S. Federal Communications Commission is taking up the obvious question of whether the same rules should apply to telephone companies that sell DSL service. http://www.redherring.com/article.aspx?a=12580 - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: ISP phishing
On Wed, 29 Jun 2005, Suresh Ramasubramanian wrote: We dont do sender rewriting / envelope rewriting for forwarded email, just pass it on We'll prepend Resent: headers though .. that should be enough That's not permitted by RFC 2822 and it'll cause interoperability problems with software that only implements RFC 822 Resent- semantics (only one group of Resent- fields). AFAIK most software that understands Resent- fields does not understand RFC 2822 multiple Resent- groups. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD.
Cisco Security Advisory: RADIUS Authentication Bypass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cisco Security Advisory: RADIUS Authentication Bypass Revision 1.0 For Public Release 2005 June 29 1600 UTC - -- Contents Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: FINAL Distribution Revision History Cisco Security Procedures - -- Summary === Remote Authentication Dial In User Service (RADIUS) authentication on a device that is running certain versions of Cisco Internetworking Operating System (IOS) and configured with a fallback method to none can be bypassed. Systems that are configured for other authentication methods or that are not configured with a fallback method to none are not affected. Only the systems that are running certain versions of Cisco IOS are affected. Not all configurations using RADIUS and none are vulnerable to this issue. Some configurations using RADIUS, none and an additional method are not affected. Cisco has made free software available to address this vulnerability. There are workarounds available to mitigate the effects of the vulnerability. The vulnerabilities are documented as the following Cisco Bug IDs: * CSCee45312 -- Radius authentication bypass when configured with a none fallback method This advisory will be posted at http://www.cisco.com/warp/public/707/cisco-sa-20050629-aaa.shtml. Affected Products = Vulnerable Products Systems that are running the following release trains of Cisco IOS are affected if configured with RADIUS authentication and a none fallback method. * 12.2T based trains * 12.3 based trains * 12.3T based trains * 12.4 based trains A system configured for RADIUS authentication and none fallback method will have a command line in show running-configuration output which is similar to the following . aaa authentication login xx group radius none (This is an affected configuration) aaa authentication ppp xx group radius none (This is an affected configuration) A system that is configured for RADIUS authentication with local and none fallback methods is also affected. An example to this configuration may look like similar to the following. aaa authentication login xx group radius local none (This is an affected configuration) aaa authentication ppp xx group radius local none (This is an affected configuration) A system is only vulnerable if none method is used as a fallback to RADIUS without any other method in between, or if only local method is used in between. Systems that are configured for RADIUS authentication with a fallback method other than local prior to none method are not affected. Refer to the Details section for more information about affected and unaffected configurations. Products Confirmed Not Vulnerable * Products that are not running Cisco IOS are not affected. * Products running Cisco IOS versions 12.1 and earlier (including 12.0S) and 12.2 mainline are not affected. * Products that are running Cisco IOS are not affected unless they are configured for RADIUS authentication with a fallback method to none. No other Cisco products are currently known to be affected by this vulnerability. Details === Authentication, Authorization, and Accounting (AAA) network security services provide the primary framework through which access control is set up on a device. AAA authentication services are used to control access to different services on a system. Multiple AAA authentication services can be configured on a system to fall back to a backup authentication method in case the primary authentication method is unavailable. AAA authentication can be used for different purposes (controlling access to the routers, authenticating remote subscribers etc.). Refer to the following URL for more information on AAA: http://www.cisco.com/ univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fsaaa/index.htm Remote Authentication Dial In User Service (RADIUS) is defined in RFC2865 and describes a protocol for carrying authentication, authorization, and configuration information. There is a vulnerability in AAA RADIUS authentication if none is used as a fallback method. Sending a sufficiently long username will bypass the RADIUS authentication and succeed. Following algorithm can be used to determine whether a configuration is vulnerable: 1. Are you using an affected version of IOS? No: You are not vulnerable. Yes: Go to step 2. 2. Is AAA RADIUS Authentication used? No: You are not vulnerable. Yes: Go to step 3. 3. Is none used as an alternative to RADIUS? No: You are not vulnerable. Yes: Go to step 4. 4. Is there any other method between RADIUS and none
Re: ISP phishing
On Wed, 29 Jun 2005, Suresh Ramasubramanian wrote: On 29/06/05, william(at)elan.net [EMAIL PROTECTED] wrote: BTW - I happened to know person who has setup email forwarding for his department in major university in st.louis on sparc2 12 years ago. It is still working as far as I know! Last mail software update on it I believe was made 5 or 6 years ago when open relaying was disabled. We dont do sender rewriting / envelope rewriting for forwarded email, just pass it on We'll prepend Resent: headers though .. that should be enough And that would like be against what is specified in RFC2822 as in section 3.6.6 it says: -- Note: Reintroducing a message into the transport system and using resent fields is a different operation from forwarding. Forwarding has two meanings: One sense of forwarding is that a mail reading program can be told by a user to forward a copy of a message to another person, making the forwarded message the body of the new message. A forwarded message in this sense does not appear to have come from the original sender, but is an entirely new message from the forwarder of the message. On the other hand, forwarding is also used to mean when a mail transport program gets a message and forwards it on to a different destination for final delivery. Resent header fields are not intended for use with either type of forwarding. -- You really should not be using Resent- unless this is done from MUA by direct manual action of the user - but use of Resent- by automated MTA process is not ok. But well, we run linux and postfix, and a reasonably recent (non bleeding edge) version of both. We're not running on sendmail 8.8.8 or whatever your university department friend was running, I assure you The point is that there are many systems setup all over the world and people don't realize how many of those small intermediate systems are out there that are not running recent mail software. And because for forwarding systems setup many do not need to do more then relay to pre-defined address from aliases file or database, there is little need to to keep system updated to latest standards and this creates a very big problem as far as getting every forwarding system updated fast with something like SRS. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: FCC to probe DSL regulations
In message [EMAIL PROTECTED], Fergie (Paul Ferguson) writes: Via Red Herring: Now that the U.S. Supreme Court has upheld the cable operatorsÂ’ right to bar c ompetitors from their lines, the U.S. Federal Communications Commission is tak ing up the obvious question of whether the same rules should apply to telephon e companies that sell DSL service. http://www.redherring.com/article.aspx?a=12580 From today's Wall Street Journal: Federal Communications Commission Chairman Kevin Martin plans to act as quickly as possible to change the agency's rules so phone companies won't be required to share their Internet lines with rivals. We'll need to move quickly to establish regulatory parity between telephone companies and cable companies that are providing a broadband service, Mr. Martin said in an interview yesterday, a day after the Supreme Court upheld the FCC's decision to allow cable companies exclusive access to their broadband Internet lines. Telephone companies are currently required to share their digital-subscriber lines, or DSL, for the Internet with rivals but want similar exclusivity. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: ATM
Philip Lavine wrote: I plan to design a hub and spoke WAN using ATM. The data traversing the WAN is US equities market data. Market data can be in two flavors multicast and TCP client/server. Another facet of market data is it is bursty in nature and is very sensitive to packet loss and latency (like voice). What type of ATM AAL format would be best for this topology? Is there any other concerns I should be aware of. Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. (in addition to the fact that you probably posted your question in the wrong forum) Pete
Re: ATM
On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... Pete -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM
On Wed, 29 Jun 2005, Jason Frisvold wrote: On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... look to the private networks luke... Seriously, many large private ATM/Frame networks are transitioning to MPLS networks because the ATM or Frame gear is/was/will-be-shortly EOL/EOS from the vendors. The costs to run these networks don't jibe well with the alternatives. Now, start the discussion on: private network and mpls vpn and oops, hey, that runs over the same routers as that bad-old Internet thing with the haxors and such! :)
Re: FCC to probe DSL regulations
On Wed, 29 Jun 2005, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Fergie (Paul Ferguson) writes: Commission is tak ing up the obvious question of whether the same rules should apply to telephon e companies that sell DSL service. http://www.redherring.com/article.aspx?a=12580 From today's Wall Street Journal: Federal Communications Commission Chairman Kevin Martin plans to act as quickly as possible to change the agency's rules so phone companies won't be required to share their Internet lines with rivals. We'll need to move quickly to establish regulatory parity between telephone companies and cable companies that are providing a broadband service, Mr. Martin said in an interview yesterday, a day after the now, where is that trenching tool again??
RE: ATM
Well, also keep in mind that pure ATM/FR is becoming more and more of an edge service, where it is actually transported as MPLS in the core. Thus, an MPLS VPN does make more sense in some cases (why would I want to take a beating on cell tax if I don't have to?) -Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Frisvold Sent: Wednesday, June 29, 2005 10:19 AM To: Petri Helenius Cc: Philip Lavine; nanog Subject: Re: ATM On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... Pete -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM
On 6/29/05, Randy Bush [EMAIL PROTECTED] wrote: indeed! i use them often. remember when you had to go into the bank and wait in a queue for a teller? Hopefully soon to be replaced with RFID machines with voice activated commands.. :) Speaking of which.. It's 2005.. Where's my flying car? randy -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
Re: ATM
On 6/29/05, Christopher L. Morrow [EMAIL PROTECTED] wrote: look to the private networks luke... Seriously, many large private ATM/Frame networks are transitioning to MPLS networks because the ATM or Frame gear is/was/will-be-shortly EOL/EOS from the vendors. The costs to run these networks don't jibe well with the alternatives. I figured MPLS was going to be the answer.. :) Now I must learn, research, implement, and debug! :) Now, start the discussion on: private network and mpls vpn and oops, hey, that runs over the same routers as that bad-old Internet thing with the haxors and such! Heh... :) -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
RE: ATM
Most MPLS networks use a combination of point to point, frame and ATM facilities as the infrastructure. The phone companies use ATM just about everywhere to deliver voice across their networks. I don't see ATM/FR equipment being EOL'd anytime in the near future. James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L. Morrow Sent: Wednesday, June 29, 2005 10:25 AM To: Jason Frisvold Cc: Petri Helenius; Philip Lavine; nanog Subject: Re: ATM On Wed, 29 Jun 2005, Jason Frisvold wrote: On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... look to the private networks luke... Seriously, many large private ATM/Frame networks are transitioning to MPLS networks because the ATM or Frame gear is/was/will-be-shortly EOL/EOS from the vendors. The costs to run these networks don't jibe well with the alternatives. Now, start the discussion on: private network and mpls vpn and oops, hey, that runs over the same routers as that bad-old Internet thing with the haxors and such! :)
Re: ATM
ATM is a great technology. indeed! i use them often. remember when you had to go into the bank and wait in a queue for a teller? When FIX-East was in College Park (Maryland), FIX-E was in an building NSI (as in NASA Science Internet) labelled the Maryland National Bank building. It appeared on all the network map slides. QA time - Why have you hooked up a bank building? Because of ATM What does that get you? It's how we get our funding from HQ. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.
colo price matrix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Just wondering if anyone has any links and /or price matrix for colos? Any pointers will be appreciated. regards, /vicky -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwt+ypbZvCIJx1bcRAotTAJ0f17A0qfo+ysueR3GRpB4+yCXmXgCZAczY fRVgNFEOB3oUiP3KBt9p3hk= =AdGf -END PGP SIGNATURE-
Re: ATM
On Wed, Jun 29, 2005 at 01:33:14PM -0400, Jason Frisvold wrote: On 6/29/05, Randy Bush [EMAIL PROTECTED] wrote: indeed! i use them often. remember when you had to go into the bank and wait in a queue for a teller? Hopefully soon to be replaced with RFID machines with voice activated commands.. :) Speaking of which.. It's 2005.. Where's my flying car? randy -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED] your flying car awaits http://www.moller.com/skycar/ --bill
Re: colo price matrix
[EMAIL PROTECTED] (Vicky Rode) writes: Just wondering if anyone has any links and /or price matrix for colos? Any pointers will be appreciated. at the very low end, there's http://www.vix.com/personalcolo/. i've thus far resisted several tempting requests to generalize this to the ixp, hosting, on-net, and transit markets. -- Paul Vixie
RE: ATM
EOL? What do you mean EOL? Come Again? What you say? Phone companies EOL stuff? ;-) Just because it's not EOL, doesn't mean you can't do better either. Rather than saying I want this type of MAC technology and posting it (as a troll) to a forum concerned primarily with IP operations, one should probably step back and worry about what you're trying to accomplish. Mentioning ATM (and saying you want it for IP QoS) on NANOG is in my book much like screaming Fire! or Free beer! in a crowded place. ;) Ah, nice to see how the NANOG Chain(TM) can still be yanked quite easily. ;).. Define the problem you're trying to solve. Assess the tool chest. Implement. Observe. Rinse. Repeat. Best regards, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Laszko Sent: Wednesday, June 29, 2005 1:34 PM To: Christopher L. Morrow; Jason Frisvold Cc: Petri Helenius; Philip Lavine; nanog Subject: RE: ATM Most MPLS networks use a combination of point to point, frame and ATM facilities as the infrastructure. The phone companies use ATM just about everywhere to deliver voice across their networks. I don't see ATM/FR equipment being EOL'd anytime in the near future. James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L. Morrow Sent: Wednesday, June 29, 2005 10:25 AM To: Jason Frisvold Cc: Petri Helenius; Philip Lavine; nanog Subject: Re: ATM On Wed, 29 Jun 2005, Jason Frisvold wrote: On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... look to the private networks luke... Seriously, many large private ATM/Frame networks are transitioning to MPLS networks because the ATM or Frame gear is/was/will-be-shortly EOL/EOS from the vendors. The costs to run these networks don't jibe well with the alternatives. Now, start the discussion on: private network and mpls vpn and oops, hey, that runs over the same routers as that bad-old Internet thing with the haxors and such! :) * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 118
RE: ATM
On Wed, 29 Jun 2005, James Laszko wrote: Most MPLS networks use a combination of point to point, frame and ATM facilities as the infrastructure. The phone companies use ATM just about everywhere to deliver voice across their networks. I don't see ATM/FR equipment being EOL'd anytime in the near future. really, that is interesting. James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher L. Morrow Sent: Wednesday, June 29, 2005 10:25 AM To: Jason Frisvold Cc: Petri Helenius; Philip Lavine; nanog Subject: Re: ATM On Wed, 29 Jun 2005, Jason Frisvold wrote: On 6/29/05, Petri Helenius [EMAIL PROTECTED] wrote: Maybe the small fact that ATM is fading away and building new networks with technology going away is going to explode your operational cost in a few years time. Business grade IP networks will provide you with equal if not better performance than a dedicated ATM WAN. And being replaced with ? GigE? DPT/RPR? MPLS? ATM is a great technology... Unfortunately, I don't think it was ever fully utilized.. From what I understand, MPLS takes some of the good bits and combines it with traditional routing.. But I don't see a lot of MPLS implementations either... look to the private networks luke... Seriously, many large private ATM/Frame networks are transitioning to MPLS networks because the ATM or Frame gear is/was/will-be-shortly EOL/EOS from the vendors. The costs to run these networks don't jibe well with the alternatives. Now, start the discussion on: private network and mpls vpn and oops, hey, that runs over the same routers as that bad-old Internet thing with the haxors and such! :)
Re: ATM
Thus spake James Laszko [EMAIL PROTECTED] Most MPLS networks use a combination of point to point, frame and ATM facilities as the infrastructure. The phone companies use ATM just about everywhere to deliver voice across their networks. Some may. I know of at least one that moves all their LD voice traffic via VoIP on a private POS/MPLS network. Most won't admit one way or the other unless you're under NDA and have a need to know. Getting back to the OP's question, I'd rather build a new private network via carriers' MPLS (e.g. TLS) offerings. The ATM cell tax, as well as the high cost of interfaces (compared to either POS or Ethernet), is simply not worth the supposed benefits. You'll get equally bad service regardless of the technology chosen -- spend your money on getting them to manage the CPE (no finger-pointing) and better SLAs (you'll at least get money back when, not if, you have problems). I don't see ATM/FR equipment being EOL'd anytime in the near future. I think talking about EOS/EOL is jumping the gun, but most of it hasn't seen any new development (or speed increases) in quite a while. The telcos are going to milk that sunk investment for as long as customers are willing to pay for it, and the vendors are happy to sell them replacement cards, but few if any people are designing new ATM cards or new ATM networks. FR will live on long after ATM is dead and gone because it fits a distinct customer demand (cheap, simple, and very slow) with no reasonable replacement. S Stephen Sprunk Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do. K5SSS --Isaac Asimov
RE: ATM
On Wed, 29 Jun 2005, James Laszko wrote: Most MPLS networks use a combination of point to point, frame and ATM facilities as the infrastructure. The phone companies use ATM just about everywhere to deliver voice across their networks. I don't see ATM/FR equipment being EOL'd anytime in the near future. really, that is interesting. Thanks. I just snorted my soda. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163
Re: colo price matrix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 this is a good start for me...i'll take it from here :-) regards, /vicky Paul Vixie wrote: | [EMAIL PROTECTED] (Vicky Rode) writes: | | |Just wondering if anyone has any links and /or price matrix for colos? | |Any pointers will be appreciated. | | | at the very low end, there's http://www.vix.com/personalcolo/. i've thus | far resisted several tempting requests to generalize this to the ixp, hosting, | on-net, and transit markets. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwv9hpbZvCIJx1bcRAj9yAJ48B8jE0Dj0ZrA0SWSLAPU+alGyvACg+GNc axeob2iSVglMu3ADcMhltjo= =iBbi -END PGP SIGNATURE-
IESG statement on e-mail authentication drafts
Okay. Gasoline, fire, etc. Article: Antispam proposals advance http://news.com.com/Antispam+proposals+advance/2100-1032_3-5768498.html IESG announcements: Document Action: 'Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1' to Experimental RFC https://datatracker.ietf.org/public/recent_announcement.cgi?command=show_detailballot_id=1599 Document Action: 'SMTP Service Extension for Indicating the Responsible Submitter of an E-mail Message' to Experimental RFC https://datatracker.ietf.org/public/recent_announcement.cgi?command=show_detailballot_id=1573 Most appropriate comment (from the IESG): While many proposals for domain-based authorization have been under consideration, no consensus has yet been reached concerning a single technical approach, the IESG said in a statement. The IESG does not endorse either of the two mechanisms documented in the experimental RFCs--their publication is intended to encourage further discussion and experimentation in order to gain experience that can be used to write future standards in this space. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Is my BIND Server's Cache Poisioned ?
Hi, I met a strange problem with my cache server, which runs BIND9.3.1. In past days, our customers complaint that three domain names (www.hangzhou.gov.cn, www.zpepc.com.cn) could not be resolved frequently. I checked on the cache server and found, when the cache server could not resolve www.hangzhou.gov.cn (www.zpepc.com.cn) I can solve the problem by running rndc flush. The debugging output of named process has the following output when it could not resolve www.hangzhou.gov.cn. Do that mean my cache server is poisioned for these two domain name? === 24-Jun-2005 19:02:00.015 client 202.101.172.148#32769: UDP request 24-Jun-2005 19:02:00.026 client 202.101.172.148#32769: view internal-in: request is not signed 24-Jun-2005 19:02:00.026 client 202.101.172.148#32769: view internal-in: recursion available 24-Jun-2005 19:02:00.026 client 202.101.172.148#32769: view internal-in: query 24-Jun-2005 19:02:00.026 client 202.101.172.148#32769: view internal-in: query (cache) 'www.hangzhou.gov.cn/A/I N' approved 24-Jun-2005 19:02:00.026 client 202.101.172.148#32769: view internal-in: replace 24-Jun-2005 19:02:00.026 clientmgr @2addf8: createclients 24-Jun-2005 19:02:00.026 clientmgr @2addf8: create new 24-Jun-2005 19:02:00.026 client @3c19f28: create 24-Jun-2005 19:02:00.026 createfetch: www.hangzhou.gov.cn A 24-Jun-2005 19:02:00.026 client @3c19f28: udprecv 24-Jun-2005 19:02:00.026 fctx 37ad318(www.hangzhou.gov.cn/A'): create 24-Jun-2005 19:02:00.026 fctx 37ad318(www.hangzhou.gov.cn/A'): join 24-Jun-2005 19:02:00.026 fetch 2739250 (fctx 37ad318(www.hangzhou.gov.cn/A)): created 24-Jun-2005 19:02:00.026 fctx 37ad318(www.hangzhou.gov.cn/A'): start 24-Jun-2005 19:02:00.026 fctx 37ad318(www.hangzhou.gov.cn/A'): try 24-Jun-2005 19:02:00.026 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelqueries 24-Jun-2005 19:02:00.026 fctx 37ad318(www.hangzhou.gov.cn/A'): getaddresses 24-Jun-2005 19:02:00.027 fctx 37ad318(www.hangzhou.gov.cn/A'): query 24-Jun-2005 19:02:00.027 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): send 24-Jun-2005 19:02:00.027 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): sent 24-Jun-2005 19:02:00.027 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): senddone 24-Jun-2005 19:02:00.049 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): response 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): noanswer_response 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): cache_message 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelquery 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelqueries 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): try 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelqueries 24-Jun-2005 19:02:00.049 fctx 37ad318(www.hangzhou.gov.cn/A'): getaddresses 24-Jun-2005 19:02:00.050 fctx 37ad318(www.hangzhou.gov.cn/A'): query 24-Jun-2005 19:02:00.050 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): send 24-Jun-2005 19:02:00.050 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): sent 24-Jun-2005 19:02:00.050 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): senddone 36 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): noanswer_response 37 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): cache_message 38 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelquery 39 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelqueries 40 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): try 41 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelqueries 42 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): getaddresses 43 24-Jun-2005 19:02:00.052 fctx 37ad318(www.hangzhou.gov.cn/A'): query 44 24-Jun-2005 19:02:00.052 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): send 45 24-Jun-2005 19:02:00.053 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): sent 46 24-Jun-2005 19:02:00.053 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): senddone 47 24-Jun-2005 19:02:00.054 resquery 74b4870 (fctx 37ad318(www.hangzhou.gov.cn/A)): response 48 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): answer_response 49 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): cache_message 50 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): clone_results 51 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelquery 52 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): done 53 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): stopeverything 54 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): cancelqueries 55 24-Jun-2005 19:02:00.054 fctx 37ad318(www.hangzhou.gov.cn/A'): sendevents 56 24-Jun-2005 19:02:00.054 fetch 2739250 (fctx 37ad318(www.hangzhou.gov.cn/A)):
Re: Is my BIND Server's Cache Poisioned ?
i On Thu, 30 Jun 2005, Mark Andrews wrote: No. These are just a mis-configured zones. hangzhou.gov.cn only has glue records for the nameservers. zpepc.com.cn has CNAMEs for the nameservers. Both of these misconfigurations are visible to nameservers that are IPv6 aware. Nameservers that are not IPv6 aware are not likely to make the queries that make these misconfigurations visible. Why would these dns misconfigurations be visible only to IPV6-aware servers? Because IPv6 aware nameservers make queries for the IPv6 addresses of the nameservers and as a result see the NXDOMAIN / CNAME. The IPv4 only nameservers don't make these queries, as a matter of practice, and only see the problems if some client of the nameserver makes a query for some records with the same name as that of the nameservers. Mark -- William Leibzon Elan Networks [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
