- Test - lists.nanog.org

Internic contact?
by Alex Rubenstein 06 Jan '98

06 Jan '98

Who do I speak to at the internic in regards to a root-server not foing proper delegation for a domain? I called the 703.742.4777 #, and got a nobody, who transfered me to the 'second level tech'. He must be sleeping, cause they never answered the phone after abotu 30 rings. HELP!

1 0

Re: route ingress [summary 3]
by Paul A Vixie 06 Jan '98

06 Jan '98

I think this discussion is pretty well played out. ------- Forwarded Messages > so the question that's got me perturbed at the moment is, if a spammer wanted > to spam from unallocated address space using five minute windows, would YOUR > routing core allow it? subquestion 1: if the spammer is your customer. Almost always no. Almost all BGP speaking customers are filtered by network and AS-Path. There are a couple who aren't who are filtered by network (i.e. are filtered by path only) who should know better. We are putting PRDB filtering on when we get the code ready. > subquestion 2: if the spammer is a customer of one of your BGP peers. Currently yes. Again we have PRDB filtering in the pipeline to fix this. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. Currently yes. I do not currently plan to apply PRDB filtering to transit providers - the connectivity loss would be too great. We will also leave it off for large peers (UUnet for instance). *HOWEVER* we've got some experimental stuff which generates ACLs (i.e. filterlists) based on unallocated space, as well as BGP network filtering (the IP access group business mostly for our amusement - the real idea is to use these to automatically build customer facing anti-spoofing filters from RIPE/RA etc.). Blackholing stuff destined for unallocated blocks is neater by far. My fear is that people will instead pick an unused prefix as opposed to an unregistered one. IE if I advertize a /16 like 195.224.0.0 and the top /19 is not used, some joker will probably have a fair amount of success stealing the top /19 for a few minutes to spam with. Worse still, they probably would have a fair amount of success stealing an *inuse* more specific of a block - and that really does have nasty consequences. [ i think we can take for granted that spammers, at least, will only steal resources in ways they think won't be noticed. on the other hand, sequence number guessing such that you don't care if the recipient can EVER get a packet back to you, is probably even better by that measure. --vix ] ------- Message 2 >i've been tracking some spammers through unallocated address space of late. >i'm about to have to turn on extreme-level debugging in my bgp speaker, since >what's been happening is that a route is injected "somewhere" to unallocated >space, a whole boatload of relayspam is unloaded in a matter of minutes, and >the unallocated-space route is withdrawn. The Merit/RA/RSNG/etc folks keep logs containing every BGP announcement and withdrawal seen by the route servers. >however, when you set up BGP peerage with somebody, you're at the mercy of >whatever level of selectivity they use in their injections. that is, most >folks do not use RPSL or the PRDB or whatever to control what they'll listen >to from a BGP peer. the assumption of trust and competence still runs high >among people who speak BGP to each other. Believing any transitive source leads to the same vulnerability, whether it is BGP or a database like PRDB or IRR. The problem isn't one of too much trust or competence, but rather distrust and corporate priorities. >so the question that's got me perturbed at the moment is, if a spammer wanted >to spam from unallocated address space using five minute windows, would YOUR >routing core allow it? subquestion 1: if the spammer is your customer. >subquestion 2: if the spammer is a customer of one of your BGP peers. >subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. First you have to decide what is "unallocated address space." Unallocated by whom: IANA, a regional registry, a provider, or even an end-user? And I suspect it isn't just a question of unallocated address space, but also what used to be known as "connected status." There are several allocated address blocks which are never announced to the Internet. Longest match rules of CIDR makes any network subnet that isn't actively being used vulnerable to unnoticed hijacking. The reason its important to decide what type of unallocated address space is involved is because there are a variety of ingress filters used by different providers and they stop different things. The common methods are 1) filtering by expected address, 2) filtering by AS number or path, 3) filtering by exception, e.g. blocking martian networks. Or filtering using a combination of those methods. A provider might block announcements from net 1.1.1.1, but not block 213.1.1.1. [ i am primarily interested in space which has not been allocated by IANA, or which has been allocated by IANA but not by the regional registry yet. unused portions of allocated, connected, advertised blocks are so much harder for me to track that i know i never shall track them. --vix ] Answers to your questions 1: We have a lot of backdoor connections to sites that are also connected to the former NSF regional networks. In general, we have to filter our customer connections to prevent all sorts of routing leaks, not just unallocated address announcements. BGP speaking customers provide a list of network numbers and ASNs they plan to announce. Currently they are manually verified against WHOIS and then entered into the IRR databases. BGP core routers have egress filters to prevent both unintended transit, and unknown network announcements. This also acts as a belt-and-suspenders approach to preventing unintended network announcements beyond our network. 2: All BGP peers are passed through an "Oops filter" blocking patently offensive network announcements (martians, extremely long prefixes, broadcast, loopback and default). Unallocated addresses aren't blocked (currently) by my Oops filter. A few BGP peers have explicit network address ingress filters, which would block an unallocated address. 3: Currently I don't have any source ASN/IP address cross-checking. A distant BGP-connected AS could announce any network I accept from the BGP peer in tha path directly connected to me. The same Oops filter or applies in any case. And finally, a couple of untested filters For those that prefer "if it isn't explicitly denied, allow it": ! Based on ftp://ftp.isi.edu/in-notes/iana/assignments/ipv4-address-space ! as of Dec 30, 1997, check for new allocations if used ! IANA - Reserved access-list 100 deny ip 0.0.0.0 0.255.255.255 any access-list 100 deny ip 1.0.0.0 0.255.255.255 any access-list 100 deny ip 2.0.0.0 0.255.255.255 any access-list 100 deny ip 5.0.0.0 0.255.255.255 any access-list 100 deny ip 7.0.0.0 0.255.255.255 any ! IANA - Private Use access-list 100 deny ip 10.0.0.0 0.255.255.255 any ! IANA access-list 100 deny ip 23.0.0.0 0.255.255.255 any access-list 100 deny ip 27.0.0.0 0.255.255.255 any access-list 100 deny ip 37.0.0.0 0.255.255.255 any access-list 100 deny ip 39.0.0.0 0.255.255.255 any access-list 100 deny ip 41.0.0.0 0.255.255.255 any access-list 100 deny ip 42.0.0.0 0.255.255.255 any access-list 100 deny ip 58.0.0.0 0.255.255.255 any access-list 100 deny ip 59.0.0.0 0.255.255.255 any access-list 100 deny ip 60.0.0.0 0.255.255.255 any ! IANA - Reserved 64/8 - 127/8 (Note: 127/8 is LOOPBACK, not RESERVED) access-list 100 deny ip 64.0.0.0 63.255.255.255 any ! IANA - Private Use access-list 100 deny ip 172.16.0.0 0.15.255.255 any ! IANA - Private Use access-list 100 deny ip 192.168.0.0 0.0.255.255 any ! IANA - Reserved 213/8 - 223/8 access-list 100 deny ip 213.0.0.0 0.255.255.255 any access-list 100 deny ip 214.0.0.0 1.255.255.255 any access-list 100 deny ip 216.0.0.0 7.255.255.255 any ! IANA - Multicast 224/8 - 239/8 access-list 100 deny ip 224.0.0.0 15.255.255.255 any ! IANA - Reserved 240/8 - 255/8 access-list 100 deny ip 240.0.0.0 15.255.255.255 any ! If not denied above, assume address is an allocated IPv4 unicast address access-list 100 permit ip any any For those that prefer "unless explicitly allowed, deny it": ! Based on ftp://ftp.isi.edu/in-notes/iana/assignments/ipv4-address-space ! as of Dec 30, 1997, check for new allocations if used access-list 100 permit ip 3.0.0.0 0.255.255.255 any access-list 100 permit ip 4.0.0.0 0.255.255.255 any access-list 100 permit ip 6.0.0.0 0.255.255.255 any access-list 100 permit ip 8.0.0.0 0.255.255.255 any access-list 100 permit ip 9.0.0.0 0.255.255.255 any access-list 100 permit ip 11.0.0.0 0.255.255.255 any access-list 100 permit ip 12.0.0.0 0.255.255.255 any access-list 100 permit ip 13.0.0.0 0.255.255.255 any access-list 100 permit ip 14.0.0.0 0.255.255.255 any access-list 100 permit ip 15.0.0.0 0.255.255.255 any access-list 100 permit ip 16.0.0.0 0.255.255.255 any access-list 100 permit ip 17.0.0.0 0.255.255.255 any access-list 100 permit ip 18.0.0.0 0.255.255.255 any access-list 100 permit ip 19.0.0.0 0.255.255.255 any access-list 100 permit ip 20.0.0.0 0.255.255.255 any access-list 100 permit ip 21.0.0.0 0.255.255.255 any access-list 100 permit ip 22.0.0.0 0.255.255.255 any access-list 100 permit ip 24.0.0.0 0.255.255.255 any access-list 100 permit ip 25.0.0.0 0.255.255.255 any access-list 100 permit ip 26.0.0.0 0.255.255.255 any access-list 100 permit ip 28.0.0.0 0.255.255.255 any access-list 100 permit ip 29.0.0.0 0.255.255.255 any access-list 100 permit ip 30.0.0.0 0.255.255.255 any access-list 100 permit ip 31.0.0.0 0.255.255.255 any access-list 100 permit ip 32.0.0.0 0.255.255.255 any access-list 100 permit ip 33.0.0.0 0.255.255.255 any access-list 100 permit ip 34.0.0.0 0.255.255.255 any access-list 100 permit ip 35.0.0.0 0.255.255.255 any access-list 100 permit ip 36.0.0.0 0.255.255.255 any access-list 100 permit ip 38.0.0.0 0.255.255.255 any access-list 100 permit ip 40.0.0.0 0.255.255.255 any access-list 100 permit ip 43.0.0.0 0.255.255.255 any access-list 100 permit ip 44.0.0.0 0.255.255.255 any access-list 100 permit ip 45.0.0.0 0.255.255.255 any access-list 100 permit ip 46.0.0.0 0.255.255.255 any access-list 100 permit ip 47.0.0.0 0.255.255.255 any access-list 100 permit ip 48.0.0.0 0.255.255.255 any access-list 100 permit ip 49.0.0.0 0.255.255.255 any access-list 100 permit ip 50.0.0.0 0.255.255.255 any access-list 100 permit ip 51.0.0.0 0.255.255.255 any access-list 100 permit ip 52.0.0.0 0.255.255.255 any access-list 100 permit ip 53.0.0.0 0.255.255.255 any access-list 100 permit ip 54.0.0.0 0.255.255.255 any access-list 100 permit ip 55.0.0.0 0.255.255.255 any access-list 100 permit ip 56.0.0.0 0.255.255.255 any access-list 100 permit ip 57.0.0.0 0.255.255.255 any access-list 100 permit ip 61.0.0.0 0.255.255.255 any access-list 100 permit ip 62.0.0.0 0.255.255.255 any access-list 100 permit ip 63.0.0.0 0.255.255.255 any ! IANA - Private Use access-list 100 deny ip 172.16.0.0 0.15.255.255 any ! 128-191/8 access-list 100 permit ip 128.0.0.0 63.255.255.255 any ! IANA - Private Use access-list 100 deny ip 192.168.0.0 0.0.255.255 any ! 192-212/8 access-list 100 permit ip 192.0.0.0 15.255.255.255 any access-list 100 permit ip 208.0.0.0 3.255.255.255 any access-list 100 permit ip 212.0.0.0 0.255.255.255 any ! If not permitted above, assume address is not an allocated IPv4 address access-list 100 deny ip any any [ i have to caution against installing such filters in most networks, since it will make it really really hard for us as a community to ever use that unallocated space. this is one instance where it is safer to use the RBL (which has synchronized withdrawal) than to filter things locally. though i would feel pretty great if IANA would advertise routes to its unallocated space, just to "claim" it. --vix ] ------- Message 3 Because you indicated some concern over the silent replies the first time around, I will add our "me too". We filter our outbound announcements, and specify them using network statements anyway. Injecting routes is not a good way for us to do things. Regarding route announcements we listen to, we accept them without filters, and carry full tables, so we are susceptible to remote AS's which add unallocated routes, then withdraw them. We are multihomed to only two providers, Sprint and XXX. XXX gets most of their routes from MCI, whom I believe peers with the RADB, while the Sprint peerage is likely to be more suspect. We do not allow relay mail, so we are more likely to be stung by this than inflict it on someone else. ------- Message 4 >so the question that's got me perturbed at the moment is, if a spammer wanted >to spam from unallocated address space using five minute windows, would YOUR >routing core allow it? subquestion 1: if the spammer is your customer. No, we have filters on our outgoing that allow out only the networks we are currently advertising. >subquestion 2: if the spammer is a customer of one of your BGP peers. We don't have any customers doing BGP to us, but I would throw filters down on their connection as well, so only the networks they were advertising or ones they planned to advertise could get out. >subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. Connected to my AS? I think the response to 2 would apply to 3. If not to my AS, there's not much I can do about it. ------- Message 5 > so the question that's got me perturbed at the moment is, if a spammer wanted > to spam from unallocated address space using five minute windows, would YOUR > routing core allow it? subquestion 1: if the spammer is your customer. no. > subquestion 2: if the spammer is a customer of one of your BGP peers. currently yes, changed to no in a week. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. currently yes, changed to no in a week. ------- Message 6 From: smd(a)clock.org > > one day the routing will collapse; you would think people might have been > > frightened by recent redistribution or deaggregation disasters, but people > > go blithely on not filtering. > > there are a lot of fence sitters such as myself who know that filtering > is good but who don't want to maintain 10,000 element filter lists for > big peers like uunet and who don't want to just trust sprint to do the > right thing and who don't want to run RPSLmumble. what's the right answer? There is no right answer; it is endemic to the IP (v4/v6) addressing structure. The right thing to do is to can development on IPv6 since it (mo's proposal notwithstanding) irretrievably suffers the same problems with respect to the trust versus dynamism trade-off for external routing. Next, work on developing some of the good ideas which were abandoned after (and during) ROAD/BIGTEN in favour of the current IPv6 proposal, letting the best get picked through natural (rather than committee) selection. IOW, work out a scheme whereby translating gateways can be used to make it possible to build a multiprotocol catenet which supports current and future applications decently. Then let people choose what they want to run where. Note that this is essentially (and ironically) what Bound's NNAT amounts to, although his is more a clever hack rather than something architecturally sound. My gut feeling is that admitting that IPv4 will be around in some form or another for a long time will allow us to focus on fixing some of its near-term deficiencies, none of which have been touched on in IPv6 development. That in turn buys us more time to develop and learn from the partial deployment of alternative protocols. Current answer for the routing system: prayer? Sean. ------- End of Forwarded Messages

