- NANOG - lists.nanog.org

Problems on ATDN this evening?
by Chris Horry 18 Feb '04

18 Feb '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could a clueful person at ATDN (I've totally given up on Tech Support who seem to think it's an Internet Explorer issue...) tell me who I'm to call to get sensible technical support? :) I don't think this is an issue clearning my IE cache will resolve: Sample traceroute: traceroute to www.yahoo.akadns.net (216.109.118.67), 30 hops max, 38 byte packets: ~ 1 [censored] ~ 2 10.104.208.1 (10.104.208.1) 33.261 ms 19.641 ms 9.481 ms ~ 3 pos0-1.orldfldltn-rtr1.cfl.rr.com (24.95.226.113) 10.082 ms 7.719 ms 7.483 ms ~ 4 srp2-0.orldflwrpk-rtr2.cfl.rr.com (24.95.224.73) 17.200 ms 10.182 ms 12.921 ms ~ 5 srp4-0.orldfldvsn-rtr4.cfl.rr.com (24.95.224.10) 32.796 ms 21.182 ms 23.678 ms ~ 6 pop1-tby-P0-2.atdn.net (66.185.136.173) 17.532 ms 16.125 ms 17.136 ms ~ 7 bb1-tby-P0-2.atdn.net (66.185.136.164) 30.288 ms 14.761 ms 16.735 ms ~ 8 bb2-atm-P7-0.atdn.net (66.185.152.245) 46.710 ms 32.990 ms 32.029 ms ~ 9 pop1-atm-P4-1.atdn.net (66.185.150.3) 34.682 ms 34.601 ms 32.156 ms 10 CandW-atm.atdn.net (66.185.150.14) 563.166 ms 546.645 ms 533.035 ms 11 dcr1-so-4-3-0.Atlanta.cw.net (208.172.75.109) 554.113 ms 545.217 ms 560.184 ms . . . . . 17 p4.www.dcn.yahoo.com (216.109.118.67) 576.579 ms 528.573 ms 547.647 ms Apologies to the list if this is off topic. Chris - -- Chris Horry "Winter is the season in which people zerbey(a)wibble.co.uk try to keep the house as warm as it was PGP: DSA/2B4C654E it was in the summer, when they complained Amateur Radio: KG4TSM about the heat" --Author Unknown -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAMrkYnAAeGCtMZU4RAlP2AJ9Qfps4HpsPAFmZVRuauS75Aa2fZwCeMI2I TZ+vJ/w404jwLAqL9IVzfew= =T8HW -----END PGP SIGNATURE-----

2 1

BGP - weight
by Sven Huster 18 Feb '04

18 Feb '04

