- Test - lists.nanog.org

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 02 Mar '05

02 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

not operationally relevant until it's used in the wild
by k claffy 02 Mar '05

02 Mar '05

but in the interest of full and early disclosure, etc k ----- Forwarded message from k claffy <kc(a)caida.org> ----- Date: Tue, 1 Mar 2005 17:34:27 -0800 From: k claffy <kc(a)caida.org> Subject: [Caida] yoshi's study on remote physical device fingerprinting To: caida(a)caida.org Cc: Tadayoshi Kohno <tkohno(a)cs.ucsd.edu> Yoshi Kohno (doctoral student in UCSD's CSE program) just released an eye-opening paper demonstrating methods for remotely fingerprinting a physical device without any modification to or known cooperation from the fingerprintee. At a high level, these techniques exploit microscopic deviations in device hardware: clock skews. Specifically, they exploit the fact that most modern TCP stacks implement the TCP Timestamps Option (RFC 1323). When this option is enabled, outgoing TCPs packets leak information about the sender's clock. Yoshi's results further confirm a fundamental reason why securing real-world systems is so difficult: it is possible to extract security-relevant signals from data canonically considered to be noise. The equally disturbing corrolary is that there remain fundamental properties of networks that we have yet to integrate into our security models. please don't forward to any bad guys. </cough> k paper and abstract available here: ======================================================= <http://www.cse.ucsd.edu/users/tkohno/papers/PDF/> [mirror site] <http://www.caida.org/outreach/papers/2005/fingerprinting/> Our abstract: We introduce the area of remote physical device fingerprinting, or fingerprinting a physical device, as opposed to an operating system or class of devices, remotely, and without the fingerprinted device's known cooperation. We accomplish this goal by exploiting small, microscopic deviations in device hardware: clock skews. Our techniques do not require any modification to the fingerprinted devices. Our techniques report consistent measurements when the measurer is thousands of miles, multiple hops, and tens of milliseconds away from the fingerprinted device, and when the fingerprinted device is connected to the Internet from different locations and via different access technologies. Further, one can apply our passive and semi-passive techniques when the fingerprinted device is behind a NAT or firewall, and also when the device's system time is maintained via NTP or SNTP. One can use our techniques to obtain information about whether two devices on the Internet, possibly shifted in time or IP addresses, are actually the same physical device. Example applications include: computer forensics; tracking, with some probability, a physical device as it connects to the Internet from different public access points; counting the number of devices behind a NAT even when the devices use constant or random IP IDs; remotely probing a block of addresses to determine if the addresses correspond to virtual hosts, e.g., as part of a virtual honeynet; and unanonymizing anonymized network traces. _______________________________________________ Caida mailing list Caida(a)caida.org http://rommie.caida.org/mailman/listinfo/caida ----- End forwarded message -----

1 0

Fwd: Impending publication: draft-iab-dns-assumptions-02.txt
by Fergie (Paul Ferguson) 01 Mar '05

01 Mar '05

Of imminent interest to the operations community.... FYI, - ferg ---------- Forwarded Message ---------- The IAB is ready to ask the RFC-Editor to publish What's in a Name: False Assumptions about DNS Names draft-iab-dns-assumptions-02 as an Informational RFC. This document reviews the potential assumptions that may be made based on domain names, as well as the potential implications (and pitfalls) of those assumptions. The IAB solicits comments by March 29, 2005. Please send comments to the IAB (iab(a)iab.org) or to ietf(a)ietf.org. The document can be found at http://www.ietf.org/internet-drafts/draft-iab-dns-assumptions-02.txt >From the Abstract: The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, URIs, and other application layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. A danger of this trend is that the humans and automata which consume and use these identifiers will make assumptions about the services that are or should be provided by the hosts associated with these identifiers. This document discusses this problem in more detail and makes recommendations on how it can be avoided. Leslie Daigle, For the IAB. _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

1 0

[ACM SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05)]
by k claffy 01 Mar '05

01 Mar '05

perhaps more relevant to nanog-futures list but i'll assume everyone cares. k ----- Forwarded message from Bob Braden <braden(a)ISI.EDU> ----- Date: Mon, 28 Feb 2005 08:50:30 -0800 (PST) From: Bob Braden <braden(a)ISI.EDU> Subject: [e2e] ACM SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05) To: end2end-interest(a)postel.org ------------------------------------------------------------------- Call for papers ****************************************************************** * * * SIGCOMM 2005 Workshop on Mining Network Data (MineNet-05) * * * * (to be held with SIGCOMM 2005, Aug 20-26, Philadelphia, USA) * * * * http://www.acm.org/sigs/sigcomm/sigcomm2005/cfp-minenet.html * ****************************************************************** Today's IP networks are extensively instrumented for collecting a wealth of information including traffic traces (e.g., packet or flow level traces), control (e.g., router forwarding tables, BGP and OSPF updates), and management (e.g., alarms, SNMP traps) data. The real challenge is to process and analyze this vast amount of primarily unstructured information and extract structures, relationships, and "higher level knowledge" embedded in it and use it to aid network management and operations. The goal of this one day workshop is to explore new directions in network data collection, storage, and analysis techniques, and their application to network monitoring, management, and remediation. The workshop will provide a venue for researchers and practitioners from different backgrounds, including networking, data mining, machine learning, and statistics, to get together and collaboratively approach this problem from their respective vantage points. We are soliciting original/position papers on topics (including, but not limited to) listed below. - Collection, storage & access infrastructure: platform instrumentation (e.g. multi-modal, multi-resolution sensors), collection techniques (e.g. event sampling, filtering, aggregation, etc.), storage and access (e.g. retention policy, indexing techniques etc.). - Network data analytics techniques & tools: network stream mining, network graph mining, micro-clustering, temporal and statistical correlation, causality tracking, machine learning. - Applications to network operations & management: network problem determination, network reliability and performance, root-cause analysis, security, emerging phenomenon detection (e.g. DDoS, virus/worm, spam etc.), traffic classification. Of particular interest are (i) new solution techniques as well as applications of existing techniques from data mining, machine learning and statistics to IP network problems, (ii) experiences with the use of such techniques for IP networks, and (iii) open networking problems and challenges that would benefit from the use of such techniques. Selected papers will be forward-looking, with impact and implications for both operational networks and ongoing or future research. Submission Instructions ----------------------- Papers should be at most 6 pages long, in standard ACM format (single-spaced, double column, at least 10pt font). Accepted papers will appear in the workshop proceedings. Authors of accepted papers are expected to present their work at the workshop. Detailed submission guidelines will be available soon at http://www.acm.org/sigs/sigcomm/sigcomm2005/cfp-minenet.html. Important Dates --------------- Submission Deadline: Wed, April 6, 2005, 9.00 PM EST Notification Deadline: May 10, 2005 Camera Ready Deadline: May 30, 2005 Workshop Date: Aug 26, 2005 Workshop Organizing Chairs -------------------------- Subhabrata Sen, AT&T Research Chuanyi Ji, Georgia Tech Debanjan Saha, IBM Research Joe McCloskey, Dept. of Defense Technical Program Committee ---------------------------- Constantinos Dovrolis, Georgia Tech. Chuanyi Ji, Georgia Tech. Nick Koudas, Univ. of Toronto Vipin Kumar, Univ. of Minnesota Joe McCloskey, Dept. of Defense Robert Novak, Univ. of Wisconsin-Madison Rajeev Rastogi, Lucent Bell Labs John Reumann, IBM Research Jennifer Rexford, Princeton Univ. Mathew Roughan, Univ. of Adelaide Debanjan Saha, IBM Research Subhabrata Sen, AT&T Research William Szewczyk, Dept. of Defense Walter Willinger, AT&T Research Zhi-Li Zhang, Univ. of Minnesota ----- End Included Message ----- ----- End forwarded message -----

1 0