September 2008 - NANOG - lists.nanog.org

Is the export policy selective under valley-free?
by Kai Chen 03 Sep '08

03 Sep '08

Just want to ask a direct question. Will an AS export all it gets from its customers and itself to its providers? Or even under valley-free, the BGP export policy is also selective? Thanks a lot, -- -Kai

7 14

hosting net guest
by Randy Bush 03 Sep '08

03 Sep '08

we have a couple of sharp net engs coming to nanog/arin in la from far less privileged parts of the world. i thought it might be nice if they could stay a few extra days or a week to see how those of us privileged to have larger markets and hence scaled up networks run our shows. would anyone on the left coast be willing to host a guest or two for a few days and let them see inside the guts of your operation? responses to me privately, please. and excuse poor response this week as i am on holiday. thanks. randy

1 0

Re: ingress SMTP
by hobbit＠avian.org 03 Sep '08

03 Sep '08

Wow, lots of responses already. Thanks, good discussion. I should clarify a little, that it's not necessarily about "blanket" port blocking or denying "random" ports as threats are perceived, but where needed in a well thought-out manner and trying to take customer needs [stated or observed] into account first. And back it up with AUP verbiage. There must be plenty of places where it just makes sense, and others where it's borderline, iffy, or unmanageable. One has to start *someplace*. Oh, and don't get me started about abuse-desk competency, or even existence, especially in the big providers. I'll bet most of them can't even find the *rack* where the autoresponder machine is, let alone actually figure out why its disk has been full for six months. Related question, now that some discussion has started: why the F does Gmail refuse to put real, identifiable injection-path headers in mail they relay out? The current "policy" only protects spammer identities behind a meaningless 10.x and is completely at odds with what almost every other freemail provider does, which of course breaks any receiving-end model. Who's here from Google that I can chat with about this? _H*

2 1

[NANOG-announce] Important Reminders and Announcement
by Betty Burke 03 Sep '08

03 Sep '08

Dear NANOG Community: Just a few reminders and a news item. The deadline for Steering Committee Nominations is near, Tue 2008-09-09. Complete election information is available on the NANOG website. The new process will work if many are involved... nudge: A great NANOG44 agenda is now posted. Make sure to check it out and register!! Merit, along with the entire NANOG community, appreciates the involvement and support from our sponsors. If you are interested, please send email to nanog-support(a)nanog.org, as a few sponsorship opportunities for NANOG44 remain. Do not miss out on your opportunity to be part of this meeting. As many of you know, Merit has been working to improve the NANOG.ORG website. We are very pleased to announce the new site will be launched on Thursday morning, Sept. 4, at 7 am EST. Members of the NANOG Steering Committee have been working with Merit, and we hope all issues have been resolved. We believe the community will find the new site to be much more useful. "I think the website looks great, is very professional, and a huge leap forward in functionality and usability", Philip Smith-SC Chair. New features include: - Graphic and Text version of the web site - New presentation archive that allows for searching by NANOG meeting, year, presenter and more. - "Print This" feature, which will strip away page navigation for easier printing. - Easier web site navigation and improved appearance - RSS Feeds and much more! The meeting archive and presentation archive are still being completed, but you will soon be able to access the remaining past meeting information. Thanks for being a part of NANOG. We hope you check out the new site and use it to keep in touch with important issues surrounding the Internet and the NANOG community. We look forward to seeing many of you in LA at NANOG44! and for your participation in the NANOG 2008 Elections process. As always, if you have any questions, concerns, or issues with NANOG support activities, please feel free to send a note to NANOG-Support(a)nanog.org or phone us at Merit (734)764-9430. All best. Betty Burke Merit/NANOG Project Manager www.nanog.org www.merit.edu _______________________________________________ NANOG-announce mailing list NANOG-announce(a)nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce

1 0

RE: ingress SMTP
by Skywing 03 Sep '08

03 Sep '08

Intercepting port 25 traffic of your customers (as an ISP), redirecting it to your own servers, and allowing the connection to complete sounds like a pretty slippery slope of badness to me. Sure, you should be using TLS anyway, but slurping up port 25 traffic begs the question of what is happening to the SMTP authentication credentials or the mail data that flows through said intercept. Blocking traffic versus intercepting it wholesale are very different ballgames. Now, obviously, whoever is providing your pipe has the technical ability to intercept your traffic. Actually doing this has proven widely unpopular (to place it nicely) when uncovered, even with the best of intentions. There is usually an implicit trust that your ISP won't be employing underhanded tactics like that in most people's minds, I think. I suspect that most people will call any interception of their outbound mail traffic "underhanded", even for if done for a perceived good reason in the mind of said ISP. - S -----Original Message----- From: Stephen Sprunk <stephen(a)sprunk.org> Sent: Wednesday, September 03, 2008 12:09 To: Alec Berry <alec.berry(a)restontech.com> Cc: north American Noise and Off-topic Gripes <nanog(a)merit.edu> Subject: Re: ingress SMTP Alec Berry wrote: > Michael Thomas wrote: > >> But the thing that's really pernicious about this sort of policy is >> that it's a back door policy for ISP's to clamp down on all outgoing >> ports in the name of "security". >> > > I don't think ISPs have anything to gain by randomly blocking ports. They may block a port that is often used for malicious behavior (135-139, 194, 445, 1433, 3306 come to mind) as a way to reduce their support calls-- but they would have to balance that with the risk of loosing customers. It's not as much a slippery slope as much as it is a tightrope act (yes-- I am metaphorically challenged). > I see nothing wrong with filtering commonly abused ports, provided that the ISP allows a user to opt out if they know enough to ask. When port 25 block was first instituted, several providers actually redirected connections to their own servers (with spam filters and/or rate limits) rather than blocking the port entirely. This seems like a good compromise for port 25 in particular, provided you have the tools available to implement and support it properly. I also agree with the comments about switching customers to 587. My former monopoly ISP only accepted mail on 25 and I had endless problems trying to send mail from airports, hotels, coffee shops, etc. while traveling. The same hotspots also tended to block port 22, so I couldn't even forward mail via my own server. However, my new monopoly ISP only accepts mail on 587, and I have yet to have a single problem with that from any hotspot I've used since the switch. Ditto for reading my mail via IMAPS/993, whereas I used to have occasional problems reading it via IMAP/143. S

