Re: ADVANCE WARNING: Google moving to 2048-bit SSL and root keys

[Ryan Gard]

>From what it looks like, I'd assume they'll be sticking with a CA that has
a 2048 bit certificate as well.

Seems they also put a sandbox for testing together. That being said, they
won't confirm or deny whether or not they'll be using the same CA as they
have in the sandbox...

https://cert-test.sandbox.google.com/


On Fri, May 24, 2013 at 9:34 PM, Jimmy Hess  wrote:

> On 5/24/13, Jay Ashworth  wrote:
>
>
> Hm..  this might be no big deal if not for public key pinning and CA
> pinning in modern browsers of certain sites,  they could just get
> themselves 2048 bit certificates from any CA...
>
> So what could otherwise be a routine certificate change, may have some
> unusual extra baggage attached to it -- requiring end users performing
> software code update in their only slightly outdated browsers,
> instead of just switching certificates,   so they stop getting big red
> SSL errors when trying to perform searches via Google...
>
>
> > Via PRIVACY Forum:
> >
> > - Forwarded Message -
> >> From: "PRIVACY Forum mailing list" 
> >
> >> Google moving to longer SSL keys
> >>
> >> http://j.mp/10YAWaC (Google Online Security Blog)
>
> --
> -JH
>
>


-- 
Ryan Gard

Re: ADVANCE WARNING: Google moving to 2048-bit SSL and root keys

[Jimmy Hess]

On 5/24/13, Jay Ashworth  wrote:


Hm..  this might be no big deal if not for public key pinning and CA
pinning in modern browsers of certain sites,  they could just get
themselves 2048 bit certificates from any CA...

So what could otherwise be a routine certificate change, may have some
unusual extra baggage attached to it -- requiring end users performing
software code update in their only slightly outdated browsers,
instead of just switching certificates,   so they stop getting big red
SSL errors when trying to perform searches via Google...


> Via PRIVACY Forum:
>
> - Forwarded Message -
>> From: "PRIVACY Forum mailing list" 
>
>> Google moving to longer SSL keys
>>
>> http://j.mp/10YAWaC (Google Online Security Blog)

--
-JH

Re: Mailman reverting settings

[Grant Ridder]

Hi,

I received a couple offlist replies.  To answer Phil's questions, iptables
appeared to have spiked the cpu to 100% and caused it to overload and
become unresponsive.  Var was lot filled up to my knowledge.

An offlist reply suggested that if the config.pck file gets corrupted, then
mailman will revert to using an old config.db file.  After doing a file
level restore of the appropriate config.pck file, the list returned to
normal.

Thanks,
Grant

On Fri, May 24, 2013 at 9:23 AM, Phil Fagan  wrote:

> What hung the box? Core dump? Filled up var?
> On May 23, 2013 11:57 AM, "Grant Ridder"  wrote:
>
>> Hi Everyone,
>>
>> Has anyone ever seen Mailman revert to an old user list?  This morning we
>> had out lists VM pounded on from India and hung the box.  After blocking
>> the ip on our firewall and rebooting the hung vm, everything came back up
>> except 1 list.  The list appears to have reverted to old settings.  I
>> found
>> the config.pck file and it does not have the current settings in it.  This
>> has happened once before.  The box is running Ubuntu 10.04 and Mailman
>> 2.1.13.  Anyone know what would cause this and how to fix it?  We are
>> working to try a file level restore from a backup.
>>
>> Thanks,
>> Grant
>>
>> ~~
>>
>> Grant Ridder
>>
>> Assistant Systems Administrator
>>
>> Milwaukee School of Engineering 
>>
>

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 16-May-13 -to- 23-May-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS36998  176470  7.2% 208.6 -- SDN-MOBITEL
 2 - AS982954002  2.2%  50.4 -- BSNL-NIB National Internet 
Backbone
 3 - AS840236213  1.5%  38.3 -- CORBINA-AS OJSC "Vimpelcom"
 4 - AS580030402  1.2% 124.6 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 5 - AS270827616  1.1% 358.6 -- Universidad de Guanajuato
 6 - AS453824503  1.0%  47.0 -- ERX-CERNET-BKB China Education 
and Research Network Center
 7 - AS28573   22778  0.9%   6.1 -- NET Serviços de Comunicação S.A.
 8 - AS15003   21085  0.8%  46.5 -- NOBIS-TECH - Nobis Technology 
Group, LLC
 9 - AS17974   19423  0.8%   8.1 -- TELKOMNET-AS2-AP PT 
