Re: [Fwd: FC: Email a RoadRunner address, get scanned by their
I got the following personal message from Mark Herrick of rr.com (which I'm passing along with his permission/request). I hope (and I think he hopes) that by passing it along, some questions can be answered and misunderstandings explained. In an additional message, he answered my question of how does rr.com security define 'network owner'? with the following URL. http://security.rr.com/subdelegation.htm So as long as space is swipped or documented in a publicly accessible rwhois server, if you're a contact for the IP block, you should be accepted as the 'network owner'. BTW...for the time being, rr.com has stopped SMTP relay testing and is focusing entirely on finding and blocking mail from open proxies that have been used to spam their customers. -- Forwarded message -- Date: Sun, 16 Mar 2003 12:56:30 -0500 From: W. Mark Herrick, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Your NANOG post Hi Jon, I was pointed to the thread on NANOG through another person, and I saw your post on the Merit website (below). As I'm not subscribed to NANOG, and unfortunately I am prohibited (from a time resource standpoint, not administratively) from subscribing to that list at this time, but I thought that I'd comment on your post specifically, since it touched on more than one area. If you are so included, feel free to pass this along to NANOG, with my regards. So, just to set one ground rule here - we're talking about proxy and relay testing, not full-out penetration testing. With that in mind... To directly answer your first paragraph, you are absolutely correct - we have absolutely NO objection to open proxy or relay scanning of IP addresses from a system that either: 1. Has spam in hand (a la MAPS RSS). 2. Has received a direct connection from our subscriber IP address or SMTP server (a la AOL, Outblaze). That being said, we have, and will continue to have, a severe issue with so-called 'scanning services', that *proactively* scan IP addresses (e.g., DSBL), or services that accept requests from anywhere to perform 'on-demand' scans (e.g., hatcheck.org) without first requiring (and keeping on hand) proof (e.g., spam-in-hand) that the IP address is a source of spam, open to third party relay, or has an open proxy service. At no time has Road Runner performed any PROACTIVE scanning on any IP address that does not belong to Road Runner. Furthermore, we perform no REACTIVE scanning unless it meets one of the above criteria, and in addition, regardless of whether or not there has EVER been an issue with the network, we will not REACTIVELY scan ANY IP address when there is a request from the *network owner* that we do not do so. We have no wish to be abusive, and as such, we limit scans of an IP to one per week. This is all clearly explained at http://security.rr.com. You brought up another issue, which I *think* may be pointing to an argument that I had with Ron Guilmette some time ago, when his service was performing relay scans on our IP space or some such. I am fairly certain that this argument took place because I viewed Ron's scans to be proactive in nature. Our stance on proactive scanning has not changed in the 5 years that I have been with Road Runner. Anyways, as far as your last statement - since the inception of our scanning initiative (1st week in January), we have identified over 50,000 open proxy servers. The problem is big, it's only getting bigger, and it's not going to go away, unfortunately. Best, Mark Herrick Director - Operations Security Road Runner
Re: [Fwd: FC: Email a RoadRunner address, get scanned by their
[EMAIL PROTECTED] wrote: -- Forwarded message -- Date: Sun, 16 Mar 2003 12:56:30 -0500 From: W. Mark Herrick, Jr. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Your NANOG post That being said, we have, and will continue to have, a severe issue with so-called 'scanning services', that *proactively* scan IP addresses (e.g., DSBL), or services that accept requests from anywhere to perform 'on-demand' scans (e.g., hatcheck.org) without first requiring (and keeping on hand) proof (e.g., spam-in-hand) that the IP address is a source of spam, open to third party relay, or has an open proxy service. In other words, it's okay for an ISP to scan systems so long as they receive a connection from the system without spam on hand. However, it is not okay for a 3rd party to do the same scan, despite the fact that using a 3rd party limits the number of scans performed by aggregating the results. Considering how much we complain about route aggregation, I'd think scan aggregation would have a higher interest. FireDaemon is becoming pretty popular after all. -- -Jack
APNIC returning 223/8 to IANA
Hi all, APNIC is in the process of handling back the 223/8 which we received from IANA in February 2003. Please see the email below for more information. Regards son Resources Services Manager [EMAIL PROTECTED] Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: [EMAIL PROTECTED] Please send Internet Resource Requests to [EMAIL PROTECTED] _ -- Forwarded message -- Date: Fri, 14 Mar 2003 10:55:25 +1000 (EST) From: John Tran [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Anne Lord [EMAIL PROTECTED] Subject: handback of 223/8 Dear Michelle, APNIC was allocated 223.255.255.0/8 by IANA on 12 February 2003. RFC3330.txt states that 223.255.255.0/24 is RESERVED. At this point in time, the reservation means that the network cannot be further assigned or allocated. The reservation of this network impacts the sparse allocation system used by APNIC for managing allocations, limiting the amount of potential aggregation. Furthermore, the status of RESERVED is potentially confusing for APNIC members, the majority of whom do not have English as a first language. APNIC therefore is returning this block to IANA and cordially requests that IANA delegate a block with no such reservation. APNIC regards the status of this address block as a matter for resolution by the IETF and IANA. Once the status has been finally resolved however, APNIC would be willing to receive this block in a future IANA allocation. Regards Son Resources Services Manager [EMAIL PROTECTED] Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: [EMAIL PROTECTED] Please send Internet Resource Requests to [EMAIL PROTECTED] _
Re: APNIC returning 223/8 to IANA
On Mon, 17 Mar 2003, John Tran wrote: Hi all, APNIC is in the process of handling back the 223/8 which we received from IANA in February 2003. Please see the email below for more information. Anybody else think IANA should tell APNIC to take what was issued and STFU? I mean, come on, you're want a different /8 because a single /24 at the very end was reserved? And you're trying to convince us that the intelligent people in the AP have no way of coming to grips with the concept of RESERVED? Hell, just allocate that single /24 back to IANA and nobody has to deal with the earth shattering difficulty of translating RESERVED. Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems. Andy Andy Dills 301-682-9972 Xecunet, LLCwww.xecu.net Dialup * Webhosting * E-Commerce * High-Speed Access
Re: APNIC returning 223/8 to IANA
On Mon, Mar 17, 2003 at 01:11:06AM -0500, Andy Dills wrote: Anybody else think IANA should tell APNIC to take what was issued and STFU? I mean, come on, you're want a different /8 because a single /24 at the very end was reserved? And you're trying to convince us that the intelligent people in the AP have no way of coming to grips with the concept of RESERVED? Hell, just allocate that single /24 back to IANA and nobody has to deal with the earth shattering difficulty of translating RESERVED. Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems. If APNIC doesn't want it, I'm sure I could find someone who does. :) Yes this is remarkably silly. What could possibly be broken by a reserved /24 out of a /8. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: APNIC returning 223/8 to IANA
On Mon, 17 Mar 2003, Andy Dills wrote: Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems. ARIN has dealt with the issue of RESERVED blocks within /8 allocations for years (and InterNIC, SRI-NIC, etc for a decade?). I guess 223/8 could be allocated to ARIN instead, if APNIC can't fix their database software to handle special use allocations. Or IETF could reserve the entire 223/8 for future special use allocations instead of the current practice of using whatever space was next in the queue when a new special use request is made. Otherwise, some RIR will have to deal with future RESERVATIONS within a /8 eventually. It seems a bit wasteful to reserve an entire /8 just because RIR's can't deal with RESERVED allocations, but I don't run an RIR so I don't know the capabilities of the database tracking systems.
Re: APNIC returning 223/8 to IANA
On Mon, Mar 17, 2003 at 01:24:52AM -0500, Richard A Steenbergen wrote: On Mon, Mar 17, 2003 at 01:11:06AM -0500, Andy Dills wrote: Anybody else think IANA should tell APNIC to take what was issued and STFU? I mean, come on, you're want a different /8 because a single /24 at the very end was reserved? And you're trying to convince us that the intelligent people in the AP have no way of coming to grips with the concept of RESERVED? Hell, just allocate that single /24 back to IANA and nobody has to deal with the earth shattering difficulty of translating RESERVED. Somebody has to deal with the issue of breaking the pretty aggregation due to the /24 at the end. Why does APNIC feel it shouldn't be them that must deal with this small problem? That region of the net certainly causes its share of problems. If APNIC doesn't want it, I'm sure I could find someone who does. :) Yes this is remarkably silly. What could possibly be broken by a reserved /24 out of a /8. You're missing the issue that when you are assigned space, if part of it is already reserved that should be clearly spelled out. When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me. - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: APNIC returning 223/8 to IANA
On Mon, 17 Mar 2003 01:31:08 EST, Jared Mauch said: When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me. I suppose IANA *could* refund 1/2**16'th of the price paid by APNIC. pgp0.pgp Description: PGP signature
Re: APNIC returning 223/8 to IANA
At 01:31 17/03/2003 -0500, Jared Mauch wrote: You're missing the issue that when you are assigned space, if part of it is already reserved that should be clearly spelled out. When you get a /8, you expect it to be fully usable. The APNIC posture here seems to make sense to me that its an issue that needs to be resolved. using one of the other currently reserved /8's while that issue plays out seems quite logical to me. Jared, you hit the nail on the head. Anyone who was at the APNIC Policy SIG meeting during APRICOT 2003 last month will have heard the fairly lengthy discussion around 223/8. While I don't agree that the block should be handed back as it makes a fairly substantial mountain out of what is a tiny molehill, several pointed out the above issue, that 223/8 is not fully usable, and that there is no documentation stating that 223.255.255.0/24 is actually usable. Or not usable. RFC3330 (informational) states what it used to be for, but the actual paragraph discussing 223.255.255.0/24 contradicts itself, and is of no help. My disappointment was that everyone who could solve, or at least take ownership of the problem was in the room at the time. That they chose not to was sad, much to the bewilderment of the attendees I spoke to afterwards. Had the problem been solved there and then, it would have demonstrated clear progress in improving RIR/IETF cooperation. And so the address space has been returned. :-( philip --
