September 2002 - Test - lists.nanog.org

Re: How do you stop outgoing spam?
by Dave Crocker 18 Sep '02

18 Sep '02

At 01:09 PM 9/18/2002 -0400, Greg A. Woods wrote: > > I guess the last 20 years of Internet use have been entirely invalid > > then. >Not necessarily -- it's a matter of what level of risk is acceptable in >a given scenario. Thank you. That was my point. It therefore is essential to pay attention to fixing only real-world problems that have an operational basis -- or an extraordinarily unacceptable downside -- before imposing significant change on a large installed base of users. >However we've now reached a point where spammers resort daily to theft >of service against remote mail server and to direct attacks against >target remote mail servers. As bad as that is, it is a long way from stealing connections. Entirely different technical basis. The current situation is technically trivial. Stealing connections is not. Perhaps that is why the former happens all the time and the latter does not. >You're pointing out that some users don't want to live with that more >restrictive framework. I am pointing out that there is a balancing act to perform, and that 100 million users is more than "some". And lest you note that all 100 million are not mobile, and that some mobile users are not inconvenienced, I'll respond that whatever the number is, the impact on mobile hotspot users should finish the question about scale of the impact. >I.e. you can do what you want to do if you use the right tools, but you >can't do it over TCP port 25. If you think a bit harder about your assertion, you will realize that the port number neither creates nor restricts the protection. All that changing the port number does is to impose guaranteed inconvenience on the entire population of mobile users. > > Too bad the 100 million current Internet users do not know that. >Indeed it is. Your kind of F.U.D. doesn't help any either. Noting the impact on the installed base of Internet users is FUD? And by the way... For all the supposed benefit of port blocking -- eg, we don't see as much dial-in spam sourcing -- do we have less spam in the world? Is spam less of a problem? So the inconvenience to mobile users has not solved or even reduced the global problem. Mechanisms for controlling globe-scaled misbehaviors need to be surgical in the care with which they are chosen and applied. Outbound port blocking is a blunt instrument and it is swung blindly. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0

Re: How do you stop outgoing spam?
by Dave Crocker 18 Sep '02

18 Sep '02

At 11:27 AM 9/18/2002 -0400, Greg A. Woods wrote: >NO. Remote port-25 access, with or without SMTPAUTH, implies raw >unencrypted plain old TCP/IPv4, in which case there is no connection >integrity and thus no accountability. I guess the last 20 years of Internet use have been entirely invalid then. Too bad the 100 million current Internet users do not know that. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850

1 0

IPv6 revisited - I am building a list of IPv6 capable ISP's
by Joe Baptista 17 Sep '02

17 Sep '02

Hello: I am writing a second article on IPv6. My first article is indexed at http://www.circleid.com/articles/2533.asp I have tested IPv6 with the assistance if freenet6.net. It seems to work. In my second article I would like to include a list of ISP's who offer IPv6 to their customers. If you are an ISP that is IPv6 capable please drop me a line and I will include you in a list which will accompany the followup article. regards joe baptista The dot.GOD Registry, Limited http://www.dot-god.com/

2 2

N.I. Observer
by hostmaster 17 Sep '02

17 Sep '02

Anybody willing to share with me (off list) some experiences with Network Instruments' Observer and Analyst packs ? Rating A-E (A=best) perhaps ? As always obliged. Bert Fortrie hostmaster(a)nso.org

1 0

Port 2002
by Scott Call 17 Sep '02

17 Sep '02

Thanks for the quick response everyone, searching for "udp 2002" found way to many things at first, and then I found the info (within 1 minute of sending my email, of course). My apologies again for the time wasting :) -S

1 0

UDP Port 2002 DDOS?
by Scott Call 17 Sep '02

17 Sep '02

I apologize if this is an obvious question, but I've search bugtraq and other sources... I've had two customers complain today about massive amounts of incoming UDP traffic on port 2002. They appear to be some kind of DDOS or spoofed attack since the origin IPs on each packet are different. Is anyone else seeing something similar? Thanks -S -- Scott Call Router Geek, ATGi, home of $6.95 Prime Rib "Copyright Law is not a tool of repression granted to an unaccountable corporation by a corrupt congress at the expense of an ignorant public." -WW

1 0

RE: Testing BGP with real UPDATEs
by Vandy Hamidi 17 Sep '02

17 Sep '02

If you are testing the receipt of routes and inbound filtering, I just block all outbound advertisements and connect to an ISP or one of my border routers. That way you can test your filters and inbound access-lists and manipulate the BGP tables before putting the router into production. Hope that helps some, -=Vandy=- -----Original Message----- From: Sathya Perla [mailto:sperla@netplane.com] Sent: Tuesday, September 17, 2002 4:12 AM To: 'nanog(a)merit.edu' Subject: Testing BGP with real UPDATEs Hi, How is a BGP implementation tested with real Internet routing data (BGP UPDATEs)? Are there any experimental/test networks that can be connected to for testing a BGP implementation? Thanks, -Sathya