Telekomunikasi Indonesia
10 - AS45899   19103  0.8%  53.8 -- VNPT-AS-VN VNPT Corp
11 - AS31148   18670  0.8%  23.4 -- FREENET-AS Freenet Ltd.
12 - AS29049   17051  0.7%  50.1 -- DELTA-TELECOM-AS Delta Telecom 
LTD.
13 - AS390916639  0.7%2773.2 -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
14 - AS27738   16172  0.7%  28.2 -- Ecuadortelecom S.A.
15 - AS941616116  0.7% 322.3 -- MULTIMEDIA-AS-AP Hoshin 
Multimedia Center Inc.
16 - AS34744   14185  0.6%  20.5 -- GVM S.C. GVM SISTEM 2003 S.R.L.
17 - AS10620   13434  0.5%   5.6 -- Telmex Colombia S.A.
18 - AS33776   13205  0.5%  71.8 -- STARCOMMS-ASN
19 - AS211812887  0.5%   9.6 -- RELCOM-AS OOO "NPO Relcom"
20 - AS755211716  0.5%  20.6 -- VIETEL-AS-AP Vietel Corporation


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS6629 7314  0.3%7314.0 -- NOAA-AS - NOAA
 2 - AS8137 4782  0.2%4782.0 -- DISNEYONLINE-AS - Disney Online
 3 - AS423343956  0.2%3956.0 -- BBP-AS Broadband Plus s.a.l.
 4 - AS166087197  0.3%3598.5 -- KENTEC - Kentec Communications, 
Inc.
 5 - AS6174 5973  0.2%2986.5 -- SPRINTLINK8 - Sprint
 6 - AS390916639  0.7%2773.2 -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
 7 - AS449715538  0.2%2769.0 -- GOETEC-AS GOETEC Limited
 8 - AS223569156  0.4%2289.0 -- Durand do Brasil Ltda
 9 - AS194064506  0.2%2253.0 -- TWRS-MA - Towerstream I, Inc.
10 - AS369484319  0.2%2159.5 -- KENIC
11 - AS146806434  0.3%2144.7 -- REALE-6 - Auction.com
12 - AS277358332  0.3%2083.0 -- Synapsis Soluciones y Servicios 
IT LTDA
13 - AS609241897  0.1%1897.0 -- ORIXCOM Orixcom JLT
14 - AS373181390  0.1%1390.0 -- BESA
15 - AS339202605  0.1%1302.5 -- AQL (aq) Networks Limited
16 - AS608111283  0.1%1283.0 -- SAIPAYADAH-AS Saipa Yadak Co. 
PLC
17 - AS226881173  0.1%1173.0 -- DOLGENCORP - Dollar General 
Corporation
18 - AS373671984  0.1% 992.0 -- CALLKEY
19 - AS339229575  0.4% 957.5 -- NTT-LT-AS UAB Nacionalinis 
Telekomunikaciju Tinklas
20 - AS159471450  0.1% 725.0 -- CCBISP-AS Cork Community 
Broadband Limited


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 88.216.171.0/249539  0.4%   AS33922 -- NTT-LT-AS UAB Nacionalinis 
Telekomunikaciju Tinklas
 2 - 193.19.90.0/23 9089  0.3%   AS29684 -- NOURNET-ASN Nour Communication 
Co.Ltd - Nournet
 3 - 206.48.139.0/248326  0.3%   AS27735 -- Synapsis Soluciones y Servicios 
IT LTDA
 4 - 92.246.207.0/248291  0.3%   AS48612 -- RTC-ORENBURG-AS CJSC 
"Comstar-Regions"
 5 - 203.118.232.0/21   7976  0.3%   AS9416  -- MULTIMEDIA-AS-AP Hoshin 
Multimedia Center Inc.
 6 - 203.118.224.0/21   7954  0.3%   AS9416  -- MULTIMEDIA-AS-AP Hoshin 
Multimedia Center Inc.
 7 - 192.58.232.0/247314  0.3%   AS6629  -- NOAA-AS - NOAA
 8 - 194.219.56.0/245658  0.2%   AS1241  -- FORTHNET-GR Forthnet
 9 - 151.118.255.0/24   5537  0.2%   AS3909  -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
10 - 151.118.254.0/24   5537  0.2%   AS3909  -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
11 - 151.118.18.0/245520  0.2%   AS3909  -- QWEST-AS-3908 - Qwest 
Communications Company, LLC
12 - 12.139.133.0/245330  0.2%   AS14680 -- REALE-6 - Auction.com
13 - 5.56.48.0/21   5093  0.2%   AS44971 -- GOETEC-AS GOETEC Limited
14 - 209.240.40.0/214916  0.2%   AS32020 -- TRANSACT-BM-ASN - Transact Ltd.
15 - 198.187.189.0/24   4782  0.2%   AS8137  -- DISNEYONLINE-AS - Disney Online
16 - 173.232.234.0/24   4673  0.2%   AS30693 -- 
EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
17 - 173.232.235.0/24   4670  0.2%   AS30693 -- 
EONIX-C

The Cidr Report

[cidr-report]

This report has been generated at Fri May 24 21:13:21 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
17-05-13456674  260287
18-05-13456618  259718
19-05-13456593  259863
20-05-13456601  260071
21-05-13456490  260473
22-05-13456760  260482
23-05-13457215  261060
24-05-13457343  260436


AS Summary
 44264  Number of ASes in routing system
 18329  Number of ASes announcing only one prefix
  3018  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  116962272  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


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').

 --- 24May13 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 457303   260379   19692443.1%   All ASes

AS6389  3018   83 293597.2%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS28573 2768  557 221179.9%   NET Serviços de Comunicação
   S.A.
