From info at arin.net Tue Jan 23 11:11:52 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 11:11:52 -0500 Subject: Policy Proposal: Reinstatement of PGP Authentication Method - revised text Message-ID: <45B633C8.3030608@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 2 November 2006 the ARIN Advisory Council (AC) reviewed 'Reinstatement of PGP Authentication Method (Version 1)' and decided to work with the author to revise the text. The author revised the text. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Reinstatement of PGP Authentication Method Authors Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 2 Proposal type: New Policy term: Permanent Policy statement: ADDITION TO NRPM 12 Authentication Methods ARIN supports three authentication methods for communication with resource recipients. 12.1 Mail-From This section intentionally left blank. 12.2 PGP ARIN accepts PGP-signed email as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 12.3 X.509 This section intentionally left blank. UPDATES TO TEMPLATES ARIN shall include a field in templates as necessary to identify and distinguish between cryptographic and mail-from authentication methods, generally following the practices of the other RIRs. UPDATES TO DOCUMENTATION ARIN shall update documentation as appropriate, to explain the differences between mail-from, PGP, and X.509 authentication methods. KEY USE IN COMMUNICATION: ARIN shall accept PGP-signed communications, validate the signature, compare it to the identity of the authorized POCs for records referenced in the correspondence, and act appropriately based upon the validity or invalidity of the signature. ARIN shall PGP-sign all outgoing hostmaster email with the hostmaster role key, and staff members may optionally also sign mail which they originate with their own individual keys. ARIN shall accept PGP-encrypted communications which are encrypted using ARIN's hostmaster public key. ARIN shall not encrypt any outgoing communications, except by explicit mutual prior agreement with the recipient. NON-BINDING RECOMMENDED KEY MANAGEMENT PRACTICES: It is recommended that ARIN utilize normal POC-verification processes as necessary to accommodate users who lose the private key or passphrase associated with the POCs for their crypt-auth protected resources. It is recommended that ARIN exercise reasonable caution in preventing the proliferation of copies of the hostmaster private key and passphrase. It is recommended that ARIN print out a copy of the private key and passphrase, and secure them in a safe-deposit box outside of ARIN's physical premises, which any two ARIN officers might access in the event that the operating copy of the key is lost or compromised. It is recommended that ARIN publish the hostmaster public key on the ARIN web site, in a manner similar to that of the other RIRs: http://lacnic.net/hostmaster-pub-key.txt https://www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc ftp://ftp.apnic.net/pub/zones/PUBLIC_KEY It is recommended that ARIN publish the hostmaster public key by submitting it to common PGP keyservers which, among others, might include: pgp.mit.edu www.pgp.net It is recommended that ARIN attempt to cross-sign the hostmaster PGP keys of the other four RIRs and ICANN. It is recommended that ARIN's hostmaster public key be signed by members of the ARIN board of trustees. Rationale: Globally, PGP is the most commonly used cryptographic authentication method between RIRs and resource recipients who wish to protect their resource registration records against unauthorized modification. The PGP-auth authentication method is supported by RIPE, APNIC, and AfriNIC, LACNIC supports an equivalent mechanism, and it was historically supported by the InterNIC prior to ARIN's formation. By contrast, current ARIN resource recipients have only two options: "mail-from," which is trivially spoofed and should not be relied upon to protect important database objects, and X.509, which involves a rigorous and lengthy proof-of-identity process and compels use of a compatible MUA, a combination which has dissuaded essentially all of ARIN's constituents. Additionally, X.509's centralized failure mode is technically and ideologically repugnant to some members of the community, who should not be forced to choose between two evils. There isn't a lot of work to do here, and certainly nothing tricky. PGP is simple code, which was supported by the InterNIC, and which the other RIRs deployed without a second thought or complaint. If RIPE and APNIC have always done this, the InterNIC did it before ARIN was formed, and LACNIC and AfriNIC took the need for cryptographic security for granted as a part of their startup process, we see no reason why ARIN should be the only RIR to not offer this most basic of protections to its members. We need to get PGP support reinstated, so that our records can be protected against hijacking and vandalism, and so we won't look like idiots as the only one of the five regions that can't figure this stuff out. Timetable for implementation: Immediate From info at arin.net Tue Jan 23 11:12:16 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 11:12:16 -0500 Subject: Policy Proposal: Documentation of the Mail-From Authentication Method - revised text Message-ID: <45B633E0.3050707@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 2 November 2006 the ARIN Advisory Council (AC) reviewed 'Documentation of the Mail-From Authentication Method (Version 1)' and decided to work with the author to revise the text. The author revised the text. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the Mail-From Authentication Method Authors Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 2 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.1 Mail-From This section intentionally left blank. ADDITION TO THE NRPM 12.1 Mail-From Mail-From is the default authentication method by which registration records are protected from vandalism. If a registrant fails to designate a more secure method, any subsequent email which bears the sender address of an authorized Point of Contact may be deemed authentic with regard to the registrant's records. Since it is trivial to forge a sender address, Mail-From should not be regarded as secure. Use of Mail-From authentication is not recommended to any registrant who has the means to implement either of the more secure cryptographic authentication methods. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the mail-from authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Tue Jan 23 11:12:31 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 11:12:31 -0500 Subject: Policy Proposal: Documentation of the X.509 Authentication Method - revised text Message-ID: <45B633EF.70703@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 2 November 2006 the ARIN Advisory Council (AC) reviewed 'Documentation of the X.509 Authentication Method (Version 1)' and decided to work with the author to revise the text. The author revised the text. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Documentation of the X.509 Authentication Method Authors Paul Vixie Mark Kosters Chris Morrow Jared Mauch Bill Woodcock Proposal Version: 2 Proposal type: New Policy term: Permanent Policy statement: DELETION FROM THE NRPM 12.3 X.509 This section intentionally left blank. ADDITION TO THE NRPM 12.3 X.509 ARIN accepts X.509-signed transactions as authentic communication from authorized Points of Contact. POCs may denote their records "crypt-auth," subsequent to which unsigned communications shall not be deemed authentic with regard to those records. 8. Rationale: This policy complements the previously-proposed "Reinstatement of PGP Authentication Method" which introduces section 12 to the NRPM. Section 12 relates the existence of three authentication methods. Two of those, mail-from and X.509, were preexisting but not documented within the NRPM. This policy proposal simply seeks to provide brief documentation of the existence of the X.509 authentication method. Because the specific wording of the documentation may be subject to debate, and is in no way interdependent upon the documentation of the other two methods, it is being proposed in a separate policy, so that consensus may be more easily reached. Timetable for implementation: Immediate From info at arin.net Tue Jan 23 15:36:31 2007 From: info at arin.net (Member Services) Date: Tue, 23 Jan 2007 15:36:31 -0500 Subject: Deadline for Policy Proposals - 22 February 2007 Message-ID: <45B671CF.4050307@arin.net> The ARIN XIX Public Policy Meeting will take place 23-24 April 2007 in San Juan, Puerto Rico. New policy proposals must be submitted by 23:59 EST, 22 February 2007, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XIX agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Jan 24 10:04:58 2007 From: info at arin.net (Member Services) Date: Wed, 24 Jan 2007 10:04:58 -0500 Subject: Policy Proposal: Changes to IPv6 policy - removal of "interim" consideration Message-ID: <45B7759A.2050902@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Changes to IPv6 policy - removal of "interim" consideration Author: Jordi Palet Martinez Proposal Version: 1 Proposal type: delete Policy term: permanent Policy statement: Delete following text at section 6.1.1. of NRMP: "This policy is considered to be an interim policy. It will be reviewed in the future, subject to greater experience in the administration of IPv6." Rationale: The actual text suggest that it is an interim policy, however it is not longer the case. It is clear that any policy is always subjected to changes, however other policies don't have such text. It may be even considered as a negative "message" for IPv6 deployment, especially because the possible "reading" as "not enough experience and this is going to be changed, better wait", which is not a real situation. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Wed Jan 24 10:05:09 2007 From: info at arin.net (Member Services) Date: Wed, 24 Jan 2007 10:05:09 -0500 Subject: Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification Message-ID: <45B775A5.6020603@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" justification Author: Jordi Palet Martinez Proposal Version: 1 Proposal type: delete Policy term: permanent Policy statement: Delete section 6.5.4.2. of NRMP. Rationale: The current text requires the LIR to justify to the RIR/NIR when assigning multiple /48s to a single end site. It seems that the reason for this requirement is the lack of experience, which seems unreasonable after a few years this policy has been implemented, even if may not have been specific cases which used this policy section. It seems useless, now that there is already deployment experience, to require a justification from the LIR to ARIN for assigning multiple /48s (or a shorter prefix, such as for example a /47). It is up to the LIR to require the justification to its own customers and decide according to it. The LIR will be already responsible to justify to ARIN the usage of any allocated block(s) when requesting for more, and this will already implicate an implicit justification of this kind of assignments. With this policy change, both ARIN and LIR staff will save resources in a justification, which seems unnecessary and should be completely on the hands of the LIR itself. No financial/liability implications for the community and ARIN are foreseen. No special conditions, fees, exceptions, etc. seem to be required. Timetable for implementation: Immediate From info at arin.net Fri Jan 26 15:55:26 2007 From: info at arin.net (Member Services) Date: Fri, 26 Jan 2007 15:55:26 -0500 Subject: Policy Proposal: Changes to IPv6 policy - removal of "multiple /48" justification In-Reply-To: <20070125222021.DA15714445C@smtp2.arin.net> References: <20070125222021.DA15714445C@smtp2.arin.net> Message-ID: <45BA6ABE.9000702@arin.net> Hi Andrew- ARIN has not registered a large number of IPv6 reassignments. However, of those that we have registered, many of them are for initial reassignments of multiple /48s to the same organization. In fact, out of a total of 115 reassignment registrations, 56 of them are larger than a /48. To date, we have not seen requests for additional reassignments of /48s to the same organization. Our registration software however, is programmed to flag additional reassignments of this type. Currently, ARIN is not asking for justification for these larger initial reassignments. The policy text as written is unclear and contains no criteria for the RIR to use to assess justification. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers Andrew Dul wrote: >>Policy Proposal Name: Changes to IPv6 policy - removal of "multiple /48" >>justification >> >>Author: Jordi Palet Martinez >>Proposal Version: 1 >>Proposal type: delete >>Policy term: permanent >>Policy statement: >> >>Delete section 6.5.4.2. of NRMP. >> > > > When you delete section 6.5.4.2 of the NRPM you are left with only the > following phrase as a guideline in determining the assignment of multiple > /48s. > > "...except in cases of extra large end sites where a larger assignment can > be justified.", section 6.5.2.1. > > If the goal of this policy change is to remove the requirement for the RIR > to check a multiple /48 assignment to an endsite, then this policy should > define the criteria for an LIR to determine if a larger than /48 assignment > is needed. Without a criteria in policy an LIR could choose to assign any > size block to an endsite. Under the wording of section 6.5.2.1 only the > word "justified" can be labeled as a criteria for determining the > assignment size. How is "justified" defined for an endsite in this context? > > While most LIRs are usually reasonable, to me it seems important to include > defined and somewhat rigorous criteria for the assignment of multiple /48s > and a requirement for the LIR to record this justification for later > auditing by the RIR when an LIR returns to the RIR for an additional > allocation. > > >>Rationale: >> >>The current text requires the LIR to justify to the RIR/NIR when >>assigning multiple /48s to a single end site. It seems that the reason >>for this requirement is the lack of experience, which seems unreasonable >>after a few years this policy has been implemented, even if may not have >>been specific cases which used this policy section. >> > > > I think the section was reasonably written as a throttle to excessive IPv6 > assignments to endsites by LIRs. > > >>It seems useless, now that there is already deployment experience, to >>require a justification from the LIR to ARIN for assigning multiple /48s >>(or a shorter prefix, such as for example a /47). It is up to the LIR to >>require the justification to its own customers and decide according to >>it. The LIR will be already responsible to justify to ARIN the usage of >>any allocated >>block(s) when requesting for more, and this will already implicate an >>implicit justification of this kind of assignments. > > > That is not the way I read section 6.5.4.1 > > "RIRs/NIRs are not concerned about which address size an LIR/ISP > actually assigns. Accordingly, RIRs/NIRs will not request the detailed > information on IPv6 user networks as they did in IPv4, except for the cases > described in Section 6.4.4 and for the purposes of measuring utilization as > defined in this document." > > I read section 6.5.4.1 to allow an LIR to keep no records about the > justification for assignments to endsites. > > > >>With this policy change, both ARIN and LIR staff will save resources in >>a justification, which seems unnecessary and should be completely on the >>hands of the LIR itself. >> > > > How many times have ARIN staff had to evaluate the assignment of multiple > /48s to endsites so far? Is this really an issue? > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml >