- Test - lists.nanog.org

NANOG 13 INFO
by Pam Ciesla 28 May '98

28 May '98

We'd like to take this opportunity to thank folks in the community who have significantly contributed resources to this NANOG. Thanks to Bay Networks for providing the network equipment allowing us to provide several hundred hub ports in the main room and the terminal room. Thanks to Cabletron for providing wireless access head ends for the meeting. The University of Michigan Information Technology Division will be providing a handful of machines for the terminal room. Thanks to the Real Broadcast Network (RBN) for casting the NANOG 13 meeting over the net. Thanks also to Cisco for providing the equipent and resources to cast the meeting using the MBone. And finally, thanks to Aptis, Bay, and Cisco for funding the beer-n-gear event Monday evening. Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (734) 764-9430 (New Area Code) NOTE: NANOG Registration payment cutoff is Friday, 5/29 at midnight payment of $150 is due. The registration fee after the 29th will be $170 and the cancellation fee is $20. If you call with payment info my voicemail is secure so please leave a message and speak slowly. The attendee list on the webpage has been updated. Please look there first if you are not sure that you have paid. Thanks ---------------------------------------------------------------------- Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 -----------------------------------------------------------------------

1 0

Re: ingress filtering
by Jared Mauch 28 May '98

28 May '98

The great thing about the CC images released by cisco (as long as you're running with ip cef or ip cef dist), you can turn this neato command on your interfaces to your customers: ip verify unicast reverse-path This automatically does filtering based on your local routers routing table. This means you can take a customer connection and filter them. You will encounter problems if they are multihomed and have netblocks that you don't route directly to them, but you can make those changes later as they multihome. We've had a few problems with our customers and doing this, when we don't route all their address space, but this is easily fixed. Asymetrical routing is an evil you have to live with and adjust to, so if you have more than one upstream, I would not apply such filters to those interfaces. I would recommend that everyone who has the ability to do this on their routers do so. This will help many possible problems. If we can get enough people to make this part of their default configuration (such as no ip directed-broadcast is these days) on their ports to customers, we could prevent many DoS attacks. If you have dialup lans (ie: mci, uunet, etc.. who have big public dialup pools) PLEASE filter these, as well as the smaller providers out there. - jared > > On Thu, 28 May 1998, Mr. Dana Hudes wrote: > > > > > Who *does* do ingress filtering? I have it on our border routers > > > and customer connect ports. We have transit from MCI and UUNET. > > > Neither has ingress filters -- see below message from MCI on > > > this. > > > > > > Subject: Re: RFC1918 addresses from MCI > > > Date: Thu, 28 May 1998 08:16:23 -0700 > > > From: security(a)mci.net > > > To: dhudes(a)graphnet.com > > > CC: security(a)mci.net > > > > > > Mr. Hudes, > > > > > > > > > Thank you for your note. MCI does not currently source filter > > > address > > > space at it's ingress points. Addresses sourced from > > > non-routable or > > > invalid addresses are not blocked or filtered. Addresses > > > destined to > > > non-routable addresses spaced are not routed. > > > > > > If you think it is a security issue and it is on-going then > > > please > > > contact us with the target address so we can investigate. -- Work: jared(a)qual.net - We Make The Internet Work for Your Business 9-5pm(ET) 800 637 4424x2634 - 24x7 NOC - 800 424 3223 pgp key available via finger from jared(a)puck.nether.net

1 0

Re: 165.138.0.0
by Sean Donelan 28 May '98

28 May '98

>This provides the greates redundancy for our customers. Sprint's policy >does not apply to customer routes so they do not filter at the /16 level >for classic B addresses. (They do for everybody else though....) Tell me once again, what is Sprint's justification for applying these filters to everyone else? If it is for a noble purpose to save the entire Internet from collapse, why isn't it a good idea for Sprint's customers to do the same? If it is for anti-competitive reasons, to encourage people to buy service directly from Sprint to get around the filters, then I'm willing to offer identical terms and conditions for non-customers. Neither IHETS nor SPRINT is a DRA customer. Doesn't the State of Indiana have a competitive bidding system? Isn't it possible that one day, IHETS may no longer be a customer of Sprint? >we'll re-announce the /16 from at least one of the POPs. But in order to >make sure the /16 is always routable we'll have to advertise it from >every POP that has a /20 or /19 sub address. Otherwise if the one POP >advertising the /16 goes down our customers on the noted networks will >loose connectivity to your network. (We'll also have to put in a /16 >static route to overide the null0 that BGP will inject into our routing >tables.) It was much cleaner to just advertise the /19's and /20's >without the /16 but we can (and I guess will have to unless you change >your filters) do it the other way. By cooperating with your upstream ISPs, you can use several methods, such as proxy aggregation, announcing more specifics inside SPRINT, and only announcing the larger block elsewhere, you can achieve a high degree of reliability without propagating tiny CIDR blocks world-wide. Why does Sprint have these filters? Once again, I'd be happy to change my filters on the same terms and conditions as SPRINT. SPRINT could become a customer of DRA. SPRINT could change their filters to not apply to non-customers. IHETS could become a customer of DRA. There are lots of alternatives. But if prefix-length filters are a good idea, they should be a good idea for everyone. Otherwise it is hypocritical to only apply them to non-customers?

