March 2005 - Test - lists.nanog.org

Re: Heads up: Long AS-sets announced in the next few days
by Kurt Erik Lindqvist 02 Mar '05

02 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2005-03-02, at 19.38, James A. T. Rice wrote: > This seems to suggest that you are just picking ASns at random to > inject into the paths, and that you don't have a set of ASs which you > have the assignees permission to use. Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQiYNZ6arNKXTPFCVEQL/sgCdHCBV87HM9jIgNATJhpW5aON/1TwAniAR i1p06marP5ra05ey9YcxX90f =W+rc -----END PGP SIGNATURE-----

1 0

Comcast Contact. (was: RE: AOL scomp)
by chuck goolsbee 02 Mar '05

02 Mar '05

Pardon my interruption of the ongoing discussion of SMTP trust models and FUSSPs (which I think is very important BTW), but if there is somebody from Comcast here that can help us solve an immediate related issue, please contact me or one of my postmasters off list? Normal channels have been attempted unsuccessfully, for a problem that has been repeating itself every few days for the past two months. --chuck goolsbee digital.forest inc, seattle, wa <http://www.forest.net> cg(a)forest.net - noc(a)forest.net - 206-838-1630 xt2001 - AIM:chuckgoolsbee or billd(a)forest.net - postmaster(a)forest.net - 877-720-0483 xt 2002 Thanks. --

1 0

Re: Heads up: Long AS-sets announced in the next few days
by Lorenzo Colitti 02 Mar '05

02 Mar '05

Gert Doering wrote: >>2005-03-04: >> 14:00 UTC: 10-element AS-set >> 14:30 UTC: withdrawal >> 16:00 UTC: 25-element AS-set >> 16:30 UTC: withdrawal > > Please do not announce AS-sets that contain 5539. We are not part of > your experiment, and we don't want to see our AS appear in other people's > router error messages. Ok, no problem: we will not include AS 5539 in any of the AS-sets we announce. Regards, Lorenzo

1 0

Re: AOL scomp
by Anne P. Mitchell, Esq. 02 Mar '05

02 Mar '05

> Otherwise, I think that it can be helpful in identifying issues. We use it to help advise us with respect to the IADB accreditation database, and what we have found is that yes, there are a lot of complaints for legitimate opt-in mail, but a demonstrable change in *volume* (rather than the valid:invalid complain ratio) can often notify us very early on about a problem mailing by someone listed in IADB. Due to the nature of the senders listed in IADB, typically a "what's going on with this??" inquiry will result very quickly in a problem customer of the sender's either getting a clue or getting the boot. Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy http://www.isipp.com http://www.isipp.com/iadb.php Professor of Law, Lincoln Law School of SJ

1 0

ingress filter
by adrian kok 02 Mar '05

02 Mar '05

Hi all I used "ingress-loose-template" from cisco and applied to my bgp ingress filter. I got the following part of the log files and not sure it is right filter or not Can you help? BGP: 1.2.3.4 rcvd UPDATE about 168.187.178.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 167.231.51.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 147.182.199.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.208.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.216.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.224.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.232.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.240.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.248.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.208.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.216.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.224.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.232.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.240.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.248.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.208.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.216.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.224.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.232.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.240.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.248.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.192.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 158.222.4.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 170.210.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.90.0/23 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.92.0/22 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.112.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 144.106.82.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 166.114.156.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 144.106.82.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 166.114.156.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.90.0/23 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.92.0/22 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.112.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 153.2.228.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 129.66.96.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 136.210.48.0/22 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 146.178.26.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 153.96.100.0/24 -- DENIED due to: filter;

1 0

Re: AOL scomp
by Gregory Hicks 02 Mar '05

02 Mar '05

> Date: Wed, 2 Mar 2005 10:25:56 +0530 > From: Suresh Ramasubramanian <ops.lists(a)gmail.com> > > > On Tue, 01 Mar 2005 09:28:31 -0500, Vinny Abello <vinny(a)tellurian.com> wrote: > > I can attest that we do not see the same here as you are seeing (1 in 100). > > I'd agree more with the 1/3 being stupid AOL users reporting regular > > messages that were either forwarded from their own account that we host to > > Well - there's a way out, sort of. > > 1. Route .forwarded email out a separate IP (besides cutting down on > accepting and forwarding spam) > > or > > 2. Find some way - like an X-Forwarded-For header, that AOL can tag on. There aready ARE such headers... "Resent-From:", "Resent-To:", ... > > --srs > > -- > Suresh Ramasubramanian (ops.lists(a)gmail.com) ------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: ghicks(a)cadence.com I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. "A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision." - Benjamin Franklin "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

