Re: Host scanning in IPv6 Networks

[Fernando Gont]

Hi, Jimmy,

On 04/20/2012 09:22 PM, Jimmy Hess wrote:
> The mathematical argument in the draft doesn't really work,  because
> it's too focused on  there being "one specific site"  that can be
> scanned.

Not sure what you mean. Clearly, in the IPv6 world you'd target specific
networks.

How could you know which networks to scan? -- Easy: the attacker is
targeting a specific organization, are you gather possible target
networks as this information leaks out all too often (e-mail headers, etc.).



> You can't just "pick a random 120 bit number"  and have a good chance
> of that random IP happening to be a live host address.

That would be pretty much a "brute force" attack, and the argument in
this paper is that IPv6 host-scanning attacks will not be brute force
(as we know them).


> The draft is unconvincing.   The expected result is there will be very
> little preference for scanning,  and those  that will be launching
> attacks against networks will  be utilizing simpler techniques that
> are still highly effective and do not require scanning.

Not sure what you mean. Could you please clarify?



> Such as the exploit of vulnerable HTTP clients  who _navigate to the
> attacker controlled web page_, walking directly into their hands,
> instead of worms  "searching for needles in haystacks".

Well, this is part of alternative scanning techniques, which so far are
not the subject of this draft.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: Host scanning in IPv6 Networks

[Jimmy Hess]

For certain definitions of "host scanning"  it is possible to achieve
some level of that in IPv6.
But massively far less efficient and far more limited than the brute
force option that is available in IPv4.

The mathematical argument in the draft doesn't really work,  because
it's too focused on  there being "one specific site"  that can be
scanned.

You can't just "pick a random 120 bit number"  and have a good chance
of that random IP happening to be a live host address.You can't
just pick a random  /64   and have a good chance of that random /64
happening to be part of a live site.

How useful more informed attacks are,  remains to be seen.  For worm
authors it will seem like a lot of sugar for a dime.

Malware propagation against open ports doesn't work so well if your
nodes  can't effect wide scans efficiently.  If you are so misguided
as to not have a firewall preventing access to vulnerable services.

The draft is unconvincing.   The expected result is there will be very
little preference for scanning,  and those  that will be launching
attacks against networks will  be utilizing simpler techniques that
are still highly effective and do not require scanning.

Such as the exploit of vulnerable HTTP clients  who _navigate to the
attacker controlled web page_, walking directly into their hands,
instead of worms  "searching for needles in haystacks".

Any worms searching for needles in haystacks are likely to be
utilizing a combination of search engines, common dictionary name
lookups, and DNS  to discover IP addresses of potential target web
servers.

--
-JH

On 4/20/12, Steven Bellovin  wrote:
> Also see https://www.cs.columbia.edu/~smb/papers/v6worms.pdf
> (Worm propagation strategies in an IPv6 Internet. ;login:,
> pages 70-76, February 2006.)
>
> On Apr 20, 2012, at 3:08 50AM, Fernando Gont wrote:
>
>> FYI
>>
>>  Original Message 
>> Subject: IPv6 host scanning in IPv6
>> Date: Fri, 20 Apr 2012 03:57:48 -0300
>> From: Fernando Gont 
>> Organization: SI6 Networks
>> To: IPv6 Hackers Mailing List 
>>
>> Folks,
>>
>> We've just published an IETF internet-draft about IPv6 host scanning
>> attacks.
>>
>> The aforementioned document is available at:
>> 
>>
>> The Abstract of the document is:
>>  cut here 
>>   IPv6 offers a much larger address space than that of its IPv4
>>   counterpart.  The standard /64 IPv6 subnets can (in theory)
>>   accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
>>   much lower host density (#hosts/#addresses) than their IPv4
>>   counterparts.  As a result, it is widely assumed that it would take a
>>   tremendous effort to perform host scanning attacks against IPv6
>>   networks, and therefore IPv6 host scanning attacks have long been
>>   considered unfeasible.  This document analyzes the IPv6 address
>>   configuration policies implemented in most popular IPv6 stacks, and
>>   identifies a number of patterns in the resulting addresses lead to a
>>   tremendous reduction in the host address search space, thus
>>   dismantling the myth that IPv6 host scanning attacks are unfeasible.
>>  cut here 
>>
>> Any comments will be very welcome (note: this is a drafty initial
>> version, with lots of stuff still to be added... but hopefully a good
>> starting point, and a nice reading ;-) ).
>>
>> Thanks!
>>
>> Best regards,
>>
>>
>
>
>   --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>
>
>


