Re: DNS cache poisoning attacks -- are they real?
* Brad Knowles: At 1:08 PM +0200 2005-03-29, Florian Weimer wrote: BIND accepts non-authoritative answers if their additional section looks a bit like a referral. I don't tink that this check is deliberately lax, but stricter checks are simply harder to do on this particular code path. BIND explicitly assumes that there might be upstream nameservers you may talk to that may be answering from cache. Really? I can't get it to work reliably. Can you share an example where delegation to a non-authoritative caching resolver works, without the need for special seeding of the caching resolver? Your posts to nanog@merit.edu aren't distributed by the mailing list, BTW.
Re: DNS cache poisoning attacks -- are they real?
Florian Weimer wrote: * Joe Maimon: How do spammers make step 5 succeed? They delegate www.example.com instead of example.com? I suspect I am some distance over the cliff here but nevertheless, onward. I dont get it. That has nothing to do with the registrar, or dodging forced deactivation of a domain. All it does is make it appear to anti-spammers that www.example.com nameservers are the seeded resolvers. Thats not quite the described problem in the URL that chris included. http://cert.uni-stuttgart.de/archive/bugtraq/2003/09/msg00164.html Next the spammer goes back to their registry authority and changes their authoritative name servers to be the recursive name servers they populated in the last step. Since it appears that registry authorities no longer validate if a customer has permission to use the name server they specify (note that this used to be done way back when domain names were free), the record is quickly updated and users on the Internet are directed to this populated name server when querying information about the spammer's domain. The spammer is now free to push out their spam and if the Internet community decides to attack, the name server being attacked actually belongs to someone else. SO if the extent of the problem is that the victim nameserver may become blocklisted/attacked due to its apparent hosting of a spam URL, than the answer is that anti-spammers need to be a whole lot more carefull at which nameservers they direct their ire at. Specifically, they need to confine that to only certain trustworthy points in the delegation, such as delegation for .com. and .co.uk. but not any deeper. IF the concern is that spammers may try to have their spamsite records survive example.com termination, thats quite possible to attempt doing without bothering to directly attempt to seed any other resolvers cache, all they need are their trojan pcs to host the domain and to hand out NS/A records with very large TTL values. SURBL and others will helpfully prime the resolvers all over the world. Its quite possible that going after the DNS for spammers may not/should not be the quick fix to abusive spam that people would hope for. If all this activity is confined to domain names that they have originally registered and paid for and belonged to them, I might find it quite reasonable declaring this to be strictly a registrar problem. And a resolver ought to be able to tell that www.example.com delegation is lame.
Vonage Hits ISP Resistance
Intersting article on ISP issues regarding competitive VoIP services: http://www.lightreading.com/document.asp?site=lightreadingdoc_id=71020 - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]
In a message written on Tue, Mar 29, 2005 at 02:27:56PM -0600, John Dupuy wrote:
I was looking at it from a route announcement point of view. Transit is
where AS A advertises full routes to AS B. Thus, AS B is getting transit
from A. Peering is where A B only advertise their network and, possibly,
the networks that stub or purchase transit from them.
This is oversimplistic. Transit does not have to be full routes.
Don't confuse the business case with the technical configuration.
That is, all combinations of:
{paid,settlement free}-{customer routes only, full routes, no routes,
you leak mine, I leak yours}
exist. Some are more common than others. Sometimes multiple
combinations exist between the same two parties.
It is my understanding that the top ISPs trade transit. They provide full
routes to each other without payment, regardless of how or where the route
was learned from. They are willing to pass some traffic without
compensation because it makes for better connectivity. From an announcement
POV they are not peering.
The top of the food chain is a full mesh of customer routes only.
I have never seen anyone at the top of the food chain trade full
routing tables, something that would likely be obvious from time
to time in various outage scenarios. There is no business case to
provide free transit on that level. It would be too easily abused.
That's not limited to top ISP's either. Full tables are not done
on a peering level, ever. If anything wonky is being done it's
done with selective leaking of routes in one or both directions,
never ever ever with a full table.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp8b8FCskV7P.pgp
Description: PGP signature
MD5 for TCP/BGP Sessions
NANOG, I'm currently writing a paper for submission, as part of a MSc in Data Communications, and would appreciate if anyone could update me as to the implementation of MD5 for TCP authentication in BGP. Following the alerts last year: http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml http://www.us-cert.gov/cas/techalerts/TA04-111A.html http://www.cisco.com/en/US/products/products_security_advisory09186a00803be7 d9.shtml http://www.foundrynet.com/solutions/security/TCP_Vulnerability_v1_3.pdf http://www.kb.cert.org/vuls/id/415294 http://isc.sans.org/diary.php?date=2004-04-20 What has been the general effect in the ISP/Enterprise community following the warnings? - Have people applied MD5? - If not what other technologies were implemented (IPSec AH transport mode for BGP sessions/ACL/rate limiting etc)? - Has there been any performance impacts seen since implementation? - Has the support of the BGP environment been increased because of this implementation (What policies regards changing the MD5 keys were implemented)? - Was this seen as a valid fix or a knee-jerk reaction (Having re-read the exchanges on NANOG regards the actual mathematical probability of generating this attack, what did the ISP community actually do (compared to what the academic/vendor community were suggesting)? Whilst I've had some response from bgp-info and bgp-security, it's not really been sufficient to draw any real conclusions. From your knowledge and experience are you aware, either internally or with customers the take up of MD5 implementations and had anyone actually suffered an attack prior to implementation Please do not supply confidential information or anything that would be commercially sensitive, if you want to contact me off-line or from a private account please do Yours Doug Legge MDC Student Kingston University London /UK
Re: Re: T1 vs. T2 [WAS: Apology: [Tier-2 reachability and multihoming]]
[EMAIL PROTECTED] writes: Again, I'd be interested in hearing from one of the bigger ones on this: UUNet, ATT, Sprint, Level3, QWest If you can't say anything, I understand. You don't need them to say anything - just look at what they are advertising. Are they advertising each other's routes? If not, then they aren't given each other transit.
Re: outage/maintenance window opinion
The event I stated in my first email was an example, not an actual incident. I think from the 30+ emails I have received I have had 2 responses that said I should start my SLA credits and outage minutes from the beginning of the window and the rest that feel the outage minutes start ticking when the planned outage was over... Regarding Change Management procedures, we do have had deadlines for backing out, verification, etc etc. But you are right... luke At 11:59 AM 3/28/2005, Eric Gauthier wrote: Heya, I disagree as this entire event wasn't a planned outage. The planned part was what you intended to do and, if its anything like the maintenance reports that I send and receive, you typically state how long you expect the impact will be and that it will take place within your maintenance window. I'd argue that you should start the clock ticking when the outage first happened and then take off from that whatever you annouced as the impact duration. For example, if you said that the impact would be a ten-minute outage sometime during your window from 2am to 5am and your outage started at 2am, I'd count this as an unplanned outage starting from 2:10am. That's just my $0.02... On another note, you had a 3 hour window and a 6 hour outage. It sounds like someone didn't seriously consider the back out part of your change management planning. You really should have that as part of your process and have a hard deadline within the window after which you revert the network to its previous state. Eric :) Luke Parrish Centurytel Internet Operations 318-330-6661
Re: outage/maintenance window opinion
In this situation we were expecting to be done for the majority of the maintenance window, but yes I see your point. However I block out a 3 hour window for maintenance because the activities I am performing on the network could easily cause a longer service outage than planned as we all know. So if I plan for a 4 hour window but only expect 20 minutes of downtime that actually turns into 3 hours, as long as it is inside the maintenance window specified then it should not go against outage minutes. It was done in the window for a reason... ?? Luke At 02:05 PM 3/28/2005, Pete Templin wrote: Luke Parrish wrote: Trying to get clarification on an issue. Maintenance/outage window is 2:00AM to 5:00AM, during the window the router we are working on fails and does not come back online until 8:00AM. From a outage reporting/documentation standpoint is the outage start time 2:00AM or 5:01AM since 5:01AM is when the maintenance window and planned outage was over... To a small degree, it depends on how long you anticipated the outage to be. Were you expecting a three-hour tour^h^h^h^houtage, or something shorter but opened a big window to give you flexibility on when to do it? I would say that a fifteen-minute expected impact means the outage started at 2:15AM (or fifteen minutes after your work interrupted services). My $0.005, pt Luke Parrish Centurytel Internet Operations 318-330-6661
Re: MD5 for TCP/BGP Sessions
On Wed, 30 Mar 2005 16:50:38 +0100 Doug Legge [EMAIL PROTECTED] wrote: What has been the general effect in the ISP/Enterprise community following the warnings? - Have people applied MD5? Without question more BGP sessions suddenly became 'MD5-enabled' across the net. It has been debated whether this was a necessary or even if it was a good thing. You should find some references, including some on this list where BGP peer sessions were being reconfigured with MD5 applied during the last TCP sequence number scare. - If not what other technologies were implemented (IPSec AH transport mode for BGP sessions/ACL/rate limiting etc)? I don't know of any widespread use of IPsec for BGP sessions even after that last round of alerts, but I am sure some exists. I would be interested in hearing from those that have implemented it in production. ACLs are often used, but vary widely depending on organization. It can be difficult to manage ACLs on a box with a large number of peers that uses many local BGP peering addresses. I'm sure some organizations reviewed and updated their ACLs as a result of the last scare, but that is a local, private decision and it would probably be hard to get good sample of who and what changed. - Has there been any performance impacts seen since implementation? Not real world cases that I've heard, but I believe a number of sites prefer not implement MD5 in part because of the potential performance/DoS issues with it enabled. - Has the support of the BGP environment been increased because of this implementation (What policies regards changing the MD5 keys were implemented)? Not in my case. We use a simple algorithm to come up with the shared secret, then document it in our peering contact database, which is in a secure, internal location that we can reference if we ever need it. In our case it is just relatively simple additional step when configuring or reconfiguring a BGP session. Although I have seen some compatibility issues between platforms. For example, relatively long length passphrases were not properly supported. In my experience, I haven't seen much practice of changing MD5 keys on BGP sessions except when an organization makes major changes or hasn't kept a record of the shared secret during changes. That is probably the most common time it will get changed. I suppose some organizations may change it when employees who knew it leave the organization, but I've not seen much evidence of that. - Was this seen as a valid fix or a knee-jerk reaction (Having re-read the exchanges on NANOG regards the actual mathematical probability of generating this attack, what did the ISP community actually do (compared to what the academic/vendor community were suggesting)? I think that has probably been discussed enough already and will probably be again now so I'll leave it to others to re-hash that. Do note that at least a two specific and related solutions have appeared in the last few years. One is the Generalized TTL Security Mechanism (GTSM) as defined in RFC 3682. It was originally written with BGP in mind, but is also useful for things like MSDP peering. See the RFC for details and why this might be used on BGP sessions. Another is smooth transition between shared secret changes or when applying authentication where none existed. I don't have references handy, but I seem to recall this was still vendor-specific and not fully implemented. Perhaps others will step in with updated info. MD5 can mitigate a risk, but it can come with some operational costs. Some operators prefer one side of the risk equation over the other. Some place a higher weight on one side of the equation than the other depending on the organization and the network. In my experience most will do MD5 if asked and only a small number would actually refuse. Whilst I've had some response from bgp-info and bgp-security, it's not really been sufficient to draw any real conclusions. From your knowledge and experience are you aware, either internally or with customers the take up of MD5 implementations and had anyone actually suffered an attack prior to implementation Not that I'm aware of, but I've almost always used it and other knobs when I could so maybe I just didn't notice? John
drone armies CC report - March/2005
Below is a periodic public report from the drone armies / botnets
research and mitigation mailing list.
For this report it should be noted that we base our analysis on the data
we have accumulated from various sources.
According to our incomplete analysis of information we have thus far, we
now publish two reports.
The ISP's that are most often plagued with botnet CC's (command
control) are, by the order listed:
--
Top 13 with open non-resolved suspect CCs
ASN Responsible Party Unique IPs Open-unresolved
21840 SAGONET-TPA - Sago Networks 31-40 11-15
25761 STAMINUS-COMM - Staminus Commu 16-20 11-15
27595 ATRIVO-AS - Atrivo 6-10 6-10
27654 ASN-NA-MSG-01 - Managed Soluti 6-10 3-5
17676 JPNIC-JP-ASN-BLOCK Japan Netwo 6-10 3-5
16625 LEASEWEB LEASEWEB AS3-5 3-5
4713OCN NTT Communications Corpora 6-10 3-5
8551BEZEQ-INTERNATIONAL-AS Bezeqin 3-5 3-5
13749 EVERYONES-INTERNET - Everyones 3-5 3-5
4766KIXS-AS-KR Korea Telecom6-10 3-5
21788 NOC - Network Operations Cente 6-10 3-5
13301 UNITEDCOLO-AS Autonomous Syste 3-5 3-5
6517YIPESCOM - Yipes Communication 6-10 3-5
Top 10 frequently listed without regard to state
ASN Responsible Party Unique IPs
21840 SAGONET-TPA - Sago Networks 31-40
25761 STAMINUS-COMM - Staminus Commu 16-20
{10913,13790,19024,14744} INTERNAP Internap 11-15
{13884,21844} THEPLANET-AS - THE PLANET 11-15
27654 ASN-NA-MSG-01 - Managed Soluti 6-10
4766KIXS-AS-KR Korea Telecom6-10
4713OCN NTT Communications Corpora 6-10
17676 JPNIC-JP-ASN-BLOCK Japan Netwo 6-10
3356LEVEL3 Level 3 Communications 6-10
Unresolved open IPs for top 10.
ASN Responsible Party Open-unresolved.
21840 SAGONET-TPA - Sago Networks 11-15
25761 STAMINUS-COMM - Staminus Commu 6-10
{10913,13790,19024,14744} INTERNAP Internap 1-3
{13884,21844} THEPLANET-AS - THE PLANET 1-3
27654 ASN-NA-MSG-01 - Managed Soluti 3-5
4766KIXS-AS-KR Korea Telecom3-5
4713OCN NTT Communications Corpora 3-5
17676 JPNIC-JP-ASN-BLOCK Japan Netwo 3-5
3356LEVEL3 Level 3 Communications 1-3
* We would gladly like to establish a trusted relationship with
these and any organizations to help them in the future.
* We would especially like to note the serious and prompt response by
PNAP, as well as the serious efforts made by The Planet.
* By previous requests here is an explanation of what ASN is, by Joe
St Sauver:
http://darkwing.uoregon.edu/~joe/one-pager-asn.pdf
* Clarification: the definition of count is how many CC servers are
located at said AS. We replaced it to be called Unique IPs and
Open-unresolved accordingly.
The Trojan horses most used in botnets:
---
1. Korgobot.
2. SpyBot.
3. Optix Pro.
4. rBot.
5. Other SpyBot variants and strains (AgoBot, PhatBot, actual SDbots,
etc.).
* There seems to be an increase in Energymechs used for botnets running
on *nix machines.
--
Gadi Evron,
Information Security Manager, Project Tehila -
Israeli Government Internet Security.
Ministry of Finance, Israel.
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Office: +972-2-5317890
Fax: +972-2-5317801
http://www.tehila.gov.il
The opinions, views, facts or anything else expressed in this email
message are not necessarily those of the Israeli Government.
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005, Fergie (Paul Ferguson) wrote: Intersting article on ISP issues regarding competitive VoIP services: http://www.lightreading.com/document.asp?site=lightreadingdoc_id=71020 Hmm.. I was quoted in it. -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
Is everyone ready for April 12?
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2aumng.mspx Should be a very interesting period of April 12-15 :-) -Hank
Re: Intradomain DNS Anycast revisited
On Fri, 25 Mar 2005, Joe Shen wrote: Do you mean Quagga's OSPF route has higher priority than static route? or even there is static default route configured, once Quagga detects link to default router is down it will replace 0.0.0.0/0.0.0.0 in host routing table? If you're using dynamic routing (whether it be OSPF or iBGP) to distribute default routes for fail-over, yes, you need to make sure that any statics you also have are at lower priority. One way of playing it safe would be to not have static _defaults_, but to only have static routes to your internal management networks. Nope, no problem, particularly so long as the two routers are iBGP peers, so they'll both (for the most part) have the same idea of what selected paths are. I don't understand why should both routers be iBGP peers. In fact, iBGP does not run on that two routers; the two routers are only members of OSPF backbone area who only run OSPF; only border router ( at the edge of our network) runs BGP and enject default route into OSPF backbone area. Ah, you're correct, there's no requirement for the routers to be iBGP peers or to run BGP at all... If you're doing this principally as an intranet thing, you might not have any BGP speakers nearby, or any need for BGP. I've usually done it as a service provider, which meant that the point was to have the servers as close to the rest of the world as possible, which means directly adjacent to an AS-edge BGP speaker. But you're quite right. if that possible that router3 or router-1 dispers packets of the same TCP connection to different path? Depends upon the equal-cost-path load-balancing algorithm that the routers are using. You want to select a source-destination-hash one, to avoid that issue. Is there possibility that a DNS requests are divided into multiple UDP packets? No. Not unless they hit an undetected MTU below 576 bytes, or whatever it is... Any DNS packet which can't fit inside a single UDP packet is supposed to be sent via TCP instead. Note that I'm a network guy, not a DNS guy, so this is possibly an oversimplification. Do I only need to configure BIND to origin request from administration IP address ( configured on NIC and different from DNS service address)? You mean for requests that the anycast server is making of other servers? If it needs to originate a zone transfer, or perform recursive lookups? Yes, those need to originate from the unique/administration address, as opposed to the shared/service address. -Bill
[bill.st.arnaud@canarie.ca: [CAnet - news] A new vision for the future of the Internet]
- Forwarded message from Bill St.Arnaud [EMAIL PROTECTED] - Date: Wed, 30 Mar 2005 15:27:53 -0500 From: Bill St.Arnaud [EMAIL PROTECTED] Subject: [CAnet - news] A new vision for the future of the Internet To: [EMAIL PROTECTED] X-Mailer: Microsoft Outlook, Build 10.0.6626 Making the world (of communications) a different place Report of a working session of the End-to-End Research Group For more information on this item please visit the CANARIE CA*net 4 Optical Internet program web site at http://www.canarie.ca/canet4/library/list.html --- http://www.ir.bbn.com/~craig/e2e-vision.pdf January, 2005 Version 4 3/24/05 This version for preliminary release David D. Clark, Craig Partridge, Robert T. Braden (chair), Bruce Davie Sally Floyd, Van Jacobson, Dina Katabi, Greg Minshall, K.K. Ramakrishnan, Timothy Roscoe, Ion Stoica, John Wroclawski and Lixia Zhang This report is the product of a discussion held at the January 2005 meeting of the End-to-End Research Group, which is part of the Internet Research Task Force. The challenge presented to the group for this discussion was the following: How might the computing and communications world be materially different in 10 to 15 years, and how might we define a research agenda that would get us to that world? There were a number of motivations for this discussion. The Internet itself arose because of a visionary answer to a question such as this one. Through an alignment of visionary leaders, the research community, and funding agencies, there was a coherent, long-term effort to build a running prototype of a major new communications system. That effort led to a number of new research results; results that substantially expanded and changed our understanding of the communications field. The networking field does not have a shared vision of the future today. Perhaps as a result, much of the research we see today lacks a motivation to deepen or broaden our understanding of communications. Much of today's research is felt to be incremental (in the sense of least publishable increment) and lacking a long-term motivation. At the same time, the United States' National Science Foundation is interested in hearing about important focus areas that they might fund. While focus areas are some steps short of a shared vision, we thought that a discussion of visions of the future would help refine what the focus areas might be, and could even be a vehicle to bring the research community to a common objective. In this context, the participants at the meeting speculated about possible visions of the future, and whether the time was right for a focused research push to move us toward that future. The next several sections talk about some of the visions. The report concludes with some thoughts about directions we might take. [] - To SUBSCRIBE: send a blank e-mail message to [EMAIL PROTECTED] To UNSUBSCRIBE: send a blank email message to [EMAIL PROTECTED] - These news items and comments are mine alone and do not necessarily reflect those of the CANARIE board or management. --- [EMAIL PROTECTED] ___ news mailing list [EMAIL PROTECTED] http://lists.canarie.ca/mailman/listinfo/news - End forwarded message -
RE: outage/maintenance window opinion
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Parrish Sent: Wednesday, March 30, 2005 11:29 AM To: Pete Templin Cc: [EMAIL PROTECTED] Subject: Re: outage/maintenance window opinion In this situation we were expecting to be done for the majority of the maintenance window, but yes I see your point. However I block out a 3 hour window for maintenance because the activities I am performing on the network could easily cause a longer service outage than planned as we all know. So if I plan for a 4 hour window but only expect 20 minutes of downtime that actually turns into 3 hours, as long as it is inside the maintenance window specified then it should not go against outage minutes. It was done in the window for a reason... ?? Luke I'd agree that as long as it's back up before the end of the window, you're covered. However, if the outage extends beyond the end of the window, I would take the the position that made me look worst. That shows how seriously you take your maintenance window, and I think this kind of integrity gives you credibility later. Lee At 02:05 PM 3/28/2005, Pete Templin wrote: Luke Parrish wrote: Trying to get clarification on an issue. Maintenance/outage window is 2:00AM to 5:00AM, during the window the router we are working on fails and does not come back online until 8:00AM. From a outage reporting/documentation standpoint is the outage start time 2:00AM or 5:01AM since 5:01AM is when the maintenance window and planned outage was over... To a small degree, it depends on how long you anticipated the outage to be. Were you expecting a three-hour tour^h^h^h^houtage, or something shorter but opened a big window to give you flexibility on when to do it? I would say that a fifteen-minute expected impact means the outage started at 2:15AM (or fifteen minutes after your work interrupted services). My $0.005, pt Luke Parrish Centurytel Internet Operations 318-330-6661
Re: MD5 for TCP/BGP Sessions
On Wed, 30 Mar 2005, John Kristoff wrote: [on bgp/md5 and acl's] ACLs are often used, but vary widely depending on organization. It can be difficult to manage ACLs on a box with a large number of peers that uses many local BGP peering addresses. I'm sure some organizations reviewed and updated their ACLs as a result of the last scare, but that is a local, private decision and it would probably be hard to get good sample of who and what changed. I would be double careful here, just to make sure everybody understands what you're protecting. iBGP sessions? ACLs are trivial if you have your borders secured. eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well. What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain. There are other attacks you can make against TCP sessions (protected by MD5 or not) using ICMP, though. (see draft-gont-tcpm-icmp-attacks-03.txt). -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Clearwire May Block VoIP Competitors
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Bonomi Sent: Monday, March 28, 2005 7:05 AM To: nanog@merit.edu Subject: Re: Clearwire May Block VoIP Competitors Dunno where you got the 'more than 2 subscribers' bit as defining over- subscribed. Unless you mis-read/mis-interpreted my remark about 50% utilization for VoIP data. Active VoIP transmission is about 80kbps. Depends on the codec. Yes, most people default to G.711, but my experience with G.729 and header compression has been good, and closer to 12Kbps. I definitely agree that it's much more symmetrical than web traffic, and could therefore mess with someone's capacity planning. Denying traffic that doesn't conform to your engineering is one response. Re-engineering is another. Do what you will with your network, I know what I'd do with mine. Lee
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Adrian Chadd wrote: On Wed, Mar 30, 2005, Greg Boehnlein wrote: That is fairly entertaining. Perhaps you could provide the financial breakdown for ANY DSL business model that doesn't rely on over-subscription? Q. How many, full-on 6 Meg DSL subscribers can you put on a 45 meg ATM connection without oversubscription? ;) A. Depends on how many local services they're using. :) Hehehe... full-on means full capacity. Could be one service, but 6 megs is 6 megs! ;) -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
Re: Vonage Hits ISP Resistance
On Wed, Mar 30, 2005, Greg Boehnlein wrote: Q. How many, full-on 6 Meg DSL subscribers can you put on a 45 meg ATM connection without oversubscription? ;) A. Depends on how many local services they're using. :) Hehehe... full-on means full capacity. Could be one service, but 6 megs is 6 megs! ;) Ah, if you were referring to a 45meg ATM connection to the DSL cloud, sure, I get it. But heck, even Australian ISPs have bigger ATM connections to Telstra for onselling ADSL. Adrian -- Adrian ChaddTo believe with certainty we must first [EMAIL PROTECTED] begin by doubting.
Re: Vonage Hits ISP Resistance
On Wed, Mar 30, 2005, Greg Boehnlein wrote: That is fairly entertaining. Perhaps you could provide the financial breakdown for ANY DSL business model that doesn't rely on over-subscription? Q. How many, full-on 6 Meg DSL subscribers can you put on a 45 meg ATM connection without oversubscription? ;) A. Depends on how many local services they're using. :) adrian -- Adrian ChaddTo believe with certainty we must first [EMAIL PROTECTED] begin by doubting.
Re: Clearwire May Block VoIP Competitors
On Wed, Mar 30, 2005 at 07:05:44PM -0500, Jared Mauch wrote: [...] I think one of the major problems is that very few people know how to, or are capable of sending larger g711 frames (at increased delay, but more data per packet) because they can't set these more granular settings on their systems.. this means you have a lot higher pps rates which I think is the problem with the radio gear, it's just not designed for high pps rates.. So, how are the WISP folk dealing with VOIP traffic as it becomes a larger piece of their customer's traffic? Does anyone have a way to force a given VOIP endpoint to use larger data frames? Or are the WISPs forced to deal with with a shredded business plan because their gear is optimized for large packets? (Or am I simply missing something?) Or do you write a TOS that says: Customer is not allowed to send and receive lots of small packets quickly? :-)
Re: Vonage Hits ISP Resistance
Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005 21:36:19 -0600, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? Heard of a little thing called 'spam'? Jamie -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Jamie Norwood wrote: On Wed, 30 Mar 2005 21:36:19 -0600, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? Heard of a little thing called 'spam'? SMTP and NNTP are an apples / oranges comparison. Email is well nigh ubiquitous, when people think about the Internet. NNTP, like IRC, is a niche subset compared to HTTP, SMTP, and IM. The long and short, is that popular services will remain largely unregulated, by ISPs or by government, until it's clear that they're being abused. Many ISPs did this with NNTP before they did it with SMTP, largely with the advent of higher speed connections facilitating shorter turnaround on warez traffic. Once spam took off, same deal. If ISPs can't play nice with third party service providers, I predict things will get ugly. Regulators are already sniffing around, both locally and internationally. VOIP is quickly becoming a hot item, and anti-competitive tactics that limit or remove the consumers choices are going to be blood in the water for politicos looking for something to gnaw on. Obviously VOIP needs QoS to function well on oversold, commodity broadband networks. Why not just paint VOIP with a broad QoS brush (as in, prioritize all of it, not just your own service) and defang the folks just looking for an excuse to step in and take the option away from you? - billn
APRICOT 2006 withdrawn from Bangalore, India - moves to Perth
Original Message Subject: [APRICOT-INFO] APRICOT 2006 News! Date: Thu, 31 Mar 2005 13:59:07 +1000 From: Philip Smith [EMAIL PROTECTED] (apologies for duplicates) Dear Colleagues, Due to unforeseen circumstances the APIA Board has reluctantly agreed to set aside the award of APRICOT to Bangalore, India for 2006. APRICOT 2006 now will be held in Perth, Australia from Wednesday 22nd February to Friday 3rd March 2006. The host organisation for APRICOT 2006 will be the Western Australian Internet Association (WAIA), the runner up bid for APRICOT 2006. The venue will be the Perth Convention and Exhibition Centre. More information will be on the website for APRICOT 2006, www.2006.apricot.net, which will be available shortly. best wishes! Philip Smith Secretary, APIA Board ___ Apricot-info mailing list [EMAIL PROTECTED] http://mailman.apnic.net/mailman/listinfo/apricot-info
Re: DNS cache poisoning attacks -- are they real?
On Mar 29, 2005, at 5:37 AM, Simon Waters wrote: The answers from a recursive servers won't be marked authoritative (AA bit not set), and so correct behaviour is to discard (BIND will log a lame server message as well by default) these records. As others have pointed out, BT If your recursive resolver doesn't discard these records, suggest you get one that works ;) Yeah, problem is, it ain't my recursive resolver that's the problem... I don't actually follow links in spam (shock, horror), just pointing out the problem.
AOL's brains on the floor?
Anyone else confirm? Looks like AIM, www.aol.com...maybe more, are all down form various POPs here.
Re: AOL's brains on the floor?
OK got quite a few confirmations of their IM services being out and one or two others who noticed www.aol.com being out. Noticed a few complaints about mail server issues at another site I admin, but all from AOL subscribers, and it's cleared up now except for IM services. Thanks for the feedback folks, nice to know I'm not entirely insane.
Contact from ACM?
I need to talk to someone who can update the bogon filters on www.acm.org. Attempts to reach technical contacts via the website have failed, which is a bit surprising given the nature of the org. If anyone reading this is an ACM member who can pass this message along to someone who cares I'd appreciate it. Thanks, - mark -- Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82282999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223
Re: MD5 for TCP/BGP Sessions
On Wed, 30 Mar 2005, vijay gill wrote: Christopher L. Morrow wrote: provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: Infrastructure ip space) no more traffic to the peer except BGP from the peer /30. No more ping, no more traceroute of interface... (downsides perhaps?) and the 'customer' can still DoS himself :( (or his compromised machine can DoS him) or forge the source ip on the neighbors /30 or /31 (why aren't you using /31s anyway) and call it done. curse you and your new-fangled /31's! :) Yes, someone inside the customer could dos the customer... if the customer cared, they could acl their side as well though since they aren't doing egress filtering I'm betting they aren't going to do this either ;( -Chris
Re: Vonage Hits ISP Resistance
--On Wednesday, March 30, 2005 21:36 -0600 Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? Because by and large ISPs would rather not block SMTP, but, they basically have to to try and prevent massive DDOS. NNTP is not so widely abused as SMTP. Also, I would not patronize an ISP where the SMTP block was not optional, and, I encourage any of my consulting customers who encounter this and are unable to get their ISP to remove the block for them to find another ISP. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgp3YozVCC4GV.pgp Description: PGP signature
Re: MD5 for TCP/BGP Sessions
On Thu, 31 Mar 2005, Stephen J. Wilcox wrote: without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in This is why this helps for eBGP sessions only the peer is also protecting its borders. I.e., if you know the peer's network has spoofing-prevention enabled, nobody is able to spoof the srcip the peer uses. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Contact from ACM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, You are not alone. I've had problems even as a member :-) I'll try and ping someone there and see what I can do. Feel free to contact me directly if need be. regards, /virendra Mark Newton wrote: | I need to talk to someone who can update the bogon filters on www.acm.org. | Attempts to reach technical contacts via the website have failed, which | is a bit surprising given the nature of the org. | | If anyone reading this is an ACM member who can pass this message along | to someone who cares I'd appreciate it. | | Thanks, | | - mark | | -- | Mark Newton Email: [EMAIL PROTECTED] (W) | Network Engineer Email: [EMAIL PROTECTED] (H) | Internode Systems Pty Ltd Desk: +61-8-82282999 | Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCS5e4pbZvCIJx1bcRAsAYAKCN6n2N+sKOzgHQetns9brTgW45ngCeIJk2 oGn49qTY90KMFdTaEdRe12M= =dg// -END PGP SIGNATURE-
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005 21:36:19 -0600, Chris Adams [EMAIL PROTECTED] wrote: Once upon a time, Eric A. Hall [EMAIL PROTECTED] said: Do you also block NNTP so that customers have to use your servers? Change that to SMTP and you'll get a bunch of yes answers. Why is one right and the other wrong? Heard of a little thing called 'spam'? So what? You can use your car as a weapon; should we prohibit you from car driving? Jamie -- Chris Adams [EMAIL PROTECTED] Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005 22:33:49 -0800, Alexei Roudnev [EMAIL PROTECTED] wrote: Heard of a little thing called 'spam'? So what? You can use your car as a weapon; should we prohibit you from car driving? No, but if your car doesn't have seat belts, we don't let you drive it. Basic SMTP lacks safety features that are needed, ergo, retrictions were placed on it. As was mentioned, my point was just that the question posited was flawed. SMTP isn't restricted for competition and money-making reasons, but because to not restrict it can have quite undesired implications. The question was why was one ok, and the other not. The answer is because of spam. Jamie
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Jamie Norwood wrote: On Wed, 30 Mar 2005 22:33:49 -0800, Alexei Roudnev [EMAIL PROTECTED] wrote: Heard of a little thing called 'spam'? So what? You can use your car as a weapon; should we prohibit you from car driving? No, but if your car doesn't have seat belts, we don't let you drive it. Basic SMTP lacks safety features that are needed, ergo, retrictions were placed on it. As was mentioned, my point was just that the question posited was flawed. SMTP isn't restricted for competition and money-making reasons, but because to not restrict it can have quite undesired implications. The question was why was one ok, and the other not. The answer is because of spam. Ah NANOG, where people ask rhetorical questions and get answers... It seems a bit simplistic (and misses the point of the original rhetorical question) to say that it's common to block the SMTP port because of spam. Having been involved in weighing that business decision a few times, it's tended to be more a matter of balancing the direct and indirect effects of being a spam source on an ISP's operations (lots of staff time dealing with spam complaints, bad reputations, ending up on blackhole lists) with the effects of turning off a service some customers find useful. In general, the people who will be upset by an ISP not blocking outbound spam are not the ISP's customers, while those upset about the ISP blocking legitimate outbound SMTP are. But ISPs sometimes decide they can't afford to make the customers who want outbound SMTP happy. That's why the rhetorical question asked earlier made some sense. ISPs aren't going to be blocking VOIP because of spam, at least not until they start getting bombarded with complaints about their customers using VOIP services for automated telemarketing. But they may block it because they think the benefits of blocking it (reducing traffic, keeping VOIP business to themselves) outweigh the costs of customers getting annoyed. If it's ok to block SMTP for that reason, why not VOIP, or why not the web? I'll note again that these are rhetorical questions. They don't need to be answered. Personally, if the colo provider who hosts my mail server were to block outbound SMTP, the service would become pretty useless to me and I'd have to take my (non-paying) business elsewhere. If my GPRS provider were to block it, I probably wouldn't notice. Likewise, if the colo provider blocked VOIP, I probably wouldn't notice, but if my DSL provider did, it would be a problem. An ISP who blocks VOIP is going to have some customers get upset, just like an ISP that blocks outbound SMTP. They may even lose some business. But will they lose enough business to offset whatever gain they think they're getting? I think I can guess the answer, but actual numbers from those who've tried it would be far more interesting than the speculation we've been seeing here. -Steve
Re: MD5 for TCP/BGP Sessions
without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in Steve On Thu, 31 Mar 2005, Pekka Savola wrote: On Wed, 30 Mar 2005, John Kristoff wrote: [on bgp/md5 and acl's] ACLs are often used, but vary widely depending on organization. It can be difficult to manage ACLs on a box with a large number of peers that uses many local BGP peering addresses. I'm sure some organizations reviewed and updated their ACLs as a result of the last scare, but that is a local, private decision and it would probably be hard to get good sample of who and what changed. I would be double careful here, just to make sure everybody understands what you're protecting. iBGP sessions? ACLs are trivial if you have your borders secured. eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well. What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain. There are other attacks you can make against TCP sessions (protected by MD5 or not) using ICMP, though. (see draft-gont-tcpm-icmp-attacks-03.txt).
Re: Clearwire May Block VoIP Competitors
the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be half duplex whereas codecs tend to run both directions at once. who's getting good service over 802.11 using G.711 or G.729? (no fair if your wireless handset has its own proprietary halfdup codec, i'm talking real SIP here.) -- Paul Vixie
Re: Clearwire May Block VoIP Competitors
On 30 Mar 2005, Paul Vixie wrote: the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be half duplex whereas codecs tend to run both directions at once. who's getting good service over 802.11 using G.711 or G.729? (no fair if your wireless handset has its own proprietary halfdup codec, i'm talking real SIP here.) hmm running g711 on a wifi handset or a lan phone with wifi bridging in the middle results in decent quality. at 2x80kbps vs 11mbps or 54mbps there should be plenty room for both directions to communicate without too much delay Steve
Re: MD5 for TCP/BGP Sessions
Stephen J. Wilcox wrote: without wishing to repeat what can be googled for.. putting acls on your edge to protect your ebgp sessions wont work for obvious reasons -- to spoof data and disrupt a session you have to spoof the srcip which of course the acl will allow in This is why you either have a stateful firewall in your router that pushes a dynamic acl down to the linecard (or equivalent forwarding place where the for_us vs through_us decision is made), and filter it there. That makes guessing the correct 5 tuple a bit harder. Obviously GTSM is the closest we have yet to hardening (note I did not use securing) the session. On average, the stateful filter will cause the attacker to to try 32000 times to find correct 4-tuple. Conversely, attacker resources will need to be on average 32000 times greater to adversely affect a router. The cost of attacking infrastructure has risen, but the cost to defender is minor. Each configured BGP session already has all the state needed above to populate the filter. /vijay
RE: Clearwire May Block VoIP Competitors
On Wed, 30 Mar 2005, Howard, W. Lee wrote: planning. Denying traffic that doesn't conform to your engineering is one response. Re-engineering is another. Do what you will with your network, I know what I'd do with mine. I could be 1) over simplifying, 2) misunderstanding, the problem, but all of the networks that make up 'the Internet' are really just private networks. there is nothing that says any of these private networks have to transport all bits in all streams from end to end, yes? Given that, certainly some networks might choose to NOT transport VOIP or HTTP or BitTorennt across their networks. There are market reasons why this will, or could, eventually force them to re-evaluate their practices or face the consequences. I don't find it shocking at all that ISP-Y decides to block VOIP, especially if they have their own VOIP service offering. It might not be the BEST plan in the long run for them, but certainly it makes some sense to them... Just don't use their network(s), and complain to their support organization(s) about the failures on their networks. -Chris
Re: Clearwire May Block VoIP Competitors
On Wed, Mar 30, 2005 at 11:32:33PM +, Paul Vixie wrote: the bigger issue with 802.11 and VoIP is that wireless ethernet tends to be half duplex whereas codecs tend to run both directions at once. who's getting good service over 802.11 using G.711 or G.729? (no fair if your wireless handset has its own proprietary halfdup codec, i'm talking real SIP here.) you didn't ask for the size of the wireless network(1), in my experience i've not had any (major) problems with this, the key is to insure that the packets are somehow QoS'ed at the edge, even if your provider won't do QoS to you, you can do some neat artifical QoS on your upstream/uplink interfaces.. What i've done is rate-limit TCP inbound to be around 75-80% of the link speed to force things to back-off and leave space for my UDP packet streams. I think one of the major problems is that very few people know how to, or are capable of sending larger g711 frames (at increased delay, but more data per packet) because they can't set these more granular settings on their systems.. this means you have a lot higher pps rates which I think is the problem with the radio gear, it's just not designed for high pps rates.. big thing i've noticed in operational experience is that not all 802.11 handsets handle AP roaming seamlessly, some want to disconnect then re-dhcp for what is the same ssid/network domain. - jared (1) - i'm speaking for a single-ssid network with more than one AP that covers long-distance clients at 1Mb/s speeds on 802.11b (250meter+ one way) -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: MD5 for TCP/BGP Sessions
On Thu, 31 Mar 2005, Pekka Savola wrote: On Wed, 30 Mar 2005, John Kristoff wrote: [on bgp/md5 and acl's] ACLs are often used, but vary widely depending on organization. (and equipment in use) It can be difficult to manage ACLs on a box with a large number of peers that uses many local BGP peering addresses. I'm sure provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: Infrastructure ip space) no more traffic to the peer except BGP from the peer /30. No more ping, no more traceroute of interface... (downsides perhaps?) and the 'customer' can still DoS himself :( (or his compromised machine can DoS him) some organizations reviewed and updated their ACLs as a result of the last scare, but that is a local, private decision and it would probably be hard to get good sample of who and what changed. some people still use 'cisco' for their password, even on non-cisco platforms :( this md5 discussion isn't the only security problem :( I would be double careful here, just to make sure everybody understands what you're protecting. iBGP sessions? ACLs are trivial if you have your borders secured. ibgp, provided your infrastructure space is seperate from 'customer' space is simpler... but keep in mind the possible downsides (no ping, no traceroute, harder troubleshooting for the customers, perhaps) eBGP sessions? GTSM is your friend (if supported). Practically, if you know your peer and you also protect your borders, ACLs are rather trivial as well. borders, for some folks, are wide, varied and complex :( So, for some folks with limited border size/breadth making these things trivial is, of course, easy. What you seem to be saying is using ACLs to enumerate the valid endpoints for eBGP sessions. That goes further than the above but indeed is also a pain to set up and maintain. and impossible to implement on some hardware. Note: Some/all of that hardware is going away as time makes it fade into the background... sometimes not fast enough though. -Chris
Re: Sympatico / Nexxia (as577) smtp issues ?
I saw this earlier today ... hope it helps to know you're not alone -rd- Mike Tancsa wrote: Anyone know whats up with Sympatico / Bell's mail servers ? My customers are asking me why their mail is not getting there nor mail from sympatico is not getting to us. Most mail does not seem to be going through although network connectivity seems fine. I tried from 2 other networks and the issue seems to be the same. host -tmx sympatico.ca sympatico.ca mail is handled by 5 toip6.bellnexxia.net. sympatico.ca mail is handled by 5 toip7.bellnexxia.net. sympatico.ca mail is handled by 5 toip8.bellnexxia.net. sympatico.ca mail is handled by 5 toip1.bellnexxia.net. sympatico.ca mail is handled by 5 toip2.bellnexxia.net. sympatico.ca mail is handled by 5 toip3.bellnexxia.net. sympatico.ca mail is handled by 5 toip4.bellnexxia.net. sympatico.ca mail is handled by 5 toip5.bellnexxia.net. telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused telnet toip1.bellnexxia.net smtp Trying 209.226.175.84... telnet: Unable to connect to remote host: Connection refused telnet toip2.bellnexxia.net smtp Trying 209.226.175.85... telnet: Unable to connect to remote host: Connection refused telnet toip3.bellnexxia.net smtp Trying 209.226.175.86... telnet: Unable to connect to remote host: Connection refused telnet toip4.bellnexxia.net smtp Trying 209.226.175.87... Connected to toip4.bellnexxia.net. Escape character is '^]'. 421 #4.4.5 Too many connections to this host. Connection closed by foreign host. telnet toip5.bellnexxia.net smtp Trying 209.226.175.88... telnet: Unable to connect to remote host: Connection timed out telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused telnet toip7.bellnexxia.net smtp Trying 209.226.175.175... telnet: Unable to connect to remote host: Connection refused Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike -- Richard Danielli President, eSubnet (416) 203-5253 www.eSubnet.com
Re: Sympatico / Nexxia (as577) smtp issues ?
On Wed, 30 Mar 2005, Mike Tancsa wrote: Anyone know whats up with Sympatico / Bell's mail servers ? My customers are asking me why their mail is not getting there nor mail from sympatico is not getting to us. Most mail does not seem to be going through although network connectivity seems fine. I tried from 2 other networks and the issue seems to be the same. 421 #4.4.5 Too many connections to this host. Connection closed by foreign host. sometimes new email-bourne virii do this :( Suresh might know of a new virus running rampant in the email world? or perhaps others watching mailqueues do?
Re: MD5 for TCP/BGP Sessions
Christopher L. Morrow wrote: provided your gear supports it an acl (this is one reason layered acls would be nice on routers) per peer with: permit /30 eq 179 /30 permit /30 /30 eq 179 deny all-network-gear-ip-space (some folks call it backbone ip space, Paul Quinn at cisco says: Infrastructure ip space) no more traffic to the peer except BGP from the peer /30. No more ping, no more traceroute of interface... (downsides perhaps?) and the 'customer' can still DoS himself :( (or his compromised machine can DoS him) or forge the source ip on the neighbors /30 or /31 (why aren't you using /31s anyway) and call it done. /vijay
Sympatico / Nexxia (as577) smtp issues ?
Anyone know whats up with Sympatico / Bell's mail servers ? My customers are asking me why their mail is not getting there nor mail from sympatico is not getting to us. Most mail does not seem to be going through although network connectivity seems fine. I tried from 2 other networks and the issue seems to be the same. host -tmx sympatico.ca sympatico.ca mail is handled by 5 toip6.bellnexxia.net. sympatico.ca mail is handled by 5 toip7.bellnexxia.net. sympatico.ca mail is handled by 5 toip8.bellnexxia.net. sympatico.ca mail is handled by 5 toip1.bellnexxia.net. sympatico.ca mail is handled by 5 toip2.bellnexxia.net. sympatico.ca mail is handled by 5 toip3.bellnexxia.net. sympatico.ca mail is handled by 5 toip4.bellnexxia.net. sympatico.ca mail is handled by 5 toip5.bellnexxia.net. telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused telnet toip1.bellnexxia.net smtp Trying 209.226.175.84... telnet: Unable to connect to remote host: Connection refused telnet toip2.bellnexxia.net smtp Trying 209.226.175.85... telnet: Unable to connect to remote host: Connection refused telnet toip3.bellnexxia.net smtp Trying 209.226.175.86... telnet: Unable to connect to remote host: Connection refused telnet toip4.bellnexxia.net smtp Trying 209.226.175.87... Connected to toip4.bellnexxia.net. Escape character is '^]'. 421 #4.4.5 Too many connections to this host. Connection closed by foreign host. telnet toip5.bellnexxia.net smtp Trying 209.226.175.88... telnet: Unable to connect to remote host: Connection timed out telnet toip6.bellnexxia.net smtp Trying 209.226.175.174... telnet: Unable to connect to remote host: Connection refused telnet toip7.bellnexxia.net smtp Trying 209.226.175.175... telnet: Unable to connect to remote host: Connection refused Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: Vonage Hits ISP Resistance
On 3/30/2005 11:27 AM, Greg Boehnlein wrote: On Wed, 30 Mar 2005, Fergie (Paul Ferguson) wrote: Intersting article on ISP issues regarding competitive VoIP services: http://www.lightreading.com/document.asp?site=lightreadingdoc_id=71020 Hmm.. I was quoted in it. Oh good, maybe you can clarify some things: | As much as I want to see VOIP survive and thrive, I also don't want | to bear the additional cost of my customers choosing to use a | competitor's VOIP service over my own, says Greg Boehnlein, who | operates Cleveland, Ohio-based ISP N2Net. | | Without control of the last mile, we're screwed, Boehnlein says, | which is why I can identify with Clearwire's decision and say | more power to them. Do you also block NNTP so that customers have to use your servers? And if some other service used higher cumulative bandwidth than VoIP (say, Apple's music service) and didn't ~reimburse you for the use of your network, would|do you block that service too? For that matter, do you block the various P2P systems that don't make money but that generate massive traffic? What don't you plan on blocking exactly? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
IANA IPv4 allocations and bogon update: 73/8
-BEGIN PGP SIGNED MESSAGE- [ Apologies to those of you who receive this note in multiple forums. ] Hi, team. The numerous Team Cymru bogon projects have been updated as of 30 MAR 2005 to reflect the following IANA allocation made on 30 MAR 2005: 073/8 Mar 05 ARIN (whois.arin.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: http://www.cymru.com/Bogons/ A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - http://www.cymru.com/Documents/bogon-list.html The Text Bogon Lists - http://www.cymru.com/Documents/bogon-bn-nonagg.txt - http://www.cymru.com/Documents/bogon-bn-agg.txt Secure BIND Template - http://www.cymru.com/Documents/secure-bind-template.html Secure IOS Template (Cisco) - http://www.cymru.com/Documents/secure-ios-template.html Secure BGP Template (Cisco) - http://www.cymru.com/Documents/secure-bgp-template.html Secure JUNOS Template (Juniper) - http://www.cymru.com/gillsr/documents/junos-template.htm Secure JUNOS BGP Template (Juniper) - http://www.cymru.com/gillsr/documents/junos-bgp-template.htm Ingress Prefix Filter Templates, Loose and Strict (Cisco) - ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/ Ingress Prefix Filter Template, Loose (Juniper) - http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm Ingress Prefix Filter Template, Strict (Juniper) - http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - http://www.cymru.com/BGP/bogon-rs.html RADb fltr-unallocated fltr-martian fltr-bogons - http://www.cymru.com/Bogons/index.html#radb RIPE NCC fltr-unallocated fltr-martian fltr-bogons - http://www.cymru.com/Bogons/index.html#ripe DNS Bogon (bogons.cymru.com) zone - http://www.cymru.com/Bogons/index.html#dns Monitoring Bogon prefix monitoring - http://www.cymru.com/BGP/robbgp-bogon.html Bogus ASN monitoring - http://www.cymru.com/BGP/asnbogusrep.html Please feel free to contact Team Cymru [EMAIL PROTECTED] with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -BEGIN PGP SIGNATURE- Version: PGP 6.5.2 iQCVAwUBQks9clkX3QAo5sgJAQFCHgP/V6mR3gVMiNQ5bvkfSgsT5nkIw0bn2BJA nE4qKGQrB22WL6t83PMsMONjW7GvHJA7Ds4DVgVggTUBJ/SqupM1xQ3SBwEokHcW oydTMiUrsS1dmZMdoLoSHNdGC6hLciTgYayIO/EBI9IGoQYdR/swzgjzHXkLWghO 0C67MWkIT7M= =+ixP -END PGP SIGNATURE-
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005, Eric A. Hall wrote: | to bear the additional cost of my customers choosing to use a | competitor's VOIP service over my own, says Greg Boehnlein, who | operates Cleveland, Ohio-based ISP N2Net. | | Without control of the last mile, we're screwed, Boehnlein says, | which is why I can identify with Clearwire's decision and say | more power to them. Do you also block NNTP so that customers have to use your servers? And if some other service used higher cumulative bandwidth than VoIP (say, Apple's music service) and didn't ~reimburse you for the use of your network, would|do you block that service too? For that matter, do you block the various P2P systems that don't make money but that generate massive traffic? I find this to be entertaining, since as a VOIP consumer, I'm reimbursing my ISP for the cost of the traffic as part of my monthly tithe. Why exactly are networks taking this stance to QoS VOIP traffic, generated by their customers, into uselessness? This will all be especially hysterical when it's done by an ISP that comprises 100% of it's local market's internet connectivity. Munn vs. Illinois, round 2! - billn
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005, Eric A. Hall wrote: On 3/30/2005 11:27 AM, Greg Boehnlein wrote: On Wed, 30 Mar 2005, Fergie (Paul Ferguson) wrote: Intersting article on ISP issues regarding competitive VoIP services: http://www.lightreading.com/document.asp?site=lightreadingdoc_id=71020 Hmm.. I was quoted in it. Oh good, maybe you can clarify some things: | As much as I want to see VOIP survive and thrive, I also don't want | to bear the additional cost of my customers choosing to use a | competitor's VOIP service over my own, says Greg Boehnlein, who | operates Cleveland, Ohio-based ISP N2Net. | | Without control of the last mile, we're screwed, Boehnlein says, | which is why I can identify with Clearwire's decision and say | more power to them. Do you also block NNTP so that customers have to use your servers? Where the RBOC has us by the balls (ATM DSL Transport as an Example, where they refuse to provide Multi-Lata ATM interconnects and require us to put ATM circuits in each LATA that we want to service) we apply, at our discretion, rate-limits and IP Access lists to preserve and tightly control those resources. We attempt to balance the experience and utilzation for ALL the customers on those circuits against the one or two users who are beating the crap out of the interconnect w/ Peer to Peer or Usenet traffic. So yes, in some cases, we'll apply NNTP and other traffic shaping policies as neccessary to ensure that we are able to maintain low latency and a more equal sharing of bandwidth on those links. This really only applies to residential DSL subscribers. On DS1, Ethernet and DS3 circuits, we don't do anything. Those are treated as a different class of service, with a Service Level Agreement, and as such are only shaped at the customer's request. And if some other service used higher cumulative bandwidth than VoIP (say, Apple's music service) and didn't ~reimburse you for the use of your network, would|do you block that service too? For that matter, do you block the various P2P systems that don't make money but that generate massive traffic? What don't you plan on blocking exactly? The press always bends quotes to fit their story, and are easily taken out of context. You only have the benefit of seeing the quotes they chose to publish, and not the entire context of the discussion. ;) So, to clarify my position I don't block anything on my network for customers that are under a Service Level Agreement. In fact, we actually apply higher preference to VoIP traffic. However, it is MY network and I'll do whatever I please with it. If customers have an issue, they are free to contact me about it. However, If the FCC is able to dictate the types of traffic and the filtering policies of ISPs, this could have much broader, far-reaching impact on what we CAN do with our networks. Take the following ridiculous example; Assume that some SPAMMER is able to get the FCC to pass regulation that makes it illegal to block SMTP traffic, use RBLs etc. How well do you think that would go over? I'm all for network service providers having the ability to control what enters and exits their network. I'm against the Government stepping in and dictating what we can/cannot do with our networks. I'm an avid and active Asterisk developer. I want to see VoIP flourish and grow. However, anyone who has gotten into the ITSP business (Read Vonage et all) and has based their business plan on delivering service over a network they don't control has to have their head examined. VoIP makes a lot of sense, but over the public Internet? Pretty bad business judgement in my opinion. If you can't QOS both sides of the connection and control the packets between the PSTN and the End User, then you WILL have outages and problems that are beyond your control. That may be good enough for most people, but not for me. I wouldn't trust my family's life to a VoIP service when that 911 call has to transit the public Internet. -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
Re: Sympatico / Nexxia (as577) smtp issues ?
On Thu, 31 Mar 2005 00:19:18 + (GMT), Christopher L. Morrow [EMAIL PROTECTED] wrote: 421 #4.4.5 Too many connections to this host. Connection closed by foreign host. sometimes new email-bourne virii do this :( Suresh might know of a new virus running rampant in the email world? or perhaps others watching mailqueues do? Well could be a virus outbreak or an extensive spam run that's bogging the servers down Could also be our hardware is old, tired and melting down, we need to buy some more time :) -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Vonage Hits ISP Resistance
On Wed, 30 Mar 2005, Bill Nash wrote: On Wed, 30 Mar 2005, Eric A. Hall wrote: | to bear the additional cost of my customers choosing to use a | competitor's VOIP service over my own, says Greg Boehnlein, who | operates Cleveland, Ohio-based ISP N2Net. | | Without control of the last mile, we're screwed, Boehnlein says, | which is why I can identify with Clearwire's decision and say | more power to them. Do you also block NNTP so that customers have to use your servers? And if some other service used higher cumulative bandwidth than VoIP (say, Apple's music service) and didn't ~reimburse you for the use of your network, would|do you block that service too? For that matter, do you block the various P2P systems that don't make money but that generate massive traffic? I find this to be entertaining, since as a VOIP consumer, I'm reimbursing my ISP for the cost of the traffic as part of my monthly tithe. Why exactly are networks taking this stance to QoS VOIP traffic, generated by their customers, into uselessness? Well, there is a whole other side to the arguement, which is why is your local ISP even providing you the DSL service when they don't own the last mile copper and pay 98% of the revenue that you pay them to an RBOC? :) Believe me, I ask myself this question every day: Why did I agree to provide DSL services through SBC and Alltel knowing how anticompetitive they are?. And the only anwer that I can come up with is: You are an idiot. ;) This gets at a bigger issue really, which is why anyone in their right mind is actually re-selling RBOC DSL products, but that isn't your concern. ;) As an ISP, I'd love to charge you (the consumer) on a per-packet or per-byte level for your DSL so that it would actually reflect the true cost of the service. Then, I'd like to charge you for all the technical support and billing overhead involved. At the same time, I'd like to see the RBOC's relegated to nothing more than wire-carriers and get them completely out of the Telecommunications industry. Let them run the COs and the Copper/Fiber networks, but truly deregulate the Telecom industry so that everyone is on a level playing field. Fat chance of that happening, though! ;) This will all be especially hysterical when it's done by an ISP that comprises 100% of it's local market's internet connectivity. Munn vs. Illinois, round 2! Why are RBOC's even providing Internet Transport to their customers in the first place? :) -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
Re: Vonage Hits ISP Resistance
On Thu, 31 Mar 2005, Brad Knowles wrote: At 5:06 PM -0800 2005-03-30, Bill Nash wrote: I find this to be entertaining, since as a VOIP consumer, I'm reimbursing my ISP for the cost of the traffic as part of my monthly tithe. No, that's not true. Not if your ISP has oversold their upstream bandwidth, and a lot of people start using VOIP. In that case, your ISP is dependant on keeping you fat, dumb, happy, barefoot, and pregnant in the kitchen, taking whatever semidigested pabulum they choose to feed you, and if you start getting uppity by actually thinking for yourself and using something like VOIP, then they're going to have to bitch-slap you back into your rightful place under their thumb. That is fairly entertaining. Perhaps you could provide the financial breakdown for ANY DSL business model that doesn't rely on over-subscription? Q. How many, full-on 6 Meg DSL subscribers can you put on a 45 meg ATM connection without oversubscription? ;) -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
