You want to move things like gtld servers, yahoo/google (and other 'important' things), including
Do a deal with some porn hosters, they get 69.69.69.69 in exchange for advertising tons of free porn there on their next spam run - win/win brandon
this has been raised an issue before... but vanity ip address are a very very bad idea. joelja On Tue, 11 Mar 2003, Brandon Butterworth wrote:
You want to move things like gtld servers, yahoo/google (and other 'important' things), including
Do a deal with some porn hosters, they get 69.69.69.69 in exchange for advertising tons of free porn there on their next spam run - win/win
brandon
-- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary"
OK... I'm late to this discussion (been mostly ignoring it due to volume in other places), but, Sean's 911->855 mail makes me wonder... It seems to me that it would be relatively simple to solve this problem by doing the following: 1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE. 2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions: A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON. B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP. C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers. 3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers. Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date. Owen
At 05:16 PM 10-03-03 -0800, Owen DeLong wrote:
OK... I'm late to this discussion (been mostly ignoring it due to volume in other places), but, Sean's 911->855 mail makes me wonder...
It seems to me that it would be relatively simple to solve this problem by doing the following:
1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE.
2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions:
A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON.
B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP.
C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers.
3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers.
Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date.
As suggested, it has been discussed before. See: http://www.ripe.net/ripe/mail-archives/lir-wg/2002/msg00815.html Unfortunately, the answer I got from RIPE was that they will never do this. -Hank
Owen
On Mon, 10 Mar 2003, Owen DeLong wrote:
It seems to me that it would be relatively simple to solve this problem by doing the following:
1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE.
Why not just one or private/reserved?
2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions:
A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON.
B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP.
C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers.
Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy. Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS.
3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers.
How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!! Steve
Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date.
There are other ways that dont use BGP peering to create lists that are more suitable Steve
On Mon, 10 Mar 2003, Owen DeLong wrote:
It seems to me that it would be relatively simple to solve this problem by doing the following:
1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE.
Why not just one or private/reserved?
Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers.
2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions:
A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON.
B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP.
C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers.
Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy.
I think there are ways for the RIR to protect themselves from this.
Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS.
Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today.
3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers.
How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!!
Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with "all comers" and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil. Owen
Steve
Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date.
There are other ways that dont use BGP peering to create lists that are more suitable
Steve
participants (5)
-
brandon＠rd.bbc.co.uk -
Hank Nussbacher -
Joel Jaeggli -
Owen DeLong -
Stephen J. Wilcox