AS4766  2962  942 202068.2%   KIXS-AS-KR Korea Telecom
AS17974 2513  563 195077.6%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS22773 1979  131 184893.4%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS10620 2631  788 184370.0%   Telmex Colombia S.A.
AS18566 2066  474 159277.1%   COVAD - Covad Communications
   Co.
AS4755  1733  208 152588.0%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS7303  1727  453 127473.8%   Telecom Argentina S.A.
AS4323  1611  406 120574.8%   TWTC - tw telecom holdings,
   inc.
AS2118  1260   86 117493.2%   RELCOM-AS OOO "NPO Relcom"
AS7552  1167  180  98784.6%   VIETEL-AS-AP Vietel
   Corporation
AS36998 1237  301  93675.7%   SDN-MOBITEL
AS18881  951   26  92597.3%   Global Village Telecom
AS18101 1000  180  82082.0%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS9808   814   60  75492.6%   CMNET-GD Guangdong Mobile
   Communication Co.Ltd.
AS1785  1992 1242  75037.7%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS4808  1133  386  74765.9%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS8402  1753 1007  74642.6%   CORBINA-AS OJSC "Vimpelcom"
AS13977  845  138  70783.7%   CTELCO - FAIRPOINT
   COMMUNICATIONS, INC.
AS855742   56  68692.5%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS22561 1178  504  67457.2%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS8151  1266  597  66952.8%   Uninet S.A. de C.V.
AS7029  2071 1409  66232.0%   WINDSTREAM - Windstream
   Communications Inc
AS6983  1134  478  65657.8%   ITCDELTA - ITC^Deltacom
AS24560 1069  413  65661.4%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS15003  798  158  64080.2%   NOBIS-TECH - Nobis Technology
   Group, LLC
AS7545  1987 1357  63031.7%   TPG-INTERNET-AP TPG Telecom
   Limited
AS17676  733  110  62385.0%   GIGAINFRA Softbank BB Corp.
AS3549  1064  444  62058.3%   GBLX Global Crossing Ltd.

Total  4720

ADVANCE WARNING: Google moving to 2048-bit SSL and root keys

[Jay Ashworth]

Via PRIVACY Forum:

- Forwarded Message -
> From: "PRIVACY Forum mailing list" 

> Google moving to longer SSL keys
> 
> http://j.mp/10YAWaC (Google Online Security Blog)
> 
> "This encryption needs to be updated at times to make it even
> stronger, so this year our SSL services will undergo a series of
> certificate upgrades-specifically, all of our SSL certificates
> will be upgraded to 2048-bit keys by the end of 2013. We will
> begin switching to the new 2048-bit certificates on August 1st, to
> ensure adequate time for a careful rollout before the end of the
> year. We're also going to change the root certificate that signs
> all of our SSL certificates because it has a 1024-bit key."
> 
> - - -
> 
> I will note, however, that given the fundamental weaknesses in the
> PKI -- especially relating to certificate authorities in general --
> even longer keys will not solve intrinsic problems that must be faced.
> 
> --Lauren--
> Lauren Weinstein (lau...@vortex.com): http://www.vortex.com/lauren
> ___
> privacy mailing list
> http://lists.vortex.com/mailman/listinfo/privacy

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

Re: High throughput bgp links using gentoo + stipped kernel

[Nick Khamis]

Sorry for the top post!!!

N.

Re: High throughput bgp links using gentoo + stipped kernel

[Nick Khamis]

+1 on the interrupt cpu assignment

N.

On 5/24/13, Nick Hilliard  wrote:
> On 24/05/2013 20:21, Joe Greco wrote:
>> Luigi did the polling stuff more than a decade ago.  Polling fixes some
>> issues and seems to cause others.
>
> interrupt mitigation helps more than polling these days.  Make sure you're
> using modern hardware.
>
> Nick
>
>
>

Re: High throughput bgp links using gentoo + stipped kernel

[Nick Hilliard]

On 24/05/2013 20:21, Joe Greco wrote:
> Luigi did the polling stuff more than a decade ago.  Polling fixes some
> issues and seems to cause others.

interrupt mitigation helps more than polling these days.  Make sure you're
using modern hardware.

Nick

Re: High throughput bgp links using gentoo + stipped kernel

[Gabriel Blanchard]

On 13-05-24 03:17 PM, Ryan Gard wrote:
> Do you have a source on this? Reason I ask is because any recent
> documentation I've come across indicates that polling is recommended to
> reduce chances of livelock on a running system.

This depends a *ton* of what NIC you are using. Polling IMO should not
be enabled on modern NICs.
They use MSI-X to distribute interrupts to each core through the PCI bus
to the APIC. As well as various methods to reduce the number of
interrupts generated per second.

This polling thing only worked well 10years ago. (Or if you still have
10 year old gear)

