Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.txt

From: [email-masked]
Date: Mon, 09 Jan 2012 07:11:53 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

	Title           : The RPKI/Router Protocol
	Author(s)       : Randy Bush
                          Rob Austein
	Filename        : draft-ietf-sidr-rpki-rtr-23.txt
	Pages           : 25
	Date            : 2012-01-09

   In order to formally validate the origin ASs of BGP announcements,
   routers need a simple but reliable mechanism to receive RPKI
   [I-D.ietf-sidr-arch] prefix origin data from a trusted cache.  This
   document describes a protocol to deliver validated prefix origin data
   to routers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-23.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-23.txt

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Jan 2012 10:13:51 -0500

the message does not include a nice bit the authors get

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-23

randy

---

From: Danny McPherson <[email-masked]>
Date: Mon, 9 Jan 2012 22:32:37 -0500

If the plan is indeed to employ connection-oriented TCP transport for rpki-rtr signaling in order to establish prospectively volatile soft-state in router control planes directly from RPKI-derived blobs -- i.e., beyond {prefix,origin} bindings to include {ASN, public_key, & SKI} for each EE certificate in the RPKI, as well as {ASN and associated IP prefixes} for each ROA in the RPKI then I'm glad these changes were made and they address my _actionable concerns with this document.  

Thanks for resolving these specific issues, 

-danny

On Jan 9, 2012, at 10:13 AM, Randy Bush wrote:

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Jan 2012 20:09:46 -0500

At 10:32 PM -0500 1/9/12, Danny McPherson wrote:
>If the plan is indeed to employ connection-oriented TCP transport 
>for rpki-rtr signaling in order to establish prospectively volatile 
>soft-state in router control planes directly from RPKI-derived blobs 
>-- i.e., beyond {prefix,origin} bindings to include {ASN, 
>public_key, & SKI} for each EE certificate in the RPKI, as well as 
>{ASN and associated IP prefixes} for each ROA in the RPKI then I'm 
>glad these changes were made and they address my _actionable 
>concerns with this document. 
>

I think you have taken the crown from Geoff, emitting the longest sentence
on the SIDR list :-).

---

From: Randy Bush <[email-masked]>
Date: Tue, 10 Jan 2012 18:30:23 -0800

> I think you have taken the crown from Geoff, emitting the longest sentence

with a little work, i can usually understand geoff's.  the above seems
to spend all of it's power budget on trying to appear erudite, and the
result is quite unintelligible to at least this st00pid geek.

but i think danny is happy with the changes.  and if danny is happy, i
guess i am.

randy

---

From: Danny McPherson <[email-masked]>
Date: Tue, 10 Jan 2012 23:13:03 -0500

> result is quite unintelligible to at least this st00pid geek.

Erudite is a fine choice of words here, I was hoping it'd 
lead to corrections from those more learned.  I ask that 
you please indulge me Randy, I suspect you've already 
got this all figured out.  

Let me ask a couple questions, that may help me resolve 
my confusions with this.

Do you foresee rpki-rtr being "augmented" for router on-
boarding of additional RPKI-derived data to enable things 
like those provided in the BGPSEC protocol document, e.g., 
S.5 of bgpsec-protocol I-D:

[snip]

5.  Processing a Received BGPSEC Update

   Validation of a BGPSEC update messages makes use of data from RPKI
   certificates and signed Route Origination Authorizations (ROA).  In
   particular, to validate update messages containing the
   BGPSEC_Path_Signatures attribute, it is necessary that the recipient
   have access to the following data obtained from valid RPKI
   certificates and ROAs:

   o  For each valid RPKI end-entity certificate containing an AS Number
      extension, the AS Number, Public Key and Subject Key Identifier
      are required

   o  For each valid ROA, the AS Number and the list of IP address
      prefixes

[/snip]

I labeled these things prospectively [more] volatile than current 
rpki-rtr "stuff", that may or may not be appropriate.
 
If this is the intention, then have you selected the publication 
dates for the documents that "augment" this brand new rpki-rtr 
protocol, I'd like to know when I need to factor those documents 
as well? 

A general observation is that while this piecemeal draft 
progression approach appears well designed to pass IETF 
publication gates, I'm not sure it's optimal for considering 
systemic and inter-dependency implications.

Alas...

> but i think danny is happy with the changes.  and if danny is happy, i

Excellent...

-danny

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Jan 2012 11:11:44 -0800

> Do you foresee rpki-rtr being "augmented" for router on- boarding of
> additional RPKI-derived data to enable things like those provided in
> the BGPSEC protocol document, e.g., S.5 of bgpsec-protocol I-D:

i think so, but i am a bit worried as about this waterboarding stuff.

> protocol

