May 2004 - NANOG - lists.nanog.org

Re: Spamcop
by Gregory Hicks 11 May '04

11 May '04

> Date: Tue, 11 May 2004 11:51:10 -0700 > From: Vicky Rode <vickyr(a)socal.rr.com> > To: nanog(a)merit.edu, nanog(a)nanog.org, nanog-support(a)nanog.org > Cc: rrsecurity(a)socal.rr.com, vickyr(a)socal.rr.com > Subject: Spamcop > > > Hi there, > > Just wondering why was my e-mail thread (Hierarchical Credit-based > Queuing (HCQ): QoS) dated 5/9/2004 9:36 PM reported as a spam? Just > trying to understand so that I don't repeat it. Below is a cut and paste > of the reported incident. Vicky: I'm guessing here, but it was probably because the *.rr.com addresses originate a LOT of spam and someone has a procmail filter that automatically refers any mail from that domain to spamcop... Or it could be that someone didn't like what you wrote and reported it ... Dunno. Remember, I said that I'm **guessing**. Regards, Gregory Hicks > > > Please advice. > > > regards, > /vicky > > > ---- cut here ------ > > Return-Path: <988145978(a)bounces.spamcop.net> > Received: from vamx01.mgw.rr.com ([24.28.193.148]) by > acme-reston.va.rr.com > (Post.Office MTA v3.5.3 release 223 > ID# 0-59787U250000L250000S0V35) with SMTP id com > for <abuse(a)rr.com>; Mon, 10 May 2004 10:42:14 -0400 > Received: from vmx2.spamcop.net (vmx2.spamcop.net [206.14.107.117]) > by vamx01.mgw.rr.com (8.12.10/8.12.8) with ESMTP id > i4AEkwhn017175 > for <abuse(a)rr.com>; Mon, 10 May 2004 10:47:01 -0400 (EDT) > Received: from sc-app3.verio.ironport.com (HELO spamcop.net) > (192.168.11.203) > by vmx2.spamcop.net with SMTP; 10 May 2004 07:47:00 -0700 > Received: from [68.13.211.63] by spamcop.net > with HTTP; Mon, 10 May 2004 14:47:01 GMT > From: 988145978(a)reports.spamcop.net > To: abuse(a)rr.com > Subject: [SpamCop (24.30.181.126) id:988145978]Hierarchical Credit-based > Queuing (HCQ): QoS > Precedence: list > Message-ID: <rid_988145978(a)msgid.spamcop.net> > Date: Sun, 9 May 2004 21:36:30 -0700 (PDT) > X-SpamCop-sourceip: 24.30.181.126 > X-Mailer: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR > 1.0.3705) > via http://www.spamcop.net/ v1.3.4 > X-Virus-Scanned: Symantec AntiVirus Scan Engine > > [ SpamCop V1.3.4 ] > This message is brief for your comfort. Please use links below for > details. > > Email from 24.30.181.126 / Sun, 9 May 2004 21:36:30 -0700 (PDT) > http://www.spamcop.net/w3m?i=z988145978zab5cec781dcfa15ae459c11bd03b7bef > z > > [ Offending message ] > Return-path: <owner-x> > Envelope-to: x > Delivery-date: Mon, 10 May 2004 00:39:15 -0400 > Received: from [198.108.1.26] (helo=trapdoor.merit.edu) > by wilma.widomaker.com with esmtp (Exim 3.36 #1) > id 1BN2ZP-000Jo6-00 > for x; Mon, 10 May 2004 00:39:15 -0400 > Received: by trapdoor.merit.edu (Postfix) > id B68EC91206; Mon, 10 May 2004 00:36:37 -0400 (EDT) > Delivered-To: x > Received: by trapdoor.merit.edu (Postfix, from userid 56) > id 8645591243; Mon, 10 May 2004 00:36:37 -0400 (EDT) > Delivered-To: x > Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) > by trapdoor.merit.edu (Postfix) with ESMTP id 50AFD91206 > for <x>; Mon, 10 May 2004 00:36:34 -0400 (EDT) > Received: by segue.merit.edu (Postfix) > id 3B3955914F; Mon, 10 May 2004 00:36:34 -0400 (EDT) > Delivered-To: x > Received: from ms-smtp-02-eri0.socal.rr.com > (ms-smtp-02-qfe0.socal.rr.com [66.75.162.134]) > by segue.merit.edu (Postfix) with ESMTP id EAB7358E5D > for <x>; Mon, 10 May 2004 00:36:33 -0400 (EDT) > Received: from [192.168.2.2] (cpe-24-30-181-126.socal.rr.com > [24.30.181.126]) > by ms-smtp-02-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id > i4A4aUce025659 > for <x>; Sun, 9 May 2004 21:36:30 -0700 (PDT) > Message-ID: <409F________0602(a)socal.rr.com> > Date: Sun, 09 May 2004 21:36:41 -0700 > From: Vicky Rode <vickyr(a)socal.rr.com> > Reply-To: vickyr(a)socal.rr.com > User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) > X-Accept-Language: en-us, en > MIME-Version: 1.0 > To: x > Subject: Hierarchical Credit-based Queuing (HCQ): QoS > X-Enigmail-Version: 0.83.6.0 > X-Enigmail-Supports: pgp-inline, pgp-mime > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > X-Virus-Scanned: Symantec AntiVirus Scan Engine > Sender: owner-x > Precedence: bulk > Errors-To: owner-nanog-outgoing(a)merit.edu > X-Loop: nanog > > > > Hi there, > > > Just wondering if anyone out there has either implemented or looked into > > this queuing method for quality of service implementation. > This solution is offered (hardware solution) and patented by > foursticks.com. According to foursticks, "HCQ achieves the efficiency > and flexibility of first generation queuing systems, without the > disadvantages." > > It compares HCQ (interesting reading) w/ Class-Based Queuing (CBQ), > Random Early Discard (RED) and Weighted Random Early Discard > (WRED),Weighted Fair Queuing (WFQ),Priority Queuing (PQ) & Low Latency > Queuing (LLQ). > > > Also can anyone recommend a qos forum which I can ping as well. > > > Any insight will be appreciated. > > > regards, > /vicky > > ------------------------------------------------------------------- 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

5 4

Re: Spamcop
by Eric Brunner-Williams 11 May '04

11 May '04

I got one of those during the Spring last year, when I was writing about the state of the net in Iraq. Someone used SpamCop to get my ISP's abuse desk interested in me. Not much to be said about that.

1 0

Re: WAN transfer rates
by Vincent J. Bono 11 May '04

11 May '04

A nifty graph that I have found to be fairly accurate is at a little way down the page. http://www.atlantateleport.com/Services/TCP_IP_Via_Satellite/tcp_ip_via_sat… And an intensive whitepaper at: http://public.lanl.gov/radiant/pubs/drs/hpdc2002.pdf Hope this helps. -v > ----- Original Message ----- > From: "Jeff Nelson" <jnelson(a)rackspace.com> > To: <nanog(a)nanog.org> > Sent: Tuesday, May 11, 2004 4:24 AM > Subject: WAN transfer rates > > > > > > Possibly someone in this forum with a better understanding of tcp/ip can > > articulate this better than I.... > > > > I realize that transfer rates across the Internet diminish significantly > > with latency, but what's the good answer for someone shrunk down to > > <10Mbps when the smallest pipe between them is 100Mbps and latency is > > <40ms? > > > > Does anyone have reference to any study done in this area? I'm sure > > window tuning can alter this, but I'm interested in average statistics. > > > > Any reference would be appreciated. > > > > thanks, > > jeff > > > > > > >

1 0

Re: IPv6/IPv6 threat Comparison Paper available for review
by Iljitsch van Beijnum 11 May '04

11 May '04

On 11-mei-04, at 11:19, itojun(a)iijlab.net wrote: >> - Smurf >> I don't think you mention that in IPv6, there are no mechanisms that >> allow an incoming unicast packet to be turned into a broadcast or >> multicast packet, and as such, smurf-like attacks are impossible. > There are cases where malicious IPv6 packet leads to IPv4 smurf > attack (due to wacky IPv4 mapped address and API). > i think it worthwhile to look at threats due to IPv4/v6 interaction. You can obviously craft an IPv6 packet that will be delivered to an IPv4 subnet broadcast address through 6to4 or some such, but unless the hosts that receive the subsequent broadcast (that shouldn't be generated unless v4 isn't properly administered in the first place so it's still not an IPv6 issue) reply with something, nothing is going to happen. > draft-itojun-ipv6-transition-abuse-xx.txt > draft-cmetz-v6ops-v4mapped-api-harmful-xx.txt > draft-itojun-v6ops-v4mapped-harmful-xx.txt Yeah, yeah, everything is harmful. I don't think having IPv4-specific and IPv6-specific code in applications is the answer, though.

