Subject: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

From: Chris Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 11:26:27 -0400

(bcc: iesg-secretary)

SIDR folk,

A draft agenda for the April 30, 2012 meeting is below:

0900-1200 deployment discussion (walkthrough/document/discuss deployment
   scenarios)

1300-1600 o router/prefix/roa/crl - rpki repository data freshness

1600-1700 prefix validate discussion

This will also appear (shortly) at:
  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
  (sidr wiki page)

-Chris
<co-chair>
(if the iesg-secretary folk have no action here... then I'll NOT add
them in the future)

---

From: Danny McPherson <[email-masked]>
Date: Tue, 10 Apr 2012 20:48:02 -0400

Chris, 
Can you expand on these, I'm not sure I know what to read or propose in order to prepare..  

Also, are we collecting requirements for these (e.g., object scale, RPs, etc..)?  Basing these discussions on requirements that exist somewhere already?  Or simply discussing solutions that have already been developed and deployment experience?  If the latter, then we can we ensure we reference and prepare to discuss what requirements drive to the development of those solutions?

Also, it looks to me like we're in dire need of a charter update...

-danny

On Apr 10, 2012, at 11:26 AM, Chris Morrow wrote:

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

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 10 Apr 2012 20:56:25 -0400

> Can you expand on these, I'm not sure I know what to read or propose in order to prepare..

yes, my goal was to have updated the wiki today at the office, work
intruded... tomorrow I'll do that with some more content for each
item, and hopefully better coordinates as well for the location.

> Also, are we collecting requirements for these (e.g., object scale, RPs, etc..)?  Basing these discussions on requirements that exist somewhere already?  Or simply discussing solutions that have al…

I think the only bit in the 3 that has a current 'requirements'
discussion is the 'freshness' (item 2). The first item 'deployment
discussion' is really a discussion of:
  "Should there be some document that describes the top N (3?)
deployment scenarios && where should that document/presentation/etc
live?" (I suppose implicit in that is 'requirements for format,
content, intended audience')

> Also, it looks to me like we're in dire need of a charter update...

for which? (I didn't think that any of the 3 items was actually
outside of the current charter)

-chris

---

From: Danny McPherson <[email-masked]>
Date: Tue, 10 Apr 2012 21:15:44 -0400

> item, and hopefully better coordinates as well for the location.

Thanks.

> content, intended audience')

I was thinking more simply along the lines of "a fully deployed RPKI today would have o objects and r RPs a c churn and we ought to ensure our designs accommodate that" -- only then can we have a reasonable discussion on, e.g., data freshness?  What have we based these design goals on thus far - do we have a stable reference for this?

From there, we can discuss the issue of, for example, HOW TO onboard and purge signing and validating certificates to routers from the RPKI -- [I suspect the intention was to use rpki-rtr protocol for this, but it doesn't currently support it, nor are the security implications clear].  

Only when we get to that point will we really begin to understand the dynamics of RPKI and it's employment for secure routing (well beyond "authorized" origin policy configuration), and the impact of rate+state in both the RPKI and it's effectuating in the routing system, and perhaps most importantly, the inter-dependencies between the two (even basic stuff like the rate of updates from an RPKI cache to a router in a fully loaded system given today's RPKI object counts).

> outside of the current charter)

I meant the goals and milestones, apologies for not being clear.

-danny

---

From: Arturo Servin <[email-masked]>
Date: Wed, 11 Apr 2012 11:09:15 +0200

May be is somewhere and I could not find it, but, what is the timezone?

Thanks!
.as

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 09:36:09 -0400

>        May be is somewhere and I could not find it, but, what is the timezone?

wait, not everyone is in Hawaii time? :)

EDT is the TZ, I should have added that, it IS on the wiki page now.

thanks!
-chris

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 11 Apr 2012 17:28:34 +0000

speaking as regular ol' member

On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [[email-masked]] said:

>From there, we can discuss the issue of, for example, HOW TO onboard 
>and purge signing and validating certificates to routers from the RPKI -- 
>[I suspect the intention was to use rpki-rtr protocol for this, but it doesn't 
>currently support it, nor are the security implications clear].

I can not  understand your comment.  What do you mean by "signing certificates"?   