-- 
-Mysid

Re: Host scanning in IPv6 Networks

[Steven Bellovin]

Also see https://www.cs.columbia.edu/~smb/papers/v6worms.pdf
(Worm propagation strategies in an IPv6 Internet. ;login:, 
pages 70-76, February 2006.)

On Apr 20, 2012, at 3:08 50AM, Fernando Gont wrote:

> FYI
> 
>  Original Message 
> Subject: IPv6 host scanning in IPv6
> Date: Fri, 20 Apr 2012 03:57:48 -0300
> From: Fernando Gont 
> Organization: SI6 Networks
> To: IPv6 Hackers Mailing List 
> 
> Folks,
> 
> We've just published an IETF internet-draft about IPv6 host scanning
> attacks.
> 
> The aforementioned document is available at:
> 
> 
> The Abstract of the document is:
>  cut here 
>   IPv6 offers a much larger address space than that of its IPv4
>   counterpart.  The standard /64 IPv6 subnets can (in theory)
>   accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
>   much lower host density (#hosts/#addresses) than their IPv4
>   counterparts.  As a result, it is widely assumed that it would take a
>   tremendous effort to perform host scanning attacks against IPv6
>   networks, and therefore IPv6 host scanning attacks have long been
>   considered unfeasible.  This document analyzes the IPv6 address
>   configuration policies implemented in most popular IPv6 stacks, and
>   identifies a number of patterns in the resulting addresses lead to a
>   tremendous reduction in the host address search space, thus
>   dismantling the myth that IPv6 host scanning attacks are unfeasible.
>  cut here 
> 
> Any comments will be very welcome (note: this is a drafty initial
> version, with lots of stuff still to be added... but hopefully a good
> starting point, and a nice reading ;-) ).
> 
> Thanks!
> 
> Best regards,
> 
> 


--Steve Bellovin, https://www.cs.columbia.edu/~smb

The Cidr Report

[cidr-report]

This report has been generated at Fri Apr 20 21:12:51 2012 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
13-04-12408593  238754
14-04-12408628  238808
15-04-12408701  238734
16-04-12408688  238611
17-04-12408679  238737
18-04-12409045  238610
19-04-12409137  238827
20-04-12409267  238963


AS Summary
 40875  Number of ASes in routing system
 17083  Number of ASes announcing only one prefix
  3427  Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
  112041248  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').

 --- 20Apr12 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 409399   238997   17040241.6%   All ASes

AS6389  3427  198 322994.2%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS7029  3409 1784 162547.7%   WINDSTREAM - Windstream
   Communications Inc
AS4766  2497 1032 146558.7%   KIXS-AS-KR Korea Telecom
AS22773 1576  120 145692.4%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS18566 2091  705 138666.3%   COVAD - Covad Communications
   Co.
AS28573 1785  482 130373.0%   NET Servicos de Comunicao S.A.
AS2118  1304   14 129098.9%   RELCOM-AS OOO "NPO Relcom"
AS4323  1603  383 122076.1%   TWTC - tw telecom holdings,
   inc.
AS1785  1905  806 109957.7%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS4755  1587  543 104465.8%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS10620 1810  854  95652.8%   Telmex Colombia S.A.
AS7552  1170  220  95081.2%   VIETEL-AS-AP Vietel
   Corporation
AS7303  1363  440  92367.7%   Telecom Argentina S.A.
AS26615  902   32  87096.5%   Tim Celular S.A.
AS8151  1494  668  82655.3%   Uninet S.A. de C.V.
AS18101  947  163  78482.8%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS17908  826   60  76692.7%   TCISL Tata Communications
AS4808  1105  349  75668.4%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS9394   894  197  69778.0%   CRNET CHINA RAILWAY
   Internet(CRNET)