1 0

Re: WAN transfer rates
by sthaug＠nethelp.no 11 May '04

11 May '04

> I realize that transfer rates across the Internet diminish significantly > with latency, but what's the good answer for someone shrunk down to > <10Mbps when the smallest pipe between them is 100Mbps and latency is > <40ms? Without window scaling (RFC 1323) your max transfer rate at 40ms RTT is 65535*8/0.040 = 13.1 Mbps. So slightly less than 10 Mbps isn't too unexpected. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Telco alarm structured cabling standard?
by Glen Turner 11 May '04

11 May '04

Hi folks, I want to run NEBS alarm relay signals via structured cabling. Does anyone have a reference to a standard or know of the typical assignment of signals to wires? Ta, Glen -- Glen Turner Tel: (08) 8303 3936 or +61 8 8303 3936 Australian Academic & Research Network www.aarnet.edu.au

1 0

Type of Service (TOS)
by Vicky Rode 10 May '04

10 May '04

Hi there, Say if I had a qos appliance installed on networks between a lan and a wan box would the qos policies be carried across wan end points (point to point connection)? In other words, will the router retain the TOS bits across to the other side of the wan connection to provide QoS-style priority for the packets or will it clear the TOS bits? BTW, the other side of the wan connection also has the qos appliance sitting between a lan and a wan box. Just so that I'm clear, I'm not talking about an upstream neighbor being an ISP connection which I know they will likely ignore the TOS bits unless I pay them extra for the feature. The above scenario is a point to point connection to a remote site. Any insight will be appreciated. regards, /vicky

