From narten at us.ibm.com Fri Aug 1 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 01 Aug 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201408010453.s714r3vQ024629@rotala.raleigh.ibm.com> Total of 20 messages in the last 7 days. script run at: Fri Aug 1 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.00% | 3 | 85.96% | 1639316 | scottleibrand at gmail.com 20.00% | 4 | 1.81% | 34543 | jcurran at arin.net 15.00% | 3 | 3.37% | 64335 | jschiller at google.com 10.00% | 2 | 2.83% | 53987 | mueller at syr.edu 5.00% | 1 | 1.72% | 32889 | sryerse at eclipse-networks.com 5.00% | 1 | 0.99% | 18801 | hannigan at gmail.com 5.00% | 1 | 0.94% | 17877 | john.sweeting at twcable.com 5.00% | 1 | 0.61% | 11562 | owen at delong.com 5.00% | 1 | 0.54% | 10262 | michael at linuxmagic.com 5.00% | 1 | 0.50% | 9461 | info at arin.net 5.00% | 1 | 0.39% | 7438 | narten at us.ibm.com 5.00% | 1 | 0.34% | 6574 | gary.buhrmaster at gmail.com --------+------+--------+----------+------------------------ 100.00% | 20 |100.00% | 1907045 | Total From narten at us.ibm.com Fri Aug 8 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 08 Aug 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201408080453.s784r4XP010419@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Aug 8 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 7042 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 7042 | Total From info at arin.net Wed Aug 13 14:46:25 2014 From: info at arin.net (ARIN) Date: Wed, 13 Aug 2014 14:46:25 -0400 Subject: [arin-ppml] Board Adopts Recommended Draft Policies Message-ID: <53EBB281.6000802@arin.net> On 18 July 2014 the ARIN Board of Trustees adopted the following Recommended Draft Policies: ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks ARIN-2014-5: Remove 7.2 Lame Delegations ARIN-2014-12: Anti-hijack Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24 These policies will be implemented no later than 30 September 2014. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Aug 15 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 15 Aug 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201408150453.s7F4r3Wp001870@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Aug 15 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 55.22% | 6438 | narten at us.ibm.com 50.00% | 1 | 44.78% | 5221 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 11659 | Total From hannigan at gmail.com Mon Aug 18 13:21:23 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 18 Aug 2014 13:21:23 -0400 Subject: [arin-ppml] POC Validation results in locked out Admins Message-ID: Confusing. Anyone ever hear of ARIN locking people out of the online application for an invalidated POC? With no way to automatically address things like employee departures or other errors typically made by provider assigned address this seems like its over the top and contrary to an accurate whois. It would be easier to simply validate the bad data than to go through the operationally expensive efforts to fix it. How does this work ARIN? 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndavis at arin.net Mon Aug 18 16:04:57 2014 From: ndavis at arin.net (Nate Davis) Date: Mon, 18 Aug 2014 20:04:57 +0000 Subject: [arin-ppml] POC Validation results in locked out Admins In-Reply-To: References: Message-ID: From: Martin Hannigan > Date: Monday, August 18, 2014 at 1:21 PM To: "arin-ppml at arin.net" > Subject: [arin-ppml] POC Validation results in locked out Admins Confusing. Anyone ever hear of ARIN locking people out of the online application for an invalidated POC? With no way to automatically address things like employee departures or other errors typically made by provider assigned address this seems like its over the top and contrary to an accurate whois. It would be easier to simply validate the bad data than to go through the operationally expensive efforts to fix it. How does this work ARIN? 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy Martin ? We have some reference information available on ARIN?s website. The middle of the page https://www.arin.net/resources/records.html and Recovering A POC section of the page https://www.arin.net/resources/request/poc.html Users are locked out of full ARIN Online functionality only when a POC handle which is directly linked to their ARIN Online account hasn?t been validated within the required timeframe, per policy. Users that are locked out of full access can immediately, through ARIN Online, either validate the POC handle (if accurate), update the POC handle (if inaccurate, but the user still represents the person/role associated with the POC handle), or unlink from the POC handle (if the user no longer represents the person/role associated with the POC handle) and regain full access. This applies only to POC handles directly linked to the user?s web account. It does not apply to POC handles the user isn?t directly linked to - for example, POC handles for other people/roles on the same Org ID. Regards, Nate Davis American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Mon Aug 18 17:14:14 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 18 Aug 2014 17:14:14 -0400 Subject: [arin-ppml] POC Validation results in locked out Admins In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 4:04 PM, Nate Davis wrote: > > From: Martin Hannigan > Date: Monday, August 18, 2014 at 1:21 PM > To: "arin-ppml at arin.net" > Subject: [arin-ppml] POC Validation results in locked out Admins > > > > Confusing. Anyone ever hear of ARIN locking people out of the online > application for an invalidated POC? With no way to automatically address > things like employee departures or other errors typically made by provider > assigned address this seems like its over the top and contrary to an > accurate whois. It would be easier to simply validate the bad data than to > go through the operationally expensive efforts to fix it. > > How does this work ARIN? > > > 3.6 Annual Whois POC Validation > 3.6.1 Method of Annual Verification > > During ARIN's annual Whois POC validation, an email will be sent to every > POC in the Whois database. Each POC will have a maximum of 60 days to > respond with an affirmative that their Whois contact information is correct > and complete. Unresponsive POC email addresses shall be marked as such in > the database. If ARIN staff deems a POC to be completely and permanently > abandoned or otherwise illegitimate, the POC record shall be marked > invalid. ARIN will maintain, and make readily available to the community, a > current list of number resources with no valid POC; this data will be > subject to the current bulk Whois policy > > Martin - We have some reference information available on ARIN's > website. > > The middle of the page https://www.arin.net/resources/records.html and > Recovering A POC section of the page > https://www.arin.net/resources/request/poc.html > > Users are locked out of *full* ARIN Online functionality only when a POC > handle which is directly linked to their ARIN Online account hasn't been > validated within the required timeframe, per policy. Users that are > The policy doesn't state users should be locked out, rather it states a list will be provided publicly and the POC marked "invalid". POC invalidation works. Wheres the list? locked out of full access can immediately, through ARIN Online, either > validate the POC handle (if accurate), update the POC handle (if > inaccurate, but the user still represents the person/role associated with > the POC handle), or unlink from the POC handle (if the user no longer > represents the person/role associated with the POC handle) and regain full > access. This applies only to POC handles directly linked to the user's web > account. It does not apply to POC handles the user isn't directly linked > to - for example, POC handles for other people/roles on the same Org ID. > Most of the fields are related to location, not name. This is a defect in the update logic. Why we can't update the full record except the linked resource? If the provider doesn't like it, they could rescind it, but shunting expensive opex onto both networks for administrative updates especially when we are paying high fees doesn't seem quite right. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Aug 18 17:38:39 2014 From: jcurran at arin.net (John Curran) Date: Mon, 18 Aug 2014 21:38:39 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: On Aug 18, 2014, at 5:14 PM, Martin Hannigan wrote: > The policy doesn't state users should be locked out, rather it states a list will be provided publicly and the POC marked "invalid". POC invalidation works. Wheres the list? Martin - Per NRPM 3.6.1) - "ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy." Note that available to the community and subject to the current bulk Whois policy is not quite the same as "publicly"; for more details on the Bulk Whois AUP, you should check here: https://www.arin.net/resources/request/bulkwhois.html Once you have signed the Bulk Whois AUP, you may download the list of "Number Resources without valid POCs" via ARIN Online under the "Downloads & Services" menu item - FYI, /John John Curran President and CEO ARIN From hannigan at gmail.com Mon Aug 18 19:04:09 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 18 Aug 2014 19:04:09 -0400 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: John, The policy proposal in the archive initially stated that it should be brought to the attention of the community and didn't imply roadblocks. I forget how the whois requirement was inserted and I don't really care since the issue is policy, but if I recall correctly that whois document wasn't a legal agreement "back then". Transparency != 6 pages of legalese. Would have been nice to for the system to generate a warning to an associated admin POC that ARIN was going to cripple a networks ability to maintain its resource legitimately. IMHO, ARIN is over stepping its boundaries. YMMV, Marty > On Aug 18, 2014, at 17:38, John Curran wrote: > >> On Aug 18, 2014, at 5:14 PM, Martin Hannigan wrote: >> >> The policy doesn't state users should be locked out, rather it states a list will be provided publicly and the POC marked "invalid". POC invalidation works. Wheres the list? > > Martin - > > Per NRPM 3.6.1) - "ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy." > > Note that available to the community and subject to the current bulk Whois policy > is not quite the same as "publicly"; for more details on the Bulk Whois AUP, you > should check here: > > https://www.arin.net/resources/request/bulkwhois.html > > Once you have signed the Bulk Whois AUP, you may download the list > of "Number Resources without valid POCs" via ARIN Online under the > "Downloads & Services" menu item - > > > > FYI, > /John > > John Curran > President and CEO > ARIN > > From jcurran at arin.net Mon Aug 18 19:25:39 2014 From: jcurran at arin.net (John Curran) Date: Mon, 18 Aug 2014 23:25:39 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: On Aug 18, 2014, at 7:04 PM, Martin Hannigan wrote: > John, > > The policy proposal in the archive initially stated that it should be > brought to the attention of the community and didn't imply roadblocks. > I forget how the whois requirement was inserted and I don't really > care since the issue is policy, ... Martin - ARIN staff implement the policy, and the requirement is quite clear in the present policy language. I believe that there was some concern about mining of the address blocks if it were to be public, but again, that is a tradeoff that the community should consider and determine policy accordingly. Changing the policy language to drop the bulk whois requirement would be a relatively easy change, if there is community support; please let me know if you need any assistance in developing an appropriate policy proposal. Thanks! /John John Curran President and CEO ARIN From michael at linuxmagic.com Mon Aug 18 19:36:55 2014 From: michael at linuxmagic.com (Michael Peddemors) Date: Mon, 18 Aug 2014 16:36:55 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: References: Message-ID: <53F28E17.4020100@linuxmagic.com> On 14-08-18 04:25 PM, John Curran wrote: > Changing the policy language to drop the bulk whois requirement > would be a relatively easy change, if there is community support; -1 ;) Every little bit helps.. The internet needs more accurate data on who is responsible, and I am sure ARIN does as well to do their mandate.. I don't think you will get a lot of support to drop that requirement.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From hannigan at gmail.com Mon Aug 18 22:17:41 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 18 Aug 2014 22:17:41 -0400 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: John, You skipped the important bits. FYI, -M< On Monday, August 18, 2014, John Curran wrote: > On Aug 18, 2014, at 7:04 PM, Martin Hannigan > wrote: > > > John, > > > > The policy proposal in the archive initially stated that it should be > > brought to the attention of the community and didn't imply roadblocks. > > I forget how the whois requirement was inserted and I don't really > > care since the issue is policy, ... > > Martin - > > ARIN staff implement the policy, and the requirement is quite > clear in the present policy language. I believe that there was > some concern about mining of the address blocks if it were to be > public, but again, that is a tradeoff that the community should > consider and determine policy accordingly. > > Changing the policy language to drop the bulk whois requirement > would be a relatively easy change, if there is community support; > please let me know if you need any assistance in developing an > appropriate policy proposal. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Aug 19 06:53:01 2014 From: jcurran at arin.net (John Curran) Date: Tue, 19 Aug 2014 10:53:01 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: On Aug 18, 2014, at 10:17 PM, Martin Hannigan wrote: > John, > > You skipped the important bits. Martin - My apologies - you also noted: "Would have been nice to for the system to generate a warning to an associated admin POC that ARIN was going to cripple a networks ability to maintain its resource legitimately." and I should have supplied an appropriate pointer to the ARIN Consultation and Suggestion Process (ARIN ACSP) - If you would prefer that ARIN Online generate a warning, or that ARIN continue to accept changes from invalid POC records (either in general or in cases where there is no other other POCs on a resource) then it would be best to submit a suggestion per ACSP so that we can hold a focused consultation on your suggestion. Thanks! /John John Curran President and CEO ARIN From tedm at ipinc.net Tue Aug 19 16:33:35 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2014 13:33:35 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: References: Message-ID: <53F3B49F.2040802@ipinc.net> Martin, i was one of the original people involved in creating this policy and the requirement to sign a bulk whois was a compromise between the people like me who wanted full disclosure with no strings attached and the people who didn't want the information disclosed at all. I don't think it's going to be changed. Furthermore I will point out that you can use a role account email address for the important POCs, so your employee turnover would not be an issue. Please accept that the community has judged that having valid data in the database is more important than your inconvenience of keeping the database current. John, don't think your off the hook. There is one issue that Martin didn't mention that might be the cause of the POC validation issues. To put it as simply as I can, the emails that ARIN sends out for POC validation look exactly like phishing emails. I got one of those mails and I could hardly believe that one of the top Internet companies would actually send out an email that EMBEDDED A URL LINK in the mail message. I opened the message in a text editor to make sure the link was actually going to where it was supposed to go before clicking it. Your people should know better. How many spams a day do you get purporting to be from UPS/FedEX/BankofAmerica/IRS/etc. etc. etc. with embedded links in them and an enticing email message to try to get the people to click on the link (which of course immediately redirects them to a broken-into server) A lot, huh? So what on earth makes you think that your validation emails won't be regarded as phishes by the clueful people who get them - network admins? The only spamproof way of getting a proper email validation is to ask the recipient to REPLY then you parse the replies that come back in. Nobody who wrote this policy had thought that ARIN would ever resort to a tactic that is used by spammers and phishers and identity thieves thousands of times a day - which is to embed a clickable URL in the validation email message. It does not surprise me that some are complaining they missed the validation email. Ted On 8/18/2014 4:25 PM, John Curran wrote: > On Aug 18, 2014, at 7:04 PM, Martin Hannigan wrote: > >> John, >> >> The policy proposal in the archive initially stated that it should be >> brought to the attention of the community and didn't imply roadblocks. >> I forget how the whois requirement was inserted and I don't really >> care since the issue is policy, ... > > Martin - > > ARIN staff implement the policy, and the requirement is quite > clear in the present policy language. I believe that there was > some concern about mining of the address blocks if it were to be > public, but again, that is a tradeoff that the community should > consider and determine policy accordingly. > > Changing the policy language to drop the bulk whois requirement > would be a relatively easy change, if there is community support; > please let me know if you need any assistance in developing an > appropriate policy proposal. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com From jcurran at arin.net Tue Aug 19 21:17:57 2014 From: jcurran at arin.net (John Curran) Date: Wed, 20 Aug 2014 01:17:57 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <53F3B49F.2040802@ipinc.net> References: <53F3B49F.2040802@ipinc.net> Message-ID: <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> On Aug 19, 2014, at 4:33 PM, Ted Mittelstaedt wrote: > ... > There is one issue that Martin didn't mention that might be the cause of the POC validation issues. To put it as simply as I can, the > emails that ARIN sends out for POC validation look exactly like phishing > emails. > > I got one of those mails and I could hardly believe that one of the top Internet companies would actually send out an email that EMBEDDED A URL LINK in the mail message. > > I opened the message in a text editor to make sure the link was actually > going to where it was supposed to go before clicking it. > > Your people should know better. How many spams a day do you get purporting to be from UPS/FedEX/BankofAmerica/IRS/etc. etc. etc. with > embedded links in them and an enticing email message to try to get the > people to click on the link (which of course immediately redirects them > to a broken-into server) A lot, huh? So what on earth makes you think > that your validation emails won't be regarded as phishes by the clueful > people who get them - network admins? > > The only spamproof way of getting a proper email validation is to > ask the recipient to REPLY then you parse the replies that come back > in. > > Nobody who wrote this policy had thought that ARIN would ever resort > to a tactic that is used by spammers and phishers and identity thieves > thousands of times a day - which is to embed a clickable URL in the > validation email message. > > It does not surprise me that some are complaining they missed the > validation email. Ted - We did get feedback from some folks that they do not click on URLs embedded in email messages, and recently (2Q 2014) have added text to the validation email to state that you can "reply" to the email instead to validate (as well as the necessary back-end processing for replies received.) This provides a safe option for those who do not wish to click on a URL but still wish to validate their POC. Note that many folks do presently click on the URL, as it is both to an arin.net address and is visible with the same text as the actual underlying URL. As you are well aware, emails of the phishing variety almost always have URLs which purport one thing but refer to some different underlying hyperlink. Does providing the simple "reply" option as you suggest suffice, or do you believe that email reply should be the only option, with the present arin.net URLs stripped from the validation email? Thanks! /John John Curran President and CEO ARIN From mpetach at netflight.com Wed Aug 20 00:39:44 2014 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 19 Aug 2014 21:39:44 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 4:04 PM, Martin Hannigan wrote: > John, > > The policy proposal in the archive initially stated that it should be > brought to the attention of the community and didn't imply roadblocks. > I forget how the whois requirement was inserted and I don't really > care since the issue is policy, but if I recall correctly that whois > document wasn't a legal agreement "back then". Transparency != 6 pages > of legalese. > > Would have been nice to for the system to generate a warning to an > associated admin POC that ARIN was going to cripple a networks ability > to maintain its resource legitimately. > > IMHO, ARIN is over stepping its boundaries. > I disagree; I think this is well within the purview of ARIN's mandate to restrict access to records for non-compliant networks. Matt > > > YMMV, > > > Marty > > > > > On Aug 18, 2014, at 17:38, John Curran wrote: > > > >> On Aug 18, 2014, at 5:14 PM, Martin Hannigan > wrote: > >> > >> The policy doesn't state users should be locked out, rather it states a > list will be provided publicly and the POC marked "invalid". POC > invalidation works. Wheres the list? > > > > Martin - > > > > Per NRPM 3.6.1) - "ARIN will maintain, and make readily available to > the community, a current list of number resources with no valid POC; this > data will be subject to the current bulk Whois policy." > > > > Note that available to the community and subject to the current bulk > Whois policy > > is not quite the same as "publicly"; for more details on the Bulk Whois > AUP, you > > should check here: > > > > https://www.arin.net/resources/request/bulkwhois.html > > > > Once you have signed the Bulk Whois AUP, you may download the list > > of "Number Resources without valid POCs" via ARIN Online under the > > "Downloads & Services" menu item - > > > > > > > > FYI, > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwb at liveair.net Wed Aug 20 02:58:55 2014 From: jwb at liveair.net (Breeden, James W.) Date: Wed, 20 Aug 2014 01:58:55 -0500 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: <32CA967D914F9A4B8563B334392B4D7FC114E8273A@bspmail01> +1 I disagree; I think this is well within the purview of ARIN's mandate to restrict access to records for non-compliant networks. Matt +1 From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Petach Sent: Tuesday, August 19, 2014 11:40 PM Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) On Mon, Aug 18, 2014 at 4:04 PM, Martin Hannigan > wrote: John, The policy proposal in the archive initially stated that it should be brought to the attention of the community and didn't imply roadblocks. I forget how the whois requirement was inserted and I don't really care since the issue is policy, but if I recall correctly that whois document wasn't a legal agreement "back then". Transparency != 6 pages of legalese. Would have been nice to for the system to generate a warning to an associated admin POC that ARIN was going to cripple a networks ability to maintain its resource legitimately. IMHO, ARIN is over stepping its boundaries. YMMV, Marty > On Aug 18, 2014, at 17:38, John Curran > wrote: > >> On Aug 18, 2014, at 5:14 PM, Martin Hannigan > wrote: >> >> The policy doesn't state users should be locked out, rather it states a list will be provided publicly and the POC marked "invalid". POC invalidation works. Wheres the list? > > Martin - > > Per NRPM 3.6.1) - "ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy." > > Note that available to the community and subject to the current bulk Whois policy > is not quite the same as "publicly"; for more details on the Bulk Whois AUP, you > should check here: > > https://www.arin.net/resources/request/bulkwhois.html > > Once you have signed the Bulk Whois AUP, you may download the list > of "Number Resources without valid POCs" via ARIN Online under the > "Downloads & Services" menu item - > > > > FYI, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ Proprietary Information Notice: This message may contain proprietary information that is the property of LiveAir Networks or its clients. Such information may not be shared with outside entities without the prior written consent of LiveAir Networks. If you have received this message in error please destroy it immediately. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Wed Aug 20 06:46:49 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 20 Aug 2014 06:46:49 -0400 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs (was: Re: POC Validation ...) In-Reply-To: References: Message-ID: On Wed, Aug 20, 2014 at 12:39 AM, Matthew Petach wrote: > > > > On Mon, Aug 18, 2014 at 4:04 PM, Martin Hannigan > wrote: > >> John, >> >> The policy proposal in the archive initially stated that it should be >> brought to the attention of the community and didn't imply roadblocks. >> I forget how the whois requirement was inserted and I don't really >> care since the issue is policy, but if I recall correctly that whois >> document wasn't a legal agreement "back then". Transparency != 6 pages >> of legalese. >> >> Would have been nice to for the system to generate a warning to an >> associated admin POC that ARIN was going to cripple a networks ability >> to maintain its resource legitimately. >> >> IMHO, ARIN is over stepping its boundaries. >> > > I disagree; I think this is well within the > purview of ARIN's mandate to restrict > access to records for non-compliant > networks. > > > We can disagree. If ARIN made reasonable efforts to keep the registry accurate and make the record keeping reasonable as well, no arguments. But that is not the case. I wonder if the application of such a response is consistent as well. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Wed Aug 20 07:10:39 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 20 Aug 2014 07:10:39 -0400 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <53F3B49F.2040802@ipinc.net> References: <53F3B49F.2040802@ipinc.net> Message-ID: On Tue, Aug 19, 2014 at 4:33 PM, Ted Mittelstaedt wrote: > Martin, > > i was one of the original people involved in creating this policy and > the requirement to sign a bulk whois was a compromise between the people > like me who wanted full disclosure with no strings attached and the people > who didn't want the information disclosed at all. > > I don't think it's going to be changed. Furthermore I will point out > that you can use a role account email address for the important POCs, > so your employee turnover would not be an issue. Please accept that > the community has judged that having valid data in the database is > more important than your inconvenience of keeping the database current. > You can, but I'm not setting the POCs. Downstreams commonly set them to whatever they want to. If we had the ability to modify the POC on an assignment already made to us that would make the record keeping requirements reasonable. The bulk whois requirement is a product of fear, not logic, IMHO. > > John, don't think your off the hook. > > There is one issue that Martin didn't mention that might be the cause of > the POC validation issues. To put it as simply as I can, the > emails that ARIN sends out for POC validation look exactly like phishing > emails. > It's that, but if ARIN is going to block someone from maintaining their address it would be operationally sound to send the associated POC an email letting them know. Second, the application. Are the lockouts automated? My information is no. I'd argue this sets this up for abuse. [ clip - mostly agree ] Nobody who wrote this policy had thought that ARIN would ever resort > to a tactic that is used by spammers and phishers and identity thieves > thousands of times a day - which is to embed a clickable URL in the > validation email message. > > It does not surprise me that some are complaining they missed the > validation email. > It's not the validation email per se. But to your point, a role account, even without abuse of bulk whois data, is abused regularly. Literally thousands of emails per day. Yeah, yeah, filters, etc. But that's back seat driving at its worst, blindfolded. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed Aug 20 12:24:19 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2014 09:24:19 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> Message-ID: <53F4CBB3.3000704@ipinc.net> On 8/19/2014 6:17 PM, John Curran wrote: > On Aug 19, 2014, at 4:33 PM, Ted Mittelstaedt wrote: >> ... >> There is one issue that Martin didn't mention that might be the cause of the POC validation issues. To put it as simply as I can, the >> emails that ARIN sends out for POC validation look exactly like phishing >> emails. >> >> I got one of those mails and I could hardly believe that one of the top Internet companies would actually send out an email that EMBEDDED A URL LINK in the mail message. >> >> I opened the message in a text editor to make sure the link was actually >> going to where it was supposed to go before clicking it. >> >> Your people should know better. How many spams a day do you get purporting to be from UPS/FedEX/BankofAmerica/IRS/etc. etc. etc. with >> embedded links in them and an enticing email message to try to get the >> people to click on the link (which of course immediately redirects them >> to a broken-into server) A lot, huh? So what on earth makes you think >> that your validation emails won't be regarded as phishes by the clueful >> people who get them - network admins? >> >> The only spamproof way of getting a proper email validation is to >> ask the recipient to REPLY then you parse the replies that come back >> in. >> >> Nobody who wrote this policy had thought that ARIN would ever resort >> to a tactic that is used by spammers and phishers and identity thieves >> thousands of times a day - which is to embed a clickable URL in the >> validation email message. >> >> It does not surprise me that some are complaining they missed the >> validation email. > > Ted - > > We did get feedback from some folks that they do not click on URLs > embedded in email messages, and recently (2Q 2014) have added text > to the validation email to state that you can "reply" to the email > instead to validate (as well as the necessary back-end processing > for replies received.) This provides a safe option for those who > do not wish to click on a URL but still wish to validate their POC. > > Note that many folks do presently click on the URL, as it is both > to an arin.net address and is visible with the same text as the > actual underlying URL. As you are well aware, emails of the phishing > variety almost always have URLs which purport one thing but refer > to some different underlying hyperlink. > > Does providing the simple "reply" option as you suggest suffice, > or do you believe that email reply should be the only option, with > the present arin.net URLs stripped from the validation email? > Hi John, Embedded URLs are not really the problem - the problem is MIME-encoded email and HTML-encoded email that have the embedded URLs. If you are sending clickable URLs out in pure ASCII (text) emails then there isn't any problem. The fact is that many email clients when they see URL's in ASCII mail will make them "clickable" A pure text email cannot hide a different URL behind one URL. In an ideal world the URL would not exist in the email, because including it helps to legitimize the practice. But in practicality the most important thing is getting validation that the email address is being read by a human being, and the embedded URL does accomplish that. It may also be that the destination email address is something like "hostmaster at example.com" and is being forwarded to a recipient who's knee-jerk Reply would be to send the reply with a different senders address than what you emailed to. (which might complicate parsing the replies) Since your getting significant returns on the clicks then you should continue to use them - but my vote would be to ONLY use them in TEXT emails. I know that sending pure text emails is out of fashion - since that precludes people putting in all kinds of fancy logos and formatting which they believe are necessary to the continuation of the species - but us old timers were formatting ASCII-only email since before most of the young whippersnappers out there were in diapers. ;-) Ted > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > > From tedm at ipinc.net Wed Aug 20 12:41:36 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2014 09:41:36 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: References: <53F3B49F.2040802@ipinc.net> Message-ID: <53F4CFC0.8050503@ipinc.net> On 8/20/2014 4:10 AM, Martin Hannigan wrote: > > > > On Tue, Aug 19, 2014 at 4:33 PM, Ted Mittelstaedt > wrote: > > Martin, > > i was one of the original people involved in creating this policy and > the requirement to sign a bulk whois was a compromise between the people > like me who wanted full disclosure with no strings attached and the > people who didn't want the information disclosed at all. > > I don't think it's going to be changed. Furthermore I will point out > that you can use a role account email address for the important POCs, > so your employee turnover would not be an issue. Please accept that > the community has judged that having valid data in the database is > more important than your inconvenience of keeping the database current. > > > > You can, but I'm not setting the POCs. Downstreams commonly set them to > whatever they want to. If we had the ability to modify the POC on an > assignment already made to us that would make the record keeping > requirements reasonable. > You have other ways - since they are getting IP addressing from you, you just point to the section of the contract they signed that requires them to put in valid POC data, right? Since your legally obligated to supply valid POC on assignments by your own contract with ARIN I think your lawyers would have a conniption fit if you were not extending this same contractual requirement to your customers. Maybe you should enlighten them if such language does not exist? ;-) > The bulk whois requirement is a product of fear, not logic, IMHO. > I won't argue that one. > > > John, don't think your off the hook. > > There is one issue that Martin didn't mention that might be the > cause of the POC validation issues. To put it as simply as I can, the > emails that ARIN sends out for POC validation look exactly like phishing > emails. > > > > It's that, but if ARIN is going to block someone from maintaining their > address it would be operationally sound to send the associated POC an > email letting them know. Second, the application. Are the lockouts > automated? My information is no. I'd argue this sets this up for abuse. > Unfortunately, once you have a database (in this case, POCs) that you have spent a large amount of effort on cleaning and maintaining, the temptation is to link a lot of additional stuff into it. Arguably, the WHOIS database is also considered by the community as authoritative for IP assignments so linking it into other permissions on the block is implied as legitimate. This is, by the way, an artifact of IPv4 shortage politics. But, with the rise of criminals on the Internet we are finding that it's not a bad idea to hold people's feet to the fire and identify who IP block holders are. You can probably argue that theoretically this is a bad thing - but if you look at for example car license plates, states (in the US at least) tie a whole lot of stuff into vehicle license plates nowadays. > > [ clip - mostly agree ] > > Nobody who wrote this policy had thought that ARIN would ever resort > to a tactic that is used by spammers and phishers and identity thieves > thousands of times a day - which is to embed a clickable URL in the > validation email message. > > It does not surprise me that some are complaining they missed the > validation email. > > > It's not the validation email per se. But to your point, a role account, > even without abuse of bulk whois data, is abused regularly. Literally > thousands of emails per day. Yeah, yeah, filters, etc. But that's back > seat driving at its worst, blindfolded. > Well, I guess it's germane that the POC does not contain just an email, there's supposed to be a phone number and street address that is valid as well. We are most concerned with email since we need it for immediate notification in the event a criminal is using an IP number for something, but the other data is just as important. Unfortunately there isn't as easy a way to validate that as to validate an email address. I guess that all I can say is this should help concentrate Internet admins attention on penalizing spammers. If we don't like getting all of that junk mail on our role addresses, it's our Internet, we can do something about it instead of complaining. The Spam isn't coming from alien visitors who are inducing it into our fiber links - it's coming from netblocks that us administrators ultimately control. Remember AGIS went bankrupt when the head network admin refused orders of the owner of that network to continue to provide a safe haven for spammers. Ultimately spam is stopped by you, and me, and every other admin out there, gunning for those spammers one at a time. Ted > Best, > > -M< > > > From jcurran at arin.net Wed Aug 20 13:54:15 2014 From: jcurran at arin.net (John Curran) Date: Wed, 20 Aug 2014 17:54:15 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: References: <53F3B49F.2040802@ipinc.net> Message-ID: <770D7369-E172-47B3-B232-19F8CCE72529@corp.arin.net> On Aug 20, 2014, at 7:10 AM, Martin Hannigan wrote: > > It's that, but if ARIN is going to block someone from maintaining their address it would be operationally sound to send the associated POC an email letting them know. Second, the application. Are the lockouts automated? My information is no. I'd argue this sets this up for abuse. Martin - The lockout of an ARIN online account from making changes (other than to its associated POC) is automatic, and done based on last notification and last verified dates on the POC. If you have any information to the contrary, then it is in error; even the registration services desk can only update POCs (which makes then valid), there is no mechanism for the reverse. Note that accounts locked out based on being associated with an unvalidated POC can ALWAYS immediately resolve the problem and regain access without staff intervention. All they have to do is login and click validate or edit the POC handle to have correct information. There?s never a circumstance where a user would have to manage their records but be unable to do so - only that they must validate their POC first (which is completely within their ability upon login.) I will see if we can make more explanatory information about this available online, but in the meantime if you have an issue please do not hesitate to contact the Registration Services - Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Wed Aug 20 14:08:35 2014 From: jcurran at arin.net (John Curran) Date: Wed, 20 Aug 2014 18:08:35 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <53F4CBB3.3000704@ipinc.net> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> Message-ID: <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> On Aug 20, 2014, at 12:24 PM, Ted Mittelstaedt wrote: > > Hi John, > > Embedded URLs are not really the problem - the problem is > MIME-encoded email and HTML-encoded email that have the embedded > URLs. > > If you are sending clickable URLs out in pure ASCII (text) emails then > there isn't any problem. The fact is that many email clients > when they see URL's in ASCII mail will make them "clickable" A > pure text email cannot hide a different URL behind one URL. > > In an ideal world the URL would not exist in the email, because including it helps to legitimize the practice. > > But in practicality the most important thing is getting validation > that the email address is being read by a human being, and the embedded > URL does accomplish that. It may also be that the destination email > address is something like "hostmaster at example.com" and is being forwarded to a recipient who's knee-jerk Reply would be to send the > reply with a different senders address than what you emailed to. (which > might complicate parsing the replies) > > Since your getting significant returns on the clicks then you should > continue to use them - but my vote would be to ONLY use them in TEXT > emails. > > I know that sending pure text emails is out of fashion - since that > precludes people putting in all kinds of fancy logos and formatting which they believe are necessary to the continuation of the species - > but us old timers were formatting ASCII-only email since before most > of the young whippersnappers out there were in diapers. ;-) Ted - Point taken (and I am a huge fan of plain text email :-)... I will look into any downsides to this approach and report back to the list. Curious, would it help if ARIN pgp-signs the verification message with our hostmaster at arin.net account? Does this change the requirement for plain text email? Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Wed Aug 20 14:08:29 2014 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 20 Aug 2014 14:08:29 -0400 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <770D7369-E172-47B3-B232-19F8CCE72529@corp.arin.net> References: <53F3B49F.2040802@ipinc.net> <770D7369-E172-47B3-B232-19F8CCE72529@corp.arin.net> Message-ID: On Wed, Aug 20, 2014 at 1:54 PM, John Curran wrote: > On Aug 20, 2014, at 7:10 AM, Martin Hannigan wrote: > > > [ clip ] > I will see if we can make more explanatory information about this > available > online, but in the meantime if you have an issue please do not hesitate > to > contact the Registration Services - < > https://www.arin.net/contact_us.html> > > Feel free to explain it here since I raised it as a policy issue. Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Wed Aug 20 15:01:20 2014 From: lsawyer at gci.com (Leif Sawyer) Date: Wed, 20 Aug 2014 19:01:20 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John - I think that PGP signing all outgoing email is a great step at providing a level of authentication and validation for non-secure-channel communications. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP08C4ACgkQlZlwDwi+7aiOawCgsR1wcbMRql7s27u1rsdOivq8 xTsAmwXsdzlQtlHtLwe4ltyN1fJ/QtwM =JEUg -----END PGP SIGNATURE----- -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, August 20, 2014 10:09 AM To: Ted Mittelstaedt Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Access to list of Number Resources with no valid POCs On Aug 20, 2014, at 12:24 PM, Ted Mittelstaedt wrote: > > Hi John, > > Embedded URLs are not really the problem - the problem is > MIME-encoded email and HTML-encoded email that have the embedded URLs. > > If you are sending clickable URLs out in pure ASCII (text) emails > then there isn't any problem. The fact is that many email clients > when they see URL's in ASCII mail will make them "clickable" A pure > text email cannot hide a different URL behind one URL. > > In an ideal world the URL would not exist in the email, because including it helps to legitimize the practice. > > But in practicality the most important thing is getting validation > that the email address is being read by a human being, and the > embedded URL does accomplish that. It may also be that the > destination email address is something like "hostmaster at example.com" > and is being forwarded to a recipient who's knee-jerk Reply would be > to send the reply with a different senders address than what you > emailed to. (which might complicate parsing the replies) > > Since your getting significant returns on the clicks then you should > continue to use them - but my vote would be to ONLY use them in TEXT > emails. > > I know that sending pure text emails is out of fashion - since that > precludes people putting in all kinds of fancy logos and formatting > which they believe are necessary to the continuation of the species - > but us old timers were formatting ASCII-only email since before most > of the young whippersnappers out there were in diapers. ;-) Ted - Point taken (and I am a huge fan of plain text email :-)... I will look into any downsides to this approach and report back to the list. Curious, would it help if ARIN pgp-signs the verification message with our hostmaster at arin.net account? Does this change the requirement for plain text email? Thanks! /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From farmer at umn.edu Wed Aug 20 15:20:27 2014 From: farmer at umn.edu (David Farmer) Date: Wed, 20 Aug 2014 14:20:27 -0500 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> Message-ID: <53F4F4FB.6010102@umn.edu> On 8/20/14, 13:08 , John Curran wrote: > On Aug 20, 2014, at 12:24 PM, Ted Mittelstaedt wrote: >> >> Hi John, >> >> Embedded URLs are not really the problem - the problem is >> MIME-encoded email and HTML-encoded email that have the embedded >> URLs. ... > Ted - > > Point taken (and I am a huge fan of plain text email :-)... I will > look into any downsides to this approach and report back to the list. I went back and looked at the latest validation email I got Aug 1 for my POC, quite timely for this discussion. As far as I can tell it is not a HTML email, but plain text email with a plain text URL, quoted below is the relevant portion depersonalized. > The following is your current POC Whois registration record. To validate, please take one of the actions listed below. If no action is taken within 60 days, your POC record will be marked invalid in ARIN's Whois. > > Your POC information in Whois is: XXXXX > 1) If the information above is correct, please confirm by visiting: > > https://www.arin.net/public/pocValidation.xhtml?validationCode=XXXXXXXXXXX > > Alternatively, you may confirm by replying to this email. > > 2) If the information is incorrect: > > a) Log into your ARIN Online account (you can create an account by going to www.arin.net and selecting 'new user' on the left) ... I'll note that when I first look at it the reply to email option, was hiding under the URL and didn't fully catch my attention. Might I suggest a minor rewrite, enumerating the options for confirming and adding "log into ARIN Online" as the first option, something more like the following; ---- 1) If the information above is correct, please confirm using one of the following methods: a) Log into your ARIN Online account and follow instructions there to confirm; b) Or, visit the following URL https://www.arin.net/public/pocValidation.xhtml?validationCode=XXXXXXXXXXX c) Or, reply to this email. ---- This would encourage the safest behavior, action that is completely independent of the prompting email "log into ARIN Online". However, still allowing less preferred, but probably more convenient, behavior of clicking on a link or replying to the email. Thanks. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From tedm at ipinc.net Wed Aug 20 16:21:06 2014 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2014 13:21:06 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <53F4F4FB.6010102@umn.edu> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> <53F4F4FB.6010102@umn.edu> Message-ID: <53F50332.5000308@ipinc.net> I looked at the last one of these I got (that I saved) and it was indeed text - but I could have sworn I got something from ARIN recently with HTML mail that had an embedded URL. It might not have been a POC validation but something else. And of course I can't find the dang email right now. Note that it's possible to define Courier font on an HTML email and make it look like text - I've seen that trick done by a spammer before. So even if ARIN is sending out text with URLs in it, they should try to limit the types of emails that contain links. Most especially never send out any emails that link to a Login page on the ARIN website. That's the trick phishers use to collect userID's and passwords for banks, ya know. The POC email addresses, being public, are harvest-able. It would not take much for a spammer to duplicate a POC validation email in Courier font as an HTML mail and send it out to all the POCs in the whois database with a hidden link in it. Whether it would be that successful in catching anyone with their pants down is another story - those email addresses would be going to the most suspicious people on the Internet. I still think a simple Reply is the safest. Ted On 8/20/2014 12:20 PM, David Farmer wrote: > On 8/20/14, 13:08 , John Curran wrote: >> On Aug 20, 2014, at 12:24 PM, Ted Mittelstaedt wrote: >>> >>> Hi John, >>> >>> Embedded URLs are not really the problem - the problem is >>> MIME-encoded email and HTML-encoded email that have the embedded >>> URLs. > ... >> Ted - >> >> Point taken (and I am a huge fan of plain text email :-)... I will >> look into any downsides to this approach and report back to the list. > > I went back and looked at the latest validation email I got Aug 1 for my > POC, quite timely for this discussion. As far as I can tell it is not a > HTML email, but plain text email with a plain text URL, quoted below is > the relevant portion depersonalized. > >> The following is your current POC Whois registration record. To >> validate, please take one of the actions listed below. If no action is >> taken within 60 days, your POC record will be marked invalid in ARIN's >> Whois. >> >> Your POC information in Whois is: > XXXXX >> 1) If the information above is correct, please confirm by visiting: >> >> https://www.arin.net/public/pocValidation.xhtml?validationCode=XXXXXXXXXXX >> >> >> Alternatively, you may confirm by replying to this email. >> >> 2) If the information is incorrect: >> >> a) Log into your ARIN Online account (you can create an account by >> going to www.arin.net and selecting 'new user' on the left) > ... > > I'll note that when I first look at it the reply to email option, was > hiding under the URL and didn't fully catch my attention. Might I > suggest a minor rewrite, enumerating the options for confirming and > adding "log into ARIN Online" as the first option, something more like > the following; > > ---- > > 1) If the information above is correct, please confirm using one of the > following methods: > > a) Log into your ARIN Online account and follow instructions there to > confirm; > > b) Or, visit the following URL > > https://www.arin.net/public/pocValidation.xhtml?validationCode=XXXXXXXXXXX > > c) Or, reply to this email. > > ---- > > This would encourage the safest behavior, action that is completely > independent of the prompting email "log into ARIN Online". However, > still allowing less preferred, but probably more convenient, behavior of > clicking on a link or replying to the email. > > Thanks. > From jcurran at arin.net Wed Aug 20 17:49:12 2014 From: jcurran at arin.net (John Curran) Date: Wed, 20 Aug 2014 21:49:12 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: References: <53F3B49F.2040802@ipinc.net> <770D7369-E172-47B3-B232-19F8CCE72529@corp.arin.net> Message-ID: On Aug 20, 2014, at 2:08 PM, Martin Hannigan > wrote: On Wed, Aug 20, 2014 at 1:54 PM, John Curran > wrote: I will see if we can make more explanatory information about this available online, but in the meantime if you have an issue please do not hesitate to contact the Registration Services - Feel free to explain it here since I raised it as a policy issue. Martin - The effort to provide a better description on how POC validation works is should result in ARIN having more detailed documentation of the existing POC validation process online, i.e. it is to improve documentation of ARIN's implementation of the existing POC validation policy. With respect to ARIN following the POC validation policy for access to the list of resources with no valid POCs (i.e. the policy issue that you raised), I already noted that "changing the policy language to drop the bulk whois requirement would be a relatively easy change, if there is community support; please let me know if you need any assistance in developing an appropriate policy proposal." If you raised some other issue with respect to the existing policy, please feel free to restate that issue for clarity on this list, or submit a policy proposal, as you prefer. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Aug 22 00:53:03 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 22 Aug 2014 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201408220453.s7M4r3Lf028088@rotala.raleigh.ibm.com> Total of 25 messages in the last 7 days. script run at: Fri Aug 22 00:53:03 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 28.00% | 7 | 29.09% | 68881 | hannigan at gmail.com 28.00% | 7 | 22.60% | 53497 | jcurran at arin.net 16.00% | 4 | 15.71% | 37197 | tedm at ipinc.net 4.00% | 1 | 8.68% | 20553 | jwb at liveair.net 4.00% | 1 | 5.49% | 13000 | ndavis at arin.net 4.00% | 1 | 5.27% | 12485 | mpetach at netflight.com 4.00% | 1 | 4.13% | 9770 | farmer at umn.edu 4.00% | 1 | 3.61% | 8556 | lsawyer at gci.com 4.00% | 1 | 2.71% | 6416 | narten at us.ibm.com 4.00% | 1 | 2.70% | 6394 | michael at linuxmagic.com --------+------+--------+----------+------------------------ 100.00% | 25 |100.00% | 236749 | Total From mpetach at netflight.com Sun Aug 24 18:34:23 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 24 Aug 2014 15:34:23 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <53F4F4FB.6010102@umn.edu> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> <53F4F4FB.6010102@umn.edu> Message-ID: On Wed, Aug 20, 2014 at 12:20 PM, David Farmer wrote: > On 8/20/14, 13:08 , John Curran wrote: > >> On Aug 20, 2014, at 12:24 PM, Ted Mittelstaedt wrote: >> >>> >>> Hi John, >>> >>> Embedded URLs are not really the problem - the problem is >>> MIME-encoded email and HTML-encoded email that have the embedded >>> URLs. >>> >> ... > > Ted - >> >> Point taken (and I am a huge fan of plain text email :-)... I will >> look into any downsides to this approach and report back to the list. >> > > I went back and looked at the latest validation email I got Aug 1 for my > POC, quite timely for this discussion. As far as I can tell it is not a > HTML email, but plain text email with a plain text URL, quoted below is the > relevant portion depersonalized. > > The following is your current POC Whois registration record. To validate, >> please take one of the actions listed below. If no action is taken within >> 60 days, your POC record will be marked invalid in ARIN's Whois. >> >> Your POC information in Whois is: >> > XXXXX > >> 1) If the information above is correct, please confirm by visiting: >> >> https://www.arin.net/public/pocValidation.xhtml? >> validationCode=XXXXXXXXXXX >> >> Alternatively, you may confirm by replying to this email. >> > For the truly paranoid, is there a place on arin.net where we can manually nagivate to the page, and then enter the validation code by hand (or copy-paste it into a web form) so that we can be sure it's going to the right place? Thanks! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sun Aug 24 18:47:16 2014 From: jcurran at arin.net (John Curran) Date: Sun, 24 Aug 2014 22:47:16 +0000 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> <53F4F4FB.6010102@umn.edu> Message-ID: <46364AE2-B574-4641-942A-93511488DAAB@arin.net> On Aug 24, 2014, at 6:34 PM, Matthew Petach > wrote: 1) If the information above is correct, please confirm by visiting: https://www.arin.net/public/pocValidation.xhtml?validationCode=XXXXXXXXXXX Alternatively, you may confirm by replying to this email. For the truly paranoid, is there a place on arin.net where we can manually nagivate to the page, and then enter the validation code by hand (or copy-paste it into a web form) so that we can be sure it's going to the right place? To my knowledge, there is not such an option today. Would you make use of such (as opposed to simply cut/paste of the URL or using the reply option)? /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpetach at netflight.com Sun Aug 24 19:23:25 2014 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 24 Aug 2014 16:23:25 -0700 Subject: [arin-ppml] Access to list of Number Resources with no valid POCs In-Reply-To: <46364AE2-B574-4641-942A-93511488DAAB@arin.net> References: <53F3B49F.2040802@ipinc.net> <785407E1-1AAB-4F53-9E89-5946EDDABE14@corp.arin.net> <53F4CBB3.3000704@ipinc.net> <72F926D2-0FA9-41F5-9A73-B723EA95887F@arin.net> <53F4F4FB.6010102@umn.edu> <46364AE2-B574-4641-942A-93511488DAAB@arin.net> Message-ID: On Sun, Aug 24, 2014 at 3:47 PM, John Curran wrote: > On Aug 24, 2014, at 6:34 PM, Matthew Petach > wrote: > > 1) If the information above is correct, please confirm by visiting: >>> >>> https://www.arin.net/public/pocValidation.xhtml? >>> validationCode=XXXXXXXXXXX >>> >>> Alternatively, you may confirm by replying to this email. >>> >> > For the truly paranoid, is there a place > on arin.net where we can manually > nagivate to the page, and then > enter the validation code by > hand (or copy-paste it into a > web form) so that we can be sure > it's going to the right place? > > > To my knowledge, there is not such an option today. Would you make use > of > such (as opposed to simply cut/paste of the URL or using the reply option)? > > /John > > John Curran > President and CEO > ARIN > > > I've started worrying more and more about copy-pasting seemingly-safe URLs that are UTF-8 encoded with alternate characters that map to what appear to be safe ascii characters; the use of plain-text email helps ameliorate that risk somewhat, but years of -T usage in perl have taught me to not trust any input I haven't validated for myself. In short--anything arriving into my inbox, I assume to be potentially compromised; much like with credit card companies, I prefer to dial their number myself, before giving any important information out. Thanks! Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Aug 29 00:53:02 2014 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 29 Aug 2014 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201408290453.s7T4r37U021941@rotala.raleigh.ibm.com> Total of 4 messages in the last 7 days. script run at: Fri Aug 29 00:53:02 EDT 2014 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 2 | 57.82% | 21940 | mpetach at netflight.com 25.00% | 1 | 24.01% | 9110 | jcurran at arin.net 25.00% | 1 | 18.17% | 6896 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 37946 | Total