AS17974 1799 1102  69738.7%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS7545  1677  997  68040.5%   TPG-INTERNET-AP TPG Internet
   Pty Ltd
AS13977  762  125  63783.6%   CTELCO - FAIRPOINT
   COMMUNICATIONS, INC.
AS3356  1097  461  63658.0%   LEVEL3 Level 3 Communications
AS30036 1412  792  62043.9%   MEDIACOM-ENTERPRISE-BUSINESS -
   Mediacom Communications Corp
AS17676  688   76  61289.0%   GIGAINFRA Softbank BB Corp.
AS19262  996  401  59559.7%   VZGNI-TRANSIT - Verizon Online
   LLC
AS22561  989  406  58358.9%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS3549  1013  437  57656.9%   GBLX Global Crossing Ltd.
AS24560 1024  453  57155.8%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS4780   826  261  56568.4%   SEEDNET Digital United Inc.

Total  43978145612941766.9%   Top 30 total


Po

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 12-Apr-12 -to- 19-Apr-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS840252684  3.3%  31.4 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS982939059  2.5%  44.6 -- BSNL-NIB National Internet 
Backbone
 3 - AS12479   27357  1.7% 132.8 -- UNI2-AS France Telecom Espana SA
 4 - AS24186   25455  1.6% 454.6 -- RAILTEL-AS-IN RailTel 
Corporation of India Ltd., Internet Service Provider, New Delhi
 5 - AS32528   25445  1.6%   12722.5 -- ABBOTT Abbot Labs
 6 - AS597618740  1.2% 164.4 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 7 - AS580018194  1.1%  57.6 -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 8 - AS755216539  1.0%  13.1 -- VIETEL-AS-AP Vietel Corporation
 9 - AS24560   16017  1.0%  22.2 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
10 - AS15399   14025  0.9% 122.0 -- WANANCHI-KE
11 - AS54600   13078  0.8%4359.3 -- PEGTECHINC - PEG TECH INC
12 - AS16960   12901  0.8% 248.1 -- Cablevision Red, S.A de C.V.
13 - AS12396   12438  0.8% 460.7 -- INAR-ARKHNAGELSK-AS OJSC MegaFon
14 - AS671312426  0.8%  27.3 -- IAM-AS
15 - AS44798   11731  0.7%   11731.0 -- PERVOMAYSK-AS PP 
"SKS-Pervomaysk"
16 - AS786 10862  0.7%  54.0 -- JANET The JNT Association
17 - AS283069444  0.6% 277.8 -- TC Net Informática e 
Telecomunicações LTDA
18 - AS290499229  0.6%  22.1 -- DELTA-TELECOM-AS Delta Telecom 
LTD.
19 - AS2697 8991  0.6%  45.4 -- ERX-ERNET-AS Education and 
Research Network
20 - AS285738589  0.5%  10.4 -- NET Servicos de Comunicao S.A.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS32528   25445  1.6%   12722.5 -- ABBOTT Abbot Labs
 2 - AS44798   11731  0.7%   11731.0 -- PERVOMAYSK-AS PP 
"SKS-Pervomaysk"
 3 - AS54600   13078  0.8%4359.3 -- PEGTECHINC - PEG TECH INC
 4 - AS174083141  0.2%3141.0 -- ABOVE-AS-AP AboveNet 
Communications Taiwan
 5 - AS4658 1582  0.1%1582.0 -- NETFRONT-AS Netfront 
Information Technology Limited,
 6 - AS369801033  0.1%1033.0 -- JOHNHOLT-ASN
 7 - AS212711017  0.1%1017.0 -- SOTELMABGP
 8 - AS55665 947  0.1% 947.0 -- STMI-AS-ID PT Sampoerna 
Telemedia Indonesia
 9 - AS8657  780  0.1% 780.0 -- CPRM CPRM Autonomous System
