Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops-

From: Christopher Morrow <[email-masked]>
Date: Fri, 17 Aug 2012 11:03:10 -0400

Hello WG folk,
This draft has undergone 9 revisions since the last WGLC, which seemed
to end with requests for changes by the authors.
Can we now have a final-final-please-let's-progress WGLC for this
draft now? Let's end the call: 08/31/2012 (Aug 31 2012).

Htmlized version available at:
http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19

Abstract:
"Deployment of RPKI-based BGP origin validation has many operational
   considerations.  This document attempts to collect and present the
   most critical.  It is expected to evolve as RPKI-based origin
   validation is deployed and the dynamics are better understood."

Thanks!
-Chris
<co-chair-2-of-3>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Aug 2012 04:03:11 -0400

> draft now? Let's end the call: 08/31/2012 (Aug 31 2012).

Ok, Please let's progress this doc…

W

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

--
Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup.

---

From: Eric Osterweil <[email-masked]>
Date: Fri, 24 Aug 2012 15:18:38 -0400

I've reviewed this draft and have a number of comments:

At a high level, I think this draft is a very important piece of the sidr landscape, so I certainly applaud Randy for writing it.

- The second sentence in the abstract is a fragment, without a direct object.

Section 1 Intro:
- 1st paragraph: if we are going to predicate advice on terms like "widespread deployment," I think we need define them.  I know we all roughly know things like, "widespread means `a lot' of deployment," but the assertion that RPKI-based origin validation has a dependency on some level of penetration either needs to be qualified (or better yet, quantified) or removed, imho.

- 2nd para: "... the next year to five years." As a living document, this work might want to stay away from relative time references.  Will this statement need to be updated every year?
- 2nd para: "... eventually there will be a single root..." Is this assumed in order for this document's advice to matter?  It seems like operational advice ought to be more topical than this.  The advice in this draft is intended to be relevant before the single root, so this reference seems quite out of place.

- 3rd para: s/AS's/AS'/

Section 3:

- 2nd para: Some intuition behind _why_ hierarchy affects performance would be quite useful.

- 3rd para: As this is an operational document, and there is nothing else available, shouldn't this text explain that there is currently no choice of what to use?

- 4th para: The edict that operators should make use of the cache-chaining facility seems like it should have some operational explanation/justification/intuition/something.  It may be good advice, but shouldn't there be some rationale that allows for the evaluation of tradeoffs?
- 4th para: "Of course, the recipient relying parties SHOULD re-validate the date."  This makes it seem (imho) like the benefits of the immediately preceding advice might be lessened... Without an explanation of the rationale, the reader is forced to ask if doing this re-validtion wouldn't cause the same scaling worries as before the chaining.  Without a more detailed explanation, the reader really can't tell.

- 5th para: This seems quite inappropriate to me.  We need to know how this design will scale and function in an operational setting.  If there's any place that this should be discussed, it would seem to be here.  The operational behavior, configuration, and dynamics of the system seem like they must be described in the operational guidance documents.  How else should an operator know what configurations result in which behaviors, and scaling properties, etc?  I don't think this draft can simply punt by saying these operational concerns are beyond the scope of its operational guidance.

- 6th para: What if the objects in a network are multi-mastered?  I wasn't able to tell what this paragraph's guidance was, but it seemed to be a little narrow in its application.  Maybe it is superfluous?

- 7th para: I think this advice seems a little dilute, and may not be as useful as it could be.  Clearly, network configurations can be quite varied, right?  Since this is the case, I think it would be much more helpful for the author to build a strawman here, and overlay advice on it.  In fact, perhaps a set of running strawmen throughout the document would allow various pieces of advice to be hung on specific examples that operators could then adapt to their own configurations.  At the very least, it would provide some context, and possibly some additional substance to the document.

- 8th para: This seems like good advice, but it could use an example (i.e., the above comment).

- 9th para: This paragraph seems to give direction without intuition of the cost/benefits tradeoffs of this decision or the deployment decisions (like how many).  More generally, it seems like there is important advice to give here, but maybe the experts should frame the advice in terms of something like: what (specifically) does an operator pay for $n$ peers and what (specifically) does she gain?

- 10th para: I don't think the text is clear: it seems like upstreams carrying traffic and the trust one has in attestation objects are quite different.  I don't think this is an apt analogy, and it really confuses me (as a reader).  As a result, it's hard for me to understand what the point of that paragraph is (given the inapt analogy).
- 10th para: With the above caveat that I might not be understanding what is being said, the final sentence raises additional concerns for me.  If we recommend that operators use each others' caches, and then force them to revalidate, we are either introducing a new attack vector (cache poisoning of non-authoritative caches), or we increasing the attack surface of an existing attack vector (more caches must be validated because they can lie to me).  Either way, I don't see the benefit gained here, just the drawback.

- 11th para: How does trusting caches relate to mandatory revalidation?  As I read the text (at least, as written), it seems to me that this is a conflation of very different concepts.

- 12th para: Should we define the term ``super-block'' before using it here?  I'm more used to seeing it in the context of filesystems, but that doesn't mean we can't overload its definition here... I just think we need to do so before using it.

- 13th para: I think we need to add some context in this paragraph.  Specifically, I suggest adding the following text t the penultimate sentence, ``, but only for those external routers that have also deployed RPKI-based origin validation.''  And adding the following text to the final sentence, `` for just those RPs.''