4 3

International Internet Connectivity
by George McCormick 05 Jan '98

05 Jan '98

I would be extremely appreciative if someone could explain to me how US ISPs and backbone operators address their international connectivity requirements: o How is their traffic routed? o How do peering relationships work and where do they take place? o Who pays whom for international transport(undersea cable and/or satellite) and services? Sincerely, George McCormick CSMG Cambridge, Massachusetts 617-864-0022

2 1

Request for State of the Internet Volunteers
by William B. Norton 05 Jan '98

05 Jan '98

Hi all - At the last couple of NANOGs I asked the audience if they were interested in another State of the Internet presentation set as we had done back in Washington, D.C. (NANOG 7) and the answer was a resounding yes. So, I am sending this request to the nanog list asking for: 3 volunteers from the ISP community, 3 volunteers from the Exchange Point community, and 3 volunteers that could reflect the current end-user community Internet experience. As we did the first time, each will be asked to give a 10 minute 3-4 slide talk answering the following three questions: 1) What are the top three most pressing problems you face? 2) What is the topology of your backbone or Exchange Point, or end-user, how are you connected? 3) What quantitative data do you have to share to show these problems? The hope is that we can identify a couple of common problems to the NANOG community that can be addressed by the router vendors, software or OS developers, ISP community itself, Exchange Point Operators, TelCos, Facilities Providers, etc. If you would like to volunteer to speak in this segment of the NANOG meeting, please e-mail me a paragraph that will give me an idea of the answers to the above 3 questions. If you have slides or web pointers that would be wonderful. Please send this to wbn(a)merit.edu with "State of the Internet Volunteer" in the subject field. Those speaking at NANOG 12 will of course get in free and receive the limited edition versions of the NANOG 12 speaker T-shirts ;-) Thanks, Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