10 - AS57767 747  0.1% 747.0 -- RTTC-AS Federal State-owned 
Enterprise Russian Television and Radio Broadcasting Network
11 - AS34043 726  0.1% 726.0 -- RISS Internet Security Systems 
SRL
12 - AS25600 688  0.0% 688.0 -- MATRIKON-1 - Matrikon Inc.
13 - AS27169 548  0.0% 548.0 -- TRIDENTAS - Trident Systems, 
Inc.
14 - AS388571020  0.1% 510.0 -- ESOFT-TRANSIT-AS-AP e.Soft 
Technologies Ltd.
15 - AS51825 932  0.1% 466.0 -- TELZAR-ASN TELZAR INTERNATIONAL 
TELECOMINICATIONS LTD
16 - AS12396   12438  0.8% 460.7 -- INAR-ARKHNAGELSK-AS OJSC MegaFon
17 - AS56094 920  0.1% 460.0 -- ITENET-SG 10 Dover Drive
18 - AS24029 455  0.0% 455.0 -- NIXI-IN-AS NIXI is an IXP in 
India
19 - AS24186   25455  1.6% 454.6 -- RAILTEL-AS-IN RailTel 
Corporation of India Ltd., Internet Service Provider, New Delhi
20 - AS57201 421  0.0% 421.0 -- EDF-AS Estonian Defence Forces


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 130.36.34.0/2412723  0.7%   AS32528 -- ABBOTT Abbot Labs
 2 - 130.36.35.0/2412722  0.7%   AS32528 -- ABBOTT Abbot Labs
 3 - 91.202.212.0/22   11731  0.7%   AS44798 -- PERVOMAYSK-AS PP 
"SKS-Pervomaysk"
 4 - 205.107.121.0/24   8935  0.5%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
 5 - 62.36.252.0/22 8013  0.5%   AS12479 -- UNI2-AS France Telecom Espana SA
 6 - 72.31.221.0/24 7137  0.4%   AS33363 -- BHN-TAMPA - BRIGHT HOUSE 
NETWORKS, LLC
 7 - 122.161.0.0/16 6970  0.4%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti 
Airtel Ltd., Telemedia Services
 8 - 62.36.249.0/24 6434  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 9 - 62.36.241.0/24 6065  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
10 - 62.36.210.0/24 5921  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
11 - 205.106.248.0/24   5896  0.3%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD 
Network Information Center
12 - 194.63.9.0/24  5891  0.3%   AS1273  -- CW Cable and Wireless Worldwide 
plc
13 - 199.180.100.0/23   4383  0.2%   AS54600 -- PEGTECHINC - PEG TECH INC
14 - 199.180.100.0/24   4348  0.2%   AS54600 -- PEGTECHINC - PEG TECH INC

Re: Host scanning in IPv6 Networks

[Scott Weeks]

>  Original Message 
> From: Fernando Gont 

> We've just published an IETF internet-draft about IPv6 host scanning
> attacks.


--- oscar.vi...@gmail.com wrote:
From: Tei 

It would be a very fast dictionary attack :D

accede
bade

feed



Just some Friday fun...

To find firewalls quickly, look for:

f0c:0ff

>;-)
scott

Re: Assymetric routing L3/VZ (FIOS)

[Christopher Morrow]

On Fri, Apr 20, 2012 at 3:09 PM, Deepak Jain  wrote:
>
> Is anyone else seeing this? DC - DFW back to DC? AFAIK, Verizon-GNI is a

why would GNI still be a customer 5 yrs on after GNI bought a transit
provider with worldwide reach? (uunet's network)

Assymetric routing L3/VZ (FIOS)

[Deepak Jain]

Is anyone else seeing this? DC - DFW back to DC? AFAIK, Verizon-GNI is a 
customer of L3, so no weird peering issues should be afoot. This adds 
about 40ms to the R/T time.  The path leaving Verizon-GNI (FIOS) goes 
(seemingly) DC-DC and has lower times (<5ms) unidirectionally.


Tracing the route to pool-173-79-242-218.washdc.fios.verizon.net 
(173.79.242.218  )


[...]

  3 ge-6-16.car1.Baltimore1.Level3.net (4.59.244.85) [AS 65518] 4 msec 
0 msec 4   msec
  4 ae-11-11.car2.Baltimore1.Level3.net (4.69.134.110) [AS 65518] 0 
msec 4 msec   0 msec
  5 ae-8-8.ebr2.Washington1.Level3.net (4.69.134.105) [AS 65518] 4 msec 
4 msec 4   msec

  6 ae-72-72.csw2.Washington1.Level3.net (4.69.134.150) [AS 65518] 4 msec
ae-82-82.csw3.Washington1.Level3.net (4.69.134.154) [AS 65518] 8 
msec 8 msec

  7 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) [AS 65518] 4 msec
ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) [AS 65518] 4 msec
ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) [AS 65518] 4 msec
  8 ae-2-2.ebr3.Atlanta2.Level3.net (4.69.132.85) [AS 65518] 16 msec 16 
