July 2000 - Test - lists.nanog.org

Re: Telco NOC vs. Internet NOCs (WAS: Wanted: Clueful Individual @ TeleGlobe.n
by Robert Cannon 19 Jul '00

19 Jul '00

I am not saying too much solid at all about how much the IXC's utilize each others networks. It is really just an impression. I suppose one that I am curious about how accurate it is. The impression again is that AT&T provides end to end service - which is quite different from the Internet where networks keep playing hot potato with the traffic. Sean's comments are interesting - I would love to see something more substantiated just for fun. I would be curious, where two networks exist, how much traffic they might exchange. And then there is the situation which was pointed out where one of two networks does not exist and the first must rely on the second to complete the transmission. I think regulatorily there has been a lot of attention paid to traffic exchanged between LEC and LEC - and traffic exchanged between LECs and IXCs - but not necessarily traffic exchanged between IXC and IXC (again, except in the case of network reliability where one IXC is down and relies upon the other). -B www.cybertelecom.org ------Original Message------ From: Ric Messier <rmessier(a)Genuity.NET> To: Robert Cannon <rmcannon(a)mail.com> Sent: July 18, 2000 4:40:44 PM GMT Subject: Re: Telco NOC vs. Internet NOCs (WAS: Wanted: Clueful Individual @ TeleGlobe.n On Tue, 18 Jul 2000, Robert Cannon wrote: > > I am curious how often you think that ATT telephone long distance would hand > traffic off to MCI telephone long distance. My impression of telephone long > distance is that it is largely an end to end service (one of the great > differences from the Internet). That as far as long distance goes, there is > not a great deal traffic hand off (one exception is times of network trouble > where carriers have agreements to hand off traffic to maintain network > reliability). > So, what you are saying is that all long-distance carriers have at least nationwide networks and never have to ride another carrier (except for the last-mile service provided by the LEC)? Just trying to understand your remarks. Ric ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

1 0

HOUSE MOVES TO BAN SPAM
by Henry R. Linneweh 19 Jul '00

19 Jul '00

http://www.internetnews.com/isp-news/article/0,2171,8_417901,00.html -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | |--------------------------------| Henry R. Linneweh

1 0

OK.. WHo's the wise guy?
by Valdis.Kletnieks＠vt.edu 19 Jul '00

19 Jul '00

The root nameservers seem a tad confused about the orbs.org domain this morning. A, E, F, and G seem to know about it, while B, C, D, and H-L don't. But even the 4 that know about it seem to be returning only a partial list of NS entries (possibly the others are secondaries - but if the roots aren't returning the NS entries, they'll never get referenced)? And yes, I know that the ORBS guys have shut down temporarily due to the above.net hassles they've been getting. But even the NS entries going poof? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech dig @a.root-servers.net orbs.org ns ; <<>> DiG 8.2 <<>> @a.root-servers.net orbs.org ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 4 ;; QUERY SECTION: ;; orbs.org, type = NS, class = IN ;; ANSWER SECTION: orbs.org. 2D IN NS NS.VUURWERK.NL. orbs.org. 2D IN NS NS1.MANAWATU.NET.NZ. orbs.org. 2D IN NS NS1.ABS.NET. orbs.org. 2D IN NS SKYNET.SIMKIN.COM. orbs.org. 2D IN NS DOUBTFUL.SIMKIN.COM. orbs.org. 2D IN NS NS3.AUSTRIA.EU.NET. orbs.org. 2D IN NS ORBSNS.PORT80.SE. ;; ADDITIONAL SECTION: NS1.ABS.NET. 2D IN A 207.114.0.130 SKYNET.SIMKIN.COM. 2D IN A 199.175.137.111 DOUBTFUL.SIMKIN.COM. 2D IN A 207.6.128.246 NS3.AUSTRIA.EU.NET. 2D IN A 193.154.160.110 dig @b.root-servers.net orbs.org ns ; <<>> DiG 8.2 <<>> @b.root-servers.net orbs.org ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 12, ADDITIONAL: 12 ;; QUERY SECTION: ;; orbs.org, type = NS, class = IN ;; AUTHORITY SECTION: ORG. 6D IN NS A.ROOT-SERVERS.NET. ORG. 6D IN NS G.ROOT-SERVERS.NET. ORG. 6D IN NS E.GTLD-SERVERS.NET. ORG. 6D IN NS F.GTLD-SERVERS.NET. ORG. 6D IN NS F.ROOT-SERVERS.NET. ORG. 6D IN NS J.GTLD-SERVERS.NET. ORG. 6D IN NS K.GTLD-SERVERS.NET. ORG. 6D IN NS A.GTLD-SERVERS.NET. ORG. 6D IN NS M.GTLD-SERVERS.NET. ORG. 6D IN NS H.GTLD-SERVERS.NET. ORG. 6D IN NS C.GTLD-SERVERS.NET. ORG. 6D IN NS I.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 E.GTLD-SERVERS.NET. 6D IN A 207.200.81.69 F.GTLD-SERVERS.NET. 6D IN A 198.17.208.67 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 J.GTLD-SERVERS.NET. 6D IN A 198.41.0.21 K.GTLD-SERVERS.NET. 6D IN A 195.8.99.11 A.GTLD-SERVERS.NET. 6D IN A 198.41.3.38 M.GTLD-SERVERS.NET. 6D IN A 210.176.152.18 H.GTLD-SERVERS.NET. 6D IN A 216.33.75.82 C.GTLD-SERVERS.NET. 6D IN A 205.188.185.18 I.GTLD-SERVERS.NET. 6D IN A 192.36.144.253 dig @NS.VUURWERK.NL orbs.org ns ; <<>> DiG 8.2 <<>> @NS.VUURWERK.NL orbs.org ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 6 ;; QUERY SECTION: ;; orbs.org, type = NS, class = IN ;; ANSWER SECTION: orbs.org. 1D IN NS doubtful.simkin.com. orbs.org. 1D IN NS ns1.abs.net. orbs.org. 1D IN NS ns2.abs.net. orbs.org. 1D IN NS ns3.austria.eu.net. orbs.org. 1D IN NS ns.vuurwerk.nl. orbs.org. 1D IN NS orbsns.p80.net. orbs.org. 1D IN NS ns.uni2.net. orbs.org. 1D IN NS sunsite.auc.dk. orbs.org. 1D IN NS sunsite.icm.edu.pl. orbs.org. 1D IN NS monkeys.com. orbs.org. 1D IN NS dns-orbs.proxy.aol.com. orbs.org. 1D IN NS ns1.manawatu.net.nz. orbs.org. 1D IN NS ns2.manawatu.net.nz. orbs.org. 1D IN NS skynet.simkin.com. ;; ADDITIONAL SECTION: doubtful.simkin.com. 7h31m27s IN A 207.6.128.246 ns1.abs.net. 7h31m47s IN A 207.114.0.130 ns2.abs.net. 5h53m43s IN A 207.114.0.140 ns3.austria.eu.net. 3h35m44s IN A 193.154.160.110 ns.vuurwerk.nl. 1D IN A 194.178.232.2 ns.uni2.net. 7h31m27s IN A 129.142.7.99

1 0

CALEA Update
by Chip Sharp 19 Jul '00

19 Jul '00

At the NANOG meeting, I think I promised to provide an update on the CALEA meeting held at the end of June. Information on CALEA JEM II can be found at http://www.tiaonline.org/standards/CALEA_JEM/ This includes the meeting minutes and latest draft of the JEM Report under "contributions". I went away for 2 weeks vacation and when I returned I found that the Carnivore system that the FBI presented is now all over the news so there isn't much point going into it, although there is a lot of misinformation about what it does going around. Any technical questions or comments, feel free to email me. Chip ------------------------------------------------------------------- Chip Sharp, !Ph.D. JBM Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org -------------------------------------------------------------------

1 0

Re: RFC 1918
by Richard A. Steenbergen 19 Jul '00

19 Jul '00

On Tue, 18 Jul 2000, Eric A. Hall wrote: > "Richard A. Steenbergen" wrote: > > > > On Mon, 17 Jul 2000, Eric A. Hall wrote: > > > > > When ISPs choose to mark their packets with Internet-illegal > > > addresses, they are contributing to these problems. Sorry, but > > > you're not supposed to be using these addresses anyway. > > > > This is utterly stupid. You can use these addresses any way you see > > fit, you can source packets from them if you'd like, and they are as > > valid as any other address to use and be "on the internet". > > What's dumber? > > a) Filtering illegal packets from entering your network because > they use your internal address range, because they are classed > unroutable and should never appear on that interface, or both Unroutable means you can't reach where the packets came from, not that the packets can't reach you. Just because you can't reply doesn't mean someone shouldn't be allowed to send you an informative piece of information, like a traceroute ttl-exceed. > b) Sending packets that you KNOW will be dropped or filtered by > a good portion of their intended recipients. This is not true. For the people like you who think they need to filter it, you've accomplished your goal. For the rest of the world, they simply do not care. Obviously its not prefered by anyone to have RFC1918 sourced packets out there, mainly because they're not all that useful. But IMHO your belief that these are "Illegal bad wrong packets which should never appear on that interface" is incorrect. As for the DoS issue, as I explained to someone in private email, there are three distinctions you can break a filter into: 1) It provides security 2) It stops an attack 3) It reduces an attack RFC1918 filters obviously do not provide security. RFC1918 filters obviously do not "stop" any attacks outright. RFC1918 filters reduce the impact of attacks which can spoof by 3.19% I really don't see why you're wasting your time on it. Actually I really don't see why we're waiting our time argueing, this thread has long outlived its usefulness. But IMHO the RFC1918-nazi is not needed. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 4

suggestions? hylafax/IXO/ITAP addressable pager companies in UK
by Jim Mercer 19 Jul '00

19 Jul '00

i've got a server in London, UK that from time to time needs some attention. i've been using hylafax here in canada to send off alpha and/or numeric messages using a dial-up into the pager company and the IXO or ITAP protocols. works quite nicely. in any case, i would like to do the same thing for the technicians in London, however, they aren't clue'd enough to ask their pager company the right questions and/or the pager companies i've called were not clue'd enough to understand what i was asking. any recommendations for direct-access pagers and/or cellphones in the UK? -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

5 6

Re: Filtering (was Re: RFC 1918)
by Paul Vixie 19 Jul '00

19 Jul '00

Valdis.Kletnieks(a)vt.edu writes: > OK.. I'll bite - what's in YOUR favorite list of things to filter? ;) networks owned by spam-friendly people or companies.

1 0

Re: RFC 1918
by Richard A. Steenbergen 18 Jul '00

18 Jul '00

On Mon, 17 Jul 2000, Eric A. Hall wrote: > When ISPs choose to mark their packets with Internet-illegal addresses, > they are contributing to these problems. Sorry, but you're not supposed > to be using these addresses anyway. This is utterly stupid. You can use these addresses any way you see fit, you can source packets from them if you'd like, and they are as valid as any other address to use and be "on the internet". What you CAN'T do however, is expect that these packets can ever be replied to, or exchange or accept any kind of information on how to route this IP space outside of your network. Sure its probably not the best idea in the world to send out packets you can't expect a reply to, but its not prohibited for a reason, and its certainly not the end of the world you make it out to be. If you really want to filter RFC1918 sourced packets at your borders for whatever reason its your choice. Trust me I've probably seen a lot more DoS then most people in one way or another, and filtering 1918 space is in absolutily NO way any kind of magic bullet or even worth the processor time (if you're gonna spend the time filtering there are much better things out there). -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 2