-Gabe

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 25 May, 2013

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  455658
Prefixes after maximum aggregation:  185562
Deaggregation factor:  2.46
Unique aggregates announced to Internet: 224685
Total ASes present in the Internet Routing Table: 44157
Prefixes per ASN: 10.32
Origin-only ASes present in the Internet Routing Table:   34642
Origin ASes announcing only one prefix:   16112
Transit ASes present in the Internet Routing Table:5852
Transit-only ASes present in the Internet Routing Table:152
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  54
Max AS path prepend of ASN ( 56484)  51
Prefixes from unregistered ASNs in the Routing Table:   315
Unregistered ASNs in the Routing Table: 128
Number of 32-bit ASNs allocated by the RIRs:   4775
Number of 32-bit ASNs visible in the Routing Table:3663
Prefixes from 32-bit ASNs in the Routing Table:   10451
Special use prefixes present in the Routing Table:   26
Prefixes being announced from unallocated address space:244
Number of addresses announced to Internet:   2619297836
Equivalent to 156 /8s, 31 /16s and 80 /24s
Percentage of available address space announced:   70.7
Percentage of allocated address space announced:   70.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   94.5
Total number of prefixes smaller than registry allocations:  160151

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   110112
Total APNIC prefixes after maximum aggregation:   33502
APNIC Deaggregation factor:3.29
Prefixes being announced from the APNIC address blocks:  111514
Unique aggregates announced from the APNIC address blocks:44846
APNIC Region origin ASes present in the Internet Routing Table:4843
APNIC Prefixes per ASN:   23.03
APNIC Region origin ASes announcing only one prefix:   1218
APNIC Region transit ASes present in the Internet Routing Table:829
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 30
Number of APNIC region 32-bit ASNs visible in the Routing Table:537
Number of APNIC addresses announced to Internet:  722621440
Equivalent to 43 /8s, 18 /16s and 84 /24s
Percentage of available APNIC address space announced: 84.5

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 131072-133119
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:159423
Total ARIN prefixes after maximum aggregation:80337
ARIN Deaggregation factor: 1.98
Prefixes being announced from the ARIN address blocks:   160003
Unique aggregates announced from the ARIN address blocks: 73260
ARIN Region origin ASes present in the Internet Routing Table:15710
ARIN Prefixes per ASN:10.18
ARIN Region origin ASes announcing only one

Re: High throughput bgp links using gentoo + stipped kernel

[Joe Greco]

> Do you have a source on this? Reason I ask is because any recent
> documentation I've come across indicates that polling is recommended to
> reduce chances of livelock on a running system.

What recent documentation have you come across?

Luigi did the polling stuff more than a decade ago.  Polling fixes some
issues and seems to cause others.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Geoip lookup

[Tom Vest]

On May 24, 2013, at 3:27 AM, Paul Kelly :: Blacknight wrote:

>>> 
>>> Just because I have operations in one region does not preclude me
>> from having operations
>>> in other regions.  YMMV of course.
>>> 
>>> /bill
>> 
>> That was exactly my point, Bill... If you have operations in RIPE and ARIN
>> regions, it is entirely possible for you to obtain addresses from RIPE or 
>> ARIN
>> and use them in both locations, or, obtain addresses from both RIPE and
>> ARIN and use them in their respective regions, or mix and match in just about
>> any imaginable way. Thus, IP addresses don't reside in regions, either. They
>> are merely issued somewhat regionally.
>> 
> 
> In theory Maxmind is quite accurate. From 1 x /20 that we own we tag 
> different space with the country: flag in the RIPE db. Maxmind picks this up 
> after approx 30 days and says it's in Country X vrs country Y.

Interesting.

I wonder how many days it takes the RIPE db to report the correct country for 
those more specifics that you've tagged...

TV

> e.g.
> 
> $ geoiplookup 81.17.247.64
> GeoIP Country Edition: US, United States
> $ geoiplookup 81.17.247.1 
> GeoIP Country Edition: IE, Ireland
> 
> Obviously the RIPE db structure makes this simple. As for other RIRs it's not 
> as easy. Like someone else said, it's going to be an 80% solution and its 
> really down to good administration from a network operator point of view. 
> i.e. if you route some of your RIPE space in ARIN territory you should 
> specify the country. There's numerous reasons for this but it's just good 
> practice IMO.
> 
> Pk
> 

Re: High throughput bgp links using gentoo + stipped kernel

[Ryan Gard]

Do you have a source on this? Reason I ask is because any recent
documentation I've come across indicates that polling is recommended to
reduce chances of livelock on a running system.


On Mon, May 20, 2013 at 2:51 PM, Eduardo Schoedler wrote:

> 2013/5/19 Andrew Jones 
>
> > As for migration to another OS, I find FreeBSD better as a matter of
> >> network performance. The last time I checked OpenBSD was either
> >> lacking or was in the early stages of multiple cores support.
> >>
> >
> > If you do decide to go the FreeBSD route (you can run openbgpd on FreeBSD
> > if you like), check out the POLLING option on ethernet NICs, it cuts down
> > on the number of interrupts and can increase performance, particularly
> when
> > dealing with smaller packets.
> >
>
> Polling on FreeBSD in modern NICs is discouraged.
>
> --
> Eduardo Schoedler
>



-- 
Ryan Gard

Re: What hath god wrought?

[Ryan Gard]