1 0

Re: How do you stop outgoing spam?
by Brad Knowles 17 Sep '02

17 Sep '02

At 1:51 PM -0400 2002/09/17, Greg A. Woods wrote: > No, Dave's second sentence is not true, thus his conclusion is bogus. Dave was talking about "normal" TCP connections, and I was following the same model. If you're talking about hi-jacking the TCP connection, then you are correct. > If you're talking about commercially available product, perhaps.... > > However this kind of thing is trivial with basic IPsec gateways and > simple filtering ala IP Filter, etc. How many ISPs use IPsec gateways and simple filtering with tools like IP filter? How scalable is this sort of thing? Could AOL do it with dozens or hundreds of OC-48 and OC-96 links? How long would it take to fix all the ISPs in the world that might potentially do transparent proxying of port 25? And where is the intelligence to selectively forward only those connections that are themselves encrypted and authenticated? -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

1 0

Re: How do you stop outgoing spam?
by Brad Knowles 17 Sep '02

17 Sep '02

At 10:26 AM -0700 2002/09/15, Dave Crocker wrote: > 2. The issue with email is authentication, not privacy. > Authentication can be achieved can be achieved easily over port > 25, without encryption. Hence, blocking port 25 blocks > legitimately validated email, as well as possible spam. True enough. However, there are no intelligent transparent proxies that I know of which will allow authenticated and/or link-encrypted port 25 connections through to the indicated site, and shunt the non-authenticated/non-encrypted sessions to the side. Since this information is only available at the IP level, this is not something you can fix inside the SMTP MTA -- the critical information is destroyed before then. I imagine if you could get cisco (and other vendors) to fix their transparent proxy server software to be more intelligent, that would fix the problem. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

2 2

Re: Eugene Call for Presentations
by Susan Harris 17 Sep '02

17 Sep '02

Thanks Henk! We'll be back in touch in later in September, once all the NANOG26 submissions have been received and reviewed. Susan Harris, Ph.D. Merit Network/Univ. of Mich. On Mon, 16 Sep 2002, Henk Uijterwaal (RIPE-NCC) wrote: > Hi Susan, > > > Hi - just a reminder that abstracts are due this Monday, Sept. 16. > > > CALL FOR PRESENTATIONS > > I'd like to propose the following presentation: > > > New services from the RIPE NCC > ------------------------------ > > During the last 5 years, the RIPE NCC has been working on 2 new services > for the entire ISP community: TTM or Test Traffic Measurements, and the > RIS or Routing Information Service. These projects were presented at the > Spring 1999 NANOG meeting but a large number of new features have been > added during the last 3 years. > > TTM: The TTM now consists of a network of +/- 70 machines, measuring > delay and loss between sites all over the world. Since 1999, 2 new > measurements have been added: > > - IP Delay Variations a.k.a. Jitter > - Bandwidth measurements, providing an estimate of both the > total available bandwidth between sites as well as the > unused bandwidth. > > We also would like to take this opportunity to present the new > CDMA based version of the measurement device. CDMA is a 3rd > generation mobile telephony standard that, as a side effect, > produces a timing signal. This timing signal can be used to measure > the performance of both IPv4 and IPv6 networks down to the 10 > microsecond level, anywhere when one can use a mobile phone without > the need for an expensive and hard to install GPS system. > > RIS: The RIS is now collecting BGP information from 9 sites world-wide, > with collectors in North American, Europe and Asia, with some 200 > ISP's participating by providing a BGP feed. New applications (since > the project was presented at the Spring 1999 NANOG) of the data > include: > > - Daily lists of hot-spots with the most active prefixes > - Analysis of flaps in the routing table. > - Detection of AS's and prefixes announced by ISP's but not properly > registered in the whois data-base and/or not assigned to them. > - Multi homing effects. > > This talk gives a short overview of the various services and how they can > be used in daily ISP operations, using the shutdown of a major European > backbone provider that recently went bankrupt as an example. > > Henk > > > ps. While I hope that more people will start using these services after > this talk, this is definitely not a sales talk. > > > Comment: I can do this talk in either one of 2 ways (or both): a short > plenary presentation (20 mins or so), showing the highlights and URL's, > inviting people to try these at home, or a longer version (2 hours or so) > showing people the details. The latter would be more suitable for a > tutorial or BOF. Just let me know what you prefer. > > > > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.5354414 > 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > That problem that we weren't having yesterday, is it better? (Big ISP NOC) > > NOTE: My email address (and a hole in our mailing list software) is being > abused by a spammer. We are working on fixing this hole and tracking > the spammer down. If you receive mail from "henk(a)ripe.net" that is > obviously spam, please send me a copy of the mail including ALL headers. > I'm sorry for any inconvenience caused by this. > >

1 0