I can guess that "validating certificates" means the certs carrying public keys used to validate signatures, but the "signing certificates" part has me stumped.

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Danny McPherson [[email-masked]]
Sent: Tuesday, April 10, 2012 9:15 PM
To: Christopher Morrow
Cc: sidr wg; [email-masked]; [email-masked]
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)

Thanks.

-danny

---

From: Chris Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 13:30:58 -0400

On 04/11/2012 01:28 PM, Murphy, Sandra wrote:
>> From there, we can discuss the issue of, for example, HOW TO
>> onboard and purge signing and validating certificates to routers
>> from the RPKI 

> I can guess that "validating certificates" means the certs carrying
> public keys used to validate signatures, but the "signing
> certificates" part has me stumped.

router ee-cert ... I believe he means (what signs outbound for this ASN
on the router doing eBGP)

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 13:35:26 -0400

>> item, and hopefully better coordinates as well for the location.

I think the 2 above items are done... please have a look when you get
some time, comments/questions welcome.

> I was thinking more simply along the lines of "a fully deployed RPKI today would have o objects and r RPs a c churn and we ought to ensure our designs accommodate that" -- only then can we have a r…

hopefully this is captured in the wiki update.

> From there, we can discuss the issue of, for example, HOW TO onboard and purge signing and validating certificates to routers from the RPKI -- [I suspect the intention was to use rpki-rtr protocol…

The rtr cert/ee-cert part was never planned/designed to be done via rpki-rtr.
Ideally at provisioning time your ee-cert is dropped onto the box,
similar to base-config today. Potentially your fav vendor has a
methodology in their plan for this. I can't imagine it's too tough,
nor that it's exact specification needs to be in an IETF doc (since it
seems implementation specific). Could be wrong though.

> Only when we get to that point will we really begin to understand the dynamics of RPKI and it's employment for secure routing (well beyond "authorized" origin policy configuration), and the impact…

sure, some modelling seems like a good thing here, I think this was
asked for at the mic in PAR as well, no? (in response to some
discussions with Sriram?)

> I meant the goals and milestones, apologies for not being clear.

we can chat about that on-list or in the meeting... I suppose there's
a slew of milestones which are 'complete', there aren't really any
changes (that I planned) from an 'adding things' perspective. The
ops-documentation (see wiki) to me is probably NOT an ietf document,
again happy to talk at the meeting about that though.

-chris

---

From: Danny McPherson <[email-masked]>
Date: Wed, 11 Apr 2012 13:45:09 -0400

> seems implementation specific). Could be wrong though.

It has huge implications on the scale and operations, particularly when considering how rollovers and other such changes are effectuated.  Also, decoupling these entirely from validating certificates means I've got two mechanisms now for on-boarding [just] these things.  I'd prefer not to leave this to "magic happens" given that it's foundational to pretty much everything else that's being built.

> discussions with Sriram?)

Yep!

> again happy to talk at the meeting about that though.

I'd be interested in lining out the longer-term deliverables for the group on the list..

-danny

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 13:49:40 -0400

On Wed, Apr 11, 2012 at 1:45 PM, Danny McPherson <[email-masked]> wrote:
> From there, we can discuss the issue of, for example, HOW TO onboard and
> purge signing and validating certificates to routers from the RPKI -- [I
> suspect the intention was to use rpki-rtr protocol for this, but it doesn't
> It has huge implications on the scale and operations, particularly when

right: "Dear vendor, if you do this with a GUI only option I will stab
you in the eye"

I suppose, to me this looks like any other configuration thing you do
today on routers... beating the vendor over the head to support sane
(netconf? maybe?) methods for provisioning, is already done.

> considering how rollovers and other such changes are effectuated.  Also,

rollovers == acl-updates == routing-policy-updates == ntp server
reconfig == .... normal router configuration processes.

> decoupling these entirely from validating certificates means I've got two
> mechanisms now for on-boarding [just] these things.  I'd prefer not to leave

or another configuration bit to sling, yes.

> this to "magic happens" given that it's foundational to pretty much
> everything else that's being built.

copy my comment to vendors, into your rfp.

> discussions with Sriram?)

ok, so ... got proposal? I think Sriram is itching/looking for how to
get a more reasoned approach to this (or that seemed to be his intent
at the mic).

> I'd be interested in lining out the longer-term deliverables for the group

sure, shoot.

---

From: Danny McPherson <[email-masked]>
Date: Wed, 11 Apr 2012 13:57:43 -0400