msec 16   msec
  9 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) [AS 65518] 36 msec 36 
msec 36 m  sec

 10 ae-73-73.csw2.Dallas1.Level3.net (4.69.151.145) [AS 65518] 40 msec
ae-63-63.csw1.Dallas1.Level3.net (4.69.151.133) [AS 65518] 40 msec 
40 msec

 11 ae-4-90.edge2.Dallas3.Level3.net (4.69.145.204) [AS 65518] 44 msec
ae-3-80.edge2.Dallas3.Level3.net (4.69.145.140) [AS 65518] 36 msec
ae-1-60.edge2.Dallas3.Level3.net (4.69.145.12) [AS 65518] 36 msec
 12 MCI-level3-ae.dallas3.level3.net (4.68.62.34) [AS 65518] 36 msec
mci-level3-30g.dallas3.level3.net (4.68.62.166) [AS 65518] 36 msec
MCI-level3-ae.dallas3.level3.net (4.68.62.34) [AS 65518] 36 msec
 13 0.ge-0-0-0.DFW01-BB-RTR1.verizon-gni.net (152.63.2.146) [AS 65518] 
36 msec 3  6 msec

0.ae2.DFW01-BB-RTR2.verizon-gni.net (152.63.2.229) [AS 65518] 36 msec
 14  *  *  *


We're opening a ticket with them, but figured NANOG is an often better 
place for these resolutions.


Thanks in advance,

Deepak Jain
AiNET
Home of CyberNAP
www.ai.net

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 21 Apr, 2012

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

Analysis Summary


BGP routing table entries examined:  406332
Prefixes after maximum aggregation:  172729
Deaggregation factor:  2.35
Unique aggregates announced to Internet: 197504
Total ASes present in the Internet Routing Table: 40749
Prefixes per ASN:  9.97
Origin-only ASes present in the Internet Routing Table:   33074
Origin ASes announcing only one prefix:   15626
Transit ASes present in the Internet Routing Table:5448
Transit-only ASes present in the Internet Routing Table:136
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  64
Max AS path prepend of ASN ( 9902)   56
Prefixes from unregistered ASNs in the Routing Table:   391
Unregistered ASNs in the Routing Table: 128
Number of 32-bit ASNs allocated by the RIRs:   2611
Number of 32-bit ASNs visible in the Routing Table:2227
Prefixes from 32-bit ASNs in the Routing Table:5570
Special use prefixes present in the Routing Table:2
Prefixes being announced from unallocated address space:119
Number of addresses announced to Internet:   2538235344
Equivalent to 151 /8s, 74 /16s and 101 /24s
Percentage of available address space announced:   68.5
Percentage of allocated address space announced:   68.5
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   92.4
Total number of prefixes smaller than registry allocations:  173084

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:99600
Total APNIC prefixes after maximum aggregation:   32224
APNIC Deaggregation factor:3.09
Prefixes being announced from the APNIC address blocks:   96078
Unique aggregates announced from the APNIC address blocks:39691
APNIC Region origin ASes present in the Internet Routing Table:4681
APNIC Prefixes per ASN:   20.53
APNIC Region origin ASes announcing only one prefix:   1238
APNIC Region transit ASes present in the Internet Routing Table:729
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 20
Number of APNIC region 32-bit ASNs visible in the Routing Table:185
Number of APNIC addresses announced to Internet:  644102752
Equivalent to 38 /8s, 100 /16s and 58 /24s
Percentage of available APNIC address space announced: 81.7

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 131072-132095, 132096-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, 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:149874
Total ARIN prefixes after maximum aggregation:76295
ARIN Deaggregation factor: 1.96
Prefixes being announced from the ARIN address blocks:   121117
Unique aggregates announced from the ARIN address blocks: 50365
ARIN Region origin ASes present in the Internet Routing Table:15044
ARIN Prefixes per ASN: 8.05
ARIN Region origin ASes announcing only one prefix:5734
ARIN 

