Re: BCP 38 coverage if top x providers ...

[Florian Weimer]

* Laurent Dumont:

> Wouldn't you want BCP38 policies to be as close as possible to the 
> traffic sources? Instead of creating more "fake" traffic?

Maybe as close as possible, but still without sacrificing source
network attribution is sufficient.

> And at the same time, partial filtering doesn't seem as a very
> effective way to fight spoofed traffic on a large scale.

That depends on the problems caused by spoofed traffic.  My hunch is
that non-policing networks emit a constant trickle of spoofed traffic
which does not cause any problems, and that traffic can be used to
detect lack of policing even without actual abuse of the spoofing
capability.

Re: BCP 38 coverage if top x providers ...

[Laurent Dumont]

Wouldn't you want BCP38 policies to be as close as possible to the 
traffic sources? Instead of creating more "fake" traffic?


And at the same time, partial filtering doesn't seem as a very effective 
way to fight spoofed traffic on a large scale.


On 03/24/2017 11:07 AM, Florian Weimer wrote:

* Jared Mauch:


On Nov 19, 2016, at 9:13 PM, Frank Bulk  wrote:

My google fu is failing me, but I believe there was a NANOG posting a year
or two ago that mentioned that if the top x providers would
implement BCP 38
then y% of the traffic (or Internet) would be de-spoofed.  The point was
that we don't even need everyone to implement BCP 38, but if the largest
(transit?) providers did it, then UDP reflection attacks could be
minimized.

If someone can recall the key words in that posting and dig it up, that
would be much appreciated.

A double lookup of the packet is twice as expensive and perhaps
impractical in some (or many) cases.

Do you actually have to filter all packets?

Or could you just sample a subset and police the offenders, on the
assumption that if you don't implement an anti-spoofing policy, you
end up with near-constant leakage?

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,
MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

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 Mar, 2017

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

Analysis Summary


BGP routing table entries examined:  639326
Prefixes after maximum aggregation (per Origin AS):  249732
Deaggregation factor:  2.56
Unique aggregates announced (without unneeded subnets):  309219
Total ASes present in the Internet Routing Table: 56642
Prefixes per ASN: 11.29
Origin-only ASes present in the Internet Routing Table:   49032
Origin ASes announcing only one prefix:   21726
Transit ASes present in the Internet Routing Table:7610
Transit-only ASes present in the Internet Routing Table:213
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  41
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:75
Numnber of instances of unregistered ASNs:   76
Number of 32-bit ASNs allocated by the RIRs:  17833
Number of 32-bit ASNs visible in the Routing Table:   13867
Prefixes from 32-bit ASNs in the Routing Table:   56285
Number of bogon 32-bit ASNs visible in the Routing Table:46
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:412
Number of addresses announced to Internet:   2839257668
Equivalent to 169 /8s, 59 /16s and 162 /24s
Percentage of available address space announced:   76.7
Percentage of allocated address space announced:   76.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.5
Total number of prefixes smaller than registry allocations:  212171

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   175163
Total APNIC prefixes after maximum aggregation:   50255
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  174442
Unique aggregates announced from the APNIC address blocks:72098
APNIC Region origin ASes present in the Internet Routing Table:7950
APNIC Prefixes per ASN:   21.94
APNIC Region origin ASes announcing only one prefix:   2232
APNIC Region transit ASes present in the Internet Routing Table:   1126
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 41
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2789
Number of APNIC addresses announced to Internet:  762323332
Equivalent to 45 /8s, 112 /16s and 33 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
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:195124
Total ARIN prefixes after maximum aggregation:93482
ARIN Deaggregation factor: 2.09
Prefixes being announced from the ARIN address blocks:   197529
Unique aggregates announced from the ARIN address blocks: 90549
ARIN Region origin ASes present in the Internet Routing Table:17854
ARIN Prefixes per ASN:

Re: BCP 38 coverage if top x providers ...

[Florian Weimer]

* Jared Mauch:

>> On Nov 19, 2016, at 9:13 PM, Frank Bulk  wrote:
>> 
>> My google fu is failing me, but I believe there was a NANOG posting a year
>> or two ago that mentioned that if the top x providers would
>> implement BCP 38
>> then y% of the traffic (or Internet) would be de-spoofed.  The point was
>> that we don't even need everyone to implement BCP 38, but if the largest
>> (transit?) providers did it, then UDP reflection attacks could be
>> minimized.
>> 
>> If someone can recall the key words in that posting and dig it up, that
>> would be much appreciated.

> A double lookup of the packet is twice as expensive and perhaps
> impractical in some (or many) cases.

Do you actually have to filter all packets?

Or could you just sample a subset and police the offenders, on the
assumption that if you don't implement an anti-spoofing policy, you
end up with near-constant leakage?

Re: TRILL

[Donald Eastlake]

On Fri, Mar 24, 2017 at 8:46 AM,  wrote:
>
> Hi all!
>
> Can anybody recommend any good resources on TRILL? Particularly anything that 
> addresses do's and don'ts or any problems and pitfalls. Also any experiences 
> deploying and using TRILL in networks that anybody would like to share would 
> be welcome.

That might depend on your application and to some extent whose
equipment you are using.

You might want to contact the people at
http://www.six.sk/?lang=en= or SANET
https://www.infinera.com/how-sanet-created-a-different-kind-of-network-backbone-a-discussion-between-marian-durkovic-sanet-and-geoff-bennett-infinera/

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> For clarity, this is the TRILL I'm referring to:
> https://en.m.wikipedia.org/wiki/TRILL_(computing)
>
> Jared

TRILL

[nanog-isp]

Hi all!

Can anybody recommend any good resources on TRILL? Particularly anything that 
addresses do's and don'ts or any problems and pitfalls. Also any experiences 
deploying and using TRILL in networks that anybody would like to share would be 
welcome. 

For clarity, this is the TRILL I'm referring to:
https://en.m.wikipedia.org/wiki/TRILL_(computing)

Jared