1 0

RE: 165.138.0.0
by Aaron Branham 28 May '98

28 May '98

On Thu, 28 May 1998, Sean Donelan wrote: > >The purpose of the /20's and /19's on our 165.138.0.0, 165.139.0.0 and > >157.91.0.0 networks was to provide better service to our customers and to > >try and save IP address space for others. Like some of the class A's > >above we treated these as CIDR blocks instead of going to our upstream > >providers or the ARIN to get more addresses. Because our network has > >a dozen pops thoughout the state and each has at least one upstream > >connection to Sprint and MCI we advertise them as the /19's and /20's. > >This provides the greates redundancy for our customers. Sprint's policy > >does not apply to customer routes so they do not filter at the /16 level > >for classic B addresses. (They do for everybody else though....) > > Sure. It makes sense. Just have sprint change their policy about > filtering non-customers, and I'd be happy to do the same. Otherwise it > seems a bit hollow to say Sprint's filters are saving the Internet from > collapse when they allow they customers do do the exact thing they > are telling everyone else is a bad idea. > > Of course, it does lock you into SPRINT for all times, since if you > ever become a non-customer, they will begin filtering your routes no > matter how sensible the idea. I'm a customer of Sprint and I can say two things, one they have gotten a lot better this year in overall quality of service and two their filtering policy is very outdated & Sprint's customers seem to have the most violations of the policy. It does appear that the policy is enforced with peers like MCI and UUnet on routes Sprint learns from them, but not visa versa. Looking quickly over the MCI, ANS, and UUnet routes (via 'show ip bgp neighbor x.x.x.x received-routes') I see the Sprint AS's pop up in a lot of the CIDR routes, (/24 - /19) esp in the old class B range (look at 129.122.0.0.) Sprint's got GSR's now and they haven't had any network wide BGP flaps like they did a 12-18 months ago, even though the current policy was used at that time. Because of the shortage of IP addresses I think your going to see a lot more attempts to squeeze CIDR blocks out of the remaining class A's and B's, if we use them we'll have addresses for a couple of more years. (might even cut the routing tables if people can stand renumbering and turning in their /19's and such for a /16, /15, /14 or so.....) As a customer I'm asking Sprint to pull the filters on non-customers. I'd urge other customers to do the same. ------ P.S. Sean, I took a /20 that we haven't used yet and just advertised it to MCI - the route didn't make it into the Sprint tables. But it also didn't make it into your network even though it appears that you have a direct connection to MCI.....are you using the same filter on MCI? If so are you having problems getting to some of the networks I mentioned in my other email? INDY1#traceroute Protocol [ip]: Target IP address: 150.147.1.1 Source address: 165.138.16.254 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to StLouis21-e1.dra.net (150.147.1.1) 1 bordercore4-hssi6-0-2.NorthRoyalton.mci.net (166.48.234.9) [AS 3561] 300 msec 272 msec 32 msec 2 core1.NorthRoyalton.mci.net (204.70.4.205) [AS 3561] 20 msec 28 msec 24 msec 3 core-hssi-2.Chicago.mci.net (204.70.1.93) [AS 3561] 32 msec 28 msec 32 msec 4 border4-fddi-0.Chicago.mci.net (204.70.3.83) [AS 3561] 36 msec 32 msec 36 msec 5 * * * 6 * * etc...... ----but using MCI's IP---- INDY1#traceroute 150.147.1.1 Type escape sequence to abort. Tracing the route to StLouis21-e1.dra.net (150.147.1.1) 1 bordercore4-hssi6-0-2.NorthRoyalton.mci.net (166.48.234.9) [AS 3561] 28 msec 24 msec 24 msec 2 core1.NorthRoyalton.mci.net (204.70.4.205) [AS 3561] 24 msec 24 msec 28 msec 3 core-hssi-2.Chicago.mci.net (204.70.1.93) [AS 3561] 32 msec 28 msec 28 msec 4 border4-fddi-0.Chicago.mci.net (204.70.3.83) [AS 3561] 32 msec 32 msec 36 msec 5 data-research.Chicago.mci.net (204.70.27.10) [AS 3561] 36 msec 44 msec * 6 StLouis21-e0.dra.net (150.147.112.21) [AS 1746] 56 msec * 40 msec

