- NANOG - lists.nanog.org

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
by Paul Vixie 29 Aug '02

29 Aug '02

> > If this function of your ISP costs less than 1 FTE per 10,000 > > dialups or 1,000 T1's or 100 T3's, then your ISP is a slacker and > > probably a magnet for professional spammers as well. > ... you're offering very definitive figures/labeling, and I'm curious > as to what you are basing your calculations/labels on, and what the > linearity of the scaling is in your opinion. > > Your own experience at MAPS? At MFN? Wishful thinking? those numbers are very round. i've seen folks do 1 FTE per 50,000 dialup users and get away with it, but that person was VERY busy. that ratio only works if the rest of the system is designed to repel the professional spammers, i.e., full ANI with filtering, full verification of credit cards (charge and refund before opening the account), nonrefundable deposit if terminated for spamming, and instant termination even at 4AM on sunday morning, ~30 hours or more before the account manager or any other manager could give approval. > Personally, I'd much rather try to justify a FTE for 1000 T-1s than I > would for 10,000 dialup users. like i said, the numbers were very round. as long as you understand that there IS a ratio and that the cost of dealing with outbound traffic does not end at the demarc point where it's handed to a peer or transit, then what the actual nonzero "abuse desk" costs actually are is a detail. this seems like something isp/c or cix should do a survey on.

4 3

Re: IPv6 Interview Questions and critic
by Kurtis Lindqvist 29 Aug '02

29 Aug '02

> However IPv6 has many privacy issues. IPv6 address space uses an ID > (indentifier) derived from your hardware or phone. "That allows your > packets to be traced back to your PC or cell-phone" said <censored>. > <censored> fears abuse as a hardware ID wired into the ipv6 protocol can > be used to determine the manufacturer, make and model number, and value > of the hardware equipment being used by the end user. ...uhm, and? What is the real difference with a IPv4 address and privacy? You can tell as much (more or less) with a port scan to a IPv4 address...and someone will always track the "ID" (I guess that is what I call IP address). If we are talking about the EUI64, that will disclose the vendor but hardly the make and model number.... - kurtis -

5 8

irtf-chair@ietf.org: Internet Measurement Research Group
by Mark Allman 29 Aug '02

29 Aug '02

Folks- A new group within the IRTF has been formed that will focus on measuring networks. It seems obvious that operators will have some valuable input into these issues and I would encourage folks to participate if they can. The announcement (& group charter) are attached. allman -- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ ------- Forwarded Message From: irtf-chair(a)ietf.org To: IETF-Announce:;;@loki.ietf.org Subject: Internet Measurement Research Group Date: Thu, 29 Aug 2002 07:24:02 -0400 A new IRTF research group, IMRG (Internet Measurement Research Group), has begun, with the appended charter. Use imrg-request(a)ietf.org to subscribe to the mailing list. See http://imrg.grc.nasa.gov/imrg/ for further information. - - Vern Paxson (IRTF chair) - -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ There is considerable network measurement work being conducted within the Internet community -- both in standards bodies (e.g., IETF IPPM WG) and in various research labs. The goal of the Internet Measurement Research Group (IMRG) is to provide a venue to: (1) provide a forum for discussion of Internet measurement research issues, (2) aid in the coordination of various research projects, (3) assess new measurement techniques, and (4) increase interactions between operators, developers of measurement tools and techniques, and researchers who analyze and model Internet dynamics. The scope includes all kinds of network measurement (active techniques, passive monitoring, end-point probing, in-network methods, network layer, transport layer, application layer, etc.). The RG will both attempt to design new measurement techniques and analyze measurements of the network taken. The following represent examples of the types of projects that the RG might undertake: Tackle outstanding issues dealing with measurement infrastructures (e.g., Surveyor, NIMI), such as: scalability of meshes, security of measurement tools in the mesh, access control, resource control, scheduling issues. Tackle the often thorny issue of sharing measurement data within the community. The RG could define a systematic way for storing measurements and any needed meta-data that should be kept with the measurements. In addition, the RG could foster research into systems for remote requests for measurement, analysis, and anonymization, facilitating a formed of reduced access to data that cannot be directly released. Provide a venue for assessing new measurement techniques, and a forum for sharing preliminary findings in rough form, to encourage further work and collaboration. Provide a venue for developing models based on network measurements, helping to better understand network dynamics and aiding researchers attempting to conduct useful simulations of the network. Foster communication between the research and operations communities. For example, operators could provide feedback to researchers as to what sorts of network properties/characteristics they would like to see measured, and how well current techniques work. Catalog core problems that need to be addressed. Even if the RG is not actively working on these problems, having a "wish list" of outstanding problems may foster work in these areas. Coordination - the RG will provide: A venue for exploring measurement techniques before they are ready to be standardized by the IETF (in IPPM, for instance). A venue for discussing real world experience with IETF defined metrics and measurement techniques. A "measurement arm" to various IETF working groups to gain a better understanding of how protocols work in the wild (e.g., which HTTP capabilities are being implemented or the performance of the global DNS system). ------- End of Forwarded Message

1 0

