Subject: [sidr] LTAM Discussion and questions

From: Christopher Morrow <[email-masked]>
Date: Fri, 9 Aug 2013 13:26:51 -0400

During the Wednesday IETF meeting there was a presentation by Stephen
Kent about the LTAM current draft and outlining what problems the
authors of the document foresaw with using LTA's in practice. Some of
these ideas/problems had come up previously on-list or in meetings...
some perhaps had not?

In the end... the discussion seemed to get to:
   1) the LTAM doc and design and ideas are in need of more discussion
and perhaps a rework

   2) there may be a document to be written, or the current document
might need to be re-written

   3) there is potential for the LTAM/LTA work to require a full
design-team to be chartered and a longer cycle of discusison/etc to be
done.

Could we chat on-list about this? doing it only in the in-person
meeting isn't super cool :)

-chris
co-chair-like-person

---

From: Geoff Huston <[email-masked]>
Date: Sat, 10 Aug 2013 08:04:38 +1000

> design-team to be chartered and a longer cycle of discusison/etc to be

As I recall the main content of the comments at the WG meeting was that 
without a document that detailed the concepts behind the presentation, 
the presentation did not make much sense. In the continuing absence of
a draft, what's changed?

And even if we were to discuss this, then why not broaden the
discussion to understand why this is such a difficult problem - i.e.
why not re-open the WG to consider the entire concept of RPKI 
certificate validity?

But you are asking for the WG discuss the slide pack???

OK. 

I thought the last slide was kinda cute.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 9 Aug 2013 20:00:50 -0400

> the presentation did not make much sense. In the continuing absence of

I think nothing's really changed, except that the number of people in
the room != number of people involved in the sidr-wg? so I was hoping
to recap the conversation and push on the appropriate direction:
"write document to describe problem" or "nothing to see here, you are
crazy" or "wow, we really need to rethink this, design-team it!"

> why not re-open the WG to consider the entire concept of RPKI

i suppose we could go that route, though I am hoping it's not necessary?

> I thought the last slide was kinda cute.

great! progress!

-chris

---

From: Randy Bush <[email-masked]>
Date: Sat, 10 Aug 2013 09:30:41 +0200

> to recap the conversation and push on the appropriate direction:

cool.  so please recap.  as there is no draft, and the preso did not
really describe it in useful detail, good luck.

this needs a design team.

randy

---

From: Terry Manderson <[email-masked]>
Date: Sun, 11 Aug 2013 18:30:12 -0700

Please, before a design team, I would like to see an unambiguous problem
statement and a scoped set of requirements to deal with that problem
statement. 

I would feel more comfortable having the design team address those once we
collectively agree on the problem and requirements.

Cheers
Terry

On 10/08/13 5:30 PM, "Randy Bush" <[email-masked]> wrote:

>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Mon, 12 Aug 2013 09:33:38 -0300

Hello,

On Sun, Aug 11, 2013 at 10:30 PM, Terry Manderson <[email-masked]
> wrote:

> collectively agree on the problem and requirements.

+1

I commented on the mic that I thought this was a problem worth solving,
but, I also believe that the problem needs to be better defined.

cheers,

~Carlos

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Aug 2013 17:38:03 -0400

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

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 23 Aug 2013 18:06:01 -0400

On Thu, Aug 15, 2013 at 5:38 PM, Stephen Kent <[email-masked]> wrote:
> 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.
>
> This is still the primary motivation for LTAMv2, but I think it’s worth
> -   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.
>
>
>
> 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 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.

> 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

---

From: Stephen Kent <[email-masked]>
Date: Sat, 24 Aug 2013 08:48:22 -0400

Chris,
> ok... there seem to be several calls for 'please document what you mean to say'.
and a separate call for starting with a characterization of the problem, 
hence the message
that I sent.
> very dicey :( (or at least very undefined)
My observation was that if one used the mechanism we initially 
described, then re-homing an ISP, to "protect" a prefix allocated by 
that ISP to another entity, would cause problems re ROAs. This problem 
is independent of crossing administrative domains. I don't recall anyone 
ever commenting about this issue since we first published the LTAM spec!
> sounds like 'crazy talk' (technical term), but sure.
Actually this is a very reasonable response to concerns that have been 
raised
about national sovereignty vs. the address allocation hierarchy. I 
suggest the US
DoD follow this approach.
> (and probably more fun) talk at the next meeting in Vancouver? Is 4wks
yes.

Steve