1 0

RE: Cable & Wireless buys MCI Internet
by Pete Farmer 28 May '98

28 May '98

curtis(a)lamere.net wrote: >Excuse me for posting this here, but this is from news.com. It >basically says CWIX.NET gets the whole shooting match. Layer and all. Not quite. The joint press release (from MCI: http://www.mci.com/news-news/headline-896341261.shtml ; from C&W: http://www.cwplc.com/press/1998/p98may28.htm ) both state that Initially, MCI will provide the underlying telecommunications transport services supporting the Cable & Wireless backbone and will provide additional services as required by Cable & Wireless. Pete ______________________________________________________________________ Peter J. Farmer E-mail: pfarmer(a)strategies-u.com Strategies Unlimited Voice: +1 650 941 3438 201 San Antonio Circle, Suite 205 Fax: +1 650 941 5120 Mountain View, CA 94040 WWW: http://www.strategies-u.com

1 0

ingress filtering
by Mr. Dana Hudes 28 May '98

28 May '98

Who *does* do ingress filtering? I have it on our border routers and customer connect ports. We have transit from MCI and UUNET. Neither has ingress filters -- see below message from MCI on this. The result of course is that spammers and other bad guys can try to attack your systems with forged source IP addresses. Random strange people in the 'net send "NETBIOS name service" (port 137) packets to my unix mail relay, which of course ignores them. Other such fun things continue to be seen in the logs. Subject: Re: RFC1918 addresses from MCI Date: Thu, 28 May 1998 08:16:23 -0700 From: security(a)mci.net To: dhudes(a)graphnet.com CC: security(a)mci.net Mr. Hudes, Thank you for your note. MCI does not currently source filter address space at it's ingress points. Addresses sourced from non-routable or invalid addresses are not blocked or filtered. Addresses destined to non-routable addresses spaced are not routed. If you think it is a security issue and it is on-going then please contact us with the target address so we can investigate. Regards, -Julian Min

2 1

RE: Cable & Wireless buys MCI Internet
by Gregory Soo 28 May '98

28 May '98

> -----Original Message----- > From: Pete Farmer [mailto:pfarmer@strategies-u.com] > Sent: Thursday, May 28, 1998 1:10 PM > To: NANOG (E-mail) > Subject: RE: Cable & Wireless buys MCI Internet > > 1) MCI will continue to provide raw transport (think of it as Layer 1 > stuff) for the traffic associated with its Internet wholesale > ("backbone") services, at least for now. Doesn't C&W have extensive North American fibre with more to come? Anyone care to guess how quickly C&W could move the traffic across to their own transport?

1 0

RE: Cable & Wireless buys MCI Internet
by Pete Farmer 28 May '98

28 May '98

I've tried parsing the original press release http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/0 5-28-1998/0000666960&EDATE= . Here's what I come up with. Think of the services being provided as existing in three chunks: raw transport, wholesale, and retail. Under this deal, 1) MCI will continue to provide raw transport (think of it as Layer 1 stuff) for the traffic associated with its Internet wholesale ("backbone") services, at least for now. 2) C&W will take over (own) the routers, the connection agreements, and the service agreements for providing wholesale services to ISPs. Looks like this applies worldwide. C&W will be a customer of MCI for raw transport. 3) MCI will continue to own the service agreements and be the service provider to end users (to corporate customers for access and/or Web hosting, plus dial-up internetMCI consumers.) For some period (they say 2 years), MCI will be a customer of C&W for backbone services. MCI and C&W bravely say in their press release that this deal "should clear the way for the swift approval of the MCI WorldCom merger." We'll see. I expect that the EC will require that C&W have an explicit "out" on the transport piece (i.e. be able to take in-house or contract with others for the big transport pipes as it chooses.) Pete ______________________________________________________________________ Peter J. Farmer E-mail: pfarmer(a)strategies-u.com Strategies Unlimited Voice: +1 650 941 3438 201 San Antonio Circle, Suite 205 Fax: +1 650 941 5120 Mountain View, CA 94040 WWW: http://www.strategies-u.com