1 0

Re: BGP Scalability Simulation
by Fouant, Stefan 03 Sep '08

03 Sep '08

Topology and setup of these kinds of tests largely depend on whether you are testing iBGP or eBGP. In my experience, eBGP testing is fairly straight forward as you are almost always testing reconvergence of the BGP next-hop. iBGP testing scenarios on the other hand can be quite a bit more complex as you may also be testing the reconvergence of the underlying IGP if the BGP next-hop remains unchanged. Can you describe your testing goals and environment in a bit more detail? Stefan Fouant Principal Network Engineer NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D ----- Original Message ----- From: Moazzam Khan <emoazzam(a)gmail.com> To: nanog(a)nanog.org <nanog(a)nanog.org> Sent: Mon Sep 01 15:37:19 2008 Subject: BGP Scalability Simulation Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK

6 7

"How the 'Net works: an introduction to peering and transit" (arstech)
by Paul Vixie 02 Sep '08

02 Sep '08

http://arstechnica.com/guides/other/peering-and-transit.ars -- Paul Vixie

1 0

BGP Scalability Simulation
by Moazzam Khan 02 Sep '08

02 Sep '08

Hi I am trying to simulate BGP for scalability testing. I have few queries. 1) What sort of topology I should try out ? 2) What parameters should I test? I am trying to simulate it in ns-2 and i would appreciate reply from you guys. Regards MAK

2 1

Re: GLBX De-Peers Intercage [Was: RE: Washington Post: Atrivo/Intercag e, why are we peering with the American RBN?]
by Paul Ferguson 01 Sep '08

01 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- "Steven M. Bellovin" <smb(a)cs.columbia.edu> wrote: >On Mon, 01 Sep 2008 11:08:20 -0400 Valdis.Kletnieks(a)vt.edu wrote: > >> a) There exist providers that are willing to take money from scum. >> b) We won't get rid of the scum until we admit (a) is true. > >I mostly agree with you -- but I get very worried about who defines >"scum". Consider the following cases, which I will assert are not very >far-fetched: > I can certainly see how the definition of "scum" could be hijacked to fit any particular political agenda, too. For the particular purposes I referred to earlier, the definition would be: "Continuing to allow criminal activity to occur within your network." "Criminal activity" is easily definable by laws which state that malicious, willful, and concerted attempts to perpetrate financial theft, fraud, and unauthorized computer tampering are illegal. But with all the ensuing discussion, it would appear that this is a matter in which ISPs defer, and a matter best addressed by law enforcement. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFIvEXpq1pz9mNUZTMRAhRNAJ9nzEVp3PCAoQKFKltQFRwh3yLpwACg0gRO EnWO3Y4YQ/Z+F52z5il6Pdg= =cMVa -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Washington Post: Atrivo/Intercage, why are we peering with the American RBN?
by Gadi Evron 01 Sep '08

01 Sep '08

Hi all. This Washington Post story came out today: http://voices.washingtonpost.com/securityfix/2008/08/report_slams_us_host_a… In it, Brian Krebs discusses the SF Bay Area based Atrivo/Intercage, which has been long named as a bad actor, accused of shuffling abuse reports to different IP addresses and hosting criminals en masse, compared often to RBN in maliciousness. "The American RBN", if you like. 1. I realize this is a problematic issue, but when it is clear a network is so evil (as the story suggests they are), why are we still peering with them? Who currently provides them with transit? Are they aware of this news story? If Lycos' make spam not war, and Blue Security's blue frog were ran out of hosting continually, this has been done before to some extent. This network is not in Russia or China, but in the silicon valley. 2. On a different note, why is anyone still accepting their route announcements? I know some among us re-route RBN traffic to protect users. Do you see this as a valid solution for your networks? What ASNs belong to Atrivo, anyway? Anyone has more details as to the apparent evilness of Atrivo/Intercage, who can verify these reports? As researched as they are, and my personal experience aside, I'd like some more data before coming to conclusions. Hostexploit released a document [PDF] on this very network, just now, which is helpful: http://hostexploit.com/index.php?option=com_content&view=article&id=12&Item… Gadi.

5 5