1 0

Re: route ingress
by Vadim Antonov 05 Jan '98

05 Jan '98

Are there any pointers? Thanks! --vadim > The only real solution is strong cryptographical authentication of > the ownership of routing prefixes. For some reason i do not see > any serious work in that direction being done. Actually, it is being done. It's not ready for implementation yet. Tony

4 3

ATM --> HSSI
by andrew khoo 05 Jan '98

05 Jan '98

what box can i use to convert PacBell ATM (for PacBell NAP) into HSSI? ============================================================== andrew khoo - rebel leader aus: +61-2-9223-2777 Ourworld Global Network, Australia usa: +1-415-902-8820 ============================================================== -- We Bite (tm) --

5 4

RE: aggregation tool
by Dave Van Allen 05 Jan '98

05 Jan '98

Jared, Avi Freedman <freedman(a)netaxs.com> had begun work on an aggregate evaluator some time back. A quick look at http://www.routes.netaxs.com/ shows it has not seen new work since April of 1996. I think your idea is very worthwhile - perhaps Avi can share some of his experiences with you. Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions -----Original Message----- From: Jared Mauch [mailto:jared@puck.nether.net] Sent: Friday, January 02, 1998 3:23 PM To: nanog(a)merit.edu Subject: aggregation tool How many backbone NSP's would use a bgp aggreation tool that was setup similar to the route-views.oregon-ix.net or route-server.cerf.net that you would be able to do queries on to say "what might I not be aggregating correctly?" I'm working on such a tool that would be able to speak eBGP to a router (multihop or otherwise) and give this information. I've noticed a few providers that have /16's that announce each specific /24 or almost each one also, this would also make it possible to generate lists of folks that clog the routing table. I've sent e-mail to some of these folks today... Please direct responses directly to me if you're interested, or if you have something useful on this topic for *everyone* on nanog, include them also. - Jared -- ----------------- jared(a)puck.nether.net - Nether Network ------------------ CICNet/IAGNet/QUALnet/NetherNet - finger jared(a)puck.nether.net for pgp key

