Re: [sidr] LTAM Discussion and questions

[Christopher Morrow <[e-mail]>]

On Thu, Aug 15, 2013 at 5:38 PM, Stephen Kent <[e-mail]> wrote:
>
> 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.
>

ok... there seem to be several calls for 'please document what you mean to say'.

> 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.
>

this gets to some of the problem(s) that danny (and I think terry)
were concerned with... across administrative domains this all becomes
very dicey :( (or at least very undefined)

> 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.
>

sounds like 'crazy talk' (technical term), but sure.

>
> 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.

ok... so at the end of the day you are going to spin a draft to talk
about this in more detail, or that's what it sounds like you're
planning on doing :) If there were a draft out in the next say 4 weeks
we could have a better discussion about this on-list and then a longer
(and probably more fun) talk at the next meeting in Vancouver? Is 4wks
doable for this?

-chris