January 1998 - Test - lists.nanog.org

cisco FAQ UPDATE
by Dave Van Allen 06 Jan '98

06 Jan '98

Happy New Year! We have completed the move of the old CISCO-FAQ to its new home and final resting spot. ftp.fast.net/cisco This is the new semi-official site and directory of both the old (deferred) FAQ and soon the new revamped FAQ. There are a few announcement files in the directory that will go into detail on how we are working to get an up to date FAQ, at least started by end of January. Before the holidays, I asked if anyone would be kind enough to send me <dave(a)fast.net> config files (stripped of passwds and incriminating stuff) along with a brief explanation of the more advanced sections. I received a few - THANK YOU! However I need many more - Specifically I am interested in collecting complex BPG configs that exploit the more advanced attributes such as communities, MED's and route reflectors. We also need ATM and FDDI config examples, a touch of CLNS, a sprinkle of IS-IS and OSPF with just a splash of IPX. SMNP, ACL's and general IP interface examples will also go along way. I will keep all configs sent confidential, and will only use sections in the FAQ that are generic. I will run everything past the donator prior to public consumption, and of course you'll get a plug for the help. We need general questions and answers too. We have set up a LISTSERV for the sole and exclusive purpose of submitting info to the FAQ. Details are in the .ann file on the ftp site. A special cry goes out to the gurus, you know who you are. You run the Net or at least help keep it running. I'd really like to hear from you - with even a quick config snippet, anything. We have a small team set up and ready to finally get an updated FAQ out after many years. We're committed and we appreciate your help! 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

1 0

Re: UDP port 137 Question
by Joe Pruett 06 Jan '98

06 Jan '98

this is a wonderful feature of ms internet explorer. when it connects to an http server, it also tries to make an smb connection as well.

2 1

Re: UDP port 137 Question
by Joe Provo - Network Architect 06 Jan '98

06 Jan '98

>One would hope the backbones aren't passing 255.255.255.255 around to come >in via his Internet connection You would be surprised at the *source* addresses on packets that hit some of my borders: [typical 1918 addresses clipped] deny ip 127.0.0.0 0.255.255.255 any (56 matches) deny ip host 0.0.0.0 any (1818 matches) I find source 0/0 to be truly entertaining. Cheers, Joe -- Joe Provo, Network Architect 508.229.8400 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: Deciding whose network block is whose?
by Sean M. Doran 06 Jan '98

06 Jan '98

Geoff Huston <gih(a)telstra.net> writes: > I am looking to the regional registeries to take some level of initiative > and provide clients of their address allocation service the ability to > sign the allocation and then the client can sign the routing request to the > provider which the provider can verify against the regional registry. > We went through this in discussion in the room at the time and it > looked like a viable and useful approach. Yes, but this is only part of the problem. I mean, fantastic idea, but then it's not exactly transitive. How do I know I can trust that Telstra's announcements have been authorized by the people responsible for the prefixes in question? Worse, since I do not talk directly with Telstra, how do I know I can trust the intermediary networks not to have performed (or fallen victim to) AS path surgery? Moreover, other than prefix-length filtering, what can I do to prevent falling victim to subnet-announcement attacks? Note that a larger CIDR block can still fall victim to announcements of /19s in networks which use The Satanic Filters. Perhaps you have some idea other than mine (prayer) for scalably solving these and similar issues? Sean.

2 1

Re: UDP port 137 Question
by gary flynn 06 Jan '98

06 Jan '98

> From: "C. Jon Larsen" <jlarsen(a)ford.ajtech.com> > > Is there any *valid* reason to see UDP traffic directed at a unix box's > port 137 coming from IP sources across the internet ? The unix servers in > question are most definitely *not* running samba, and there is absolutely > no NT anywhere on this customer's network (that is seeing the incoming UDP > traffic directed at an IP destination address on port 137). (A couple > of 95 boxes scattered across an Ethernet comprise the Micro$oft part of > the network). None of the 95 boxen are running any file or print serving > (sharing) resources. > > I can't think of any valid reason to see this traffic, personally. Anybody > out there that can present a scenario where I would expect to see these > UDP packets coming back in ? > > netbios-ns 137/tcp nbns > netbios-ns 137/udp nbns > netbios-dgm 138/tcp nbdgm > netbios-dgm 138/udp nbdgm > netbios-ssn 139/tcp nbssn Windows boxes will attempt name resolution using whatever protocols are configured...TCP/IP, Netbios, Netbios/TCP, Netbios/IPX, etc. Our name servers and some other public boxes are hit all the time because of this. (A campus WINS server would really cut down on this but we haven't got around to it yet.) I've seen a *LOT* of LAND attacks using these ports too. (i.e. 134.126.1.2 port 137 -> 134.126.1.2 port 137) Is the source address and port the same as the destination? I also seem to recall that using a Web browser (IE only?) on a Windows client with TCP and Netbios configured will hit these ports but I don't remember the details. If the Win95 boxes are browsing exterior NT based Web servers, those servers may be attempting name lookups for the Win95 boxes to the authoritative name servers. Or someone may just be scanning the network looking for someone with their C:, N:, etc. drives published to the world with no passwords :) Gary Flynn Network Analyst James Madison University