Hello Dumb question: If I apply a equal weight to all our transit/peers, will that affect route announcements to iBGP or eBGP peers anyhow? We got a very simple setup: - 2 routers on the border to transit/peers (that's were i want to set the weight) - 1 edge router to customers - core router running BGP as well What I want to achieve is that traffic leaves through the border router it arrived, rather than have it bounced around. We had some recent issues were it looks like the core got "out of sync" with the border (looks more like a sw issue than just convergence delay) and packets bounced back and forth between them. I know this doesn't solve the cause but the before digging for the initial reason I want a quick workaround. Cheers Sven

4 10

Re: Clueless service restrictions (was RE: Anti-spam System Idea)
by Michael.Dillon＠radianz.com 18 Feb '04

18 Feb '04

> * No authentication scheme Bang on! > People do, however, use it because there >currently is no realistic widely deployed alternative available. Those >that are currently available (e.g. SPF) are not widely deployed, and >in any case are far from perfect. Whilst we have no hammer, people will >keep using the screwdriver to drive in nails, and who can blame them? Another way of saying this is that every ISP who operates an SMTP server on port 25 which is willing to accept incoming email from unauthenticated sources is guilty of destroying the end-to-end model of the Internet and pushing us to a centrally controlled model where ISPs run walled gardens. It's that simple. --Michael Dillon

1 0

Re: Open, anonymous services and dealing with abuse
by Michael.Dillon＠radianz.com 18 Feb '04

18 Feb '04

>Everybody thinks if its not us, we don't have problem so we dont want >to spend anything to fix it - bu its not true, you already are paying >for it due to increased cost of operation. The cost of fixing your own >network even 50% of other ISPs did it, would in the end be smaller. The cost of building a network is a step function. If you didn't have to provision the capacity to handle the traffic from spammers and DDoS attacks, then you could delay spending these significant chunks of money. In fact, I suspect that this was an important factor in killing off companies during the telecom collapse. These companies were driven to expand their networks faster than could be justified by the paying customers because of the large amount of traffic generated by non-paying customers. DDoS and spam have to be tackled in two different ways but both of these problems will not be solved until we address the roots of the issue and not the symptoms. In both cases, the root of the issue is that network operators are unable to cooperate effectively in tracking down network abuse. I know that a lot of people in the ISP industry have a basically anarcho-libertarian political viewpoint and that viewpoint has helped them make the right kind of decisions in building most of the technical architecture of the Internet. But this has also blinded people to the advantages of co-operative action. There is nothing wrong with network operators meeting together in a forum to jointly make decisions about best practices for running the Internet's email system or for tracking down the true sources of network abuse. This is basically the same kind of thing that the IETF does for network protocols and the MPLS forum and the ATM forum, etc. Once again, I call on the companies who participate in the various NANOG forums to get your email engineers and email architects and email managers all together in a single forum to hash out the issues. We have solutions, too many of them, but we cannot deploy these things succesfully without broad agreement. Remember what Tony Hain and Phil Karn have said about end-to-end. If you get a bunch of network engineers together and ask them to stop spam they will inevitably want to configure their routers which leads to filtering and ACLs. Anyone who believes that would be a mistake should be supporting the concept of an Internet Email Operators Forum because the people responsible for the application will be able to find a solution at the application layer. --Michael Dillon

1 0

RE: Clueless service restrictions (was RE: Anti-spam System Idea)
by Alex Bligh 18 Feb '04

18 Feb '04

Tony, --On 17 February 2004 17:27 -0800 Tony Hain <alh-ietf(a)tndh.net> wrote: > Clearly I misinterpreted your comments; sorry for reading other parts of > the thread into your intent. The bottom line is the lack of a -scalable- > trust infrastructure. You are arguing here that the technically inclined > could select from a list of partial trust options and achieve 'close > enough'. While that is true, Joe-sixpack wouldn't bother even if he could > figure out how. Whatever trust infrastructure that comes into existence > for the mass market has to appear to be seamless, even if it is > technically constructed from multiple parts. What I am thinking of takes the policy decision at the "end" MTA level, i.e. the MTA closest to the user receiving the mail. That could be a techy user on a DSL line. In the case of Joe-Sixpack, it would be whoever runs POP/IMAP for him. If he runs an MTA without any of this stuff, he is left where he is now (i.e. gets all mail). > Steve Bellovin suggested earlier that identity based approaches wouldn't > work. While I agree having the identity won't solve the problems by > itself, it does provide a key that the rest of the legal system can start > to work with. False identities are common in the real world, so their > existence in the electronic world is not really any different. I am not sure you need to go as far as verifiable individual identities for each sender/user; however, you may need to go as far as being able to verify identities of MTAs - at least the first one that claims "I have received this from someone for whom I am prepared to deal with the abuse consequences". > I guess I > am looking at this from the opposite side the two of you appear to be, > rather than requiring authorization to send, irrefutable identity should > be used to deny receipt after proven abuse. I am using authorization to permit/deny *receipt* (not sending). Clearly if enough people deny unauthenticated receipt then in practice it does imply one needs to authenticate sending. Whether you deny receipt after proven abuse, or only accept receipt on proven identity is just a policy decision in the hands of the mail-system-admin as to what they do with the "don't know" case. I think this is getting (further) OT for NANOG & I should just write something up. Alex

1 0

Re: Stopping open proxies and open relays
by Dr. Jeffrey Race 18 Feb '04

18 Feb '04

On Fri, 6 Feb 2004 22:43:39 -0600 (CST), Adi Linden wrote: >I am looking for ideas to stop the spam created by compromised Windows >PC's. This is not about the various worms and viruses replicating but >these boxes acting as open relays or open proxies. > >There are valid reasons not to run antivirus software, coupled with >clueless users, this results in machines that SPAM again just a few hours >after having been cleaned. First step is correctly to specify the system's properties. Yours is not a technical issue but one of user negligence. You have to build the solution around this fact. Curative measures that have worked elsewhere are: 1-Scan every client when it accesses 2-Disconnect compromised clients or route only to a warning page allowing access only to your tech support 3-First cleanup and advice to owner of compromised machine on how to be a good internet member is free; second costs $100; third results in permanent discontinuance of service and refusal to accept back as a client. These measures will fix your problem. Jeffrey Race

2 1

Analogies=dead threads (was RE:Open, anonymous services and dealing with abuse)
by Rainer Atkins 18 Feb '04

18 Feb '04

Is it just me, or is it a clear indication that a thread is ending its useful life is when people start debating the merits of the analogies that have been posed rather than the original subject matter of the thread? Or, maybe a thread is exhausted when the analogies start to crop up. _________________________________________________________________ Take off on a romantic weekend or a family adventure to these great U.S. locations. http://special.msn.com/local/hotdestinations.armx

4 3

Re: SMTP authentication for broadband providers
by Michael.Dillon＠radianz.com 18 Feb '04

18 Feb '04

> To attack spam, we need to attack it at its core, not at some secondary or > tertiary side-effect, with a mechanism that also hurt legitimate users. We, as network operators don't need to attack spam. We need to ignore spam itself and get to work securing the network that enables spammers to do their dirty work. > Unless and until there is broad community consensus that answers that > question in concrete and practical terms, then all our efforts are > losing and stop-gap. I wouldn't go quite so far as that. Yes, broad consensus of the network operator community would help us to secure the architecture of the email system. That's why I have suggested that large email operators should be meeting regularly in a forum where they can discuss and agree upon *BEST PRACTICES*. But it also helps for people to implement best practices in a piecemeal fashion because that provides the real-world operational experience to prove that a particular practice is feasible. >From recent conversations on the list it appears that the BCPs for email include using the submission protocol for all end-user sending of email. But I would like to see this go a step further and require SMTP AUTH for every single SMTP session on port 25 as well. That means that AOL's mailservers would have to authenticate their sessions on Hotmail's servers before sending email and vice versa. It means that you cannot operate a mailserver without having a bilateral agreement in place with some set of email peers. It provides a chain of trust through those bilateral agreements that makes it easier to block SPAM and catch spammers. Yes, this probably means that we need to have some DNS related changes so that a domain can publish a list of their email peers and so that MTA software can figure out where to forward a particular email to reach its destination. But none of this is rocket science. And all of it could be accomplished by sitting the major email operators around a table to hash it out. NANOG could help here by devoting the next meeting to the various technical operational email issues and by extending to an additional day for the email operators forum. There is plenty of BCP material that could be presented and even though some of the operators like AOL have presented this in the past, an update would be useful to a lot of us. --Michael Dillon

15 19

NTIA/DoC public comment period
by Tony Hain 18 Feb '04

18 Feb '04

As I mentioned yesterday, the DoC is looking for public comment on IPv6. http://www.ntia.doc.gov/reports.html Specifically toward the end they ask: In some instances, government has responded to concerns over potential "chicken and egg" problems by playing an active role in the introduction of certain products and services, such as FM radio and HDTV. We request comment on how the deployment of IPv6 compares to other standards-based technology transitions and whether IPv6 presents the same or similar concerns that warrant government action. If you have opinions, be sure to send them by March 8. Tony

3 3

RE: Clueless service restrictions (was RE: Anti-spam System Idea)
by Chen, Weijing 17 Feb '04

17 Feb '04

You are right. End station (PC) is SCP-equivalent in packet world. Will Internet community allow or push for it? How to manage credentials, etc...? Pain and more pain... -----Original Message----- From: Alex Bligh [mailto:alex@alex.org.uk] Sent: Tuesday, February 17, 2004 4:21 PM To: Chen, Weijing; nanog(a)merit.edu Cc: Alex Bligh Subject: RE: Clueless service restrictions (was RE: Anti-spam System Idea) --On 17 February 2004 16:10 -0600 "Chen, Weijing" <Weijing_Chen(a)labs.sbc.com> wrote: > Sound like an any to any end to end signaling/control mechanism with > authentication capabilities. Smell fishy (packet version of dial tone?) Since when had dialtone got end-to-end signalling/control? My POTS line doesn't run C7/SS7. I mean authentication as in scp (and not tftp). IE one end user authorizes the other end user, using whatever credentials they like. Alex

1 0