On Thu, Aug 15, 2013 at 5:38 PM, Stephen Kent <k...@bbn.com> 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 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