1 0

165.138.0.0
by Shawn David Solomon 28 May '98

28 May '98

---------- Forwarded message ---------- Date: Thu, 28 May 1998 10:46:54 -0500 (EST) From: Aaron Branham <abranham(a)ind.net> To: Sean Donelan <SEAN(a)SDG.DRA.COM> Cc: nanog(a)merit.edu Subject: 165.138.0.0 Sean, when I look at a full BGP table from MCI/Sprint/UUnet/and ANS I see a lot of /16 - /24's on the 12.0.0.0 (which also has a /8), 24.0.0.0 (which has no /8), 53.0.0.0, 62.0.0.0, etc.....Some of these have the classic /8 covering them and some don't. It's the same story for several /16's (class b networks) I see 132.155.204.0/23 (without a /16 anywhere), 134.128.52.0/24 (without a /16). Do you have problems getting to all of these? >From a router that has a customer connection to ANS, MCI, UUnet, and Sprint I see all of our routes even though we only have uplinks to MCI and Sprint. This router has direct connects with MCI and UUnet and iBGP peers with a router that has the connections to Sprint and ANS. Core#sh ip b reg _1767_ ...cut.... * i165.138.96.0/20 208.160.14.1 0 0 1239 1239 1767 i * i 208.160.14.1 0 0 1239 1239 1767 i *> 166.48.222.45 0 0 3561 3561 1767 i * 157.130.97.209 0 0 701 701 1239 1767 i ...cut.... This is the other router..... ...cut.... * i165.138.96.0/20 208.160.10.1 0 0 3561 3561 1767 i * i 208.160.10.1 0 0 3561 3561 1767 i * 192.103.62.121 0 0 1323 1673 3561 1767 i *> 144.228.13.229 0 0 1239 1239 1767 i ...cut.... The purpose of the /20's and /19's on our 165.138.0.0, 165.139.0.0 and 157.91.0.0 networks was to provide better service to our customers and to try and save IP address space for others. Like some of the class A's above we treated these as CIDR blocks instead of going to our upstream providers or the ARIN to get more addresses. Because our network has a dozen pops thoughout the state and each has at least one upstream connection to Sprint and MCI we advertise them as the /19's and /20's. This provides the greates redundancy for our customers. Sprint's policy does not apply to customer routes so they do not filter at the /16 level for classic B addresses. (They do for everybody else though....) Neither does MCI and it appears that ANS and UUnet do not filter with their connections to MCI and Sprint. We have run this way for several weeks now and this is the first call on the problem that we have gotten. But since the idea here is connectivity we'll re-announce the /16 from at least one of the POPs. But in order to make sure the /16 is always routable we'll have to advertise it from every POP that has a /20 or /19 sub address. Otherwise if the one POP advertising the /16 goes down our customers on the noted networks will loose connectivity to your network. (We'll also have to put in a /16 static route to overide the null0 that BGP will inject into our routing tables.) It was much cleaner to just advertise the /19's and /20's without the /16 but we can (and I guess will have to unless you change your filters) do it the other way. - - Aaron Branham [AKB8] (a(a)ind.net) <Phone# 317.263.8976>

1 0

PC Bozo's World bites again (CNN, too)
by Vadim Antonov 28 May '98

28 May '98

Check http://cnn.com/TECH/computing/9805/26/net.access.idg/index.html Those bozos are suggesting to reduce MTU from 1500 to 576 to "improve performance", so packets "won't fragment in backbones"! The bright idea to fix CTS/RTS setting didn't come along in their brilliant minds. Here goes the average packet size. Down the drain... Now what do we do to control the damage? I also think it's a good time to measure the gullibilty of the general public by measuring packet size distribution :) --vadim

6 6