RE: Colocation in New York for a POP

[Dan Golding]

111 8th Avenue is probably your best choice for straight-up Internet
peering and transit. However, this largely depends on your traffic. If
you do a lot of long distance voice, for example, 60 Hudson can be a
better choice. There is also a good amount of peering at 165 Halsey in
NJ, right across the river. 
Whichever you choose - there is inexpensive transport between these
locations.

In a choice between Equinix and Telx, I think there are many factors to
choose from - price, level of customer service, contract length, ability
to expand, and facility quality. How you weigh these factors depends on
your own business. 

- Dan

As far as which specific pr

> From: Abdelkader Chikh Daho [mailto:achikhd...@iweb.com]
> 
> Hi,
> 
> Thanks a lot for all your inputs and feedback.
> My goal is to peer with a lot of networks especially ISPs. We are
> mainly
> a content provider. Tlex and Equinix seem to be the obvioius choice
for
> a neutral colocation facility. According to your experience, between
60
> Hudson and 111 8th Avenue, which one I should choose?
> 
> 
> Best regards,
> 
> Abdelkader Chikh Daho
> Network Architect
> iWeb Technologies
> Email : achikhd...@iweb.com
> Web : www.iweb.com
> Tel : 514-286-4242 ext 2309

Re: Colocation in New York for a POP

[Michael Costello]

On 04/20/2012 12:39 PM, Abdelkader Chikh Daho wrote:
> Hi,
> 
> Thanks a lot for all your inputs and feedback.
> My goal is to peer with a lot of networks especially ISPs. We are mainly
> a content provider. Tlex and Equinix seem to be the obvioius choice for
> a neutral colocation facility. According to your experience, between 60
> Hudson and 111 8th Avenue, which one I should choose?

I don't think anyone mentioned it yet, but there is also The Hub at 32
Sixth.

  http://www.thehubat32sixth.com/

I've only ever purchased transit from one provider there through another
and never colocated any equipment.  It's a beautiful building, by the way.

mc

Re: Colocation in New York for a POP

[Abdelkader Chikh Daho]

Hi,

Thanks a lot for all your inputs and feedback.
My goal is to peer with a lot of networks especially ISPs. We are mainly 
a content provider. Tlex and Equinix seem to be the obvioius choice for 
a neutral colocation facility. According to your experience, between 60 
Hudson and 111 8th Avenue, which one I should choose?



Best regards,

Abdelkader Chikh Daho
Network Architect
iWeb Technologies
Email : achikhd...@iweb.com
Web : www.iweb.com
Tel : 514-286-4242 ext 2309


On 19/04/2012 11:01 AM, Abdelkader Chikh Daho wrote:

Hi everyone,

Can some one please tell us what is the best Colo in New york to set 
up a POP (one cabinet) in order to get bandwidth, peering (NIIX, etc).


Best regards,

RE: Colocation in New York for a POP

[Pierce Lynch]

Interesting, I wasn't aware of that - thanks for the heads up! I knew 

Telx, 60 Hudson Street was consider to be an alternative to TH 25B at the time 
(approx 24 months ago), as mentioned by a few others in this thread.

Kind regards,

P.


-Original Message-
From: vinny_abe...@dell.com [vinny_abe...@dell.com]
Sent: 19 April 2012 21:14
To: Pierce Lynch; achikhd...@iweb.com
Cc: nanog@nanog.org
Subject: RE: Colocation in New York for a POP