> (netconf? maybe?) methods for provisioning, is already done.

So how we onboard, update, or purge information from RPKI and sign stuff on n routers in z locations that 10's of thousands of others will evaluate in millions of routers to determine reachability of our information is relegated to "out of scope" of SIDR?

Gotcha - done here....

-danny

---

From: Chris Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 14:08:29 -0400

On 04/11/2012 01:57 PM, Danny McPherson wrote:
> 
> 
>> I suppose, to me this looks like any other configuration thing you
>> do today on routers... beating the vendor over the head to support
>> sane (netconf? maybe?) methods for provisioning, is already done.
> 
> So how we onboard, update, or purge information from RPKI and sign

I think there are 2 things here:
  1) router-signing-cert (ee-cert?)
  2) rpki-digested-data (prefix + origin + cert-sig/etc)

they don't have to get to the router in the same way, do they? (I
suppose they COULD, but that isn't necessarily mandatory and isn't how
it's currently spec'd)

> stuff on n routers in z locations that 10's of thousands of others
> will evaluate in millions of routers to determine reachability of our

wait, now you added a 3rd item:
  3) rpki data repository/publication-point

> information is relegated to "out of scope" of SIDR?

nope, I think the part I was talking about was JUST #1 above. you put
that cert on your router in some implementation-specific manner. Does
the IETF have to (should it?) state there are some operational security
concerns with this? ie: "It is probably a bad idea to copy/paste an
unencrypted private key on a telnet session across the open Internet to
the router."  (that sort of thing could be placed in the bgpsec-ops doc,
it's not there as near as I can tell today).

-chris

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 14:09:33 -0400

(-home-email ... never should have started that:( )

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Apr 2012 14:23:43 -0400

My understanding is, that at least for the origination aspect, the
"freshness" argument is that the keys get rolled periodically.
And this has to occur on all the routers, with new keys published along
with the key roll, and possibly a unique key per router.

So, the key roll frequency alone, there are operational scalability things
to be concerned about.

The keys in question (which go into ee-cert?) have to have private keys on
routers, and public keys in RPKI, right?

This isn't a "do it once when you build the router" thing, this is a live
update of all aspects of the whole system (router + RPKI).

As in, we should probably take at least some of the time allotted for the
meta-discussion of, is private/public key really what we should be doing
here?
And if so, what are the ways that that can be done, with some analysis of
scaling factors (order of magnitude at a minimum).

E.g. it is one thing to say "sort the data", and quite another thing to say
"When you sort the data, be aware that bubble-sort is really a bad idea,
and quicksort is what you should use for N>6".

(Some thought should be given to comparative analysis of non-PKI crypto
mechanisms, such as hashing (SHA-256), including security, performance, and
whether onboarding-offboarding-purging are needed.)

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 14:31:52 -0400

(if the ads want off this train, speak up)

> "freshness" argument is that the keys get rolled periodically.

they can get rolled periodically, sure. That could be as often as 1/yr
or 1/N yrs... your (operators) choice, within reason... which the mic
discussion also spun around in PAR.

> And this has to occur on all the routers, with new keys published along with
> the key roll, and possibly a unique key per router.

could be per router? per POP? per METRO? per REGION? per Continent?
per Country? per ASN?

> So, the key roll frequency alone, there are operational scalability things

Sure, just like updating prefix-lists for all your customers today...
which L(3) does ~4x/day? NTTA does ~6x/day?

> routers, and public keys in RPKI, right?

Sure, you are updating 2 things here, potentially. Or pulling data
from a single store to put in 2 places (depends on your perspective
and systems/OSS I suppose).

> update of all aspects of the whole system (router + RPKI).

there are 2 systems there... with potentially very different
operational requirements.

we already all manage routers in the field ... this is just another
'prefix-list' or 'acl' or ... (or I hope it's just like that anyway -
see 'stab in eye' vendor comment)

> "When you sort the data, be aware that bubble-sort is really a bad idea, and
> quicksort is what you should use for N>6".
>

I think that ship sailed... but it seems like a fun list discussion.

-chris

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Apr 2012 04:06:55 +0900

> that cert on your router in some implementation-specific manner.

draft-ymbk-bgpsec-rtr-rekeying-00.txt

randy

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 11 Apr 2012 15:10:26 -0400

> draft-ymbk-bgpsec-rtr-rekeying-00.txt

oh hai!