October 2003 - Test - lists.nanog.org

Route-Views peering at PAIX and NSPIXP
by David Meyer 27 Oct '03

27 Oct '03

As part of the "Route-Views Update" presentation delivered at the NANOG 29 in Chicago, we openly invited participants at the PAIX (install pending) and NSPIXP (WIDE) exchanges to peer with Route-Views (AS6447). For those who may have forgotten or were not present, we thought we would repeat the offer. Those willing to peer, please contact us at help(a)routeviews.org. Thanks, The Route-Views Team

1 0

Re: ISPs' willingness to take action
by Stewart, William C (Bill), RTSLS 27 Oct '03

27 Oct '03

Brian Bruns asserts that there are lots of home users connecting to their office Exchange servers without VPNs, and that therefore blocking the Microsoft ports was bad. While I agree with his point that you shouldn't do it without documenting what you are or are not blocking, I'm really surprised to hear the assertion that people are leaving unfirewalled Exchange servers out on the net. Is this actually common? /shudders...

13 14

RE: ISPs' willingness to take action
by Michael.Dillon＠radianz.com 27 Oct '03

27 Oct '03

>VPN technologies are either too weak, like PPTP, too >expensive or difficult to grasp like IPsec, or too new >like the HTTPS tunnels. A couple of years ago, I was working at a company that used Exchange for corporate email. They had a web version of Outlook that, I believe, was part of Exchange server. It is almost a no-brainer to put that up on an HTTPS server. Due to the prevalence of online shopping and banking, even relatively clueless users understand how to look for the secure web browsing icon (key or lock). This is reasonably strong security, cheap to implement and easy to grasp. It's also been proven for almost 10 years now. And if you don't like Outlook's web version, there is always one of the many web email packages like SquirrelMail http://www.squirrelmail.org/ which can use IMAP or POP (both supported on Exchange server) and which can be secured via SSL/HTTPS. Somebody oughta sell a secure email box that plugs in between the Exchange server and the network and includes a secure SMTP server relay, secure POP server, secure IMAP server and secure web email interface. No doubt somebody already supplies boxes like this, and ISPs just have to start reselling them. >I don't recall the source, but it was recently reported >that 40% of the exchange server base is still on the v5.5 >platform. Using that as a general indication, many of >these shops probably won't plan to upgrade anytime soon. According to Google, Exchange 5.5 does both POP and IMAP so the possibility of secure web mail service is there. Seems to me that you could sell some service and educate the users about safe email practices at the same time. --Michael Dillon

2 1

Re: NOAA warning for rf communications
by Chris Yarnell 27 Oct '03

27 Oct '03

my office experienced 802.11b weirdness (sudden bouts of 0% signal for no apparent reason) earlier this week. i'm fully expecting more tomorrow. :) > There is a high likelihood that things like 802.11, licensed and > unlicensed microwave links, and certainly satellite links will sustain > interference over the next few days. I assume that everyone on the list > is both aware, and prepared ;-)

12 14

I-D ACTION:draft-savola-bcp38-multihoming-update-01.txt (fwd)
by Pekka Savola 27 Oct '03

27 Oct '03

FYI, This document has passed the IETF Last Call for Best Current Practice, and has been significantly revised based on the comments. I'll be on the IESG agenda in a couple of weeks. Feedback and comments is still sought (especially, I'd like to reword the title to be more generic, but couldn't figure out anything :-). Sending them off-list would probably be the most appropriate choice. Thanks, Pekka & Fred ---------- Forwarded message ---------- Date: Fri, 24 Oct 2003 10:35:41 -0400 From: Internet-Drafts(a)ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-bcp38-multihoming-update-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Ingress Filtering for Multihomed Networks Author(s) : F. Baker, P. Savola Filename : draft-savola-bcp38-multihoming-update-01.txt Pages : 19 Date : 2003-10-23 RFC 2827, BCP 38, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. However, it causes problems of its own. This document addresses the issues and proposes several possible solutions. This memo updates RFC 2827. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-bcp38-multihoming-update-0…

1 0

Re: AOL fixing Microsoft default settings
by Stewart, William C (Bill), RTSLS 27 Oct '03

27 Oct '03