Re: RFC 1918
by Bohdan Tashchuk 18 Jul '00

18 Jul '00

> Though technically you're right, this kind of attitude is exactly the > problem. Everyone should filter all RFC1918 usage on public links, > regardless of whether they themselves use is, or their customers use it, > or not. To not do such filtering is to be a bad neighbour. I'm just a home DSL user, and usually a fly on the wall for this mailing list. But I've found it beneficial to make a practical exception to your blanket condemnation of RFC1918 source addresses. I don't think there is much harm to it. The relevant snippet of my rules on my ingress filter is: 1) ... block bad things such as unused or spoofed addrs ... 2) allow icmp from any to any icmptypes 0,3,4,11,12 3) deny ip from 10.0.0.0/8 to any 4) deny ip from 172.16.0.0/12 to any 5) deny ip from 192.168.0.0/16 to any 6) allow tcp from any to any 1024-65535 established 7) ... some other rules ... 8) deny everything else by default Line #2 allows relatively benign incoming ICMP, such as "fragmentation needed", but hopefully blocks the more problematic stuff. I added this exception for a very practical reason. Without it there were many routers, generating ICMP messages using RFC1918 source addresses, whose error messages were important, but that I dropped at the firewall. Interestingly, these messages passed thru MANY intermediate routers that didn't block packets with RFC1918 source addresses. If you take it upon yourself to "filter all RFC1918 usage" from the outside world, you (and your customers) will suffer for it. Because it seems to be established practice out there. Of course I never send packets to the Internet with an RFC1918 address in them.

7 9

ARIN Meetings and Upcoming Elections
by Richard Jimmerson 18 Jul '00

18 Jul '00

ARIN will hold it's biannual public policy and members meetings on October 2 through 4 in Herndon, Virginia. Registration and other information about these meetings can be found under the announcements section of ARIN's front page (http://www.arin.net) Information about upcoming ARIN elections can also be found under the announcements section of ARIN's front page. There is currently an open call for ASO AC election nominations and member volunteers are being sought for the BOT elections nominating committee. Updated information regarding ARIN elections will be announced and posted to ARIN's website periodically between now and October. Regards, American Registry for Internet Numbers (ARIN)

1 0