Chris,
I agree with several of the folks who commented about the LTAMv2
presentation and your call for comments.
We need to provide an updated description of the problems we are trying
to address, and details of how we propose to address these problems. The
slide presentation at the meeting was intended to provide a preview, but
it is not a substitute for detailed text.
So, let's begin the revised problem discussion, starting with text from
the most recent version of the LTAM doc (v8). BTW, this text has not
changed since the 00 version, dated November, 2010.
The abstract from the I-D(s) says:
The primary motivation for the facility described in this
document is to enable an RP to ensure that INR information
that it has acquired via some trusted channel is not
overridden by the information acquired from the RPKI
repository system or by the putative TAs that the RP imports.
This is still the primary motivation for LTAMv2, but I think it's worth
expanding on the rationale behind this mechanistic description of the
motivation. The concerns we are addressing are twofold:
-Local use of private (RFC 1918) address space in conjunction with RPKI
validation mechanisms
-Ways to recover from errors, or malicious actions, by CAs in the RPKI
hierarchy
In SIDR WG presentations we discussed the first rationale extensively.
The second concern was discussed more extensively in RIR meetings, where
the specter of law enforcement orders issued to RIRs was cited as a
significant concern by some folks.
As I mentioned in my presentation two weeks ago, we noticed that the
mechanism that we documented was probably fine for dealing with
allocations performed at the IANA and RIR tiers of the RPKI. So, for
example, if an RP wants to employ RFC 1918 private address space with
RPKI controls, the local TA mechanism, which makes use of "re-parenting"
and "hole punching" would work. However, if we use these mechanism to
"protect" address space for ISP-1, who received an allocation from ISP-2
(vs. from an RIR), problems could arise. Specifically, ROAs issued by
ISP-2 could be rejected by an RP using LTAM, due to hole-punching. This
was an unintended side-effect of the mechanism, one we would like to avoid.
The abstract also says:
This mechanism is designed for local use by an RP,
but any entity that is accorded administrative control over a
set of RPs may use this mechanism to convey its view of the
RPKI to RPs within its jurisdiction. The means by which this
latter use case is effected is outside the scope of this
document.
The lack of a description of how to securely distribute the LTAM
constraints file was viewed by some folks as a shortcoming. Moreover, we
were approached by an NIR that wanted to extend the capability noted
above. Their desire was to be able to publish resource allocation data
for folks in their country, for consumption both internally and
externally, in a way that would be immune to errors or malicious actions
by actors within the RPKI hierarchy (but outside of their country).
(This data needed to be valid as per the RPKI hierarchy, prior to any
errors or malicious actions, to limit the ability of a country to make
assertions about address space that was not allocated to entities within
the country.) No RPs outside of the country would have to pay attention
to this data, but they could make use of it if they wished (if there
were standards for how to make it available in a secure fashion). While
an NIR raised this issue, the concern is generally applicable,
irrespective of the presence of NIRs within a region.
We revisited the LTAM design to see if we could address the cited
motivation(s) via a mechanism that would not have the problem we noted
above, and if we could also address the concerns raised by the NIR.We
also received some comments on the document noting that the mechanisms
seemed complex, even after we revised the text to try to better explain
what was happening. So, a simpler design was also a goal. Finally, we
wanted to make the design a bit more flexible, to accommodate other
objects that might be added to the RPKI system in the future.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
