Re: Public shaming list for ISPs announcing other ISPs IP space by mistake

* Christian Koch · * Thu Aug 14 11:37:46 2008

apologies for the encrypted email, pgp acting up..
---

pardon my ignorance, as i may not have the experience _most_ of you do
in the  SP community..

but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services

if you are a new customer and you sign up for bgp, it is clearly
stated in the contract, the customer/provider requesting this service
must maintain objects radb..

in the install process, if the customer does not have radb objects,
bgp sessions remain shutdown until the provider verifies this and
generates filters with rpsl tool

same goes for peers.. if you don't require contracts as not all
networks do, just require irr /radb objects, this one may be more of a
pain, but thats why we go to scripts and automation..

maybe some more work would need to be done to ensure proper ownership
and delegation of number resources in radb, but i dont think that
would be so difficult, would it?

if larger networks adapted to something like this, i think people
would start to follow, as they would have no choice because  they
would be cut off from certain routes

christian

On Thu, Aug 14, 2008 at 11:34 AM, Christian Koch
<[email protected]> wrote:
> -----BEGIN PGP MESSAGE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: http://getfiregpg.org
>
> owFdVAtsFFUUbRdaZRIoQfkUxLzwaRHWbgtIC0RA8YNfsEBAIJTZmbe7r52ZN857
> s8tWgSIoUiqoAUUQlE8aAxYrgUpbqKCQEotSykeCKRLoR2qBQspXqN43uy3iJvub
> ue/cc849dz7q2inGFbtZH3r58It/SbFFnZd5E9OGp2WkD89IHT1iZPoon9/0Z3Hd
> fIFoeNLWKR+bsqVSA+lhRPwGtWRDwW4kM0SQLoeRQTkKyEGMeAAjPN/EFsFQgbJ0
> yngWoj4UpjZSqUQMpwRNnYIUquu2QXg4JUWSvDZ3o1AgjELU1lQjmSNGdcwDxPAj
> jeRg5KOWLmtaGFn4LZtYcF1SbMahyGIeE4tPDqwY4cyDuYI4jRCyZNWLqDcbK5wJ
> vjJKjiBgHRs8WQJcJI4DoKcdEHn9JmLYChIFM0kiEfayheG0gUOoo042VOcWA0+Q
> bQqS4qwbEY4IQ4qGZUsLS4zLHKsoql2hBjBVQK/zL4rlMS0aJCqACnqYcaEc9LN2
> IpIOlWA2MTi8OyQJfcLAKDgxoJmmIUAD7gyY+B5oAzPA7P64/uuOW4rIZoxQA4Cx
> 6IVYwOYqDYE8gxPNwepgGgTbfATwHJ5ghuTHBrZALEM+onEYCgoRHkCWyeAopZok
> MVnHyC9ItDvPUlIQaQ+ImHx0Ph1GOXMTlEGYZGAeolYOg1o3yhaWtJcTy0KeBwRF
> eFEDOxn1wheFOgijLJmgzY0gdVAjQwcneoKYCA5TLGJyRxGSbfBN5mAJ0JQkAAIc
> kc0ImOASySwkA2YMp+G+KnrCT2ww23IMg41A4CKoDRBTEsAq1rDfARaMDFv3OrNn
> 1LZgciIsQkuEIxGIgioxchzCUqSlQwWpxOcjiq2JDXIuEz7eSa0mW34A7bBMVmWT
> R0j+b7uEUZCVaAcTU1PD0R6QJ4uLIz6qaTTkLD2kILqpkRgZFCkBCiEFRopsM1hw
> UXKfpQIiqM+HfBbVkYItJ8IWtbnYLyVgEci7bEjwWu56rHNMrCsmPs4lHjsxUpfu
> 7U+p2pXdY75SFkw+sun0cy1fr8lM/nxYy8XqtsqB42d7PIfVYxcaugz+YntLQlLL
> kJwjeyuaTTm9sltXd9PBM32nHm1a96d747WaksYt+/6+caX+6oTzK0mBJOUdLFnU
> q/fD5rvo6MWGTzJLty8Z8PLc87HNavbapJrcn/tfdI2cdS63Z1v5zSmZcROWZyT0
> Oj33UlvtvYlLdi3Ox+xkuPX4zpl3d1c9m/HmjTv6zazc1Y2XTzTUlI1uXVx6+OSq
> 4s+qV2zdv35m0TjfvarypfUHnnu6esGovWOK59zZU53Xv++oc0m329K7zPhDrs3O
> rnlm4uC6hvz0D07FVaQeK/zuajCnZMSXiSvrfqnaOzmp6PrQ+cWDzu6c/cqR3AsD
> 4u9OOr79UM9riwt6lO7Zb259Ku/x0etKEwb3PacU9tbDtn0w0A03DfNuejVYeaso
> Z/rYK7OW5GZe/SF/w+59q6f1KziwZmBqn22tg25nTGupO3PiypyU4K45aYGCIWWP
> bk4oWVRc2Hxt16eb0/plNZsnvlk7fE1i2q1izyOX3rlZGfj2cn3F1NCCspcS/Xzc
> 6t/jY8sXxldU9yx86P15bzTX//jkoaE/uV6L37cjY9l7qQs7xbW2VpV5l45Z9XZt
> UfeJeuPrfda6zuaFq3L92+zG8tRt10/N80+/x71jd1yy19ecbdqy7vtFckz6zBnm
> 6X+S5i37sFeP5/NPbazb0Gnhiid8v/72Lw==
> =TITY
> -----END PGP MESSAGE-----
>
> On Thu, Aug 14, 2008 at 11:03 AM, Randy Bush <[email protected]> wrote:
>> ok, i can not hold my tongue.  sorry.
>>
>> might there be a formally rigorous approach to this problem?  we keep
>> having it.  perhaps there is something solid and real we could do, as
>> opposed to temp hack after temp hack.
>>
>> randy
>>
>>
>