1 0

Re: Deciding whose network block is whose?
by Sean M. Doran 06 Jan '98

06 Jan '98

Sean Donelan <SEAN(a)SDG.DRA.COM> writes: > Other than Sprint's global default for 0/1 (and then > SPRINT has the nerve to complain when people point > default at them) there is no information in the IRR > about valid origin ASNs for Net 3/8. I am a hypocrite. I have flexible opinions. However, I do not believe for an instant that Sprint actually advertised 0/1 to the people Sprint (whether you mean me, Peter or Hank by that) have complained about. (We did twice advertise 0/1 to InternetMCI and others, which was interesting in several ways.) > The problem of bogus routing has been getting worse. Is it going to > take a disaster to get the attention of various > provider's management? Uhm, what does manglement have to do with reality? Do you really think there is some manager out there who is preventing people from "fixing" this problem, or who could somehow cajole her or his staff into doing a "fix"? The address registries are believed because the address registries aggregate the routability policies of the various networks participating in the Internet routing system. They are authoritative because ISPs have made them so to prevent a large amount of bilateral negotiations about what really should be routed where. The problem is not the lack of a canon, but the lack of a cannon; there is no simple means by which to enforce completely correct routing with present technology, while preserving the flexibility of timely dynamic reconfiguration of the Internet. Sean.

1 0

Whats up?
by Leigh Porter 06 Jan '98

06 Jan '98

Hi, Did something just happen? There seem to be an awfull lot of damped routes right now? -- Leigh Porter Wisper Bandwidth.

2 2

Re: International Internet Connectivity
by steveb＠internet.netway.co.nz 06 Jan '98

06 Jan '98

I can give you the historical situation, although this is slowly changing as the Net is becoming slightly less 'US-centric'. The philosophy for international connection to 'the Internet' (ie USA) was exactly the same as with in the US itself. That is, those wishing to connect could do so at some financial cost levied by the US ISP/NSP in addition to the cost of the transport. In the international case, this means a huge cost to those wishing to connect as they must pay the whole cost of trans-oceanic capacity. In general, because of the fact that the Internet is still US-centric, this results in high traffic flows outgoing from the US compared with much smaller incoming traffic flows. In the the case of New Zealand, only aobut 20% of the total traffic is incoming at the US end. Traditionally (and I speak for Oceania only), there were virtually no peering agreements internationally, with the result that the cost of all traffic and all transport was borne by the country connecting to the USA. This is changing slowly as large US ISP's find the need to service their multi-national customers in countries other than the US. To answer your questions more specifically: 1) I'm not sure of the answer you want here, but in general the peering rules internationally are similar to those in the US; that is, the international connection would appear in a similar manner to any normal ISP connection. 2) Peering agreements are now being considered internationally and these are generally very much 'ad hoc'. There are no hard and fast rules and the agreements are generally based on the perceived benefit to each of the parties. This may be done purely on a 'guesstimate' of traffic ensuing from requests emanating from each of the parties and a settlement made on this basis. The peering arrangement may be at either end of the international links although the 'normal' situation is for the agreement to be held at the 'busy' end - normally the USA, in the case of that country. 3) The international connectivity (cables and satellites) is owned by various consortia and capacity is 'sold' to interested parties. This may be done on a 'wholly-owned', end to end basis (depending on connection and operation agreements in place between the countries) or on a 'half-circuit' basis where the purchase of the (say) cable would be made by one party. For example, New Zealand would purchase the capacity to half-way across the Pacific, in the case of a New Zealand-USA connection. The remainder, from that point in the Pacific to the US, say, would be purchased by some US ISP/NSP. Traditionally the American half would be leased back to the remote country, who would then effectively pay for the whole transport cost. Hope this helps... Steve Barr Netway Communications +64 9 357-1566 ______________________________ Reply Separator _________________________________ Subject: International Internet Connectivity Author: George McCormick <gmccormick(a)csmgusa.com> at internet Date: 06/01/98 09:09 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

1 0

Internic contact?
by Alex Rubenstein 05 Jan '98

05 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 05 Jan '98

05 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