Re: BCP38 making it work, solving problems
On 12-okt-04, at 7:30, Fred Baker wrote: From an ISP perspective, I would think that it would be of value to offer *not* ingress filtering (whether by ACL or by uRPF) as a service that a customer pays for. So what is our collective position on ISPs filtering their peers? Both the position that this should be done as there are too many clueless peers and the position that it shouldn't as it breaks too much legitimate stuff (especially possible future stuff such as the multiaddress multihoming for IPv6) are reasonable. We need to agree on one or the other, though: half the net doing one and the other half doing the other won't make anyone happy. Steve Bellovin wrote an April Fool's note suggesting an Evil Bit (ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt); I actually think that's not such a dumb idea if implemented as a Not Evil flag, using a DSCP or extending the RFC 3168 codes to include such, as Steve Crocker has been suggesting. Basically, a customer gets ingress filtered (by whatever means) and certain DSCP settings are treated as someone not proven to have their act together. Should a ddos happen, such traffic is dumped first. But if the customer pays extra, their traffic is marked not evil, protected by the above, and ingress filtering may be on or off according to the relevant agreement. I would much rather see a solution where ISPs rate limit their customers except for flows for which the customer can present a token that shows the recipient actually wants to receive the traffic, or the recipient gets to send a message to shut up the flow. This should solve the (D)DoS thing very nicely, although it does require both ends to cooperate and it requires customer facing stuff to look fairly deep into packets. Address spoofing is just one part of the ddos problem; to nail ddos, we also need to police a variety of application patterns. One reason I like the above is that it gives us a handle on what traffic might possibly be not evil - someone has done something that demonstrates that it is from a better managed source. Trusting the source when it says that its packets aren't evil might be sub-optimal. Evaluation of evilness is best left up to the receiver.
Re: short Botnet list and Cashing in on DoS
--- Andrew D Kirch [EMAIL PROTECTED] wrote: ... and anyone posting from yahoo/gmail/hotmail should have their posting rights immediately revoked because obviously they have no claim whatsoever to any critical Network Operations. You had me until then: has it not occurred to you that some of us work for large corporations which would rather not make official stands on the topics discussed on the NANOG list? There is a certain plausible deniability which is created by using a yahoo/etc account. Furthermore, some of us have changed jobs inside the field, and the use of personal email addresses avoids any complications with that. Also, it avoids the stupid autoresponder issues which some corporations force upon their employees. Your argument works if you're the boss. If you're not, of if there's any PHBs above you, it's better to stick with the private email. = David Barak -fully RFC 1925 compliant- ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
Re: I-D on operational MTU/fragmentation issues in tunneling
On 11-okt-04, at 10:12, Pekka Savola wrote: The document is about to be IETF Last Called for Informational RFC, but prior to that, I'd like to solicit comments/feedback/review from the people here because I'm 100% sure a lot of people have been faced with these issues (we certainly have..). Well, tunnels suck. No news there. It is interesting to note that at least one implementation provides a special knob to fragment the inner packet prior to encapsulation even if the DF bit has been set -- this is non-compliant behaviour, but possibly has been required in certain tightly controlled passive monitoring scenarios. Such a setup wouldn't work for packets which have already been fragmented if they needed to be fragmented again, though. Why would it be impossible to refragment fragments??? I have a setup with dial-up over L2TP that doesn't support an MTU bigger than 576 (which is completely unnecessary of course, but try telling the people at the other end of the L2TP thingy that) so I clear the DF bit for all incoming packets that have to go through the PPP/L2TP tunnel. Works like a charm. (Surprisingly, all users seem to have systems that are capable of reassembling 1.5 kB packets now.) But I don't understand why anyone would want to use tunnels in the backbone. That's what VLANs are for. And if you don't use ether, you aren't bound by yester-millennium's 1500 byte MTU anyway. In IPv6 there is the interesting problem that there are already many tunnels all over the place that often have a 1280 byte MTU, so tunneling over that can't be done because of the mandatory minimum MTU of 1280 bytes.
Re: short Botnet list and Cashing in on DoS
On Wed, 13 Oct 2004, David Barak wrote: and anyone posting from yahoo/gmail/hotmail should have their posting rights immediately revoked because obviouslythey have no claim whatsoever to any critical Network Operations. You had me until then: has it not occurred to you that some of us work for large corporations which would rather not make official stands on the topics discussed on the NANOG list? There is a certain plausible deniability which is created by using a yahoo/etc account. I have no problem with those using yahoo or hotmail accounts, to create new email account not associated with actual work address. But I do have problem if service provider makes it too easy to create new virtual identities without providing a way to identify real origin of email. This offers opportunity for various forms of public forum denial of service attacks. Two email service providers that do come to mind that offer this are hashmail and gmail as neither one of them puts ip address of the user into email headers. As such I consider anybody posting from email account with one of these providers to be of very questinable origin and consider his words and his name in similar way. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: BCP38 making it work, solving problems
For the week starting Sept 12, our dark space telescope saw 1675 spoofed DDOS attacks. any idea why someone(s) is ddosing dark space? seems a bit silly. randy
Re: BCP38 making it work, solving problems
At 04:59 AM 13-10-04 -0700, Randy Bush wrote: For the week starting Sept 12, our dark space telescope saw 1675 spoofed DDOS attacks. any idea why someone(s) is ddosing dark space? seems a bit silly. No one is DDOSing dark space. The dark space telescope picks up the richochets caused by DDOS. CAIDA created a nice 90 second video clip explaining this at: http://www.caida.org/outreach/resources/animations/passive_monitoring/backscatter.mpg -Hank randy
Re: BCP38 making it work, solving problems
Randy Bush wrote: For the week starting Sept 12, our dark space telescope saw 1675 spoofed DDOS attacks. any idea why someone(s) is ddosing dark space? seems a bit silly. Something like this I rather fancy ... http://lists.planet-lab.org/pipermail/announce/2004-April/12.html [Planetlab-announce] network telescope Larry Peterson llp at CS.Princeton.EDU Thu Apr 15 16:31:24 EDT 2004 * Previous message: [Planetlab-announce] Cambridge meeting * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] I have a request to make of PlanetLab sites... There is an effort underway to collect information about worms, ddos backscatter, and other suspect activity on the Internet. Our ability to do this sort of analysis would be greatly enhanced by having access to IP address blocks spread across the Internet, for example, at as many PlanetLab sites as possible. My specific request is for sites to contribute blocks of, say, 16 otherwise unused addresses to PlanetLab. I have attached a note from Vern Paxson outlining the idea, a so called network telescope. Please let me know if your site would be willing to contribute (assign) some number of addresses to PlanetLab for this purpose. Larry -- A basic challenge for analyzing Internet-scale malicious phenomena such as worms and automated scanning is acquiring sufficiently broad visibility into their workings. Monitoring at a single location may for example miss the early stages of a worm's spread or, more generally, lack the diverse perspectives necessary for capturing large-scale behavior. A powerful tool for acquiring such broader visibility is a network telescope. Network telescopes monitor traffic sent to communication dead-ends such as unallocated portions of the IP address space or ports on endhosts for which no server is listening. Since there is no legitimate reason for a host to send packets to those destinations, such traffic provides strong evidence of malicious activity - including DDoS backscatter, port scanning, and probe activity from worms. Our goal is to build a large-scale telescope with significantly more sampling breadth and diversity than current telescopes. This telescope will be structured as two layers. Its front-end sensors will be spread across a large number of address blocks and monitoring points to achieve sampling diversity. We'll use both unallocated address blocks (which attackers can learn about fairly easily) but also unused subblocks within allocated blocks. This latter dark address space is much more difficult for an attacker to learn about and also enables highly diverse distribution of the sensors. It's this latter that we're hoping can be done in conjunction with PL nodes. In particular, the way we picture it working is that the PL nodes will have multiple addresses assigned to them. A monitor running on the host then tunnels traffic it receives on the extra addresses over to the analysis point. It could also tunnel traffic sent to its normal address but for which there's no listener. One crucial issue with building a large telescope is *filtering*. For a very large telescope, the volume of data collected can be enormous. However, for many forms of analysis we can often filter out a great deal of the traffic. For example, for worm detection we can drop traffic seen by the sensor rather than forwarding it if the traffic does not correspond to worm activity of possible interest (e.g., it's instead DoS backscatter, or activity from known worms). Because PL nodes can do computation before they forward traffic over the tunnel (unlike, for example, telescope sensors based on using routers), they make ideal platforms for developing such filtering.
Re: BCP38 making it work, solving problems
on Wed, Oct 13, 2004 at 07:09:10AM +0530, Suresh Ramasubramanian wrote: [EMAIL PROTECTED] [12/10/04 13:16 -0400]: If I, and my little 7-man company, can afford to have me solve the problem on our end, why the heck can't you do the same? You can do it because you are a 7-man company. So can I. However, companies the size of Sprint cannot do it. Most filtering that I've seen (email, router, whatever) that just works great for a 7 man company will not work when you serve several million users, that's a fact. A 7 man Web app development company with ~100 or so hosted POP mail accounts, FYI. Not that it matters. If I can write rules that block spam with forged headers, so can any damn body else. And I'm tired of getting the bounces from those who feel it's not possible. Some examples of headers from mail that other ISPs have felt compelled by their size to accept and then bounce back to me: Received: from dslam129-213-59-62.adsl.zonnet.nl (62.59.213.129) by 0 with SMTP; 27 Aug 2004 21:20:16 - Received: from thewordfactory.com (mail.thewordfactory.com [216.27.21.211]) by dslam129-213-59-62.adsl.zonnet.nl (Postfix) with ESMTP id 0453B70AB1 for [EMAIL PROTECTED]; Fri, 27 Aug 2004 15:29:58 -0500 The second Received header is forged. The first is from a dynamic DSL line. The message was accepted by mail.philonline.com ([203.177.71.7]) and bounced back to me in a message that didn't even have a Message-ID header, letting me know they are so dumb they accept forged mail from dynamic IPs and only then analyze it to see if the user exists or if the forged sender should be notified. Received: from ip84-RND_DIGIT[2-3]-RND_DIGIT[2-3]-RND_DIGIT[2-3].4tvMsWC8okzw.customer.aviamail.zzn.com (50-RND_DIGIT[2-3]-RND_DIGIT[2-3]-RND_DIGIT[2-3].customer.aviamail.zzn.com [24.135.29.42]) by ezEG4GA1.aviamail.zzn.com (RND_DIGIT[1-3].RND_DIGIT[1-3].RND_DIGIT[1-3]/RND_DIGIT[1-3].RND_DIGIT[1-3].RND_DIGIT[1-3]) with SMTP id B3tc6UKcaTVY This was in a bounce from mail.cygentech.com (geoanalysis36.cust.viawest.net [216.150.205.36]). We've been seeing these headers for more than a year now, and blocking them almost as long. But these idiots can't see that backscattering them at me is rather stupid. Just a few of the others who've done this (accepted mail with completely bogus RNDizer headers from broken spamware): plesk4.merkury.com (216-86-139-44.tns.net [216.86.139.44] (may be forged)) smtp03.adnc.com (smtp03.adnc.com [206.251.248.23]) cobble.phpwebhosting.com (cobble.phpwebhosting.com [64.65.61.211]) date.marketorder.com ([64.65.150.229]) (by way of postini) exchgkom.TRI.NET (mail.tecolote.com [65.170.33.20]) DNS2.TCBINC.NET (DNS2.TCBINC.NET [64.124.116.30]) mail-in-01.netsonic.net (mail-in-01.netsonic.net [66.180.172.253]) ms1.tcnoc.com (ms1.tcnoc.com [63.150.10.30]) exchange3.corp.bcs-tx.com (ip204.bcs-tx.com [216.136.93.204] (may be forged)) [...etc...] My full list of backscatter hosts is ~17K entries long. And those are just the ones who've hit my servers. Never mind the charter/rr/att/hotmail/etc. hosts that are also listed - I'm not just talking about random Exchange boxes here - I'm talking about every major ISP with which I am familiar. Want to know if you're responsible for backscatter abuse? Just ask. As you know, Suresh, Outblaze does the same thing. Listed here as hosts we no longer accept null sender mail from: mta1-1.us4.outblaze.com BOUNCER spf0.us4.outblaze.com BOUNCER spf10.us4.outblaze.com BOUNCER spf1.us4.outblaze.com BOUNCER spf2.us4.outblaze.com BOUNCER spf4-1.us4.outblaze.com BOUNCER spf5-1.us4.outblaze.com BOUNCER spf7-17.us4.outblaze.comBOUNCER At least you've said you're moving towards fixing it. Thanks. One false positive report per week from 7 users. How many per week - or per day - when you have 40 million users, is a question that gets answered real fast. I don't even want to go into the backscatter messages that show that: - the sender forged the IP/domain of the recipient into HELO/EHLO - the recipient accepts mail for unknown accounts - the relaying host forwarded Webmail from Nigeria without proper Received headers added for blocking purposes - you name the obvious spamsign Come on, there is so much obvious crud that should be checked that isn't being checked - we could reduce backscatter by a third or more simply by refusing during SMTP handshake messages from hosts that forge the receipient IP/hostname/domain in HELO, or to users that don't exist, or if virus filters were clueful enough to drop, rather than emit DSNs, for known virus-originated messages that always forge the sender. A lot of the bad filtering (or lack of filtering, for that matter) decisions I've seen at large network providers and ISPs is generally where they are also unresponsive to their users and to the internet community that reports stuff to them (quite a few places I could name where most role accounts seem to funnel straight
Re: BCP38 making it work, solving problems
On 13 Oct 2004, Paul Vixie wrote: How many people have seen forged spoofed IP addresses being used for DOS attacks lately? syn-flood protection, and random TCP ISS, are now common enough that spoofed-source isn't effective for TCP flows. if you want to bring down somebody's web server then blackhats really do have to use real addresses. of course the docs were written a couple years ago, and things have changed a lot in that time. the proliference of and ease of establishing bot networks is such that their controllers dont care if you track them and shut them down as they are easily replaced Steve
NANOG Posting
NANOG, It is with great sadness that I inform you that Richard Steenbergen, long-time NANOG contributor and colleague, has been censored by Dr. Harris this morning. Richard will be barred from posting to this list until such a time when the Doctor deems it appropriate. Those who take issue with this decision are encouraged to contact Susan and ask for leniency. Richard's family has asked that contributions be sent to the ACLU free speech fund and Trustees of the University of Michigan in his honor.
Re: NANOG Posting
FREE RICHARD -chris On Wed, 13 Oct 2004, Husan Sarris wrote: NANOG, It is with great sadness that I inform you that Richard Steenbergen, long-time NANOG contributor and colleague, has been censored by Dr. Harris this morning. Richard will be barred from posting to this list until such a time when the Doctor deems it appropriate. Those who take issue with this decision are encouraged to contact Susan and ask for leniency. Richard's family has asked that contributions be sent to the ACLU free speech fund and Trustees of the University of Michigan in his honor.
Re: NANOG Posting
FREE RICHARD so really low capex but high opex? randy
aggregation table entries
i've never seen a dns attack that didn't have 50% or more packets coming from spoofed sources, though due to loose-mode uRPF, most spoofed sources in the last year or so have been from addresses for which a route exists. -- Paul Vixie reiterating a sometimes heretical idea... are you refering to things like 172.17.0.0/16 where only a couple hundred of those numbers have real services, e.g. all the services are in 172.17.22.0/24 and the spoofed addresses are in 172.17.128.0/17 space? or... why do people insist on injecting routes to non-existent things?a route table entry is a route table entry, regardless of the scope. --bill
Re: aggregation table entries
i've never seen a dns attack that didn't have 50% or more packets coming from spoofed sources, though due to loose-mode uRPF, most spoofed sources in the last year or so have been from addresses for which a route exists. -- Paul Vixie reiterating a sometimes heretical idea... are you refering to things like 172.17.0.0/16 where only a couple hundred of those numbers have real services, e.g. all the services are in 172.17.22.0/24 and the spoofed addresses are in 172.17.128.0/17 space? In that example, if the receiver uses loose-mode uRPF to filter ingress and carries within their AS only the minimal set of RFC1918 routes corresponding to their actual use of it, then spoofed-source packets from 172.17.22.0/24 would be allowed in by loose-mode uRPF because a route table entry exists. Packets from the rest of 172.17.0.0/16 would be filtered. Loose-mode uRPF does not protect you from spoofed-source packets where the source address falls within a prefix that you use internally, whether that space is RFC1918 space or not. Likewise, loose-mode uRPF does not (completely) protect you from spoofed-source packets where the source address falls within a prefix that is valid externally, not necessarily via the reverse path on which you're receiving the packet. The first can be addressed with additional filtering, as has been mentioned. The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. or... why do people insist on injecting routes to non-existent things?a route table entry is a route table entry, regardless of the scope. Is this where you advocate that providers only announce the parts of their assigned blocks that are in use? Stephen
Re: aggregation table entries
or... why do people insist on injecting routes to non-existent things?a route table entry is a route table entry, regardless of the scope. Is this where you advocate that providers only announce the parts of their assigned blocks that are in use? seems like a good lead in, so yes - i advocate folks only announce what they use. may play old-hob on the ISP that likes to use some other metric for accepting announcements, (e.g. RIR or other routing registry DB) and will no doubt increase the tension on justification of proxy announcements, but overall, this seems to be a good goal. thanks for letting me rant. :) --bill
Re: Excessive DNS Requests
On Wed, Oct 13, 2004 at 07:49:03PM +0100, Anderson, Ian wrote: Anyone else seeing excessive DNS requests hammering their local forwarders this evening. We've just taken our residence network off-line owing to the level of port 53 traffic coming from it. Can't see anything in the usual places regarding this I see no abnormal dns requests on our caching aswell authorative servers. -- Cliff Albert [EMAIL PROTECTED]
Re: Excessive DNS Requests
quote who=Anderson, Ian Anyone else seeing excessive DNS requests hammering their local forwarders this evening. We've just taken our residence network off-line owing to the level of port 53 traffic coming from it. Can't see anything in the usual places regarding this Things seem normal over here... http://fiona.everybox.com/~davidu/dns1-101304-120500pdt.png (authoritative ns) Are the residents actually making legit DNS queries or just spewing down port 53? -davidu David A. Ulevitch - Founder, EveryDNS.Net http://david.ulevitch.com -- http://everydns.net
website to display AS No and ip info also
Hi all ls there any websites to provide the information about AS no and IP? When typing the AS no, it can display all the information fo the company and IP belongs to this company also Thank you
Re: website to display AS No and ip info also
www.cidr-report.org On Thu, Oct 14, 2004 at 03:19:58AM +0800, adrian kok wrote: Hi all ls there any websites to provide the information about AS no and IP? When typing the AS no, it can display all the information fo the company and IP belongs to this company also Thank you -- Bubba Parker [EMAIL PROTECTED] CityNet LLC http://www.citynetinfo.com/
Re: aggregation table entries
On (13/10/04 18:43), [EMAIL PROTECTED] wrote: Is this where you advocate that providers only announce the parts of their assigned blocks that are in use? seems like a good lead in, so yes - i advocate folks only announce what they use. may play old-hob on the ISP that likes to use some other metric for accepting announcements, (e.g. RIR or other routing registry DB) and will no doubt increase the tension on justification of proxy announcements, but overall, this seems to be a good goal. i thought that a common goal was to announce only your aggregates (which would inherently include unused space) rather than announce all your deag'ed space (which should be more well used) two of my acl's have dropped ~9million packets destined for bogon networks in the past week (only about 20 Mbps on this router)...bogon sources are probably equivalent (although i havent been logging it, but in light of recent discussions, i probably will start again) thanks for letting me rant. :) yep - me too /joshua -- END NET CENSORSHIP - FREE RAS
Re: website to display AS No and ip info also
On Thu, 14 Oct 2004, adrian kok wrote: ls there any websites to provide the information about AS no and IP? When typing the AS no, it can display all the information fo the company and IP belongs to this company also That's what whois does. There are web-sites which gateway to whois, like geektools: http://www.geektools.com/whois.php -Bill
Re: website to display AS No and ip info also
Um, no. That site is a dud, and I have no idea why Crack would be related to ASNs. On Wed, Oct 13, 2004 at 03:29:04PM -0400, [EMAIL PROTECTED] wrote: http://www.smartwhois.net -Original Message- From: Bubba Parker [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 3:21 PM To: adrian kok Cc: [EMAIL PROTECTED] Subject: Re: website to display AS No and ip info also www.cidr-report.org On Thu, Oct 14, 2004 at 03:19:58AM +0800, adrian kok wrote: Hi all ls there any websites to provide the information about AS no and IP? When typing the AS no, it can display all the information fo the company and IP belongs to this company also Thank you -- Bubba Parker [EMAIL PROTECTED] CityNet LLC http://www.citynetinfo.com/ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. -- Bubba Parker [EMAIL PROTECTED] CityNet LLC http://www.citynetinfo.com/
Re: website to display AS No and ip info also
At 03:19 PM 10/13/2004, you wrote: ls there any websites to provide the information about AS no and IP? When typing the AS no, it can display all the information fo the company and IP belongs to this company also http://www.fixedorbit.com/search.htm Have fun! -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 Good will, like a good name, is got by many actions, and lost by one. - Francis Jeffrey
Re: website to display AS No and ip info also
A standard whois program can not tell you what IP addresses a particular AS is announcing. On Wed, Oct 13, 2004 at 12:21:34PM -0700, Bill Woodcock wrote: On Thu, 14 Oct 2004, adrian kok wrote: ls there any websites to provide the information about AS no and IP? When typing the AS no, it can display all the information fo the company and IP belongs to this company also That's what whois does. There are web-sites which gateway to whois, like geektools: http://www.geektools.com/whois.php -Bill -- Bubba Parker [EMAIL PROTECTED] CityNet LLC http://www.citynetinfo.com/
Re: website to display AS No and ip info also
A standard whois program can not tell you what IP addresses a particular AS is announcing. When typing the AS no, it can display all the information fo the company and IP belongs to this company also That's true, however, it's not what he asked. I loosely interpreted belongs to as meaning allocated or assigned to, rather than announced by. -Bill
Re: aggregation table entries
Date: Wed, 13 Oct 2004 18:43:45 + From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] or... why do people insist on injecting routes to non-existent things?a route table entry is a route table entry, regardless of the scope. Is this where you advocate that providers only announce the parts of their assigned blocks that are in use? seems like a good lead in, so yes - i advocate folks only announce what they use. may play old-hob on the ISP that likes to use some other metric for accepting announcements, (e.g. RIR or other routing registry DB) and will no doubt increase the tension on justification of proxy announcements, but overall, this seems to be a good goal. First, we do accept prefixes from most ASes based on RIR. Second, we don't simply assign address space sequentially from our assigned spaces. We have an addressing plan that leaves the assignments deliberately sparse to allow for better management and the ability to keep our PA assignments to a site contiguous. To only announce the active space would increase the number of routes we announce by about 80%. If everyone did this, the routing table would increase massively. So would the time to compute the routes which might lead to some really bad instability for some routers. thanks for letting me rant. :) Any time, Bill. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634
Re: aggregation table entries
The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. i presume you are not intending to recommend that i drop packets that multi-homed customers hand me when they have also asked me to de-pref the prefix from which they come? i might be their backup for inbound, but they need to balance their outbound. randy
Re: aggregation table entries
On Wed, Oct 13, 2004 at 12:54:44PM -0700, Kevin Oberman wrote: Date: Wed, 13 Oct 2004 18:43:45 + From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] or... why do people insist on injecting routes to non-existent things?a route table entry is a route table entry, regardless of the scope. Is this where you advocate that providers only announce the parts of their assigned blocks that are in use? seems like a good lead in, so yes - i advocate folks only announce what they use. may play old-hob on the ISP that likes to use some other metric for accepting announcements, (e.g. RIR or other routing registry DB) and will no doubt increase the tension on justification of proxy announcements, but overall, this seems to be a good goal. First, we do accept prefixes from most ASes based on RIR. good traditional thinking requireing me to announce the whole /20 when all i'm using is a /27... after all, its just one routeing table entry... why should you care? :) (playing straightman) Second, we don't simply assign address space sequentially from our assigned spaces. We have an addressing plan that leaves the assignments deliberately sparse to allow for better management and the ability to keep our PA assignments to a site contiguous. To only announce the active space would increase the number of routes we announce by about 80%. If everyone did this, the routing table would increase massively. So would the time to compute the routes which might lead to some really bad instability for some routers. so -IF- everyone followed your internal address assignment policies, scattering used space in a sparse matrix throughout the allocated pool, then announing a single prefix (the aggregate) makes sense. Of course this leaves you w/ lots of space that is useful for forging as valid source addresses. (we'll even leave DHCP pools out of the discussion - for now) so it would make sense for you to announce the aggregate - since you use random bits throughout (nice marbling!) but for those folks who use a more compact internal representation, is there a good reason to reject their /27 instead of the larger /20 that has been allocated? thanks for letting me rant. :) Any time, Bill. I'll try and use it wisely --bill
Re: website to display AS No and ip info also
Cliff Albert wrote: On Wed, Oct 13, 2004 at 02:33:53PM -0500, Bubba Parker wrote: A standard whois program can not tell you what IP addresses a particular AS is announcing. Actually it can tell you what IP adresses a particular AS SHOULD announce. whois -i origin -h whois.ripe.net AS28788 And what it actually announced, and when, can be found here... http://www.ripe.net/projects/ris/tools/index.html Ian
Reminder: Who has VA INET GOD?
I seem to remember someone telling me they had this license plate. Saw it today, not sure I recognized the driver. Would someone mind refreshing my poor little memory? Thanks, Deepak
Re: NANOG Posting
On Wed, 13 Oct 2004, Christian Malo wrote: FREE RICHARD Of course my understanding of revoking posting privileges is that you cant post to the list.. not you are imprisoned in the merit dungeons, i think that punishment is reserved for Bandy/Husan/etc However I do like some humor being injected onto the list, so long as the SNR doesnt diminish too much it can help to inject some life inbetween the 'paging bob smith' / 'anyone help me configure bgp' / path mtu / urpf cyclical debates.. actually we've not had Hitler discussed for a while, perhaps I can start a thread... ooops Steve
Re: aggregation table entries
The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. i presume you are not intending to recommend that i drop packets that multi-homed customers hand me when they have also asked me to de-pref the prefix from which they come? i might be their backup for inbound, but they need to balance their outbound. No, I'm not recommending that. In the example that you give, the prefix from which the packets in question will be sourced *is* offered as a destination? Assuming yes, then regardless of whether that offer is selected as the best to use to reach the destination or not, the edge router that needs to make the decision to accept or reject packets sourced in that prefix can use its knowledge that the offer was made to accept packets. The problem is differentiating these two cases: 1. the offer of a route to a prefix is not made but packets sourced in that prefix are legitimate and are expected to be forwarded; the reverse path is only available through a different AS 2. the source address is spoofed; packets are not legitimate and should be dropped Once upon a time, I tried to enable loose-mode uRPF on a peering interface, effectively treating #1 as #2. The complaints were relatively instantaneous (at 2am local for me, a traffic-low time), and not localized to a specific source prefix (the majority were residential broadband users); I wound up turning the loose-mode uRPF check off in fairly short order. Attempts to discover why #1 was happening ended with technical people shrugging their shoulders and saying that the money people made them do it. Stephen
NANOG censorship
|On Wed, 13 Oct 2004, Husan Sarris wrote: | | NANOG, | | It is with great sadness that I inform you that Richard Steenbergen, | long-time NANOG contributor and colleague, has been censored by |Dr. ETC. finally! i just want to say how disappointed I am that people have been posting notes using our names with the letters mixed around over the last few years. thanks doc for finally kicking one of these trangressors off the list. sincerely, -- Bandy Rush, Dean Soran, Husan Sarris, and Sichard Reenbergen 3 more to go!!
3 Mb question
I've got what seems to me like an innocuous question for this list... Someone is requesting access to about 3 mb of traffic up/dn. I figure 2 T1s will give them the 3 Mb I need, but I'm looking for suggestions on either efficiently combining those 2 to get the most bandwidth for their buck or else I have to look at getting them a ds3 and scaling back to what they need. Is there an good low end suggestion for making effective use of 2 T1s to give 3 Mb of bandwidth? In practice, I've seen 2 T1s load balanced with CEF not do very well at giving a full 3 Mb. (This was without turning on per-packet CEF) I'm not personally experienced with MLPPP or mux hardware if that helps, but I could get it set up if that's the consensus as the best option. The NRC of something that would effectively couple the 2 T1s would easily beat the MRC of a DS3 which I think might be overkill for just 3 Mb. Thanks for suggestions and tips. Gerald
Re: aggregation table entries
The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. i presume you are not intending to recommend that i drop packets that multi-homed customers hand me when they have also asked me to de-pref the prefix from which they come? i might be their backup for inbound, but they need to balance their outbound. No, I'm not recommending that. so i suspected g In the example that you give, the prefix from which the packets in question will be sourced *is* offered as a destination? not by me. but by one or more of the originator's other upstreams. i suspect this is not uncommon. The problem is differentiating these two cases: 1. the offer of a route to a prefix is not made but packets sourced in that prefix are legitimate and are expected to be forwarded; the reverse path is only available through a different AS 2. the source address is spoofed; packets are not legitimate and should be dropped Once upon a time, I tried to enable loose-mode uRPF on a peering interface, effectively treating #1 as #2. The complaints were relatively instantaneous (at 2am local for me, a traffic-low time), and not localized to a specific source prefix (the majority were residential broadband users); I wound up turning the loose-mode uRPF check off in fairly short order. Attempts to discover why #1 was happening ended with technical people shrugging their shoulders and saying that the money people made them do it. yep. some times it is even less intentional and less understood; see tim's paper on bgp wedgies. and the management made me do it, is a bit disingenuous. it's part of what it means to have customers. randy
Re: 3 Mb question
multilinking t1s will work fine. but depending on your customer, there are lots of things between a T1 and DS3.. such as 10Mb ethernet Steve On Wed, 13 Oct 2004, Gerald wrote: I've got what seems to me like an innocuous question for this list... Someone is requesting access to about 3 mb of traffic up/dn. I figure 2 T1s will give them the 3 Mb I need, but I'm looking for suggestions on either efficiently combining those 2 to get the most bandwidth for their buck or else I have to look at getting them a ds3 and scaling back to what they need. Is there an good low end suggestion for making effective use of 2 T1s to give 3 Mb of bandwidth? In practice, I've seen 2 T1s load balanced with CEF not do very well at giving a full 3 Mb. (This was without turning on per-packet CEF) I'm not personally experienced with MLPPP or mux hardware if that helps, but I could get it set up if that's the consensus as the best option. The NRC of something that would effectively couple the 2 T1s would easily beat the MRC of a DS3 which I think might be overkill for just 3 Mb. Thanks for suggestions and tips. Gerald
Re: aggregation table entries
yep. some times it is even less intentional and less understood; see tim's paper on bgp wedgies. and the management made me do it, is a bit disingenuous. it's part of what it means to have customers. My customers, back when I had them, must have been better-behaved than most.
Verio Routing
Did anyone else just get a hiccup on Verio circuits? Lost routing in small 2-5 second bursts incrementally over the past 10 minutes. Joe Johnson JMDN.net
Re: aggregation table entries
yep. some times it is even less intentional and less understood; see tim's paper on bgp wedgies. and the management made me do it, is a bit disingenuous. it's part of what it means to have customers. My customers, back when I had them, must have been better-behaved than most. then why did you get those calls you mention in your last message? randy
Re: aggregation table entries
yep. some times it is even less intentional and less understood; see tim's paper on bgp wedgies. and the management made me do it, is a bit disingenuous. it's part of what it means to have customers. My customers, back when I had them, must have been better-behaved than most. then why did you get those calls you mention in your last message? They weren't from customers, they were from users connected to Other People's Networks who couldn't reach my customers. I took trouble tickets from them, too.
FW: Verio Routing
We saw a hiccup in San Diego. Routes towards a lot of our monitored customers vanished and starting going out other providers... James Laszko Pipeline Communications, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Johnson Sent: Wednesday, October 13, 2004 3:06 PM To: [EMAIL PROTECTED] Subject: Verio Routing Did anyone else just get a hiccup on Verio circuits? Lost routing in small 2-5 second bursts incrementally over the past 10 minutes. Joe Johnson JMDN.net
Re: NANOG censorship
Bandy Rush, Dean Soran, Husan Sarris, and Sichard Reenbergen ^^ Clearly an imposter... Anyone who knows Dean S. Moran knows he would never misspell his own name. -Bill
Updated monitoring pages from Team Cymru
[ Apologies to those of you who receive this note in multiple forums. ] Hi, team. We are pleased to announce some updated monitoring, as well as some new monitoring, on our web site. This includes aesthetic fixes as well as increased visibility. Our DNS monitoring now has increased visibility as well as a new look and feel. Gone are the multiple pages for each zone, replaced with a single page that will have additional zones soon. You'll find it at the following URL. http://www.cymru.com/DNS/dns.html The times are DNS query response times, and the query responses are checked for correctness. Clicking on the query response time will bring you to a more detailed, graphical view of the query responses for the given pod and name server combination. We've updated our network monitoring to include several new components. This includes pod to pod ICMP, TCP, and UDP monitoring. It also includes traffic graphs for a select few Darknet pods, and our new Internet Garbage Meter. :) http://www.cymru.com/Reach/index.html For more on Darknets, from which our Darknet monitoring and Internet Garbage Meter are generated, please see our Darknet Project page at the following URL. http://www.cymru.com/Darknet/ We hope you find this of use. Comments and suggestions are always welcome! Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: Verio Routing
We have an OC3 with Verio and took a hit as well.. On Wed, 13 Oct 2004 17:06:02 -0500 Joe Johnson [EMAIL PROTECTED] wrote: Did anyone else just get a hiccup on Verio circuits? Lost routing in small 2-5 second bursts incrementally over the past 10 minutes. Joe Johnson JMDN.net ** Richard J. Sears Vice President American Digital Network [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
RE: Verio Routing
Everything did come back up before I sent the email (otherwise I wouldn't have been able to unless I dialed in). I was a little disappointed about their blanket temporary major network issues statement from Level 3 support. Normally they are really good about support. Joe Johnson JMDN.net -Original Message- From: Richard J. Sears [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 13, 2004 5:27 PM To: Joe Johnson Cc: [EMAIL PROTECTED] Subject: Re: Verio Routing We have an OC3 with Verio and took a hit as well.. On Wed, 13 Oct 2004 17:06:02 -0500 Joe Johnson [EMAIL PROTECTED] wrote: Did anyone else just get a hiccup on Verio circuits? Lost routing in small 2-5 second bursts incrementally over the past 10 minutes. Joe Johnson JMDN.net ** Richard J. Sears Vice President American Digital Network [EMAIL PROTECTED] http://www.adnc.com 858.576.4272 - Phone 858.427.2401 - Fax INOC-DBA - 6130 I fly because it releases my mind from the tyranny of petty things . . Work like you don't need the money, love like you've never been hurt and dance like you do when nobody's watching.
Re: 3 Mb question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...also look into IMA (inverse multiplex atm). regards, /vicky Gerald wrote: | I've got what seems to me like an innocuous question for this list... | | Someone is requesting access to about 3 mb of traffic up/dn. I figure 2 | T1s will give them the 3 Mb I need, but I'm looking for suggestions on | either efficiently combining those 2 to get the most bandwidth for their | buck or else I have to look at getting them a ds3 and scaling back to | what they need. | | Is there an good low end suggestion for making effective use of 2 T1s to | give 3 Mb of bandwidth? In practice, I've seen 2 T1s load balanced with | CEF not do very well at giving a full 3 Mb. (This was without turning on | per-packet CEF) | | I'm not personally experienced with MLPPP or mux hardware if that helps, | but I could get it set up if that's the consensus as the best option. | The NRC of something that would effectively couple the 2 T1s would | easily beat the MRC of a DS3 which I think might be overkill for just 3 | Mb. | | Thanks for suggestions and tips. | | Gerald | -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBbb0TpbZvCIJx1bcRAtrbAKDxZDh+ln530q9peNDO5spDq6Qh6ACcD9/P Jf/tXerUTYMWuqwvnhCIPkw= =fhaT -END PGP SIGNATURE-
Re: aggregation table entries
On Wed, 13 Oct 2004, Randy Bush wrote: The second is a harder problem, because of the business decisions of some providers to source packets from prefixes that they do not announce. i presume you are not intending to recommend that i drop packets that multi-homed customers hand me when they have also asked me to de-pref the prefix from which they come? i might be their backup for inbound, but they need to balance their outbound. FWIW, (you probably know this, but most on nanog maybe don't), If you do 'feasible path strict uRPF' as described in BCP84 (I don't know if others than Juniper are providing that), you can enable strict uRPF toward those customers, still de-pref them, and accept the packets with correct source addresses. That's what we do with our customers whether multihomed or not. One can also achieve the same without 'feasible path' by operationally adjusting the weight or preference for the advertisement you receive w/ eBGP and the advertisement you send in iBGP (so that only that one router would send its traffic over that link), but that's likely a bit more work and operational complexity. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
