Hi all,
About the talk "BGP Origin ASN Validation" from Roque Gagliano at SwiNOG #21 I talked afterwards with him with the following remark:
Roque showed a route-map like this one:
route-map foo seq 10 match invalid set local-preference 50 ! route-map foo seq 20 match incomplete set local-preference 100 ! route-map foo seq 30 match valid set local-preference 200 !
This will not fix the "youtube vs. Pakistan"-problem.
For example, youtube announces a /22, signed, gets local-pref 200. "Bad ISP" announces a /24 out of the /22, unsigned, gets local-pref 50, BUT gets into my routing table!
I think it whould by cool to have a system to prevent an *unsigned* prefix, which is more specific than a *signed* prefix, to be accepted.
Maybe this could be done in IOS Code, for example with the configuration option "do not allow an unsigned more specific prefix within a signed prefix".
This will allow us to configure the route-map as shown above and accept invalid/incomplete prefixes. But the accepted invalid/incomplete prefixes are not more specific than a signed prefix.
If someone does know more, please comment.
Cheers, Tim
Wouldn't that do it?
! route-map bar deny 10 match invalid !
Cheers, Viktor
On 15.11.2010 11:06, tim wrote:
Hi all,
About the talk "BGP Origin ASN Validation" from Roque Gagliano at SwiNOG #21 I talked afterwards with him with the following remark:
Roque showed a route-map like this one:
route-map foo seq 10 match invalid set local-preference 50 ! route-map foo seq 20 match incomplete set local-preference 100 ! route-map foo seq 30 match valid set local-preference 200 !
This will not fix the "youtube vs. Pakistan"-problem.
For example, youtube announces a /22, signed, gets local-pref 200. "Bad ISP" announces a /24 out of the /22, unsigned, gets local-pref 50, BUT gets into my routing table!
I think it whould by cool to have a system to prevent an *unsigned* prefix, which is more specific than a *signed* prefix, to be accepted.
Maybe this could be done in IOS Code, for example with the configuration option "do not allow an unsigned more specific prefix within a signed prefix".
This will allow us to configure the route-map as shown above and accept invalid/incomplete prefixes. But the accepted invalid/incomplete prefixes are not more specific than a signed prefix.
If someone does know more, please comment.
Cheers, Tim
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi Viktor,
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
When all of these starts rolling-out, you would have a huge percentage of "not-found", that is why you would not want to deny those. There you can see the importance of generating your ROAs, although you are not particularly interested in filtering.
Regards and thanks Tim for the catch,
Roque
On Mon, Nov 15, 2010 at 11:27 AM, Viktor Steinmann stony@stony.com wrote:
Wouldn't that do it?
! route-map bar deny 10 match invalid !
Cheers, Viktor
On 15.11.2010 11:06, tim wrote:
Hi all,
About the talk "BGP Origin ASN Validation" from Roque Gagliano at SwiNOG #21 I talked afterwards with him with the following remark:
Roque showed a route-map like this one:
route-map foo seq 10 match invalid set local-preference 50 ! route-map foo seq 20 match incomplete set local-preference 100 ! route-map foo seq 30 match valid set local-preference 200 !
This will not fix the "youtube vs. Pakistan"-problem.
For example, youtube announces a /22, signed, gets local-pref 200. "Bad ISP" announces a /24 out of the /22, unsigned, gets local-pref 50, BUT gets into my routing table!
I think it whould by cool to have a system to prevent an *unsigned* prefix, which is more specific than a *signed* prefix, to be accepted.
Maybe this could be done in IOS Code, for example with the configuration option "do not allow an unsigned more specific prefix within a signed prefix".
This will allow us to configure the route-map as shown above and accept invalid/incomplete prefixes. But the accepted invalid/incomplete prefixes are not more specific than a signed prefix.
If someone does know more, please comment.
Cheers, Tim
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Am 15.11.2010 12:39, schrieb Roque Gagliano:
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
When all of these starts rolling-out, you would have a huge percentage of "not-found", that is why you would not want to deny those. There you can see the importance of generating your ROAs, although you are not particularly interested in filtering.
While from a technical perspective the BGP Origin ASN Validation is a good approach, it loads a burden to the system itself and to the BGP engineers around the globe, just because Pakistan Telecom's network engineer is not capable to type 'set community no-export' and PCCW (Upstream of Pakistan Telecom) f***ed up the prefix list (copy-paste for other example, replace names).
Why should we change a generally good working system just because some network rookies don't know better? Fix the problem by the source, don't circumvent it.
My CHF 0.05, Fredy
On 15.11.2010 12:53 Fredy Kuenzler wrote
Why should we change a generally good working system just because some network rookies don't know better? Fix the problem by the source, don't circumvent it.
Because times are changing? I grew up in Internet _without_ firewalls. You perhaps would have argued the same in the early 1990's ...
The routing eco system is what air-traffic control is for aviation. And it has to be as safe and trustworthy imho. YMMV of course ...
Just my .02€, Arnold
On 2010-11-15 12:53, Fredy Kuenzler wrote: [..]
Why should we change a generally good working system just because some network rookies don't know better? Fix the problem by the source, don't circumvent it.
Because you can't trust remote networks?
RPSL would have fixed the PakistaniYoutube issue already btw as it would have filtered out the more specific announcement, unless they spoofed the source ASN, that is the IMHO only advantage that this RPKI trick gives you.
Another approach to all of this is to do off-line filtering and have a UI that allows you to approve changes in routes.
Thus you are running the system, all prefixes are accepted. Now somebody announces prefix A.B.C.D/24 from a path ending in "F G H". As your system did not see it yet two options: it is a more specific, in that case your system puts it on the 'to approve' list and does not accept it yet, or it is most specific, in that case your system puts it on the 'to check' list but does accept it.
The big issue of course is that you once have to approve/check 300k prefixes, but you can eliminate most of those with RPSL already today.
In combination with an RPKI which has BGP origin validation, the system has just an extra metric to state 'oh that is also a valid source ASN'.
Greets, Jeroen
Am Monday 15 November 2010 schrieb mir Roque Gagliano:
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
Does somebody at cisco try to build a standard from that filtering stuff mabye together with other player on the market or do we get another isolated application with some patents on top to deny implementations on other platforms than cisco?
Regards Oli
On 2010-11-15 13:05, Oliver Schad wrote:
Am Monday 15 November 2010 schrieb mir Roque Gagliano:
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
Does somebody at cisco try to build a standard from that filtering stuff mabye together with other player on the market or do we get another isolated application with some patents on top to deny implementations on other platforms than cisco?
The configuration might be different, the work and protocols come from the IETF, see the SIDR working group
And for instance: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-The_RPKI_Origin...
and http://www.netnod.se/presentations/netnodevent1002/20100217--18-netnod-rpki....
Which contains: https://subvert-rpki.hactrn.net/ which is even open source
google(BGP Origin ASN Validation) aka the subject for more details....
Thanks Roque for introducing folks to what is and has to come!
Greets, Jeroen
Am Monday 15 November 2010 schrieb mir Jeroen Massar:
On 2010-11-15 13:05, Oliver Schad wrote:
Am Monday 15 November 2010 schrieb mir Roque Gagliano:
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
Does somebody at cisco try to build a standard from that filtering stuff mabye together with other player on the market or do we get another isolated application with some patents on top to deny implementations on other platforms than cisco?
The configuration might be different, the work and protocols come from the IETF, see the SIDR working group
Thank you for the pointer.
Regards Oli
Thanks Jeroen,
Should add the standards references to the slides.
Roque
On Mon, Nov 15, 2010 at 1:16 PM, Jeroen Massar jeroen@unfix.org wrote:
On 2010-11-15 13:05, Oliver Schad wrote:
Am Monday 15 November 2010 schrieb mir Roque Gagliano:
I believe Tim has a point in this comment, we already analyze it positively internally to add that capability.
Does somebody at cisco try to build a standard from that filtering stuff mabye together with other player on the market or do we get another isolated application with some patents on top to deny implementations on other platforms than cisco?
The configuration might be different, the work and protocols come from the IETF, see the SIDR working group
And for instance: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-The_RPKI_Origin...
and http://www.netnod.se/presentations/netnodevent1002/20100217--18-netnod-rpki....
Which contains: https://subvert-rpki.hactrn.net/ which is even open source
google(BGP Origin ASN Validation) aka the subject for more details....
Thanks Roque for introducing folks to what is and has to come!
Greets, Jeroen
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
On 15 Nov 2010, at 10:27, Viktor Steinmann wrote:
Wouldn't that do it?
! route-map bar deny 10 match invalid
Hi,
Works *only* if you had a direct adjacency with the network being spoofed. If your upstream sends you a /22, and a spoofed /24, you can drop the spoofed /24, but as soon as you send the packet upstream, it will still end up with the spoofer.
Another argument in favour of being widely peered. :-)
Andy
-
Andy Davidson -
Arnold Nipper -
Fredy Kuenzler -
Jeroen Massar -
Oliver Schad -
Roque Gagliano -
tim -
Viktor Steinmann