- NANOG - lists.nanog.org

Re: [ncc-services-wg] RPKI Resource Certification: building features
by mkarir 04 Oct '10

04 Oct '10

Hi Alex, We are trying to tackle a similar problem with the RADB. The approach we have taken is to build into the object management web portal an alerting system that provides alerts to a user when there is a mismatch between what is in the IRR and what is observed in BGP. Right next to the alert will be a button that they can click on to "fix" their own IRR information or to flag an object as "conflict - needs review" to allow Merit to manually review and resolve conflicting IRR information. If it indeed is a hijack then they can take other steps. A second piece of this is a historical origin database we have built where we attempt to learn from history what a valid origin might be for a given prefix. Lots of complications here with moas and newly announced prefixes but some heuristics can help here. Once again this db becomes a source of validation information like the IRR database. Not for use in rejecting/accepting routes but for generating alerts that allow a user to fix/monitor their routing assets. So in both these cases we take what is reported in BGP and compare it with sources of possible validation and generates alerts for users on mismatches. The final piece of the puzzle which is a link with roa is something that we are still working on integrating into the RADB. The piece that is currently in place add roa-uri tag to irrd which allows a user to specify in the IRR a URI pointer to a roa for that prefix. Currently we dont use it in any validation. However we have a modified rpki-whois that at the end of the whois query will perform roa validation and tell the user whether the roa was valid or in in addition to the usual whois reponse. -manish On Oct 4, 2010, at 6:00 AM, routing-wg-request(a)ripe.net wrote: > > Message: 1 > From: Alex Band <alexb(a)ripe.net> > Date: Sun, 3 Oct 2010 19:08:33 +0200 > To: ncc-services-wg(a)ripe.net, > routing-wg(a)ripe.net > Subject: [routing-wg] RPKI Resource Certification: building features > > Most of the discussions around RPKI Resource Certification that have = > been held up to now have largely revolved around infrastructure and = > policy topics. I would like to move away from that here and discuss > what = > kind of value and which features can be offered with Certification > for = > network administrators around the world. Because in the end, the > goal is = > to make Internet routing more robust and create a more reliable > method = > for network operators to make routing decisions. > > We all know about the shortcomings of the IRR system and that just > half = > of all prefixes on the Internet have a route object associated with > them = > (http://bgpmon.net/blog/?p=3D140) However, it does mean that there > is = > ton of valuable information in the IRRs, whereas the Certification = > system needs to start from scratch. Based on many discussion I've > had = > with members and the Community, here is my idea for a Route Origin = > Authorisation** (ROA) wizard that retrieves IRR information, > compares it = > to real world routing and uses that for the creation of ROA = > Specifications. This has a number of benefits: > > - Network operators don't have to create their routing policy in the = > Certification system from scratch > - Because a comparison between is done the IRR and RIS = > (http://ripe.net/ris/) only accurate up-to-date information is > added to = > the Certification system > - The accuracy of the IRR is increased as a bonus, and is achieved = > without leaving the wizard > > Ideally, a network operator should be able to manage and publish > their = > routing policy =96 both for the IRR and Certification =96 from one = > single interface.=20 > > Here are the basic steps for the wizard after a certificate is = > generated: > > 1. Start ROA Wizard > > 2. Detect IRR information using the AS numbers in the Certificate, > like = > for example: > = > http://www.db.ripe.net/whois?searchtext=3DAS286&inverse_attributes=3Dorigi= > n&form_type=3Dsimple > > 3: Compare results with RIS using RRCC/Netsense, like for example: > http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=3DAS286 > > 4: Allow user to flag which ROA specifications they would actually > like = > to create, based on the IRR and RRCC/Netsense results. > > 5: Allow user to create additional ROA Specifications > > 6: Detect which maintainer is used for the route objects in the IRR > > 7: Allow user to specify maintainer password/pgp key, so all route = > objects are updated/removed/added based on the ROAs that were > created. = > This makes sure the data in the IRR and the Certification system is = > consistent.=20 > > 8: Save and publish ROAs and route objects > > Do you think there is value in creating a system like this? Are > there = > any glaring holes that I missed, or something that could be added? > I'm = > looking forward to your feedback. > > Alex Band > RIPE NCC > http://ripe.net/certification > > > ** The certification system largely revolves around three main > elements: = > (1) the Certificate, that offers validated proof of holdership of an = > Internet Resource, (2) the Route Orgin Authorisation Object (ROA), a = > standardised document that states that the holder of a certain > prefix = > authorises a particular AS to announce that prefix and (3) the = > Validator, which relying parties, i.e. your peers, can use to > validate = > certificates and ROAs.= > >

1 0

Re: [ncc-services-wg] RPKI Resource Certification: building features
by Owen DeLong 04 Oct '10

04 Oct '10

>> >> No... I'm saying that if ISPs aren't the only entities that hold their >> private keys, then they aren't the only entities that can sign their >> resources. > > The hosted system that we created uses Hardware Signing Modules (HSM) > for generating keys and signing operations. By design it is impossible > to retrieve the private keys. Any process or feature that would involve > the transferral of keys cannot be implemented. > In other words, not only do you hold the resource holders private key, but, they do not. This means that the ability to sign their resources is 100% under your control and 0% under their control except to the extent that you allow it. While I'm not accusing RIPE of nefarious conduct and do not believe that there is any malicious intent in the system, I do believe that it is a security model that any rational provider would likely consider untenable. The fact that you cannot retrieve the key is of little relevance, since you have full use of the key without retrieving it. > Access to the *use* of the keys is a different thing though. This is > controlled by the software. Although we cannot extract the keys, we can > instruct the HSM to create a new key, or use an existing key to sign > something. > Exactly... > Our hosted software controls all (activated) hosted member certificate > authorities. The process has potential access to the *use* of *all* keys > in the system. However, other security layers are implemented to ensure > that for a given LIR only those users that have the 'certification' > group enabled are *authorised* to use the hosted system -- and thereby > the applicable keys. > But by the very nature, the administrators of the system have the ability to make themselves members of the certification group. While I'm not saying that I think RIPE would do such a thing, the reality is that using this hosted solution is placing a tremendous amount of trust in the system and the administrators of the system. I have no problem with LIRs that choose to do this, so long as they are making an informed decision and understand the risks. I think the risks have been substantially down-played. >> >> If you choose to delegate the CA role for signing your resources >> to someone else, then, obviously, you have to give them a valid >> private key with which to sign those resources. >> > > > Given this setup a member can authorise any person to use the system by > creating an LIR Portal account for them and enabling the certification > group. Only the LIR's admin user can do this. > Really? There's no way for any member of RIPE staff to make corrections to an LIR's admin account such that it would be possible to bypass this? I tend to doubt that any sustainable system could be built in such a manner. Again, I am not accusing RIPE of doing so, but, pointing out that for such a hosted solution to remain functional over time, there must be certain compromises in the trust model. These compromises should at least give one pause and be carefully considered prior to handing over that level of trust. >> However, in doing that, you've created a situation where your >> signature is now much easier to forge. Kind of like automatic >> signing machines for checks. Benefit: The accounting department >> can sign thousands of checks and the CFO doesn't have to. >> Draw-back... The accounting department can sign thousands of >> checks without the CFO knowing they did so. >> > > The current system has an audit history page that shows all the commands > executed by users. It includes details like the name of the user, the > time of the change and further details: e.g. in case of the modification > of a ROA specification the complete new specification is visible in the > history. > So at least if someone does something horrible, assuming the system integrity is not compromised in the process, we can tell what happened and either who did it, or, at least who they chose to impersonate. That's good, but, by itself it is not enough. > There is currently no additional notification mechanism implemented but > that would be fairly trivial to add if there is a demand. > That would be a good additional safety feature. > > Non-hosted: > ===== > > Of course we put a lot of effort into maintaining security and quality > of the implementation we built. But we can well imagine that for some > people it is a matter of principle that they want full local access to > their own private keys and important configuration objects such as ROAs > -- and don't want to be hosted on a shared system outside of their > control. Other members may not mind so much about this and choose to > trust and use the hosted services. > Exactly my point... Such a choice should be an informed decision and if it is not a matter of choice made by the organization holding the resource (as is currently the case), then, there are issues. > There is standard that is close to completion in the SIDR WG in the IETF > that defines a protocol by which a parent and child Certificate > Authority can communicate. > > http://tools.ietf.org/html/draft-ietf-sidr-rescerts-provisioning-06 > Which is a major step forward in this area. > In our case the RIPE NCC system could function as the parent CA for a > non-hosted LIR child CA. The LIR can then deploy anything they see fit > themselves. They would have full access to their own private keys and > everything else in their system and can delegate as they see fit. And > add new features of course. > Another alternative in the meantime would be for the resource holder to maintain their private key and have transactions accomplished through a CSR process, but, obviously, this comes with a different set of tradeoffs, not the least of which is a certain amount of manual and mechanical complexity. > But.. > 1) We have not implemented support for this yet. We plan to go live with > the fully hosted version first and extend it with support for non-hosted > systems around Q2/Q3 2011. > > 2) It can take considerable effort for LIRs to set up their own > non-hosted solution from scratch. We know that ISC is developing an open > source solution (rpkid) that may be useful for LIRs that want to run > their own instance. From our side we will make sure that we test > interoperation with this system when we implement this protocol in our > system. > I think that's a good plan. However, Randy's criticisms of the hosted solution are not without merit. While I am glad to see that the RIPE hosted solution is not such a scheme, my comments were based on the fact that other schemes I have seen for other certificate systems involved the user holding their private key after it was given to them by the hosted system. Such a system would obviously the worst of all worlds from a security standpoint. Owen

1 0

Re: [ncc-services-wg] RPKI Resource Certification: building features
by Owen DeLong 04 Oct '10

04 Oct '10

> >> I'll go a step further and say that the resource holder should be >> the ONLY holder of the private key for their resources. >> >> Owen > > If you're saying that ISPs can only participate in an RPKI scheme if they > run their own Certificate Authority, then I think that would practically > ruin the chances of Certification actually ever taking off on a large > scale. > > -Alex No... I'm saying that if ISPs aren't the only entities that hold their private keys, then they aren't the only entities that can sign their resources. If you choose to delegate the CA role for signing your resources to someone else, then, obviously, you have to give them a valid private key with which to sign those resources. However, in doing that, you've created a situation where your signature is now much easier to forge. Kind of like automatic signing machines for checks. Benefit: The accounting department can sign thousands of checks and the CFO doesn't have to. Draw-back... The accounting department can sign thousands of checks without the CFO knowing they did so. Owen

1 0

RPKI Resource Certification: building features
by Alex Band 04 Oct '10

04 Oct '10

Most of the discussions around RPKI Resource Certification that have been held up to now have largely revolved around infrastructure and policy topics. I would like to move away from that here and discuss what kind of value and which features can be offered with Certification for network administrators around the world. Because in the end, the goal is to make Internet routing more robust and create a more reliable method for network operators to make routing decisions. We all know about the shortcomings of the IRR system and that just half of all prefixes on the Internet have a route object associated with them (http://bgpmon.net/blog/?p=140) However, it does mean that there is ton of valuable information in the IRRs, whereas the Certification system needs to start from scratch. Based on many discussion I've had with members and the Community, here is my idea for a Route Origin Authorisation** (ROA) wizard that retrieves IRR information, compares it to real world routing and uses that for the creation of ROA Specifications. This has a number of benefits: - Network operators don't have to create their routing policy in the Certification system from scratch - Because a comparison between is done the IRR and RIS (http://ripe.net/ris/) only accurate up-to-date information is added to the Certification system - The accuracy of the IRR is increased as a bonus, and is achieved without leaving the wizard Ideally, a network operator should be able to manage and publish their routing policy – both for the IRR and Certification – from one single interface. Here are the basic steps for the wizard after a certificate is generated: 1. Start ROA Wizard 2. Detect IRR information using the AS numbers in the Certificate, like for example: http://www.db.ripe.net/whois?searchtext=AS286&inverse_attributes=origin&for… 3: Compare results with RIS using RRCC/Netsense, like for example: http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286 4: Allow user to flag which ROA specifications they would actually like to create, based on the IRR and RRCC/Netsense results. 5: Allow user to create additional ROA Specifications 6: Detect which maintainer is used for the route objects in the IRR 7: Allow user to specify maintainer password/pgp key, so all route objects are updated/removed/added based on the ROAs that were created. This makes sure the data in the IRR and the Certification system is consistent. 8: Save and publish ROAs and route objects Do you think there is value in creating a system like this? Are there any glaring holes that I missed, or something that could be added? I'm looking forward to your feedback. Alex Band RIPE NCC http://ripe.net/certification ** The certification system largely revolves around three main elements: (1) the Certificate, that offers validated proof of holdership of an Internet Resource, (2) the Route Orgin Authorisation Object (ROA), a standardised document that states that the holder of a certain prefix authorises a particular AS to announce that prefix and (3) the Validator, which relying parties, i.e. your peers, can use to validate certificates and ROAs.

1 2

Re: [ncc-services-wg] RPKI Resource Certification: building features
by Randy Bush 04 Oct '10

04 Oct '10

> Do you think there is value in creating a system like this? yes. though, given issues of errors and deliberate falsifications, i am not entirely comfortable with the whois/bgp combo being considered formally authoritative. but we have to do something. > Are there any glaring holes that I missed yes. the operator should be able to hold the private key to their certificate(s) or the meaning of 'private key' and the security structure of the [ripe part of the] rpki is a broken. randy

3 2

Request for participation - Arbor 2010 Worldwide Infrastructure Security Report.
by Dobbins, Roland 04 Oct '10

04 Oct '10

Request for participation - Arbor 2010 Worldwide Infrastructure Security Report. ----- Folks, We're in the process of collecting feedback for the 2010 Worldwide Infrastructure Security Report (WWISR); this is the Sixth Edition of the report, and we'd really be grateful for your participation! This is the only security-focused survey we're aware of which is specifically oriented towards those who design, build, operate, and defend public-facing network infrastructure/applications/services, and provides the opportunity to share your experiences and perspectives with your peers in the operational community, as well as to benefit from their experiences and perspectives. The 2010 Infrastructure Security Survey is up and available for your input. You can register to complete the survey via this URL, which will redirect your browser to the survey tool (the survey is accessed via http/s): <http://www.arbornetworks.com/survey/ISR2010> Once again, we've added several insightful questions from past participants. Feedback collection will end as soon as we've reached the desired number of respondents (ideally, 100+). The results will be published in the 2010 Worldwide Infrastructure Security Report in January of 2011. Also, please note that NO personally- or organizationally-identifiable information will be shared in any manner. The 2009 edition of the survey is available here (registration required): <http://www.arbornetworks.com/report> Thanks in advance! ----- ----------------------------------------------------------------------- Roland Dobbins <rdobbins(a)arbor.net> // <http://www.arbornetworks.com> Sell your computer and buy a guitar.

1 0

closing 'lazy mans NW research"
by bmanning＠vacation.karoshi.com 03 Oct '10

03 Oct '10

I ask: On Wed, Sep 29, 2010 at 5:47 PM, <bmanning(a)vacation.karoshi.com> wrote: > i find myself in need of a multiport (8-16) 1 Gig ethernet HUB. > or a switch smart enough to do transparant port mirroring to at least > four ports. and the following suggestions were made: http://www.datacomsystems.com/products/details.asp?prod=5&itm=1&cat=3 http://www.dual-comm.com/gigabit_port-mirroring-LAN_switch.htm http://www.netoptics.com/products/product_family_details.asp?cid=1&pid=54&S… ftp://ftp2.zyxel.com/GS-1524/user_guide/GS-1524_1.12_Ed2.pdf Of these, it looks like the datacomsystems.com tap will be a good fit. --bill

1 0

Re: NEVERMIND! (was: ARIN Fraud Reporting Form ... )
by John Curran 03 Oct '10

03 Oct '10

On Oct 3, 2010, at 7:24 AM, "Ronald F. Guilmette" <rfg(a)tristatelogic.com> wrote: > I'm sitting here looking at your NRPM 3.6 and it says: > > Unresponsive POC email addresses shall be marked as such in the database. > > OK, Fine. So do you have a problem with ``marking those in the data base'' > and specifically within the associated AS and IP block records? And if so why? There is no problem with also marking resource records which have no valid POC's (even if not specifically stated by policy). It is an operational question not a resource policy question, and we generally handle those by informing the community of the plans to change practices through the ARIN consultation and suggestion process (https://www.arin.net/participate/acsp/index.html) > And if you have a problem with that, they please explain when and why you > suddenly developed a problem with it, because clearly ARIN _was_ doing this > before, at some point. (And it sure looks like you are NOT doing it now.) > > I'd really like to know when and why ARIN stopped putting these annotations > into the AS and IP block records associated with un-contactable POCs. > > Can you just answer me that? I mean, you know, without directing my > attention to some document which also doesn't answer the question? Amazingly, you are my customer; i.e. I do indeed work for you and the rest of the community. So, I'm happy to try and address your questions (even if at times it appears more of an inquisition than constructive engagement...) The ARIN staff has been putting those notations in manually for net blocks which lack valid contacts, but doing so is not required by policy and has been resource intensive since the contact verification portion was manual. We are now looking (as a result of your fine suggestion) at automating this process of marking resource blocks with no valid contacts as an inherent part of the new automated POC verification process. /John John Curran President & CEO ARIN

2 1

AS14202 - 'jacked routes... Whoa! This is just getting silly now!
by Ronald F. Guilmette 03 Oct '10

03 Oct '10

Somebody else on another mailing list I'm on actually found the following new 'jacking incident. Count 'em... one hundred and eighty three (183) separate jacked blocks. I can't take any credit. I wanted to include, in this posting, the name of the guy who actually found this stuff, and give him full credit for finding this, but he's asked me not to. These announcements may not be around very long. We'll see. Regards, rfg P.S. If ARIN actually does want to clean up and reclaim old abandoned blocks... well... it would appear that some nice helpful fellow has already catefully surveyed both 204/8 and 205/8 for such things, on their behalf. See below. AS14202: 198.153.0.0/21 199.5.152.0/23 199.253.192.0/21 200.1.184.0/21 200.4.32.0/20 200.41.240.0/22 204.17.128.0/23 204.17.250.0/23 204.17.252.0/23 204.19.124.0/23 204.19.126.0/23 204.19.132.0/23 204.19.180.0/22 204.19.226.0/23 204.19.234.0/23 204.52.148.0/22 204.57.8.0/21 204.57.16.0/20 204.58.132.0/23 204.58.250.0/23 204.58.252.0/23 204.61.16.0/21 204.61.24.0/22 204.61.28.0/23 204.62.148.0/23 204.62.168.0/23 204.63.144.0/21 204.63.152.0/21 204.63.168.0/22 204.63.172.0/23 204.68.232.0/23 204.75.148.0/23 204.75.240.0/23 204.76.16.0/21 204.76.24.0/22 204.76.158.0/23 204.76.160.0/22 204.76.164.0/23 204.76.198.0/23 204.76.200.0/23 204.76.214.0/23 204.76.216.0/22 204.76.230.0/23 204.76.232.0/22 204.76.236.0/23 204.76.246.0/23 204.76.248.0/22 204.76.252.0/23 204.79.130.0/23 204.80.66.0/23 204.80.68.0/22 204.80.72.0/21 204.80.80.0/22 204.80.84.0/23 204.86.0.0/21 204.86.8.0/22 204.86.104.0/21 204.86.112.0/22 204.89.0.0/21 204.89.134.0/23 204.110.184.0/23 204.115.136.0/21 204.124.4.0/22 204.124.68.0/22 204.124.72.0/22 204.124.76.0/22 204.126.180.0/23 204.126.184.0/23 204.126.244.0/23 204.147.192.0/21 204.152.16.0/23 204.152.36.0/23 204.152.52.0/23 204.152.72.0/23 204.152.120.0/23 204.152.122.0/23 204.152.136.0/23 204.152.160.0/22 204.152.164.0/23 204.153.164.0/22 204.153.180.0/22 204.153.224.0/22 204.174.48.0/23 204.174.52.0/23 204.174.76.0/22 204.174.204.0/23 204.187.50.0/23 204.187.52.0/23 204.187.96.0/23 204.187.106.0/23 204.187.108.0/22 204.187.112.0/22 204.187.116.0/23 204.194.16.0/22 204.194.48.0/21 204.194.192.0/21 204.194.200.0/22 204.194.208.0/22 204.194.216.0/22 204.194.220.0/23 204.209.30.0/23 204.209.86.0/23 204.225.184.0/23 204.225.226.0/23 204.225.234.0/23 204.231.242.0/23 204.231.244.0/23 204.239.126.0/23 204.239.176.0/23 204.239.192.0/23 204.239.200.0/23 205.132.88.0/22 205.132.92.0/23 205.132.136.0/21 205.132.152.0/21 205.142.4.0/23 205.142.32.0/22 205.142.40.0/22 205.142.68.0/22 205.142.84.0/22 205.142.132.0/22 205.142.136.0/22 205.142.140.0/22 205.142.144.0/22 205.142.160.0/22 205.142.204.0/22 205.142.208.0/22 205.142.212.0/22 205.143.8.0/21 205.143.56.0/21 205.153.4.0/22 205.153.32.0/22 205.153.72.0/22 205.153.108.0/22 205.153.124.0/22 205.153.132.0/22 205.153.164.0/22 205.153.168.0/22 205.153.184.0/22 205.153.200.0/22 205.153.216.0/22 205.153.252.0/22 205.167.12.0/23 205.167.20.0/23 205.167.32.0/23 205.167.38.0/23 205.167.50.0/23 205.167.66.0/23 205.167.72.0/23 205.167.82.0/23 205.167.98.0/23 205.167.112.0/23 205.167.160.0/23 205.167.172.0/23 205.167.178.0/23 205.167.190.0/23 205.167.194.0/23 205.167.204.0/23 205.167.228.0/23 205.167.236.0/23 205.167.246.0/23 205.172.32.0/22 205.172.36.0/22 205.172.116.0/22 205.172.120.0/21 205.172.128.0/22 205.172.140.0/22 205.172.152.0/22 205.172.176.0/22 205.172.244.0/22 205.172.252.0/22 205.173.184.0/21 205.189.74.0/23 205.189.78.0/23 205.189.118.0/23 205.189.120.0/23 205.189.222.0/23 205.189.224.0/23 206.53.128.0/21 206.82.96.0/21 206.208.72.0/21 206.220.0.0/22 207.45.96.0/21

3 2

ARIN Fraud Reporting Form ... Don't waste your time
by Ronald F. Guilmette 03 Oct '10

03 Oct '10

So ARIN put up on their web site this fancy schmancy web form that allows a person to report fraud relating to ARIN number resources. Here's what the introduction to that page says, exactly as it appears on ARIN's web site: This reporting process is to be used to notify ARIN of suspected Internet number resource abuse including the submission of falsified utilization or organization information, unauthorized changes to data in ARIN's WHOIS, hijacking of number resources in ARIN's database, or fraudulent transfers. Well, that's what it says anyway. And being naive, I actually believed that the folks at ARIN might actually give a rat's ass about all these kinds of fraud that they have enumerated above. Boy was I wrong! I just received the response attached below to one of my earlier reports using that form. And I gotta tell you, its an eye opener. Apparently the fine folks at ARIN, clever bureaucrats that they are, have subtly but substantially redefined the specific kinds of ``fraud'' they care to hear about and/or investigate, so that contrary to the above, mere hijacking of ASes or IP blocks isn't actually something that they want to hear about, much less DO anything about. Nope! Apparently, ARIN's fraud reporting form is only to be used for reporting cases where somebody has fiddled one of ARIN's whois records in a fradulent way. If somebody just waltzes in and starts announcing a bunch of routes to a bunch of hijacked IP space from a hijacked ASN (or two, or three) ARIN doesn't want to hear about it. In those rare cases where the perp is considerate enough to ALSO fiddle the relevant WHOIS records in some fradulent way, THEN (apparently) ARIN will get involved, but only to the extent of re-jiggering the WHOIS record(s). Once that's been done, they will happily leave the perp to announce all of the fradulent routes and hijacked space he wants, in perpetuity. Apparently, they consider the hijacking itself as being totally out of their charter to even look at or investigate. ONLY if a WHOIS record has been fiddled will they give a damn, and then the only one thing they will give a damn about will be the WHOIS record... and the rest of the net can go to hell, because hay! Not our problem man! Now I _know_ full well that by posting this rant here, the usual assortment of knuckle-walker throwbacks who still yearn for the wonderful rule-less frontier every-man-for-himself-and-no-sherrifs fun filled days of the old 20th Century Internet, will pipe up immediately and say `Good! Goddammit we don't want no steekin' ARIN to be ``policing'' anything at all. F**k that! Total anarchy is the best of all possible systems.' You know what? I don't care. Let them come. Let them lumber around and scream and pound their fists and try to tell me that because *I* didn't get onto the Internet until 1983 (or because their router can beat up my router) that they somehow magically outrank me, and that their opinions are God and mine are worthless. That's quite obviously horse shit. How do you have a pecking order anyway in a self-avowed anarchy? Sorry, no. The two are not compatible. I've got as much right to an opinion as you do. And until proved otherwise, mine is as valid as your's. And my opinion is that this sucks. ARIN's attitude sucks. And they are apparently redefining the word ``fraud'' in a way that will insure that they will have to do minimal work, and that they'll never ever have to do anything that might be ``hard'' in the sense of possibly being the lest bit contro- versial, you know, like telling some hijacker ``Stop doing that.'' Yes, I'm sure that there are a lot of people here who will pipe up and say that it's just wonderful that ARIN is useless and that ARIN will do nothing. Their anachronistic anarchist philosophy is not a philosophy. It's merely an abdication of responsibility, and should be seen as such. It is just a lazy man's way of avoiding having to think about how a society should be organized. It is the coward's way of avoiding making rules that some members of the group might find controversial. On the net, hijacking of IP space is just about the deepest kind of violation of the commonly accepted rules of how to behave in this shared space that I can imagine. And now, the people who _issue_ the IP space assignments say that they don't care to _police_ the very assignments that they themselves have made! Well then what's the bleeping point of even having them or their whole bloody allocation system then? I say let's disband the Federal Reserve *and* ARIN, because they are all just a bunch of useless bureaucrats at this point who are serving nobody other than themselves. If we are going to have anarchy, then bring it on! Let's not have this half-assed sort of anarchy that we have now. Let's have the real thing! I'm going out tomorrow and I'm going to buy me the biggest router than I can afford. Then I'm going to get it colocated someplace, and then I'm going to start announcing all the routes I feel like, and nobody will do shit about it... because its not their job man! And some people still wonder why this planet is so f**ked up. Geeezzz. Regards, rfg P.S. It ain't as if I'm either asking or expecting anybody from ARIN to take a plane out to that place where the hunters shot down that cable, or some exchange point in Bumf**k, Idaho, and with guns drawn, physically pull the wire out of the socket. No. I'm *not* asking for that kind of ``policing''. But Christ! They could at least take a position, instead of simply standing around with their hands in their pockets. Is that really too much to ask? They could say, to everyone involved, and to the community as a whole, ``This ain't right. *We* maintain the official allocation records. In most cases, *we* made the allocations, and that guy should NOT be announcing routes to that IP space, and he shouldn't be announcing anything at all via that AS number, because these things ain't his.'' That's all. I'd just like to see them maybe take a postion. I'm quite sure that ARIN corporate counsel has advised them to never take a position on anything... kind-of like Minister Hacker in "Yes, Minister", who often hoped that the government could have NO position on anything the least bit controversial...except with respect to things that might erode their own power, you know, like the position that IP addresses are not property, which they try desperately to maintain (against all obvious facts to the contrary) as a way of keeping courts out of the business of saying who gets what, so that they can maintain their own total and absolute sovereignty over this shit, with no annoying judges to get in their way. But you know, if they won't even take a position on a bloody blatant hijacking by low life spammer slugs and/or by others who the spammers have paid Big Bucks to, to steal the space for them, they really, like I said, what's the point of even having an allocation ``authority''? (And obviously, I am using that term very very loosely here, because they clearly only care to use their ``authority'' when it makes everybody happy, and won't use it at all when it might make even one lone spammer/hijacker sad. If there is a better definition of cowardice and abdication, I don't know what it is.) ------- Forwarded Message Replied: Fri, 01 Oct 2010 00:49:08 -0700 Replied: hostmaster(a)arin.net Return-Path: hostmaster(a)arin.net Delivery-Date: Thu Sep 30 08:30:13 2010 Return-Path: <hostmaster(a)arin.net> X-Original-To: rfg(a)tristatelogic.com Delivered-To: rfg(a)tristatelogic.com Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by segfault.tristatelogic.com (Postfix) with ESMTP id 389DDBDC34 for <rfg(a)tristatelogic.com>; Thu, 30 Sep 2010 08:30:13 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 89AD4165331; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5-arin1 (2008-06-10) on smtp1.arin.net X-Spam-Level: X-Spam-Status: No, score=-144.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,USER_IN_WHITELIST autolearn=no version=3.2.5-arin1 Received: from pgp.arin.net (pgp.arin.net [192.136.136.159]) by smtp1.arin.net (Postfix) with ESMTP id 5F592165324 for <rfg(a)tristatelogic.com>; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) Received: by pgp.arin.net (Postfix, from userid 688) id 37E9F1A8069; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) Received: from shell.arin.net (shell.arin.net [192.136.136.149]) by pgp.arin.net (Postfix) with ESMTP id AD3C81A8103 for <rfg(a)tristatelogic.com>; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) Received: by shell.arin.net (Postfix, from userid 2006) id C6F5D8059; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by shell.arin.net (Postfix) with ESMTP id C5B0A8058; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) Date: Thu, 30 Sep 2010 11:30:06 -0400 (EDT) From: hostmaster(a)arin.net X-X-Sender: jonw(a)shell.arin.net To: rfg(a)tristatelogic.com Subject: Re: [ARIN-20100928-F683] Fraud Report Confirmed In-Reply-To: <mailbox-17204-1285704731-754558(a)shell.arin.net> Message-ID: <Pine.LNX.4.64.1009301126150.20077(a)shell.arin.net> References: <mailbox-17204-1285704731-754558(a)shell.arin.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Thanks for your report. > AS11296 appears to have been hijacked. > > Separately and additionally, all of the IPv4 blocks currently being > announced by AS11296 appear to have been hijacked also: > > 63.247.160.0/19 > 199.241.64.0/19 > 206.226.64.0/24 > 206.226.65.0/24 > 206.226.66.0/24 > 206.226.67.0/24 > 206.226.68.0/24 > 206.226.69.0/24 > 206.226.70.0/24 > 206.226.71.0/24 > 206.226.72.0/24 > 206.226.73.0/24 > 206.226.74.0/24 > 206.226.75.0/24 > 206.226.76.0/24 > 206.226.77.0/24 > 206.226.78.0/24 > 206.226.79.0/24 > 206.226.96.0/19 We've looked through these records and can't find any unauthorized changes. Do you have any further details regarding unauthorized changes to ARIN's Whois data? If not, we can't take action. We can investigate fraudulent changes to registration data, but we can't investigate fraudulent activity related to use of numbering resources (e.g. routing of resources by someone other than the registrant). If you have any further questions, comments, or concerns please respond to this message or contact me directly. Regards, Jon Worley Senior Resource Analyst ARIN Registration Services https://www.arin.net/ hostmaster(a)arin.net 703.227.0660 Are you ready for IPv6? For information on transitioning to IPv6, see: https://www.arin.net/knowledge/about_resources/v6/v6.html - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMpKz/ZKymzxl/LaURAvVuAJsFT6DZxoZ5O13SDRKWK6Lkz1yusgCdFt01 aMTBE0O/ucnRx+8rk8+QbEE= =qqf5 - -----END PGP SIGNATURE----- ------- End of Forwarded Message

18 44