RE: register.com down sev0?
It was possible to implement BCP38 before the router vendors came up with uRPF. Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL. Yes, I realize that the latter approach is more of a managerial hassle, but for those of you who feel that your silicon is running a tad too warm, you may wish to consider this as a possible performance improvement technique. YMMV. Your former router vendor, Tony
different flavours of uRPF [RE: register.com down sev0?]
On Thu, 26 Oct 2006, Tony Li wrote: It was possible to implement BCP38 before the router vendors came up with uRPF. Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL. Isn't that only a problem if you want to run a loose mode uRPF? Given that loose mode uRPF isn't very useful in most places where you'd like to do ingress filtering, this doesn't seem like a big issue.. BTW, I still keep wondering why Cisco hasn't implemented something like Juniper's feasible-path strict uRPF. Works quite well with multihomed and asymmetric routing as well -- no need to fiddle with communities, BGP weights etc. to ensure symmetry. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: register.com down sev0?
but i am not foolish enough to believe that religious ranting on mailing lists is gonna change anyone from doing what makes business sense for their network. Indeed! And it is not going to change the minds of the majority of network operations folks who are not on the NANOG list nor the majority of telecoms executives who are also not on the NANOG list. Back in the old days, the NANOG list did hold the majority of Internet operations folks so new ideas like flap dampening were able to spread quickly. But those days are long gone. NANOG still has an important educational role but it is no longer based on being part of the old boys club and knowing the secret handshake. In other words, there is no cohesive society of network operators which can be swayed by attempts at social engineering like shaming or cajoling. BCP 38 has had its day. Nowadays, it is more important to look at how to mitigate current DDoS techniques and to describe the larger problem and look for larger solutions. However, any attempt at larger solutions require a large amount of humility because nobody can say for sure, what will work and what won't. The fact remains that there is not a good technical method for mitigating large scale distributed DDoS that results in LARGE TRAFFIC FLOWS ENTERING A NETWORK FROM ALL PEERED ASES SIMULTANEOUSLY. Perhaps if we could find a way to allow the attacked AS to set ACLs automatically in all the source AS networks, that would help mitigate these attacks. For instance, consider a set of ASes which all install an ACL-setter box. These boxes all trust each other to send-receive ACL setting requests through a trusted channel. The owner of a box sets some limits on the ACLs that can be set, for instance n ACLs per AS, max ACL lifetime, etc. And the box owner also decides the subset of their routers which will accept an ACL for a given address range. Then when an attack comes in, the victim AS uses some tool to identify large sources, i.e. a CIDR block that covers some significant percentage of the source addresses in one AS. They then issue an ACL request to that AS to block the flow and the ACL takes effect almost instantaneously with no human intervention. Yes, this can result in some IP addresses being blocked unfairly, but the DDoS traffic levels often have the same impact. In any case, the AS holding the destination address is the one doing the blocking even though the mechanism is an ACL inside the source AS network. On the technical side, it is not a complex problem to put such a system in place. The complexity is largely in getting network operators to come to an agreement on the terms under which operator A will allow operator B to set ACLs in operator A's network. Until network operators see DDoS as a significant business problem, this will not happen. Note that a business problem does not refer solely to the direct costs of mitigating a DDoS attack. It also includes the indirect fallout which is harder to measure such as loss of goodwill, missed opportunities, etc. --Michael Dillon
Re: BCP38 thread 93,871,738,435 + SPF
How is this attack avoided? Sounds like the attack is inherent in SPF. In that case, avoiding it is simple. Discourage the use of SPF, perhaps by putting any SPF using domain into a blacklist. Eventually, people will stop using SPF and the attack vector goes away. --Michael Dillon
Re: Extreme Slowness
Which begs the same question I've asked in the recent past: then what *is* a good diagnostic tool? If ICMP is not the best way to test, then what is? What other globally-implemented layer 3 or below protocols do we have available for troubleshooting? Sure, UDP-based traceroute still relies on ICMP TTL exceeded responses to work. I've no idea what TCP traceroute relies on, as I haven't looked at it. I love it when people answer their own questions and tell us that they are lazy, to boot. For the record, TCP traceroute and similar TCP based tools rely on the fact that if you send a TCP SYN packet to a host it will respond with either a TCP RST (if the port is NOT listening) or a TCP SYN/ACK. The round trip time of this provides useful information which is unaffected by any ICMP chicanery on the part of routers or firewalls. A polite application such as TCP traceroute will reply to the SYN/ACK with an RST packet so it is reasonably safe to use this tool with live services. Of course, even TCP packets can be blocked or dropped for various reasons so this is not a 100% solution. However, if you want to avoid ICMP filtering or low precedence, then TCP traceroute will help. --Michael Dillon
Re: Extreme Slowness
On Fri, 27 Oct 2006, [EMAIL PROTECTED] wrote: For the record, TCP traceroute and similar TCP based tools rely on the fact that if you send a TCP SYN packet to a host it will respond with either a TCP RST (if the port is NOT listening) or a TCP SYN/ACK. The round trip time of this provides useful information which is unaffected by any ICMP chicanery on the part of routers or firewalls. A polite application such as TCP traceroute will reply to the SYN/ACK with an RST packet so it is reasonably safe to use this tool with live services. Intermediate nodes are still discovered by ICMP TTL Exceeded in transit just like UDP based traceroute, ie the outgoing TCP SYN packet has a low TTL. So yes, tcptraceroute is good for getting thru firewalls in the forward direction, but intermediate routers are discovered in the same way by you getting an ICMP back because the TTL ran out. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Extreme Slowness
Adam,
Because of contractual issues it makes it very hard for me to
participate on this list hence the vague original post. I was just
asking a general question to see if anyone else was having issues. I
have peering points with Broadwing(now level3), Sprint, ATT and MCI
(now Verizon) that I can test for throughput from. This was not just
about home cable connectivity though when frontline starts to get
calls I often use wget (very low overhead) to test throughput between
my sites or to home my home box often times simulating the same sort
of connectivity that a customer may have. There were customers that
could not even get to level3.net yesterday which is their home page,
but it is always nice to get the refresher course on ICMP though :).
As for html posted messages truly my mistake I know better and thank
you for mentioning it. The new duo core 2 mac mail client which I am
still trying to get use to under preferences says it is set to plain
text hmmm something I need to look into.
Thank you
On Oct 27, 2006, at 12:22 AM, Adam Rothschild wrote:
Elijah,
On 2006-10-26-16:34:18, Elijah Savage [EMAIL PROTECTED] wrote:
[HTML mail stripped]
It seems anything traversing level3 has very high latency along with
what seems overloaded capacity as if they are running in a degraded
mode I have connections with Time Warner, ATT, and MCI [...]
On 2006-10-26-16:48:15, Elijah Savage [EMAIL PROTECTED] wrote:
[HTML mail stripped]
Say like this traceroute. This is from TW to a Broadwing DS3.
5 tenge-3-2.car1.Cincinnati1.Level3.net (4.78.216.13) 153.267 ms
207.125 ms
tenge-3-1.car1.Cincinnati1.Level3.net (4.78.216.9) 218.920 ms
6 ae-5-5.ebr2.Chicago1.Level3.net (4.69.132.206) 36.976 ms 26.923
ms 57.770 ms
7 ge-11-0.core2.Chicago1.Level3.net (4.68.101.37) 254.145 ms
ge-11-1.core2.Chicago1.Level3.net (4.68.101.101) 258.522 ms
ge-11-2.core2.Chicago1.Level3.net (4.68.101.165) 227.223 ms
8 broadwing-level3-oc12.Chicago1.Level3.net (209.0.225.10)
231.451 ms
9 so-1-1-0.c1.gnwd.broadwing.net (216.140.15.1) 53.269 ms 35.568
ms 22.511 ms
Your postings appear to be missing two key pieces of information which
would help with the community diagnosis requested: source and
destination IP addresses. From the information you did provide, one
can deduce that you're behind a TW/RoadRunner cable modem:
13.216.78.4.IN-ADDR.ARPA domain name pointer
tenge-3-2.car1.Cincinnati1.Level3.net
14.216.78.4.IN-ADDR.ARPA domain name pointer
ROADRUNNER.car1.Cincinnati1.Level3.net
9.216.78.4.IN-ADDR.ARPA domain name pointer
tenge-3-1.car1.Cincinnati1.Level3.net
10.216.78.4.IN-ADDR.ARPA domain name pointer
ROADRUNNER.car1.Cincinnati1.Level3.net
Now, the jitter and high latency you're seeing could be a result of
one or more factors, including but not limited to RF/plant issues, TWC
running their transport and/or Level(3) transit hot (which seems to be
a common occurrence these days), ECMP across two circuits of uneven
loading, or your neighbor might be jacking wifi and downloading a
bunch of torrents -- we, the readers, just don't know.
Of note when performing armchair troubleshooting across Level(3)'s
network: the 'ebr's (PTR record of ebr*.{pop}.level3.net == Force10
E1200; Experimental Backbone Router?) tend to drop a lot of diagnostic
traffic (such as, say, 'ping' and 'traceroute') as a part of overly
aggressive control-plane policers. This loss is, of course, strictly
cosmetic, and has no bearing on end-to-end performance. Hence, the
old to it, not through it rule applies.
smokeping[1] and iperf[2] (to end hosts) are your friends.
As an aside, I've noticed your string of postings today were all
HTML-tagged. While not expressly forbidden (or even discouraged) by
the current Mailing List AUP, this is generally regarded as bad form;
you might wish to reconfigure your mail client accordingly...
Hope this helps,
-a
[1] http://oss.oetiker.ch/smokeping/
[2] http://dast.nlanr.net/Projects/Iperf/
BGP Update Report
BGP Update Report Interval: 13-Oct-06 -to- 26-Oct-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS17974 24022 2.2% 48.1 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 2 - AS432311230 1.0% 10.8 -- TWTC - Time Warner Telecom, Inc. 3 - AS17557 11059 1.0% 30.0 -- PKTELECOM-AS-AP Pakistan Telecom 4 - AS337839816 0.9% 90.1 -- EEPAD 5 - AS308909394 0.9% 45.4 -- EVOLVA Evolva Telecom 6 - AS7303 9123 0.8% 42.6 -- Telecom Argentina S.A. 7 - AS9121 8993 0.8% 98.8 -- TTNET TTnet Autonomous System 8 - AS9942 8593 0.8% 19.7 -- COMINDICO-AP COMindico Australia 9 - AS124978091 0.7% 161.8 -- SANET-GE SANET NETWORK (AS) 10 - AS141177696 0.7% 32.7 -- Telefonica del Sur S.A. 11 - AS6471 7226 0.7% 30.6 -- ENTEL CHILE S.A. 12 - AS7011 6402 0.6% 9.1 -- FRONTIER-AND-CITIZENS - Frontier Communications, Inc. 13 - AS4621 6101 0.6% 45.5 -- UNSPECIFIED UNINET-TH 14 - AS145226074 0.6% 51.5 -- Satnet 15 - AS114926074 0.6% 17.4 -- CABLEONE - CABLE ONE 16 - AS7575 5950 0.5% 37.7 -- AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 17 - AS702 5873 0.5% 21.3 -- AS702 MCI EMEA - Commercial IP service provider in Europe 18 - AS346955848 0.5% 108.3 -- E4A-AS E4A Primary AS 19 - AS9583 5413 0.5% 7.5 -- SIFY-AS-IN Sify Limited 20 - AS239185223 0.5% 39.6 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS315941270 0.1%1270.0 -- FORTESS-AS Fortess LLC Network 2 - AS5310 2746 0.2% 915.3 -- DODNIC - DoD Network Information Center 3 - AS34378 913 0.1% 913.0 -- RUG-AS Razguliay-UKRROS Group 4 - AS3043 3112 0.3% 778.0 -- AMPHIB-AS - Amphibian Media Corporation 5 - AS392501485 0.1% 742.5 -- COLOPROVIDER-AS Colo Provider 6 - AS347231218 0.1% 609.0 -- RNT-AS SC Real Network and Telecomunications SRL 7 - AS8844 572 0.1% 572.0 -- COMMUNITY Community Internet plc 8 - AS30095 550 0.1% 550.0 -- NYCMEC - MediaEdge-CIA 9 - AS5868 2076 0.2% 519.0 -- DDN-ASNBLK - DoD Network Information Center 10 - AS146994397 0.4% 488.6 -- BTCBCI - Bloomingdale Communications Inc 11 - AS33188 962 0.1% 481.0 -- SCS-NETWORK-1 - Sono Corporate Suites 12 - AS32937 958 0.1% 479.0 -- CAC-FOR-THE-DEAF-AND-HARD-OF-HEARING - Communication Access Center for the Deaf and Hard of Hearing, Inc. 13 - AS305173262 0.3% 466.0 -- GREAT-LAKES-COMNET - Great Lakes Comnet, Inc. 14 - AS11316 869 0.1% 434.5 -- NERC - North American Electric Reliability Council 15 - AS1565 2079 0.2% 415.8 -- DNIC - DoD Network Information Center 16 - AS305971920 0.2% 384.0 -- AMBEST-ASN - A.M. Best Company 17 - AS31639 373 0.0% 373.0 -- ROTELEMACH SC Telemach SRL 18 - AS14548 368 0.0% 368.0 -- LISTEN-SF-1 - Listen.com 19 - AS1525 333 0.0% 333.0 -- 20 - AS264601284 0.1% 321.0 -- CERTEGY-INC - CERTEGY INC. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 209.140.24.0/243109 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 2 - 203.199.128.0/19 2381 0.2% AS4755 -- VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System 3 - 194.42.208.0/201642 0.1% AS705 -- ALTERNET-AS - UUNET Technologies, Inc. 4 - 83.98.220.0/23 1447 0.1% AS39250 -- COLOPROVIDER-AS Colo Provider 5 - 194.242.124.0/22 1270 0.1% AS31594 -- FORTESS-AS Fortess LLC Network 6 - 214.15.166.0/241263 0.1% AS5310 -- DODNIC - DoD Network Information Center 7 - 86.106.200.0/221209 0.1% AS34723 -- RNT-AS SC Real Network and Telecomunications SRL 8 - 214.15.101.0/241183 0.1% AS5310 -- DODNIC - DoD Network Information Center 9 - 208.0.225.0/24 1066 0.1% AS11139 -- CWRIN CW BARBADOS 10 - 143.81.159.0/241003 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 11 - 143.81.0.0/21 1000 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 12 - 161.246.192.0/21977 0.1% AS9486 -- KMITL-AP King Mongkut's Institute of Technology Ladkrabang 13 - 146.222.76.0/24 938 0.1% AS9502 -- OOCL-HKG-AP Hong Kong Headquarters 14 - 193.242.123.0/24913 0.1% AS34378 -- RUG-AS Razguliay-UKRROS Group 15 - 161.246.192.0/24897 0.1% AS9486 -- KMITL-AP King Mongkut's
The Cidr Report
This report has been generated at Fri Oct 27 21:46:01 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
20-10-06198382 129081
21-10-06198695 129155
22-10-06198585 129168
23-10-06198431 129263
24-10-06198574 129437
25-10-06198860 129494
26-10-06198965 129507
27-10-06199053 129547
AS Summary
23411 Number of ASes in routing system
9841 Number of ASes announcing only one prefix
1505 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91388928 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 27Oct06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 199114 1295896952534.9% All ASes
AS4134 1224 277 94777.4% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4755 1004 64 94093.6% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS18566 969 128 84186.8% COVAD - Covad Communications
Co.
AS9498 864 129 73585.1% BBIL-AP BHARTI BT INTERNET
LTD.
AS4323 1026 294 73271.3% TWTC - Time Warner Telecom,
Inc.
AS22773 713 52 66192.7% CCINET-2 - Cox Communications
Inc.
AS721963 309 65467.9% DISA-ASNBLK - DoD Network
Information Center
AS19262 732 178 55475.7% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS6197 1020 493 52751.7% BATI-ATL - BellSouth Network
Solutions, Inc
AS7018 1505 993 51234.0% ATT-INTERNET4 - ATT WorldNet
Services
AS19916 565 68 49788.0% ASTRUM-0001 - OLM LLC
AS17488 542 47 49591.3% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS11492 781 301 48061.5% CABLEONE - CABLE ONE
AS855539 88 45183.7% CANET-ASN-4 - Aliant Telecom
AS18101 464 25 43994.6% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS17676 500 64 43687.2% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS2386 1183 756 42736.1% INS-AS - ATT Data
Communications Services
AS3602 527 104 42380.3% AS3602-RTI - Rogers Telecom
Inc.
AS4766 703 311 39255.8% KIXS-AS-KR Korea Telecom
AS812423 34 38992.0% ROGERS-CABLE - Rogers Cable
Inc.
AS4812 430 61 36985.8% CHINANET-SH-AP China Telecom
(Group)
AS6467 399 72 32782.0% ESPIRECOMM - Xspedius
Communications Co.
AS8151 734 412 32243.9% Uninet S.A. de C.V.
AS16852 373 55 31885.3% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS9583 941 646 29531.3% SIFY-AS-IN Sify Limited
AS16814 329 39 29088.1% NSS S.A.
AS15270 476 190 28660.1% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS33588 391 109 28272.1% BRESNAN-AS - Bresnan
Communications, LLC.
AS14654 298 30 26889.9% WAYPORT - Wayport
AS17849 429 162 26762.2% GINAMHANVIT-AS-KR hanvit ginam
broadcasting comm.
Re: ICMP PathMTU
* Jim Popovitch: Two questions for everybody...(any and all responses appreciated, even if the reply mentions botnets or hammers ;-) ) 1) What value is ICMP if everybody pretty much considers it's accuracy suspect? The problem with ICMP-based traceroutes is that it doesn't necessarily test the path you are interested in. Use tcptraceroute or traceproto instead. Of course, this doesn't solve the problem that TTL Exceeded messages might be generated with very low priority, which is in generally a very good idea. 2) How does ICMP's suspect nature affect Path MTU? In this case, you're interested in the ICMP payload, not the fact whether an ICMP packet goes through or not. (You lose if someone filters ICMP, though.)
Re: BCP38 thread 93,871,738,435 + SPF
* Douglas Otis: Spam being sent through Bot farms has already set the stage for untraceable DNS attacks based upon SPF. In addition to taking out major interconnects, these attacks can: a) inundate authoritative DNS; b) requests A records from anywhere; c) probe IP address, port, and the transaction IDs of resolvers; (b) and (c) are not new developments because lots of MTAs already perform A lookups on HELO arguments, and MX lookups on sender domains. While not as bad as eavesdropping, it still places the network and the integrity of DNS at risk. All of this while the spam is still being delivered. What a productivity tool! The purpose of SPF, as it is deployed, is to facilitate routing solicited bulk email around spam filters. Look at email.bn.com/IN/TXT to get the idea. This application requires some of the indirection features offered by SPF.
RE: register.com down sev0?
On Thu, 26 Oct 2006, Tony Li wrote: It was possible to implement BCP38 before the router vendors came up with uRPF. Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL. Yes, I realize that the latter approach is more of a managerial hassle, but for those of you who feel that your silicon is running a tad too warm, you may wish to consider this as a possible performance improvement technique. YMMV. Your former router vendor, Tony Erm, most ISP's I talk to (since I became aware of this not too long ago) believe this is a perfect replacement for BCP38. And yet, spoofing is possible from their space. Gadi.
Re: Extreme Slowness
We peer with UUnet and Telcove (now L3 and being assimulated) Latency across Telcove has been terrible (not just routers on the path with higher than norm latency, but latency all the way to the endpoint) I have personal opinions as to why the latency is so bad, but until I can prove something I'd rather not say anything in public. Some examples : 72.30.33.194 is 60.8 ms away via uunet, it is 109ms away via Telcove. www.level3.com via uunet is 30ms away, via Telcove it is 55ms away. Trace to level3.com via UUNet Hostname %Loss Rcv Snt Last Best Avg Worst 1. ndcr3-52.datasync.net 0%66 000 0 2. ndcr6-ndcr3.datasync.net 0%55 000 0 3. POS1-2.GW4.NOL1.ALTER.NET 0%55 101 1 4. 501.at-0-0-0.XL2.NOL1.ALTER.NET 0%55 111 1 5. 0.so-6-2-0.XT1.DFW9.ALTER.NET 0%5514 14 15 15 6. 0.so-6-0-0.BR6.DFW9.ALTER.NET 0%5515 14 14 15 7. so-1-0-0.edge1.Dallas1.Level3.net 0%5516 15 16 17 8. so-1-2-0.bbr1.Dallas1.Level3.net 0%5516 15 16 16 9. ae-0-0.bbr2.Denver1.Level3.net 0%5583 29 41 83 10. ge-6-1.hsa1.Denver1.Level3.net 0%5535 29 31 35 11. 4.68.94.1 0%5530 30 30 32 12. www.Level3.com 0%5531 29 30 31 Via Telcove 1. ndcr3-52.datasync.net 0%55 000 0 2. 64.66.101.89 0%55 777 7 3. 24.56.107.229 0%4420 20 20 20 4. ??? 5. 24.56.107.94 0%4420 20 20 20 6. ge-6-23.car1.Atlanta1.Level3.net 0%44 143 20 51143 7. ae-1-51.bbr1.Atlanta1.Level3.net 0%4420 20 30 59 8. as-0-0.bbr1.Denver1.Level3.net 0%4454 53 54 54 9. ge-9-0.hsa1.Denver1.Level3.net 0%4455 54 54 55 10. 4.68.94.1 0%4455 54 55 55 11. www.Level3.com 0%4455 55 55 55 -- W. Kevin Hunt CCIE #11841 Linux+ SME There are 10 kinds of people in this world, those that understand binary and those that do not. Elijah Savage wrote: Adam, Because of contractual issues it makes it very hard for me to participate on this list hence the vague original post. I was just asking a general question to see if anyone else was having issues. I have peering points with Broadwing(now level3), Sprint, ATT and MCI(now Verizon) that I can test for throughput from.
Re: BCP38 thread 93,871,738,435 + SPF
On Fri, 27 Oct 2006 [EMAIL PROTECTED] wrote: How is this attack avoided? Sounds like the attack is inherent in SPF. In that case, how did the thread about dns providers and rfc compliance morph into SPF and spam discussions?
Re: different flavours of uRPF [RE: register.com down sev0?]
Pekka Savola wrote: On Thu, 26 Oct 2006, Tony Li wrote: It was possible to implement BCP38 before the router vendors came up with uRPF. Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL. Isn't that only a problem if you want to run a loose mode uRPF? Given that loose mode uRPF isn't very useful in most places where you'd like to do ingress filtering, this doesn't seem like a big issue.. Strict mode uRPF is likely to be implemented by performing a full forwarding table lookup and then comparing the packet's incoming interface to the interface from the forwarding table result. Tony
Re: register.com down sev0?
Hi Vadim! Vadim Antonov wrote: On Thu, 26 Oct 2006, Tony Li wrote: Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes... That would be, well, about 6 memory reads. Radix trees are great. They are indeed. If a radix trie is indeed used, you would expect to see about log2(200,000) + 1 = 19 reads on average. or against a handful of prefixes that you've statically configured in an ACL. Which will take much longer with line-by-line sequential matching. Fortunately, modern ACL implementations frequently use TCAMs (1 read) or tree based structures (log2(handful) + 1) as well. As always, the details of a particular implementation are everything. YMMV. Tony
Re: BCP38 thread 93,871,738,435 + SPF
How is this attack avoided? Sounds like the attack is inherent in SPF. In that case, how did the thread about dns providers and rfc compliance morph into SPF and spam discussions? Ask Doug Otis. He stated that SPF sets the stage for DDoS attacks against DNS servers. Presumably he said this because it points to another *COST* of DDoS that could be used as a business justification to implement BCP38. Or you could look at it as a weakness of SPF that should be used as a justification for discouraging its use. After all if we discourage botnets because they are DDoS enablers, shouldn't we discourage other DDoS enablers like SPF? --Michael Dillon
Re: BCP38 thread 93,871,738,435 + SPF
On Fri, 2006-10-27 at 14:11 +0200, Florian Weimer wrote: * Douglas Otis: Spam being sent through Bot farms has already set the stage for untraceable DNS attacks based upon SPF. In addition to taking out major interconnects, these attacks can: a) inundate authoritative DNS; b) requests A records from anywhere; c) probe IP address, port, and the transaction IDs of resolvers; (b) and (c) are not new developments because lots of MTAs already perform A lookups on HELO arguments, and MX lookups on sender domains. Each message's SPF script can prompt for web-site addresses while also inundating the web-site's DNS with other randomized requests. Network gains achieved by each script can reach 70:1, and when instances of execution (MTA/MUA, MAILFROM/PRA/DKIM, and recipient) are considered, gains per message may exceed 1000:1 while still permitting delivery and while not exposing who their victim was. While not as bad as eavesdropping, it still places the network and the integrity of DNS at risk. All of this while the spam is still being delivered. What a productivity tool! The purpose of SPF, as it is deployed, is to facilitate routing solicited bulk email around spam filters. Look at email.bn.com/IN/TXT to get the idea. This application requires some of the indirection features offered by SPF. The risk is from an amplification achieved by SPF scripts while still hiding which messages are attacking. Bulk senders can use APL RRs (42) (see rfc3123) to list the CIDRs of their SMTP clients without imposing these risks. Standardized prefixes such as _smtp-c0 and _smtp-c1 permits chaining signaled with a continuation address-family, as example. Executing powerful SPF scripts from strangers is a heavily promoted bad idea that truly needs to be discouraged. -Doug
Re: Extreme Slowness
On 2006-10-27-07:37:37, Elijah Savage [EMAIL PROTECTED] wrote: Because of contractual issues it makes it very hard for me to participate on this list hence the vague original post. I can understand you might have various NDAs in place limiting what you can and can't disclose. Unfortunately, without full information, it is difficult to provide a full and proper diagnosis. I was just asking a general question to see if anyone else was having issues. See, therein lies the problem. As pointed out in recent congressional testimony by the esteemed Senator from Alaska, the internets are comprised of very many tangled-up tubes. At any given time, something just isn't working. Without source and destination IP addresses, it's difficult to determine whether a problem is global in scope (entirely appropriate for this list), or an end-user issue (inappropriate for this list, though some folk may beg to differ :-), as suggested by your snippet of 'traceroute' output -- and ultimately take corrective action. I have peering points with Broadwing(now level3), Sprint, ATT and MCI (now Verizon) that I can test for throughput from. This phraseology is also a bit confusing, though sadly, all too common these days. Unless you're settlement-free, a better idea might be to word this as I buy transit from... or perhaps more appropriately, My cable MSO buys transit from... This was not just about home cable connectivity though when frontline starts to get calls I often use wget (very low overhead) to test throughput between my sites or to home my home box often times simulating the same sort of connectivity that a customer may have. There were customers that could not even get to level3.net yesterday which is their home page Be that as it may, a little information would have helped greatly. Had you said this sooner, and backed it up with some supporting data such as IP addresses and perhaps 'wget' output, chances are we wouldn't be having this discussion. On the other hand, if you can't trust us, perhaps a better course of action would be to open trouble tickets with your provider(s)... -a
Re: different flavours of uRPF [RE: register.com down sev0?]
On Fri, 27 Oct 2006, Tony Li wrote: Pekka Savola wrote: On Thu, 26 Oct 2006, Tony Li wrote: It was possible to implement BCP38 before the router vendors came up with uRPF. Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL. Isn't that only a problem if you want to run a loose mode uRPF? Given that loose mode uRPF isn't very useful in most places where you'd like to do ingress filtering, this doesn't seem like a big issue.. Strict mode uRPF is likely to be implemented by performing a full forwarding table lookup and then comparing the packet's incoming interface to the interface from the forwarding table result. Pekka might have meant wouldn't you build a seperate 'urpf table' per interface perhaps? (just guessing at his intent) though there is only one 'urpf table' which is the fib, right?
Re: BCP38 thread 93,871,738,435 + SPF
On Fri, 27 Oct 2006 [EMAIL PROTECTED] wrote: Or you could look at it as a weakness of SPF that should be used as a justification for discouraging its use. After all if we discourage botnets because they are DDoS enablers, shouldn't we discourage other DDoS enablers like SPF? under this assumption we should discourage user use of the internet... :( anyway, please let's get back to the original discussion :)
Re: BCP38 thread 93,871,738,435 + SPF
how did the thread about dns providers and rfc compliance morph into SPF and spam discussions? for the spf hammerers, everything looks like a nail? :) personally, i think it is overloading of mpls, dns, and bgp. :) randy
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 28 Oct, 2006 Analysis Summary BGP routing table entries examined: 201588 Prefixes after maximum aggregation: 109278 Unique aggregates announced to Internet: 97948 Total ASes present in the Internet Routing Table: 23492 Origin-only ASes present in the Internet Routing Table: 20462 Origin ASes announcing only one prefix:9840 Transit ASes present in the Internet Routing Table:3030 Transit-only ASes present in the Internet Routing Table: 78 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 1 Unregistered ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space: 10 Number of addresses announced to Internet: 1621962480 Equivalent to 96 /8s, 173 /16s and 46 /24s Percentage of available address space announced: 43.8 Percentage of allocated address space announced: 60.5 Percentage of available address space allocated: 72.3 Total number of prefixes smaller than registry allocations: 101380 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:44214 Total APNIC prefixes after maximum aggregation: 17732 Prefixes being announced from the APNIC address blocks: 41802 Unique aggregates announced from the APNIC address blocks:18547 APNIC Region origin ASes present in the Internet Routing Table:2736 APNIC Region origin ASes announcing only one prefix:762 APNIC Region transit ASes present in the Internet Routing Table:413 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 265045600 Equivalent to 15 /8s, 204 /16s and 70 /24s Percentage of available APNIC address space announced: 82.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:101164 Total ARIN prefixes after maximum aggregation:59714 Prefixes being announced from the ARIN address blocks:74325 Unique aggregates announced from the ARIN address blocks: 28105 ARIN Region origin ASes present in the Internet Routing Table:11096 ARIN Region origin ASes announcing only one prefix:4221 ARIN Region transit ASes present in the Internet Routing Table:1034 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 307322752 Equivalent to 18 /8s, 81 /16s and 95 /24s Percentage of available ARIN address space announced: 67.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 96/6, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 40878 Total RIPE prefixes after maximum aggregation:27061 Prefixes being announced from the RIPE address blocks:37833 Unique aggregates announced from the RIPE address blocks: 25312 RIPE Region origin ASes present in the Internet Routing Table: 8675 RIPE Region origin ASes announcing only one prefix:4566 RIPE Region transit ASes present in
RE: different flavours of uRPF [RE: register.com down sev0?]
It was possible to implement BCP38 before the router vendors came up with uRPF. Further, uRPF is frequently a very inefficient means of implementing BCP 38. Consider that you're going to either compare the source address against a table of 200,000 routes or against a handful of prefixes that you've statically configured in an ACL. Isn't that only a problem if you want to run a loose mode uRPF? Given that loose mode uRPF isn't very useful in most places where you'd like to do ingress filtering, this doesn't seem like a big issue.. Loose mode is a RTBH Reaction tool - not BCP 38. Don't use a screw driver to hammer a nail. BTW, I still keep wondering why Cisco hasn't implemented something like Juniper's feasible-path strict uRPF. Works quite well with multihomed and asymmetric routing as well -- no need to fiddle with communities, BGP weights etc. to ensure symmetry. Wow - I'm going to need to dust off the tutorial materials on how uRPF and using the FIB as a policy enforcement tool works. Does uRPF need to scan through the entire FIB? Saying this is saying routers look through the entire FIB table to find the next hop? What ever happened to TRIE techniques? uRPF's look up is at the same speed as the forwarding look up. In fact, in many implementations, the forwarding lookup gets the source and destination address values from the FIB. Now, are there other ways of doing BCP38 - yes lots: - ACLs - Radius loaded ACLs - uRPF Strict-Feasible-VRF modes - IP Source Verify - DHCP Lease Query - NAT on the home CPE Why hasn't Cisco done uRPF Feasible path? Cause until recently, our CEF structures would not allow for feasible/alternate paths. If the FIB is your policy table, then _what_ you are limited to the capabilities of that FIB when using it to police the packet. Cisco has that now, so feasible path is just a matter of time to work through the coding queues. What I'm shaking my head over with this whole dialog is the 1990's thinking. BCP38 is out of date. Anyone who works, mitigates, analysis, and studies attack vectors on network systems know that checking the IP source address is one of many Anti-Spoof checks you need to do on the packet. With Ethernet and Cable, you need to do a MAC check. With all mediums you need to check the Prec/DSCP value (porn at Prec 6 does wonders for the routing protocols when there is congestion in the path). Then there is TTL values, Fragments, and other values which need to be policed on the edge. This is why uRPF - while helpful - is not the primary BCP38 tool people should be considering on the edge.
Re: register.com down sev0?
Paul, As of right now I'm not prepared to comment on our recent outage in this forum. That said, I do want to discuss your assertion that Register.com is a source of spam. Spam mail is something we take very seriously. As a business we do not send spam email and we have procedures in place to address spam sent by our customers. If you're seeing spam involving us, and haven't gotten any traction from our abuse desk ([EMAIL PROTECTED]), I'd like to know about it. I've privately emailed you my phone number, please give me a call, so we can discuss this further. -- Charles Knipe Manager - Infrastructure Services Register.com, Inc.
Re: register.com down sev0?
Charles J. Knipe wrote: Paul, As of right now I'm not prepared to comment on our recent outage in this forum. That said, I do want to discuss your assertion that Register.com is a source of spam. It's pretty well-known that register.com has been a source of spam, and that complaints to them have been ineffective. If you're here to tell us that the problem has recently been fixed, or that you're working on fixing it, people will be happy to hear that. If you're here to tell us that there never was a problem and that we're all just imagining it... you'll need these: http://www.spectorracing.com/catalog/category_477_UNDERWEAR_SParco_Racing_Underwear_page_1.html Carmyth fabric has a higher flame resistance than any previous material
Re: BCP38 thread 93,871,738,435 + SPF
On Oct 27, 2006, at 10:03 AM, Chris L. Morrow wrote: On Fri, 27 Oct 2006 [EMAIL PROTECTED] wrote: Or you could look at it as a weakness of SPF that should be used as a justification for discouraging its use. After all if we discourage botnets because they are DDoS enablers, shouldn't we discourage other DDoS enablers like SPF? under this assumption we should discourage user use of the internet... :( anyway, please let's get back to the original discussion :) As Steve already pointed out, BCP38 is not a complete solution. Not only does SPF prevent the source of a Botnet attack from being detected, it also enables significantly greater amplification than might be achieved with a spoofed source DNS reflective attack. In addition, the Botnet resources are not wasted, as their spam is still being delivered. This aspect alone dangerously changes the costs related to such attacks. It seems wholly imprudent not to consider SPF in the same discussion. -Doug
RE: register.com down sev0?
Nah. You assume branching factor of 2 (and not radix tree but rather a form of binary tree, i.e. AVL, r/b or Patricia - they have that O(log2(num_entries)) behaviour, while radix trees are traversed in O(key_length/branching_factor)). I assumed a binary radix trie (not tree) because that's the normal cannonical version used by computer science students. Yes, as you outlined, there are many games you can play, if you're willing to make space/time tradeoffs. Regardless of the details, the point remains: if your data structures are largely constant, then you are more efficient searching a small data set vs. searching a large one. Tony
Reclassification of NON-PORTABLE address space?
Title: Reclassification of NON-PORTABLE address space? Anyone know if there is a precedent for reclassifying blocks of non-portable address space to portable? I didn't see anything in ARIN archives (maybe I didn't look hard enough). Bribery? Threats? Acquisition of the assignor by the assignee? If such a reclassification were simple, I expect that the process would be heavily abused by smaller networks that would like to avoid renumbering. Brad -- Covad Communications 2510 Zanker Road San Jose, CA 95131 +1-408-434-2048
Re: register.com down sev0?
It's pretty well-known that register.com has been a source of spam, and that complaints to them have been ineffective. Albert, I don't know about Register.com's opinion but I dare say the statement above isn't very helpful to me as an admin. When you say has been a source of spam is there a time frame involved? Was this in the last week? Month? Year? When you say register.com has been the source do you mean a) their netblocks b) their mail servers or c) partners acting on their behalf? You also state that complaints have been ineffective. Again is there a time frame? Did anyone get back to you? Did they investigate? Did they give you a reason for ignoring or doing nothing about your complaint? I ask this not because I want to know but because if someone from the company came here to address the issue then perhaps we should give them as much information as possible (After all- you have a contact now) Simply saying that it's pretty well-known doesn't really help. I frankly doubt they would bother posting here with let us know if they had no intention of looking into it- this isn't exactly a group likely to be pacified by empty promises. (It's also possible that in the past the right people never found out- or that there are new people there who take the issue more seriously). will be happy to hear that. If you're here to tell us that there never was a problem and that we're all just imagining it... you'll need these: I don't think they are going to claim there was never a problem- unfortunately sometimes the marketing folks don't consult or listen to their technical folks- it's happened at a lot of companies. That said- I haven't had spam from a register.com netblock in a long time. Then again maybe I've just been lucky. -Don
Re: Collocation Access
On Tue, Oct 24, 2006 at 05:38:05PM -0700, David Schwartz wrote: ... I am way too familiar with several cases where people were charged and convicted with violating obscure laws clearly intended for another purpose just for doing their jobs in a normal, reasonable way. Intel v. Schwartz (no relation) is a great example. http://www.eff.org/legal/cases/Intel_v_Schwartz/schwartz_case.intro It's quite possible (even likely, IMO) that when Florida makes it illegal to lend your driver's license to any other person, it actually means precisely that. ... Ah, THAT is what you meant by your obscure reference to IvS. Merely that lawyers can twist anything to mean anything. Well, yes, that's what they get paid to do. Another facet of that, though, is that one needs to ask a lawyer to make sure what a law might mean [deliberate phrasing, that won't say what it DOES mean, that's the judge's job, and it might and will differ from the lawyer's interpretation in different ways depending on which judge and when]. It depends on precedent, including what judges declared they meant every other time they used the same phrasing. So it's a waste of bits for us to declare what it DOES mean, unless one of us is the judge in a case deciding this, in which case it's merely illegal or ill- advised, depending on other circumstances. [This is why Microsoft is still one company.] -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: register.com down sev0?
On Wed, Oct 25, 2006 at 10:10:05PM -0400, [EMAIL PROTECTED] wrote: ... As pointed out by Rob Seastrom in private email, RFC2182 addresses things of biblical proportions - such as dispersion of nameservers geographically and topologically. Having 3 secondaries, only one of them on separate /24, and none of them on topologically different network does not qualify. ... ns1.register.com. 600 IN A 216.21.234.96 ns2.register.com. 600 IN A 216.21.226.96 ns3.register.com. 600 IN A 216.21.234.97 ns4.register.com. 600 IN A 216.21.226.97 This is two pairs, each pair in a single /24 (or /26), and there are ways in which each of these hosts could be in a widely different spot from the other three, or in several different spots. Why am I saying this? Most of the folks here know this and how to do this even better than I do. I am not saying that register.com IS doing this, just that you can't say that they're NOT just from this evidence. And by now it's moot anyway. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: Buffalo, was passports for NANOG-39, Toronto
Don't neglect the border crossing delay. I just drove back from Toronto this morning, with about a 20 minute delay into the US. It's hard to predict, some times it takes 30 seconds, on really bad times like the end of a holiday weekend it can take two hours. Flying into Buffalo is an entirely reasonable alternative to flying into Toronto. Airtran, Jetblue and Southwest all serve Buffalo, so if you're flying from other parts of the US, it's often considerably cheaper than YYZ. Renting a car and driving into Canada is routine, just tell the clerk so he gives you a Canadian insurance card. From the airport head west on NY 33 to the Thruway/I-90, then east (which is really north) on I-90 to I-290. There are two bridges you might take. The fastest is usually the Lewiston/Queenston bridge; at the end of I-290 take I-190 north all the way to the end to the bridge. After the bridge just stay on the highway which will take you to the QEW to Toronto. The other is the Rainbow bridge in Niagara Falls; take I-190 north, you will pay a toll and go over a bridge onto Grand Island, then another bridge to leave Grand Island, then immediately get off on the Robert Moses Parkway to the falls, and the bridge is right there. If you've never been to Niagara Falls before, stop and look at the falls either from the US or Canadian side for a few minutes because it really is one of the great wonders of the world. After appreciating the scenery, take highway 420 to the QEW. The Peace bridge in Buffalo is way out of the way, not useful for this trip. Culinary hint: Buffalo's greatest edible contribution to the world is a roast beef sandwich called Beef on Weck, and the best place to get one is Charlie the Butcher, about five minutes from the airport. Go west on NY 33 from the airport, turn right on Cayuga St just after the airport, go north about six blocks and it's on the left at the corner of Wehle St. The place is not much to look at, but the governor and Hillary both liked it enough to send them signed photos. R's, John
Re: register.com down sev0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 27, 2006, at 7:48 PM, Donald Stahl wrote: It's pretty well-known that register.com has been a source of spam, and that complaints to them have been ineffective. I don't know about Register.com's opinion but I dare say the statement above isn't very helpful to me as an admin. When you say has been a source of spam is there a time frame involved? Was this in the last week? Month? Year? I've received spam from them in the past month (actually I got two). When this thread started I went back to see if I could find them but unfortunately I no longer had copy. When you say register.com has been the source do you mean a) their netblocks b) their mail servers or c) partners acting on their behalf? The spam I got was directly from register.com. It came with a register.com return email address, pointed to a register.com web site and came from an IP address the resolved to *.register.com (I will admit I didn't confirm the netblock belonged to them). I've never done any business with them and the spam was for a domain name renewal for a domain registered elsewhere. In other words, it was a classic whois scrapped spam. You also state that complaints have been ineffective. Again is there a time frame? Did anyone get back to you? Did they investigate? Did they give you a reason for ignoring or doing nothing about your complaint? I submitted both spams to spamcop and the appropriate abuse addresses would have been notified in both cases. I got no response from either of my submissions. As for a reason for ignoring my complaint I really couldn't say since, well they ignored me. I ask this not because I want to know but because if someone from the company came here to address the issue then perhaps we should give them as much information as possible (After all- you have a contact now) Simply saying that it's pretty well-known doesn't really help. As I've previously said, this isn't like its some sort of borderline case where someone in one part of the company is doing something that someone else doesn't know about. These guys are pretty hard core. I'd say I get 20-30 emails a year from them for various domain names I'm a contact on. I've also received USPS spam which is another story but no less unethical since they are all these BS renewal type letters. They might not be Domain Registry of America but they are hardly innocent. I frankly doubt they would bother posting here with let us know if they had no intention of looking into it- this isn't exactly a group likely to be pacified by empty promises. (It's also possible that in the past the right people never found out- or that there are new people there who take the issue more seriously). Well maybe this guys is serious about addressing the problem but if they are serious as a company the least they could do is respond to complaints that come via spamcop. Hell it think most spamcop complaints we get are mostly BS but I at least bother to respond to them. will be happy to hear that. If you're here to tell us that there never was a problem and that we're all just imagining it... you'll need these: I don't think they are going to claim there was never a problem- unfortunately sometimes the marketing folks don't consult or listen to their technical folks- it's happened at a lot of companies. That said- I haven't had spam from a register.com netblock in a long time. Then again maybe I've just been lucky. I'd go with lucky then. Chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFQu0TElUlCLUT2d0RAj0DAKCR1pSj/xEqYcTZAv86NRjuVO2DzACfXKVc eQ30FesWFzLWNWlwGFW6tA4= =CIB0 -END PGP SIGNATURE-
Re: register.com down sev0?
On Fri, 27 Oct 2006, Albert Meyer wrote: Charles J. Knipe wrote: Paul, As of right now I'm not prepared to comment on our recent outage in this forum. That said, I do want to discuss your assertion that Register.com is a source of spam. It's pretty well-known that register.com has been a source of spam, and that complaints to them have been ineffective. If you're here to tell us that the problem has recently been fixed, or that you're working on fixing it, people will be happy to hear that. If you're here to tell us that there never was a problem and that we're all just imagining it... you'll need these: http://www.spectorracing.com/catalog/category_477_UNDERWEAR_SParco_Racing_Underwear_page_1.html Carmyth fabric has a higher flame resistance than any previous material Interpreting someone else and therefore wrong, he told you that if you get no help, contact him directly. I think that's pretty cool, and you will be able to tell if it works or not. Let's try and not kill people who try and help, today. Gadi.
Re: BCP38 thread 93,871,738,435 + SPF
On Fri, 27 Oct 2006, Douglas Otis wrote: As Steve already pointed out, BCP38 is not a complete solution. Not only does SPF prevent the source of a Botnet attack from being detected, it also enables significantly greater amplification than might be achieved with a spoofed source DNS reflective attack. In addition, the Botnet resources are not wasted, as their spam is still being delivered. This aspect alone dangerously changes the costs related to such attacks. It seems wholly imprudent not to consider SPF in the same discussion. -Doug Doug, I wonder, HOW do you intend / do track down the source of a botnet attack? I know how I and others do it. There are three approaches which fork everywhere on an expression tree. If you believe SPF prevents you from doing it, can you elaborate how?