i think the norm is to get some experience with v0 (the protocol version
number in the pdus, a la bgp_4_) before going to v1.  but, as with most
things, i could be wrong.

> I'd like to know when I need to factor those documents as well?

as i have no idea how to factor a document or how much lead time
factoring takes, even if i knew when v1 could be out which i don't, i
would not be able to answer.

> A general observation is that while this piecemeal draft progression
> approach appears well designed to pass IETF publication gates

perhaps a focus on engineering, as opposed to mis-guessing and impugning
others' motives, would be productive.

in the current taxonomy, there are three pieces, the rpki, rpki-based
origin validation, and then path validation.  rpki-rtr as it stands is
part of origin validation, and the docs for origin validation are going
through the sausage machine now.  path validation is in early to mid
design, documents are in high flux or unwritten, and are nowhere near
ready to be considered sausage.

the semantics of an rpki-rtr pdu needed to support the most recent path
validation drafts are obvious.  but, as principal author of rpki-rtr, i
am already grossly and embarrassingly behind on revisions of at least
three other docs (two for origin validation!!), origin-ops,
pfx-validate, and bgpsec-reqs.  so i have no time to chase document
drift in the very drafty path validation specs even if it was
appropriate to do so, which imiho it is not.  they're drifty enough that
an interim is being held just to discuss one tough aspect and see if a
very different conceptual area can be understood well enough to be added
to the goals.

and getting v0 of rpki-rtr through the sausage machine already has
consumed a silly amount of wall clock, tyvm.

randy

---

From: Danny McPherson <[email-masked]>
Date: Thu, 12 Jan 2012 20:20:16 -0500

> i think so, but i am a bit worried as about this waterboarding stuff.

I think simple things like asking that rpki-rtr connection-oriented 
transport require protections is reasonable in 2012, particularly
given that the current specification is unsigned prefix,origin 
binding data (i.e., otherwise no object or transport protections).

> things, i could be wrong.

This is important.  If you just needed origin,prefix bindings in 
soft-state in the router there are lots of ways you could do that
today without a new protocol (to include with BGP itself).  

If the objective is to use rpki-rtr protocol to onboard actual rpki-rtr
data into the router control plane, e.g., to accommodate 
requirements by BGPSEC, then getting those rpki-derived signed 
blobs in the router is a much higher frequency function and may 
well justify some new onboarding protocol.  

> would not be able to answer.

Cute...

If you were designing rpki-rtr protocol to load rpki data into routers 
(rtrs) then before standardizing rpki-rtr protocol it would seem to me
we should fully consider at least the initial use case that justifies a 
brand new protocol -- before we 'augment' it with new lego blocks.

If not, then I suggest to the WG that we require a proposal from 
the bgpsec-protocol team for how they intend to accommodate 
their own requirements to onboard this data before we continue 
that work.

> others' motives, would be productive.

Which portion am I mis-guessing here, can you be specific? Is the 
BGPSEC design team NOT intending to use rpki-rtr protocol to get
RPKI-derived signed blobs on the router in order to enable BGPSEC?
Your own presentations in operations fora suggestions your thinking 
is rather evolved already in this area.

Attempting to assemble the legos blocks in sidr land and determine 
what the implications might be for operations at the end of the day is 
indeed engineering and architectural in nature, do you disagree?
Should we not be considering and questioning the systemic and 
inter-dependencies these new standards introduce?

> ready to be considered sausage.

Perhaps we need to do some architectural work then, and not build 
blocks that are supposed to be pieced together without some amount
of systemic consideration.

Let me give you a simple example..  We're saying RPKI needs 
algorithm agility.  If RPKI was fully deployed, and BGPSEC was 
deployed, and rpki-rtr were used to onboard BGPSEC-required 
signed blobs as specified in the BGPSEC protocol document, 
e.g., S.5 of bgpsec-protocol I-D, then during algorithm rollover 
would the following potentially be required:

1) many  more RPKI objects
2) many more RPKI-derived signed blobs the relying parties (routers) 
    potentially need to onboard via rpki-rtr and store in soft-state
3) more BGPSEC signed data in the routing system
4) more churn in all the elements that rely in RPKI data in subsequent 
    periodic updates, "beacon" functions, etc.
5) BGPSEC speakers as relying parties would need to consider 
    algorithm suites from either new or old algorithms when performing 
    validation from independent certificate hierarchies
6) some other stuff, I suspect.

I think it's all of the above, but I may very well be wrong and I 
don't have this all figured out..  I do know that there are systemic 
implications of many of these things, particularly in concert.

I think consideration of these issues, i.e., the systemic implications 
of a set of assembled lego blocks is within the purview of both the 
iEtf and this WG.   

-danny