2 1

Re: ATM --> HSSI
by Eric Kozowski 05 Jan '98

05 Jan '98

At 04:14 AM 1/6/98 +1100, andrew khoo wrote: >what box can i use to convert PacBell ATM (for PacBell NAP) into HSSI? > kentrox adsu -- they supposedly work now.

1 0

Re: Things to do to make the network better
by Pete Ashdown 05 Jan '98

05 Jan '98

Owen DeLong said once upon a time: >> I will also point out that many of the recent "smurf" attacks and >> similar problems people are having on the net would be gone if people >> would just carefully filter internal/external addresses on their >> border machines, that is, prevent packets claiming to be from "inside" >> networks from coming in from the "outside", and prevent packets >> claiming to be from "outside" networks from going out from the >> "inside". The latter will stop your network from *ever* being the >> source of a wide variety of packet forgery attacks, and is necessary >> to being a good network citizen. The former will stop your network >> from being the subject of a wide variety fo packet forgery attacks, >> and is necessary to make your customers even remotely safe on the net. Expecting everyone else to do the right thing is the wrong way to solve the problem. 99% of everyone else will always do the easiest thing, which is nothing. >That's great if you're a downstream provider with no transit customers. >However, when you become a transit provider, it becomes much more difficult >to determine inside vs. outside, since you're more in the middle between >two "outsides" that pass traffic through you. Use customer configurable filters. There is no excuse for becoming less responsible as you grow larger.

1 0

Re: Whoa; the 3 network?
by rja＠corp.home.net 05 Jan '98

05 Jan '98

GE was the original party that was allocated Net 3, directly back when IP began. Your statements to the contrary were inaccurate. Regards, Ran

1 0