- Test - lists.nanog.org

RE: ingress filtering
by jeyers＠ialn.com 29 May '98

29 May '98

-----Original Message----- From: Eric Germann [mailto:ekgermann@cctec.com] Sent: Friday, May 29, 1998 8:09 AM To: John Fraizer Cc: Mr. Dana Hudes; nanog(a)merit.edu Subject: Re: ingress filtering At 02:32 PM 5/28/98 -0400, John Fraizer wrote: > Actually it has nothing to do with WINS. If all the ISP's would implement Bzzt. Thank you for playing, though. If it were not for WinS, there wouldn't be a second packet being sent, no matter what junk is the payload. >solid in-addr.arpa reverse mappings, this would go away. Microsoft's DNS >resolver has been extended, when DNS lookups fail, to do a reverse NETBIOS >query against the target machine so it can use its name when displaying >stuff via NBTSTAT, etc. It was designed this way, before the Internet >became popular. Excuse me? I was using the Internet way before Microshaft was a dream in Bill's head. The RFC's you quote were rammed into existance by DARPA to provide early ecanpsulation techniques so that companies like MS could say they were IP/Internet compatible, (instead of using a real protocol) and get away from Novel slamming them for non-routable protocol support only. All they did was to take the same non-routable junk and throw it inside an ip packet and call it "internet" compatible. The RFC's quoted provide a way to make that encapsulation work, they do not recommend conversion to that as a standard. To encourage that kind of conversion would be a major leap backwards. (Wow! let's all abandon our routeable protocols and use a non-routed local segment only, encapsulated protocol. Yippee!) Now I agree ISP's should do better DNS resolution, but every MS box plugged into the net sending a second packet adds up to a lot of junk packets eating up expensive bandwidth. MS catches the blunt of the critisizm because they are the only ones to have adopted such a lame networking scheme, and then forced it down others quotes. >Before we all rant at MS, I suggest we all read RFC's 1001 and 1002 and >UNDERSTAND NetBIOS over IP, before we blame ALL the worlds ills on MS. >Last I knew, they weren't written by MS. > > >RFC 1001-> http://answerpointe.cctec.com/notes/rfcs1/254e_1e2.htm > >RFC 1002-> http://answerpointe.cctec.com/notes/rfcs1/2e46_1e2.htm > >Author(s): Defense Advanced Research Projects Agency, End-to-End Services >Task Force, Internet Activities Board, NetBIOS Working Group > >>------- >>John Fraizer (root) | __ _ | >>The System Administrator | / / (_)__ __ ____ __ | The choice >>mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU >>http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation >> A 486 is a terrible thing to waste... >> > >======================================================================= ====== >Eric Germann Computer and Communications Technologies >ekgermann(a)cctec.com Van Wert, OH 45891 > Phone: 419 968 2640 > >http://www.cctec.com Fax: 419 968 2641 >Network Design, Connectivity & System Integration Services >A Microsoft Solution Provider >

1 0

Re: ingress filtering
by John Fraizer 29 May '98

29 May '98

At 01:28 PM 5/28/98 -0400, you 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. We do ingress and egress filtering. It's just a matter of keeping people on both sides of the border router from spoofing either by mistake or maliciously. >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. The NETBIOS name service comes from Winblows machines. I would venture to guess that your mailserver also has a resolver running that is also most likely authoritative for your or someones domain. Either that or you are specifying that resolver via radius to your dialup clients. When a Winblows box does a DNS lookup, for some reason, it will also send a NETBIOS name service request thinking that there is a WINS resolver living at the same IP. It's just another example of MS doing very strange things. (Read: They don't know $h!t about IP and show it regularly!) The dialup provider that these requests is originating should be filtering port 137 on egress to prevent it from making it to the global internet. Then again, we should all be egress and ingress filtering, filtering ICMP to our broadcast and network addresses and sending money to our favorite charity too. No matter how much we harp, there will be idiots with the keys to the router cabinets who just won't do the right thing. ------- John Fraizer (root) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:root@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

RE: PC Bozo's World bites again (CNN, too)
by Doug Stanfield 29 May '98

29 May '98

The explanation lies in transiting circuits with high latencies and/or packet loss, whether they're the last mile by dial up or frame circuit backbone connections. Larger packets are more prone to be corrupted or discarded so sessions with smaller packets have a better performance in comparison. No excess retransmission and all that. We've seen it in networks where the customer connection is high quality but there were provider latency/loss problems. Smaller MTU helped while the frame relay problems persisted. Once the provider network was up to snuff there was no discernable performance difference between large or small and I think most of our users went back to defaults. > The improved-performance-with-low-MTU is a puzzle I'd certainly like to > understand better. It seems step 1 is to eliminate the possibility that > the 1500 MTU is leading to fragmentation. > Vern Doug Stanfield Oceanic Cable Data Networking Manager 200 Akamainui St. dougs(a)oceanic.com Mililani, HI 96789

1 0

Re: The Great Exchange
by Sean Donelan 29 May '98

29 May '98

>I think it's a North American view of the world, unsurprising on NANOG >:-) Traffic metering is the dominant charging mechanism for permanent >connections in Oz and Connect differentiate traffic based on its >source (domestic/cache/external). Hasn't a price war just broken out in Australia, with the dominant feature being the introduction of flat-rate pricing? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: The Great Exchange
by Hal Murray 29 May '98

29 May '98

> In short, I see no economic basis for such metering, and no moves > towards such metering. Maybe I'm wrong, but I doubt that we're going > to see any change in this any time soon. There is another reason why some people don't like metering - it makes predicting costs much more difficult. Imagine your local library or university dept trying to budget for internet access. I think I saw a comment that half the cost of a long distance call was collecting the data and processing the billing. Can anybody verify that? > I think it's a North American view of the world, unsurprising on NANOG > :-) Traffic metering is the dominant charging mechanism for permanent > connections in Oz and Connect differentiate traffic based on its > source (domestic/cache/external). How much trouble is it to collect the billing data? What are the relative rates for domestic/cache/external?

2 1

Re: ingress filtering
by shields＠crosslink.net 29 May '98

29 May '98

In article <19980528145744.B1561(a)puck.nether.net>, Jared Mauch <jared(a)puck.nether.net> wrote: > 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 It is neato, but be careful not to turn it on without CEF or it will silently drop all packets on the interface. Just a tip. Not that I did that or anything. -- Shields, CrossLink.

1 0

Re: PC Bozo's World bites again (CNN, too)
by Vern Paxson 29 May '98

29 May '98

> Has anyone done an analysis of how having a smaller MTU affects > slow-start? It seems to me that a TCP session would come up to speed > about 3 times faster with a mtu of ~500 vs a mtu of ~1500. It doesn't, because the smaller MTU doesn't mean you get more acks per unit time, just that you get more acks overall. So you still get the same slow start increase pattern, only your segments are 1/3 the size they could be, so your data rate is 1/3 what it could otherwise be (until cwnd is big enough to consume the available bandwidth). The improved-performance-with-low-MTU is a puzzle I'd certainly like to understand better. It seems step 1 is to eliminate the possibility that the 1500 MTU is leading to fragmentation. Vern

1 0

Re: PC Bozo's World bites again (CNN, too)
by Darrell Fuhriman 29 May '98

29 May '98

Michael Dillon <michael(a)memra.com> writes: > I don't think so. They even said in their article that the technical > details are based upon this URL > http://www.sns-access.com/%7Enetpro/maxmtu.htm > and this guy says stuff like: > > And, it turns out, depending on how your ISP and other routers > encountered on the Internet handle your TCP/IP requests, that a MaxMTU > setting of 576, often referred to as the "Internet Standard", will in > many cases avoid the fragmentation of packets of data and the slow > transfer speeds which result. He used to be one of my users, at two different ISPs, in fact. I had a long drawn out disagreement about how this was wrong, and mathematically didn't make any sense. However, lots of people have confirmed that it really does help... which leads me to accept Karl's explanation. We shouldn't expect anymore from microsoft, really. Darrell

3 2

Re: 165.138.0.0
by Sean Donelan 29 May '98

29 May '98

>I got two nice replies from Sprint. They won't change their filtering >policy overnight but they are at least considering it. I think they're >interested in listening to customers on the issue, but please don't spamm >or rant......hey if they do change it I might resubscribe to nanog :) >I removed their email addresses because they didn't post it to nanog. I got almost an identical message from Sprint last year when this issue came up with another sprint customer. I think you are correct in one aspect, they won't change their filtering policy overnight. Individually, most sprint employees are always nice. Collectively as a corporation, they seem to have tremendous difficulty moving from the 'considering it' stage to the 'do something' stage. I'm in Missouri, the Show-Me state. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

RE: 165.138.0.0
by Sean Donelan 29 May '98

29 May '98

>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? The filters I use have existed for several years. I make lots of exceptions for networks which supply at least an interesting reason for doing it. We ask the person to contact their upstream NOC, and for most providers work something out quickly. There is one, and only one reason I won't make an exception. When someone says the policy doesn't apply to them because they are a sprint customer. After that happens they are directed to call the Sprint NOC for assistance. It would be nice if sprint accepted trouble reports directly from non-customers, then it would not be necessary to broadcast general appeals for help on lists like nanog. But when the Sprint network declines to contact the sprint NOC for assistance, it simply delays the whole problem resolution process. I'm sorry you had difficulty doing this. Contacting the Sprint NOC should put you in touch with someone to help you come up with a useful routing policy that meets the conditions Sprint says are good rules for controlling the growth of the global routing table. After all you are paying sprint, not me. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0