[6bone] SUNET announcing ALL IPv6 routes

[John Fraizer]

On Wed, 14 Aug 2002, Jorgensen, Roger wrote:

> Jorgen,
> 
> It's not sunet, it's sics that use that ASN. www.sics.se.
> Check sics@whois.6bone.net.
> 
> Probably just borrowing the ASN from sunet. Here is what we
> saw before I shut down the peering: 
> http://www2.ipv6.chello.com/bogus/file0035.html
> Pretty bad?:)

OK.  I'm not trying to sound elitist here but, if an organization doesn't
have their OWN ASN, and the associated clue, why on earth would you risk
an open, no filtering, peering session with them?

I'm not saying that an organization having an ASN (their own) is equal to
an organization having clue but, it is more likely than not.

> But this is not the first time one ASN is announcing the entire sTLA/pTLA
> list. It has happend before and would probably happend again.
> Question is really, how are we suppose to filter this kind of things on
> a transit peering? Limited amount of prefixes we can accept from an AS?

If they don't have their own ASN, filter tightly.  If they screw up like
this, filter even more tightly.


If you accept transit from someone, prefix-list filter them like so:

 neighbor 3ffe:xxxx:xxxx:x::x activate
 neighbor 3ffe:xxxx:xxxx:x::x next-hop-self
 neighbor 3ffe:xxxx:xxxx:x::x prefix-list subTLA-only out
 neighbor 3ffe:xxxx:xxxx:x::x route-map AS-SOMEPEER in
!
ipv6 prefix-list AS-SOMEPEER seq 10 permit 3ffe:xxxx::/32
ipv6 prefix-list AS-SOMEPEER seq 20 permit 2001:xxxx::/32
ipv6 prefix-list subTLA-only seq 1 permit 3ffe:1ced::/32
ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24
ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32
ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28
ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16
ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35
ipv6 prefix-list subTLA-only seq 30 permit 2002::/16
ipv6 prefix-list subTLA-only seq 500 deny any
!
ip as-path access-list AS-SOMEPEER permit ^(_NNNNN)+$
!

route-map AS-SOMEPEER permit 10
 match ipv6 address prefix-list AS-SOMEPEER
 match ipv6 address prefix-list subTLA-only
 match as-path AS-SOMEPEER
!
route-map AS-SOMEPEER permit 20
 match ipv6 address prefix-list AS-SOMEPEER
 match as-path AS-SOMEPEER
 set community no-export additive
!
route-map AS-SOMEPEER deny 30
 match as-path AS-SOMEPEER
!
route-map AS-SOMEPEER permit 40
 match ipv6 address prefix-list subTLA-only
!


In the first route-map stanza, we accept their prefixes that are not more
specific than the allocation boundries, as long as they show their ASN as
the origin.

In the second route-map stanza, we accept any "more specifics" that we
might have put in their prefix-list, as long as they show their ASN as the
origin but, since we don't want to leak these more specifics to the global
tables, we tag them as no-export.

In the third route-map stanza, we deny anything else that they send us
that shows THEM as the origin.  This keeps them from announcing every
prefix on the planet with them as the origin (like the case we're
discussing).

In the fourth route-map stanza, we accept anything that has not been
denied (didn't match their prefix-list but, did match their origin) as
long as it is within the allocation boundries.  This will allow you to
accept transit from them (within the allocation boundries) but, won't
allow them to screw up like they did today.


Simple, huh?

I love problem solving!

Filter, filter, filter on both ingress and egress.



---
John Fraizer              | High-Security Datacenter Services |
EnterZone, Inc            | Dedicated circuits 64k - 155M OC3 |
http://www.enterzone.net/ | Virtual, Dedicated, Colocation    |