Most ISPs don't provide users with a heavy-duty client that replaces or patches lots of the operating system's functions, though may will offer friendly customized browsers for users who want them, and a few misguided carriers will provide drivers for PPPoE or other evil excuses for protocols (:-) Generally, ISPs tell you the network settings to use on Windows, and tell you or let you guess for other popular operating systems, and they may give you a friendly dialer program that knows how to find their nearest POP but doesn't mess around much. Making major changes to a user's OS violates the principle of Least Astonishment (which is usually a policy problem, not an operational one, though you could argue that having a random network protocol not work quite right on Windows is less astonishing to most users than a flood of popups), but it also often fails to work successfully on security-compromised machines, which is an operational issue. So it won't stop viruses or trojans or spammerbots or crackers or spyware or worms or bad ActiveX or Javascripts. On the other hand, it could reduce some risks on machines that aren't cracked, and could reduce the spam level they receive, and can protect most of the users who aren't doing anything fancy, so as long as it's part of some friendly user interface menu and can be turned on and off it's ok. The alternative place to provide this kind of protection is in the network edge, which is probably the dial POP for most AOL users. If you implement it in a way that can be turned on or off per user, that's usually much cleaner, usually more scalable, and can work even when user machines are compromised. Bill Stewart, bill.stewart(a)pobox.com

4 3

Re: ISPs' willingness to take action
by Dr. Jeffrey Race 26 Oct '03

26 Oct '03

On Mon, 27 Oct 2003 10:25:36 -0500 (EST), Sean Donelan wrote: >Again, look the postal mail system. One proposal required everyone mail >letters in person at the post office, and show id to the postal clerk. >The problem is it really doesn't solve the problem. Third-party trust >systems don't scale well beyone one or two degrees of separation. And >there is only one major postal system. The solution is simple, proven, and works immediately (hours or days): a significant group of managers (from firms on this list) agree and announce that on a certain date and time, all mail will be bounced back to IP addresses with a recent record of emitting spam, viruses, trojans etc. (There are publicly available lists.) This has been done in limited areas and it works immediately to force the negligent providers to shut off all customers with dangerous boxes. To repeat a previous post, those with a quiet moment you might wish to take a look at <http://www.camblab.com/nugget/spam_03.pdf> and <http://www.camblab.com/misc/univ_std.txt> I'd welcome any comments. Jeffrey Race

1 0

Re: China Telecom filtering nameservers
by Owen DeLong 26 Oct '03

26 Oct '03

Yes... I just wanted to know which one this was. Owen --On Monday, October 27, 2003 07:32:07 AM +1100 gregh <chows(a)ozemail.com.au> wrote: > > ----- Original Message ----- > From: "Owen DeLong" <owen(a)delong.com> > To: "Tom (UnitedLayer)" <tom(a)unitedlayer.com>; "John Kristoff" > <jtk(a)depaul.edu> > Cc: "Daniel Medina" <medina(a)columbia.edu>; <nanog(a)merit.edu> > Sent: Thursday, October 23, 2003 5:28 PM > Subject: Re: China Telecom filtering nameservers > >> Care to share what was going on? Was it really censorship or something > more >> mundane and less offensive? > > I thought it has been LONG and WELL known that China has proxies in place to > filter what it's people see, eg censorship - or is this something different? > > Greg. > >

1 0

email to @emea.att.com still not going through -- anyone at AT&T available to look into this
by dani-nanog＠roisman.com 26 Oct '03

26 Oct '03

If there is anyone on this thread that can check out an AT&T email issue, the fix they put in place for @att.com has *not* yet been put in place for @emea.att.com, evidence below: $ dig +short mx att.com 100 ckmsi1.att.com. 100 ckmsi2.att.com. 100 kcmsi1.att.com. 100 kcmsi2.att.com. 5 almsi.att.com. 5 ckmsi.att.com. 5 kcmsi.att.com. 100 almsi1.att.com. 100 almsi2.att.com. $ dig +short mx emea.att.com 5 almsi1.att.com. 5 almsi2.att.com. 5 ckmsi1.att.com. 5 ckmsi2.att.com. 5 kcmsi1.att.com. 5 kcmsi2.att.com. As you can see above, there are 2 mx'ers available for att.com (almsi/ckmsi/kcmsi.att.com) that are not available for emea.att.com. Only the almsi1-2/ckmsi1-2/kcmsi1-2.att.com mx'ers are being handed out for @emea.att.com. Those are the mailservers that have been unreachable for most of this past week. - Dani

1 0

Any Cox network engineers?
by matthew zeier 26 Oct '03

26 Oct '03

If there are any Cox network folks, can you please contact me off list? -- matthew zeier - "Nothing in life is to be feared. It is only to be understood." - Marie Curie

1 0