The Telehouse 25 Broadway facility (last I heard) is currently planned to be 
shut down by somewhere around June 2013 if I remember correctly... so you'll 
want to keep that in mind. They have plenty of other options including a new 
facility and other existing ones as well as other colo providers in the area 
(Equinix, Telx, etc.). There are lots of choices. "Best" is relative to your 
specific requirements which is why there is competition. :)

-Vinny

Re: Host scanning in IPv6 Networks

[Owen DeLong]

>> 
> exec ?
> exceed ?
> 

Not a lot of x's in hexidecimal numbers outside of C-style formatting (0x).

IPv6 addresses are not generally notated in said style and certainly don't 
include said x in a suitable context for that to be part of a dictionary attack.

However, he also left out the common use of 7(t), 6/9(g), 1/7(I/L/T), 2(Z), 
5(S), and 0(O).

c is also often substituted for k (as in face:b00c).

Owen

Re: Host scanning in IPv6 Networks

[Steve Clark]

On 04/20/2012 08:17 AM, Tei wrote:

It would be a very fast dictionary attack :D

accede
bade
dad
decade
face
axed
babe
deaf
bed
Abe
bee
Decca
exec
fade
bead
bedded
deed
exceed
Abba
deface
efface
feed


On 20 April 2012 09:08, Fernando Gont  wrote:

FYI

 Original Message 
Subject: IPv6 host scanning in IPv6
Date: Fri, 20 Apr 2012 03:57:48 -0300
From: Fernando Gont
Organization: SI6 Networks
To: IPv6 Hackers Mailing List

Folks,

We've just published an IETF internet-draft about IPv6 host scanning
attacks.

The aforementioned document is available at:


The Abstract of the document is:
 cut here 
   IPv6 offers a much larger address space than that of its IPv4
   counterpart.  The standard /64 IPv6 subnets can (in theory)
   accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
   much lower host density (#hosts/#addresses) than their IPv4
   counterparts.  As a result, it is widely assumed that it would take a
   tremendous effort to perform host scanning attacks against IPv6
   networks, and therefore IPv6 host scanning attacks have long been
   considered unfeasible.  This document analyzes the IPv6 address
   configuration policies implemented in most popular IPv6 stacks, and
   identifies a number of patterns in the resulting addresses lead to a
   tremendous reduction in the host address search space, thus
   dismantling the myth that IPv6 host scanning attacks are unfeasible.
 cut here 

Any comments will be very welcome (note: this is a drafty initial
version, with lots of stuff still to be added... but hopefully a good
starting point, and a nice reading ;-) ).

Thanks!

Best regards,





exec ?
exceed ?


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com

[NANOG-announce] 2012 Postel Scholarship

[Betty Burke]

Colleagues:

On behalf of the North American Network Operators' Group (NANOG) and the
American Registry for Internet Numbers (ARIN), we would like to take this
opportunity to draw your attention to the 2012 Postel Network Operator's
Scholarship.

The Postel Network Operator's Scholarship targets personnel from developing
countries who are actively involved in Internet development, in any of the
following roles:

•Engineers (Network Builders)
•Operational and Infrastructure Support Personnel
•Educators and Trainers

This is not a postgraduate fellowship or academic scholarship.

Individuals may nominate themselves for the Scholarship via email or online
form. The Scholarship will be awarded annually to a recipient selected by a
committee comprising representatives from the NANOG Board of Directors and
the ARIN Board of Trustees. The selection committee will "whimsically"
select the annual recipient exclusively in response to the question: "What
Would Jon Do?" if he were asked to select a recipient.

The successful applicant will be provided with transportation to and from
the NANOG and ARIN joint meeting October 21-26, 2012, in Dallas, Texas,
USA, and a reasonable (local host standard) allowance for food and
accommodation. In addition, all fees for participation in both meetings'
events will be waived. The final grant size is determined according to
final costs and available funding. The chosen recipient will be advised at
least 2 months prior to the fall meeting date.

Applications from qualified individuals are now being accepted. The
deadline for application is June 1, 2012, and the awardees will be informed
by July 16, 2012.

Please read full information about the scholarship at:
http://www.nanog.org/scholarships/postel.php