Smells more like a honeypot than anything. Now that this guy's clearly
decided to open his mouth and claim he's got the green light from the Fed,
I wouldn't be surprised if they change their mind.


On Tue, May 21, 2013 at 1:54 PM, Phil Fagan  wrote:

> HAH! Thats pretty funnythe tinfoil piece.
>
>
> On Tue, May 21, 2013 at 10:13 AM, jim deleskie  wrote:
>
> > Maybe my tinfoil isn't on tight enough, or maybe I give to much credit
> to a
> > gov't, or perhaps I'm just feeding the trolls, but I have a very hard
> time
> > believing that DHS, launched a DoS from their own machines.
> >
> >
> > -jim
> >
> >
> > On Tue, May 21, 2013 at 12:18 PM, David Conrad 
> > wrote:
> >
> > > On May 20, 2013, at 9:56 PM, Jay Farrell  wrote:
> > > > Are you certain it was a DoS attempt?
> > >
> > > And if you were certain, are you certain the folks at DHS were aware
> > their
> > > machine(s) were engaged in a DoS attack?
> > >
> > > You can find zombies in the oddest places...
> > >
> > > Regards,
> > > -drc
> > >
> > >
> > >
> >
>
>
>
> --
> Phil Fagan
> Denver, CO
> 970-480-7618
>



-- 
Ryan Gard

Re: Geoip lookup

[Barry Shein]

You're thinking like an engineer.

Think like a marketer.

They expect less than 1% response on paper mail advertising.

Now, compare and contrast your idea of a reasonable confidence level
and theirs.


-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: Geoip lookup

[Owen DeLong]

On May 24, 2013, at 01:13 , shawn wilson  wrote:

> I knew this would come up. Actually I'm surprised and glad it waited until I 
> got a solution first.
> 
> I'll address a few points:
> - this is mainly to stop stupid things from sending packets from countries we 
> will probably never want to do business with (I'm looking mainly at that big 
> country under APNIC). 
> 

I can't tell you how much I enjoyed all the hoops I had to jump through in 
order to access my online banking while traveling in that country.

Assuming that your local customers aren't in that location isn't a valid 
assumption to begin with. Making life difficult for those that do travel will 
not earn you brownie points with them. (I am no longer with the financial 
institution that made this most difficult).
> - I'd prefer a solution that blocks all traffic that is routed through those 
> countries so that they could never see data from us (and when Jin-rong has a 
> configuration mess up and rerouts ~10% of traffic through them for a half 
> hour, I don't see any of that traffic). Since I have no idea how one would go 
> about doing this, just blocking traffic from IP addresses registered in 
> certain countries is good enough. 
> 
That's hard to do. Unless you require "record-route" on all packets and have 
some way to validate the contents of the route recording header (and enough 
space in the header to record all hops every time), it's not going to be 
possible. Further, even if it were, there's no way to ensure that all of your 
client's packets will get retransmitted on a path that works, so you would have 
the potential to severely degrade customer service in non-intuitive and 
hard-to-diagnose ways.

If you are my competitor, then I encourage you to try this.
> - it is well known (I think everyone on this list at least) that you can 
> evade geographic placement of your origin by tunneling. Given this, I fail to 
> see the point in bringing up that "GeoIP" doesn't work. Also, if it doesn't 
> work, why do content providers, CDNs, google, and streaming services rely on 
> it as part of their business model? The sad truth of the mater is it does 
> work and surprisingly well. We just don't like it because it's brittle and a 
> user can fool us (I know Akami and the like look at trip time and the like 
> because they know there are issues). Given all of this, how often is looking 
> at the country an IP address originates from via what is listed for the 
> particular ASN actually fiction?
> 

Asking why providers rely on GeoIP in the face of it's flaws is like asking why 
people continue to buy Windows. It's a cross between inertia and a lack of 
better solutions at comparable cost. The sad truth of the matter is that it 
doesn't work. It works well enough to give the illusion of working. Deeper 
analysis, however, reveals that it works just well enough to keep honest people 
honest some of the time. Further, victims of it not working have little or no 
recourse available to them even if they understand what is happening. For the 
average user, it just looks like some portion of the internet is 
{permanently|temporarily} broken again for reasons passing understanding and 
they go somewhere else.

Owen

> Again, the input was invaluable for getting me where I wanted to be so thanks 
> again. 
> 
> On May 24, 2013 2:59 AM, "Owen DeLong"  wrote:
> 
> On May 23, 2013, at 23:49 , bmann...@vacation.karoshi.com wrote:
> 
> > On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote:
> >>
> >> On May 23, 2013, at 23:17 , David Conrad  wrote:
> >>
> >>> On May 23, 2013, at 10:53 PM, Andreas Larsen  
> >>> wrote:
>  The whole idea of Geoip is flawed.
> >>>
> >>> Sure, but pragmatically, it's an 80% solution.
> >>>
>  IP dosen't reside in countries,
> >>>
> >>> True, according to (at least some of) the RIRs they reside in regions...
> >>>
> >>
> >> Really? Which ones? I thought they were only issued to organizations that 
> >> had operations in regions.
> >>
> >> Owen
> >
> >   Just because I have operations in one region does not preclude me 
> > from having operations
> >   in other regions.  YMMV of course.
> >
> > /bill
> 
> That was exactly my point, Bill... If you have operations in RIPE and ARIN 
> regions, it is entirely possible for you to obtain addresses from RIPE or 
> ARIN and use them in both locations, or, obtain addresses from both RIPE and 
> ARIN and use them in their respective regions, or mix and match in just about 
> any imaginable way. Thus, IP addresses don't reside in regions, either. They 
> are merely issued somewhat regionally.
> 
> Owen
> 
> 

Re: Geoip lookup

[Owen DeLong]

On May 24, 2013, at 00:28 , Jean-Francois Mezei  
wrote:

> On 13-05-24 02:57, Owen DeLong wrote:
> 
>> That was exactly my point, Bill... If you have operations in RIPE and ARIN 
>> regions, it is entirely possible for you to obtain addresses from RIPE or 
>> ARIN and use them in both locations, or, obtain addresses from both RIPE and 
>> ARIN and use them in their respective regions, or mix and match in just 
>> about any imaginable way. Thus, IP addresses don't reside in regions, 
>> either. They are merely issued somewhat regionally.
> 
> Correct.
> But the fact remains that a lot of services assume geolocation works and
> do so in terms of restricting access to their content (oftent due to
> legacy content rights that require geolocation).
> 

The fact remains that a certain percentage of the population robs banks.

Neither is a particularly good thing, IMHO.

> One extreme example. A sports equipment retailer operates under a
> different banner in the province of Québec than in the rest of Canada.
> They geolocate the user's province and prevent québeckers from accessing
> the "rest of canada" web site.
> 

And the quebeckers that care use a tunnel to get an address that doesn't
geolocate to quebec.

> So residents of ontario who subscribe to an ISP based in Québec are
> blocked from the web site because that web site thinks they are based in
> Québec.
> 

Which goes to prove my point wrt. bank robbery.

> The problem is with many web designers and managers who do not
> understand geolocation and the ISP business and how they are structured.
> 

So called experts who remain rather ignorant in their field of "expertise" are 
a problem across a wide variety of fields. The internet is not unique in this 
regard and geolocation is just one aspect of this problem on the internet.

> In the case of the sports equipment chain. there is no real need to
> geoblock. (perhaps to prevent Québeckers from seeing the prices in the
> rest of canada ?)
> 

Yep... And even if there were a reason, geoblocking is a joke anyway because it 
is trivially subverted by anyone who cares and more of a problem for people who 
should have access but their IP doesn't match their actual geography.

> But in the case of entertainment, rights to programs are purchased with
> strict geolocation requirements. One example are pay TV channels TMN
> (Astral) and Movie Central (Shaw). The first has eastern canada, the
> later has western Canada.

But IP geolocation doesn't help in either of these cases. Those wanting to 
subvert the programming restrictions simply use a tunnel to do so. On the other 
hand, a customer who lives near the boundary and gets his internet service from 
the "wrong side" of the boundary has access to the service from the wrong 
geography and not the correct geography.

> an IPTV BDU (regulated "cable" carrier (aka: cable competitor) must
> therefore ensure that a customer to whom it delivers the IPTV feed for
> "TMN" is located in the region for which TMN has rights. Same for all
> channels.  And there is also pesky channel substitution requirements
> rhat are based on your location. In Canada, we are not allowed to watch
> a program on a US channel if a local TV channel carries the same program
> at same time.

And geolocation by IP doesn't actually work to enforce any of these 
restrictions because tunnels easily circumvent it for those that want to 
circumvent it. OTOH, it also breaks the process for those who happen to be 
victims of unfortunate mismatches between topology and geography.

Where the IPTV provider is also the ISP, this isn't really much of a problem, 
but in that case, geo IP is kind of redundant.

Where the IPTV provider is not the ISP, it gets very strange very quickly.

> The better solution is to do like satellite BDUs do: billing address.
> But some web based systems ignore the unreliable geolocation services
> and use them to geolocate their customers.

Yep... Again, see above comments about ignorance and bank robbery.

> It is probably the fault of geolocation services which misrepresent the
> accuracy of their data.  But if you can't beat them, you might as well
> join them, and that may mean separate IP blocks for different
> provinces/states and separate registrations so geoocation companies can
> at least get province/state right.

Why would I want to help them? I'd much rather give my customers the option of 
where they want to pretend to be. If I were running a provider that crossed 
such regional boundaries, I'd likely offer a service (for a fee) where a 
customer could tunnel through whichever region got them access to the content 
they wanted at any given time.

> It will get much worse if governments start to tax purchases/services
> based on gelocation.

ROFLMAO... Indeed... That will likely lead to some very interesting lawsuits 
and consumer complaints about invalid taxation due to inaccuracies in the 
geolocation database.

Owen

Re: Geoip lookup

[David Conrad]

I replied privately to Owen, but might as well share:

On May 23, 2013, at 11:57 PM, Owen DeLong  wrote:
 True, according to (at least some of) the RIRs they reside in regions... 
>>> Really? Which ones? I thought they were only issued to organizations that 
>>> had operations in regions.
> That was exactly my point, Bill... If you have operations in RIPE and ARIN 
> regions, it is entirely possible for you to obtain addresses from RIPE or 
> ARIN and use them in both locations, or, obtain addresses from both RIPE and 
> ARIN and use them in their respective regions, or mix and match in just about 
> any imaginable way. Thus, IP addresses don't reside in regions, either. They 
> are merely issued somewhat regionally.

A direct quote from a recent interaction with ARIN (this was requested by ARIN 
staff as part of the back and forth for requesting address space):

"Please reply and verify that you will be using the requested number resources 
within the ARIN region and announcing all routing prefixes of the requested 
space from within the ARIN region. In accordance with section 2.2 of the NRPM, 
ARIN issues number resources only for use within its region. ARIN is therefore 
only able to provide for your in-region numbering needs."

I believe AfriNIC and LACNIC have similar limitations on use but am too lazy to 
look it up (and I don't really care all that much: just thought it was amusing).

Regards,
-drc

Re: Mailman reverting settings

[Phil Fagan]

What hung the box? Core dump? Filled up var?
On May 23, 2013 11:57 AM, "Grant Ridder"  wrote:

> Hi Everyone,
>
> Has anyone ever seen Mailman revert to an old user list?  This morning we
> had out lists VM pounded on from India and hung the box.  After blocking
> the ip on our firewall and rebooting the hung vm, everything came back up
> except 1 list.  The list appears to have reverted to old settings.  I found
> the config.pck file and it does not have the current settings in it.  This
> has happened once before.  The box is running Ubuntu 10.04 and Mailman
> 2.1.13.  Anyone know what would cause this and how to fix it?  We are
> working to try a file level restore from a backup.
>
> Thanks,
> Grant
>
> ~~
>
> Grant Ridder
>
> Assistant Systems Administrator
>
> Milwaukee School of Engineering 
>

Re: Geoip lookup

[John Curran]

On May 24, 2013, at 2:34 AM, Andreas Larsen  wrote:

> If we continue to support and build tools around this geolocation based
> ip-dravel, we give people a false notion that this is something we should
> do. 
> ...
> 
> Or just get rid of the whole idea and realize that the internet is global
> and reaches everywhere no matter what your IP currently is.

While the Internet is global and reaches everywhere, the same is not 
true about most businesses and governments...  As a result, there are 
many use cases that we may not like, but are seen as basic requirements 
by those organizations.  Examples include laws and business contracts 
that require different behavior depending on the location of the user, 
and from the view of these organizations, the Internet almost gives the
impression of shoddy workmanship to omit such an obvious capability.  
Luckily, many organizations did come up with workarounds, and the lack 
of a 100% reliable solution did not prevent them from distributing 
content (software, music, movies, articles, etc.) that they only had 
rights to do so in a particular region. 

If the approximate geolocation approaches had not been used, we'd
would not have had the region-restricted experimentation in content
distribution that underlies quite a bit of the industry even today.

One can argue that regionally-based business models should be changed, 
but the fact is that the not-quite-reliable geolocation services are
actually has been pretty important in enabling traditional content in
making it onto the Internet. (It is left as a exercise for the reader 
as to whether more highly reliable geolocation would meaningfully help
the situation, or simply enable its use in non-commercial contexts to 
the detriment of the global user community.)

/John

Disclaimer: My views alone (& for folks who wish to filter this email
based on my geolocation, it is presently Northern Virginia USA ;-)

Re: Mailman reverting settings

[Rich Kulawiec]

1. The mailman-users list is here:

http://mail.python.org/mailman/listinfo/mailman-users

2. Blocking one IP address is not usually sufficient.
If you don't need email from India (or any other country for
that matter) to reach that list, then you should block the
entire country from that VM.  See http://ipdeny.com/ for lists.

---rsk

Re: Geoip lookup

[shawn wilson]

I knew this would come up. Actually I'm surprised and glad it waited until
I got a solution first.

I'll address a few points:
- this is mainly to stop stupid things from sending packets from countries
we will probably never want to do business with (I'm looking mainly at that
big country under APNIC).
- I'd prefer a solution that blocks all traffic that is routed through
those countries so that they could never see data from us (and when
Jin-rong has a configuration mess up and rerouts ~10% of traffic through
them for a half hour, I don't see any of that traffic). Since I have no
idea how one would go about doing this, just blocking traffic from IP
addresses registered in certain countries is good enough.
- it is well known (I think everyone on this list at least) that you can
evade geographic placement of your origin by tunneling. Given this, I fail
to see the point in bringing up that "GeoIP" doesn't work. Also, if it
doesn't work, why do content providers, CDNs, google, and streaming
services rely on it as part of their business model? The sad truth of the
mater is it does work and surprisingly well. We just don't like it because
it's brittle and a user can fool us (I know Akami and the like look at trip
time and the like because they know there are issues). Given all of this,
how often is looking at the country an IP address originates from via what
is listed for the particular ASN actually fiction?

Again, the input was invaluable for getting me where I wanted to be so
thanks again.
On May 24, 2013 2:59 AM, "Owen DeLong"  wrote:

>
> On May 23, 2013, at 23:49 , bmann...@vacation.karoshi.com wrote:
>
> > On Thu, May 23, 2013 at 11:39:12PM -0700, Owen DeLong wrote:
> >>
> >> On May 23, 2013, at 23:17 , David Conrad  wrote:
> >>
> >>> On May 23, 2013, at 10:53 PM, Andreas Larsen <
> andreas.lar...@ip-only.se> wrote:
>  The whole idea of Geoip is flawed.
> >>>
> >>> Sure, but pragmatically, it's an 80% solution.
> >>>
>  IP dosen't reside in countries,
> >>>
> >>> True, according to (at least some of) the RIRs they reside in
> regions...
> >>>
> >>
> >> Really? Which ones? I thought they were only issued to organizations
> that had operations in regions.
> >>
> >> Owen
> >
> >   Just because I have operations in one region does not preclude me
> from having operations
> >   in other regions.  YMMV of course.
> >
> > /bill
>
> That was exactly my point, Bill... If you have operations in RIPE and ARIN
> regions, it is entirely possible for you to obtain addresses from RIPE or
> ARIN and use them in both locations, or, obtain addresses from both RIPE
> and ARIN and use them in their respective regions, or mix and match in just
> about any imaginable way. Thus, IP addresses don't reside in regions,
> either. They are merely issued somewhat regionally.
>
> Owen
>
>
>

Re: Geoip lookup

[Jean-Francois Mezei]

On 13-05-24 02:57, Owen DeLong wrote:

> That was exactly my point, Bill... If you have operations in RIPE and ARIN 
> regions, it is entirely possible for you to obtain addresses from RIPE or 
> ARIN and use them in both locations, or, obtain addresses from both RIPE and 
> ARIN and use them in their respective regions, or mix and match in just about 
> any imaginable way. Thus, IP addresses don't reside in regions, either. They 
> are merely issued somewhat regionally.

Correct.
But the fact remains that a lot of services assume geolocation works and
do so in terms of restricting access to their content (oftent due to
legacy content rights that require geolocation).

One extreme example. A sports equipment retailer operates under a
different banner in the province of Québec than in the rest of Canada.
They geolocate the user's province and prevent québeckers from accessing
the "rest of canada" web site.

So residents of ontario who subscribe to an ISP based in Québec are
blocked from the web site because that web site thinks they are based in
Québec.

The problem is with many web designers and managers who do not
understand geolocation and the ISP business and how they are structured.

In the case of the sports equipment chain. there is no real need to
geoblock. (perhaps to prevent Québeckers from seeing the prices in the
rest of canada ?)

But in the case of entertainment, rights to programs are purchased with
strict geolocation requirements. One example are pay TV channels TMN
(Astral) and Movie Central (Shaw). The first has eastern canada, the
later has western Canada.

an IPTV BDU (regulated "cable" carrier (aka: cable competitor) must
therefore ensure that a customer to whom it delivers the IPTV feed for
"TMN" is located in the region for which TMN has rights. Same for all
channels.  And there is also pesky channel substitution requirements
rhat are based on your location. In Canada, we are not allowed to watch
a program on a US channel if a local TV channel carries the same program
at same time.

The better solution is to do like satellite BDUs do: billing address.
But some web based systems ignore the unreliable geolocation services
and use them to geolocate their customers.

It is probably the fault of geolocation services which misrepresent the
accuracy of their data.  But if you can't beat them, you might as well
join them, and that may mean separate IP blocks for different
provinces/states and separate registrations so geoocation companies can
at least get province/state right.

It will get much worse if governments start to tax purchases/services
based on gelocation.

RE: Geoip lookup

[Paul Kelly :: Blacknight]

> >
> > Just because I have operations in one region does not preclude me
> from having operations
> > in other regions.  YMMV of course.
> >
> > /bill
> 
> That was exactly my point, Bill... If you have operations in RIPE and ARIN
> regions, it is entirely possible for you to obtain addresses from RIPE or ARIN
> and use them in both locations, or, obtain addresses from both RIPE and
> ARIN and use them in their respective regions, or mix and match in just about
> any imaginable way. Thus, IP addresses don't reside in regions, either. They
> are merely issued somewhat regionally.
> 

In theory Maxmind is quite accurate. From 1 x /20 that we own we tag different 
space with the country: flag in the RIPE db. Maxmind picks this up after approx 
30 days and says it's in Country X vrs country Y.

e.g.

$ geoiplookup 81.17.247.64
GeoIP Country Edition: US, United States
$ geoiplookup 81.17.247.1 
GeoIP Country Edition: IE, Ireland

Obviously the RIPE db structure makes this simple. As for other RIRs it's not 
as easy. Like someone else said, it's going to be an 80% solution and its 
really down to good administration from a network operator point of view. i.e. 
if you route some of your RIPE space in ARIN territory you should specify the 
country. There's numerous reasons for this but it's just good practice IMO.

Pk