LAC-2020-10: Authorize Recipients of Delegated Blocks to Sign ROAs

General Information

Español
20/11/2020
Under discussion
29 %. The next step will depend on moderator's decision.

Hernan Moguilevsky - Version [1]
Initial discussion
23/11/2020 - 11/05/2021
First consensus
11/05/2021 - 25/05/2021

Public Comments by LACNIC Staff for this version

LACNIC Staff's Interpretation of the Proposal

Applicability:
This proposal would modify the Policy Manual.

Modifications to the current text:
This proposal would modify the Policy Manual, adding two paragraphs to Section 2.3.2.13. Registration of Assignments.

Breakdown of the section and its modifications:

● The proposal defines the following changes with respect to section 2.3.2.13. Registration of assignments:

2.3.2.13. Registration of Assignments
All IPv4 assignments of prefixes equal to or larger than a /29 made by an ISP to customers connected to their network and to users of the services they provide must be registered in LACNIC's WHOIS database not more than 7 days after the assignment. The information available in the WHOIS database will also be used by LACNIC when analyzing additional IPv4 address requests submitted by the ISP.

As long as the prefixes are registered in the WHOIS database, the receiving client will have the exclusive right to create and manage the RPKI Route Origin Authorization (ROA) certificates for said resources.

Such certificates will be managed by the technical contact of the receiving organization.

Assignments must also be registered for the following reasons:

- To ensure that the IR has finished or is close to finishing the allocation of their address space, such that the allocation of additional space is justified.
- To inform the Internet community which organization is using the IPv4 address space, including the point of contact in case of operational, security or other types of issues.
- To study IPv4 address allocation in the region.
- To facilitate the geolocation of sub-assignments made by members in our region.
- To strengthen Internet routing security, ensuring the proper implementation of RPKI.

LACNIC Staff Comments:

1. LACNIC considers that exclusivity is not necessary for the recipient of the delegated blocks, as ROAs can be created by both organizations.
2. LACNIC believes that the paragraph which states “Such certificates will be managed by the technical contact of the receiving organization” is not in line with the goal of this proposal, as the certificate is unique for the member organization.
3. LACNIC understands that the Policy Manual is a compendium of regulations on the functions of the RIR and the Policy Development Process. Therefore, it would not be appropriate to include the phrase “To strengthen Internet routing security, ensuring the proper implementation of RPKI” in this part of the Manual, as it would perpetuate an error we have not been able to avoid until now.
4. LACNIC understands that, when the receiving organization returns the sub-assignment, the ROAs it created will be revoked.

Recommendations

1. Remove the following sentence: “Such certificates will be managed by the technical contact of the receiving organization.”
2. Remove the term “exclusive” as it applies to the rights of the receiver.
3. Remove the following sentence: “To strengthen Internet routing security, ensuring the proper implementation of RPKI” and include it as part of the rationale behind the proposal.

Official References:
--------------------------------------------------------
Similar proposals at other RIRs:

RIPE NCC: The registry only allows this via “delegated mode.”

Impact of the policy on the registry and/or other systems
--------------------------------------------------------
If this proposal is approved, several LACNIC systems will be affected, including the RPKI system and MiLACNIC.

Considering that NIC.br <http://NIC.br> uses the delegated model, any entity that is part of the chain will be included in the certificate hierarchy. Therefore, the entity that receives the sub-assignment must manage their own CA, the certificate of which is signed by the provider that made the sub-assignment. This also involves the use of the up/down protocol between CAs (the provider's and the client's).


Summary

Once this policy is implemented, the technical contact of the organization receiving an IP prefix delegation from a provider will be able to sign the ROAs for said prefix for the duration of the delegation.

Rationale

This proposal seeks to solve the problems that those who receive prefixes delegated by their providers have for signing the ROAs for those prefixes.

Current Text

2.3.2.13. Registering assignments
All IPv4 address block assignments of a /29 or larger block made by an ISP to customers connected to their network and users of services provided must be registered on LACNIC's WHOIS database no more than 7 days after the assignment. The information available in the WHOIS database will also be used by LACNIC when analyzing additional IPv4 address block requests made by the ISP.

Assignment registration is also necessary for the following reasons:

- To ensure that the IR has completed or is close to completing address space allocation such that the allocation of additional space is justified.
- To inform the Internet community which organization is using the IPv4 address space, including the point of contact in case of operational, security or other types of issues.
- To study IPv4 address allocation within the region.
- To facilitate the geolocation of sub-assignments made by members in our region.

New Text
Analyze Diff

2.3.2.13. Registration of Assignments
All IPv4 assignments of prefixes equal to or larger than a /29 made by an ISP to customers connected to their network and to users of the services they provide must be registered in LACNIC's WHOIS database not more than 7 days after the assignment. The information available in the WHOIS database will also be used by LACNIC when analyzing additional IPv4 address requests submitted by the ISP.

As long as the prefixes are registered in the WHOIS database, the receiving client will have the exclusive right to create and manage the RPKI Route Origin Authorization (ROA) certificates for said resources.
Such certificates will be managed by the technical contact of the receiving organization.

Assignments must also be registered for the following reasons:
- To ensure that the IR has completed or is close to completing address space allocation such that the allocation of additional space is justified.
- To inform the Internet community which organization is using the IPv4 address space, including the point of contact in case of operational, security or other types of issues.
- To study IPv4 address allocation in the region.
- To facilitate the geolocation of sub-assignments made by members in our region.
- To strengthen Internet routing security, ensuring the proper implementation of RPKI.

Additional Information

The community has been discussing the need for this policy.
RPKI adoption continues to grow, so signing the ROAs should no longer depend on the holder of the recourses we have been delegated.

Timetable

-

References

-