3 4

Revised MD5 proliferation statistics
by Steve Gibbard 10 May '04

10 May '04

Last week I sent out some numbers on MD5 proliferation among Packet Clearing House's peers, did some speculation about what this meant for the rest of the Net, and asked for numbers from other sources. At PCH, we had 12% of sessions configured as MD5. We had been responding to requests from peers, but not making any requests of our own. I speculated that if this meant 12% of peers were making such requests, and all peers were complying with the requests, that would mean 22% of peering sessions had MD5 configured. I got responses from six other networks, ranging from one of the traditional tier 1s with 734 peering sessions to a small ISP with five. In total, I heard about 1,226 sessions, of which 458, or 37%, had been configured for MD5. As expected, there are two very different percentage groups based on whether the network has been asking their peers to configure MD5. Among those who have been requesting MD5 from their peers, 49% have been converted (if I exclude the tier 1, that climbs to 86%). Among those who haven't been requesting MD5 from their peers, the average MD5 proliferation is 13%. I'm a little unsure how to interpret the rates for those who have been requesting that their peers configure MD5, due to a huge spread. The tier 1 who responded had 44% configured. Another response, which couldn't be included in my averages due to a lack of specific numbers, said 49%. On the other end of the spectrum were two reports, one from a small ISP that had gotten four out of five, and one from a larger ISP that had gotten 78 of 90, for 86%. I'm going to stick to my 49% number for now, but I'm still interested in seeing more data. To do the same math I did last week, with the revised numbers: If 13% of peers are making MD5 requests, that should mean MD5 requests have been made for 24% of peering sessions. If 49% of those requests are being complied with, that should mean about 12% of peering sessions are now configured for MD5. -Steve

1 0

IPv6 /20 allocated - update your BGP filters!
by Jeroen Massar 10 May '04

10 May '04

Here is a message forwarded for Gert Doering: -----Forwarded Message----- From: Gert Doering <gert(a)space.net> To: 6bone(a)ISI.EDU, ipv6-wg(a)ripe.net Subject: /20 allocated - update your BGP filters! Date: Mon, 10 May 2004 17:56:51 +0200 Hi, the first IPv6 /20 allocation ever has been made today: inet6num: 2001:2000::/20 netname: EU-TELIANET-20040510 org: ORG-TIC2-RIPE descr: PROVIDER Local Registry descr: TeliaSonera AB country: EU and this means that "if you have been following my filtering recommendations, this network will not be accepted right now" (the current filters had a minimum accepted prefix length of a /24). I have updated the prefix filter recommendation page: http://www.space.net/~gert/RIPE/ipv6-filters.html and urge you to check whether your filters are prepared for these large prefixes. (There is a /23 upcoming, and rumors speak of a /19 being requested "real soon now"). TODO: the "strict" filter could do some grouping for different IPv6 allocation ranges, but this is dangerous today, as we don't know how future allocations will look like. Note: ICANN just doesn't get it. They have not allocated a reasonable prefix size to RIPE (like a /8), not even a /19, but "a big chunk of 14 sucessive /23s, summing up to a /20+/21+/22" - see the list at http://www.iana.org/assignments/ipv6-tla-assignments Gert Doering -- RIPE Address Policy WG Co-Chair, keeper of the IPv6 filter list

1 0

route-views.oregon-ix.net
by Peter Rohrman 10 May '04

10 May '04

Is route-views.oregon-ix.net down? I cant get to it. Pete Rohrman

4 3