AT&T outage
by Manolo Hernandez 29 Aug '02

29 Aug '02

For everyones knowledge yesterdays AT&T outage was not really an outage but a Route-Reflection FUBAR on their Chicago link. -- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:manolo@dialtone.com http://www.dialtone.com "The only source of knowledge is experience." - A. Einstein

1 0

wireless access point accounting
by Hugh Irvine 29 Aug '02

29 Aug '02

Hello Everyone - I have recently been investigating wireless access points for 802.1x. Is anyone out there using radius authentication and accounting with these devices? If so could you please send me copies of the authentication requests and the accounting starts and stops? Any war stories regarding different brands would also be welcome. many thanks Hugh NB: I am travelling this week, so there may be delays in our correspondence. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.

1 1

Contact for dmisinetworks.com /
by Avleen Vig 29 Aug '02

29 Aug '02

Currently seeking an abuse contact for the above domain, or the party responsible for netblock that 66.21.84.209 is a part of: Netname: BELLSNET-BLK8 Netblock: 66.20.0.0 - 66.21.255.255 Maintainer: BELL Seeing repeated abuse from a single user against multiple hosts, and emails to abuse@bellsouth have gone unanswered. -- Avleen Vig: Work Time: Unix Systems Admin Email: work(a)silverwraith.com Play Time: Network Security Admin Pager: av-pager, at silverwraith.com Smurf Amplifier Finding Executive: http://www.ircnetops.org/smurf

2 1

Icelandic service restored
by Sean Donelan 29 Aug '02

29 Aug '02

The CANTAT-3 trans-atlantic cable between the Iceland and Canada and Europe was cut early this morning. E-mail and telephone service was restored around 3pm local time. Iceland Telecom said phone and Internet traffice was effectively cut off for about 9 hours while it re-routed the affected communications via satellite.

1 0

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at smtpng.org)
by Brad Knowles 29 Aug '02

29 Aug '02

At 6:13 PM -0700 2002/08/27, David Schwartz wrote: > I'm afraid the technology to rapidly sift through large volumes of > information to search for specific areas of interest is widely available. Really? Where? I'd like to know what they are and where. > It > is totally reasonable to not want to send mail through your ISP's mail > servers and perhaps directly to a trusted mail distributor over an encrypted > link. Fair enough. > Of course, you can easily use a port other than 25 for this purpose. Indeed. > The problem comes when the recipient tries to validate your origin address > against your secure mail server. Well, if you use TLSSMTP, I would think that would be resolved during the connection, by the authentication of the key. -- 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 1

Routing Problems?
by Mike Moglin 29 Aug '02

29 Aug '02

Anyone else seeing any Alter.net routing issues tonight?? 9 10 ms 10 ms 20 ms r1-srp13-0.in.hcvlny.cv.net [167.206.12.129] 10 10 ms 20 ms 10 ms POS3-3.GW9.NYC1.ALTER.NET [65.206.127.77] 11 10 ms 20 ms 20 ms 0.so-7-0-0.XR2.NYC1.ALTER.NET [152.63.9.2] 12 10 ms 20 ms 20 ms 0.so-1-1-0.XL2.NYC1.ALTER.NET [152.63.19.98] 13 10 ms 20 ms 10 ms 0.so-0-0-0.XL2.NYC8.ALTER.NET [152.63.21.62] 14 10 ms 20 ms 20 ms 0.so-5-0-0.XL1.NYC9.ALTER.NET [152.63.0.174] 15 10 ms 20 ms 20 ms 0.so-4-0-0.TL1.NYC9.ALTER.NET [152.63.0.173] 16 10 ms 20 ms 10 ms 0.so-5-0-0.XL1.NYC9.ALTER.NET [152.63.0.174] 17 10 ms 20 ms 10 ms 0.so-4-0-0.TL1.NYC9.ALTER.NET [152.63.0.173] 18 10 ms 20 ms 10 ms 0.so-5-0-0.XL1.NYC9.ALTER.NET [152.63.0.174] 19 10 ms 20 ms 10 ms 0.so-4-0-0.TL1.NYC9.ALTER.NET [152.63.0.173] 20 10 ms 20 ms 20 ms 0.so-5-0-0.XL1.NYC9.ALTER.NET [152.63.0.174] 21 10 ms 20 ms 10 ms 0.so-4-0-0.TL1.NYC9.ALTER.NET [152.63.0.173] 22 10 ms 20 ms 10 ms 0.so-5-0-0.XL1.NYC9.ALTER.NET [152.63.0.174] 23 10 ms 20 ms 20 ms 0.so-4-0-0.TL1.NYC9.ALTER.NET [152.63.0.173] 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out.

1 0

Re: Paul's Mailfrom (Was: IETF SMTP Working Group Proposal at
by Paul Vixie 28 Aug '02

28 Aug '02

> Interesting...I can't find any mention of integrating dcc support into > postfix (other than invoking procmail). Do you have any details or is this > wishful speculation? > > That would be quite nice... it's wishful speculation unless i'm underemployed for too much longer in which case it's a threat to port libmilter to postfix and be done with it.

2 1