Please pass along this information and encourage those interested to apply
by completing the web-based application form that is linked from the
information page.  Optionally, submissions are accepted via email PLAIN
ASCII in the BODY of the message, not as an attachment nor as a Word
document, PDF, or any other form, to postel...@nanog.org.
Please be sure to include the following:

• Full name and contact info
• Your brief biography, including current and recent jobs held
• A description of why you need and deserve this Scholarship to attend the
NANOG and ARIN meetings

• A description of how you plan to leverage your attendance at the meetings
in your work

• A brief abstract of a presentation you would give at the NANOG and/or
ARIN meetings, if selected as a Scholarship
winner


Kind regards,
 Steve Gibbard and Paul Vixie, on behalf of the Postel Scholarship
Selection Committee



-- 
Betty Burke
NANOG Executive Director
48377 Fremont Boulevard, Suite 117
Fremont, CA 94538
Tel: +1 510 492 4030
Office (810) 214-1218
___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Host scanning in IPv6 Networks

[Tei]

It would be a very fast dictionary attack :D

accede
bade
dad
decade
face
axed
babe
deaf
bed
Abe
bee
Decca
exec
fade
bead
bedded
deed
exceed
Abba
deface
efface
feed


On 20 April 2012 09:08, Fernando Gont  wrote:
> FYI
>
>  Original Message 
> Subject: IPv6 host scanning in IPv6
> Date: Fri, 20 Apr 2012 03:57:48 -0300
> From: Fernando Gont 
> Organization: SI6 Networks
> To: IPv6 Hackers Mailing List 
>
> Folks,
>
> We've just published an IETF internet-draft about IPv6 host scanning
> attacks.
>
> The aforementioned document is available at:
> 
>
> The Abstract of the document is:
>  cut here 
>   IPv6 offers a much larger address space than that of its IPv4
>   counterpart.  The standard /64 IPv6 subnets can (in theory)
>   accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
>   much lower host density (#hosts/#addresses) than their IPv4
>   counterparts.  As a result, it is widely assumed that it would take a
>   tremendous effort to perform host scanning attacks against IPv6
>   networks, and therefore IPv6 host scanning attacks have long been
>   considered unfeasible.  This document analyzes the IPv6 address
>   configuration policies implemented in most popular IPv6 stacks, and
>   identifies a number of patterns in the resulting addresses lead to a
>   tremendous reduction in the host address search space, thus
>   dismantling the myth that IPv6 host scanning attacks are unfeasible.
>  cut here 
>
> Any comments will be very welcome (note: this is a drafty initial
> version, with lots of stuff still to be added... but hopefully a good
> starting point, and a nice reading ;-) ).
>
> Thanks!
>
> Best regards,
>



-- 
--
ℱin del ℳensaje.

Fwd: Host scanning in IPv6 Networks

[Fernando Gont]

FYI

 Original Message 
Subject: IPv6 host scanning in IPv6
Date: Fri, 20 Apr 2012 03:57:48 -0300
From: Fernando Gont 
Organization: SI6 Networks
To: IPv6 Hackers Mailing List 

Folks,

We've just published an IETF internet-draft about IPv6 host scanning
attacks.

The aforementioned document is available at:


The Abstract of the document is:
 cut here 
   IPv6 offers a much larger address space than that of its IPv4
   counterpart.  The standard /64 IPv6 subnets can (in theory)
   accommodate approximately 1.844 * 10^19 hosts, thus resulting in a
   much lower host density (#hosts/#addresses) than their IPv4
   counterparts.  As a result, it is widely assumed that it would take a
   tremendous effort to perform host scanning attacks against IPv6
   networks, and therefore IPv6 host scanning attacks have long been
   considered unfeasible.  This document analyzes the IPv6 address
   configuration policies implemented in most popular IPv6 stacks, and
   identifies a number of patterns in the resulting addresses lead to a
   tremendous reduction in the host address search space, thus
   dismantling the myth that IPv6 host scanning attacks are unfeasible.
 cut here 

Any comments will be very welcome (note: this is a drafty initial
version, with lots of stuff still to be added... but hopefully a good
starting point, and a nice reading ;-) ).

Thanks!

Best regards,