- 15th para: I think it is important to be specific, and after claiming that something is ``more likely to be noticed,'' I think we ought to describe _how_ one might/should do so, in an operational setting.  As before, I'd suggest some advice be given through an example.

- 17th para: I think this paragraph makes good sense, but can we get a more quantitative discussion here?  I was just thinking that since this is an operational/engineering document, it might be good to shift this part from the qualitative end of the spectrum over more to the quantitative side.

- 20th para: This paragraph felt a little prescriptive from the policy/provisioning side, to me.  I caught myself wondering if this kind of advice really belongs here?  If it does, then maybe it would be more appropriate to just mention that proxy registration of this kind of data is an option, and cite how well that has worked elsewhere (like with IRRs and stuff)?

- 21st para: s/^While //
- 21st para: This paragraph suggest a period of ``four to six hours.''  I think we need some kind of explanation for these numbers.  As an operations document, it seems to me that we should be discussing tradeoffs and the relative value of different settings, etc.

Section 4:

- 2nd para: I worry that this advice is a little dilute, and (as a result) kind of falls a little limp (i.e., I was not able to clearly see what it was trying to explain).  I think if we had been carrying a strawman (or some strawmen) through the document, it would help bring the point of this paragraph into focus.

- 3rd para: In the same vein as the above, it seems like some examples/strawmen would be quite apropos.

Section 5: 

- 3rd para: ``10.0.666.0/24'' ?  maybe 10.0.6.0/24 ?

- 4th para: This paragraph seems to be offering tractable guidance.  Is there any thinking around the tradeoffs for when to change policy?

- 5th para: s/AS-path/AS_PATH/g

- 6th para: s/it's/its/

- 7th para: Should ``Local Pref'' be normalized to match earlier discussions of ``Local-Preference''?

- 10th para: I think we need to add a little bit of text.  Perhaps add to the last sentence, `` for the same prefix''?

Section 6:

- 1st para: The comment/implication that incoherency is a quality of all distributed caching systems is totally untrue.  In fact, there are many cache protocols with different specific consistency models that accomplish this.  To claim something is not being attempted with RPKI is one thing.  To claim that no system is able to accomplish this is quite different.  Moreover, why is this (clearly a design issue with RPKI) being discussed in this draft (an operational guidance draft)?  This seems like it is definitely the wrong place to talk about this, but regardless, the text is quite wrong.

- 2nd para: I think this paragraph brings up an important point, but doesn't mention a very important operational side effect of that point.  I suggest adding one more sentence to the end, ``Alternately, since no consistency model is attempted, it is possible that routing may not be able to converge in those networks deploying this approach without manual intervention.''

- 3rd para + 4th para: I don't understand how this paragraph is conveying helpful operational advice?

- 10th para: Why was 1 hour chosen?  What are the tradeoffs, etc?

Section 7:

s/AS-Path/AS_PATH/g

Thanks,

Eric

---

From: "George, Wes" <[email-masked]>
Date: Tue, 28 Aug 2012 17:03:35 -0400

I think we're ready to move this on, and I commend Randy for his work on it.

The only substantive comment I have is something that I believe Shane and I raised in previous versions' review and is not addressed yet. In section 3, where it discusses location of cache relative to routers "...'close' is of course complex..." - the current text still does not adequately explain why 'close' is a recommendation, or how latency might affect performance of the chosen deployment. This is a system that is by nature a loosely synchronized system, asymmetric in distribution of information, where elsewhere in this doc we say that the clock has to be accurate to the hour, which isn't exactly a high bar. If latency is a consideration, we need a bound on that - how much is too much latency such that the cache should be closer to the consuming router(s)? If there isn't a definite recommendation, what is the consideration that operators should be using to determine latency's impact? Is this just about latency's impact on TCP throughput, or is there something more complex to be considered?
I'd suggest text, but I still don't understand why geographic proximity matters. Reachability, sure, but not proximity.

Similarly with "consider trust boundaries..." - what should one be considering here? How are trust boundaries related to a cache's proximity to a given router?

I understand why bootstrap reachability between router and cache is important, but a few additional words about the reason might be helpful for the intended audience (that is, operators implementing RPKI for the first time)
Suggested text: "If the cache is not reachable via IGP or even locally, this will delay initial synchronization with the RPKI cache on boot, and may cause multiple BGP convergence events, first without RPKI data, and then again once RPKI data is synchronized."

Generally, if we are recommending that there should be some sort of proximity, we need to provide some rationale or a view into the considerations that went into that recommendation so that operators can make their own informed decision about placement, justify standalone equipment instead of VMs, etc. Otherwise, I can see having the following discussion with our systems folks internally:
"This RPKI cache thingy is just a server with an app running on it, right?"
"yeah"
"ok, we're going to stick it in a VM on our two national data center compute infrastructures like the rest of our servers, we can spin up more instances if you need to scale it"
"but RFC mumble mumble says that we shouldn't do that..."
"ok, why? And where do you want to put it?"
"ummm... 'close' to the routers? Because...reasons"

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christopher Morrow
> Sent: Friday, August 17, 2012 11:03 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [sidr] WGLC: draft-ietf-sidr-origin-ops-
>
> Hello WG folk,
> Can we now have a final-final-please-let's-progress WGLC for this draft
> now? Let's end the call: 08/31/2012 (Aug 31 2012).
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.