1 0

RE: More on Vonage service disruptions...
by Fergie (Paul Ferguson) 02 Mar '05

02 Mar '05

One the points that I left unsaid, however, is that there may be many, many reasons -- both technically and business-wise -- why an ISP would want to port- filter, or for a better generalization, "suppress" some traffic. For instance, blocking p2p traffic, or a known worm, whatever. And there very likely may be busine$$ reasons, as well. A corrollary: Is it a denial of service to suppress (dampen) a BGP route when it flaps excessively? Or perhaps an bloack-hole a RBL entry? Most would say not, certainly depending on the reason (self- and Internt-preservation and stability), but certainly someone could arguably make a federal case out of it (levity implied) or similar suppresssions or blocking of traffic. VoIP brings these issues to the forefront. In any event, it's going to be interesting to see how this evolves. - ferg -- "Church, Chuck" <cchurch(a)netcogov.com> wrote: Those are good points. Someone last week mentioned what I thought was a great list of priorities for an ISP: 1. Keep the network running 2. Remove those violating policies 3. Route packets (or something along those lines) A 30/50/90 kbps unicast stream isn't going to affect #1. I don't think any policies involved in #2 would cover a VoIP service either. That should leave #3 as the default for this traffic. I can picture a DDOS where infected Windows machines could send bogus SIP traffic to Vonage servers; in this case temporary blocking might be needed/justified. But until that happens, blocking SIP is just wrong. Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 cchurch(a)netcogov.com PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

High volume WHOIS queries
by Dan Lockwood 02 Mar '05

02 Mar '05

I'm in a disagreement with ARIN about my application for bulk whois data. I've got a software program that needs resolve AS numbers to the Company Name of the owner. The software app has need to do this on a very high volume. E.g. I run a report that returns the top 100 AS destinations for my network and I want to resolve the numbers to the names as part of the report generation. Since ARIN throttles the number of queries that you can execute against their servers I seems to "just make sense" that you would do the processing using local data. That is all fine and good, but the problem comes when I distribute the software to users. ARIN's AUP for bulk whois states: "Redistributing bulk ARIN WHOIS data is explicitly forbidden. It is permissible to publish the data on an individual query or small number of queries at a time basis, as long as reasonable precautions are taken to prevent automated querying by database harvesters." My original AUP application stated that I would transfer the data to the users using an XML file on a regular basis. Clearly in violation of the first point. Fine. But now after a phone conversation they are telling me that I can not operate a server to distribute the data on a "per query" basis too. Providing a server that answers whois queries just like ARIN seems to be clearly permissible based on the remaining AUP verbage. At this point the only thing I can get out of the guy/gal on the phone is "NO!". Does anyone have any experience doing something like this? How about a sanity check? Am I completely wrong in how I'm interpreting the AUP? Thanks, Dan

8 7

Re: Heads up: Long AS-sets announced in the next few days
by Daniel Roesen 02 Mar '05

02 Mar '05

On Wed, Mar 02, 2005 at 01:27:31AM +0000, James A. T. Rice wrote: > What exactly are you attempting to do here? Those announcements will get > dropped on the floor at least in this AS right away: > > route-map peers-in deny 5 > match as-path 109 AS-Sets, not AS-Paths... Regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

3 3

RE: Why do so few mail providers support Port 587?
by Hannigan, Martin 01 Mar '05

01 Mar '05

Hi Folks, It's time to take this thread to SPAM-L or some other spam oriented list. Thanks in advance, -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > just me > Sent: Friday, February 25, 2005 5:26 PM > To: Frank Louwers > Cc: nanog(a)merit.edu > Subject: Re: Why do so few mail providers support Port 587? > > > > On Fri, 25 Feb 2005, Frank Louwers wrote: > > The trick is to config port 587 in such a way that it ONLY accepts > smtp-auth mail, not regular smtp. > > That way, virii/spam junk won't be able to use that port. > > What are you, stupid? The spammers have drone armies of machines > with completely compromised operating systems. What makes you think > that their mail credentials will be hard to obtain? > > matt ghali > > --matt(a)snark.net------------------------------------------<darwin>< > The only thing necessary for the triumph > of evil is for good men to do nothing. - Edmund Burke >

3 2