Subject: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover)

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 9 Mar 2012 07:40:23 -0500

>We published this -00 draft to document a possible process to perform key rollovers 
>on a BGPSEC router certificate and discuss the use of rollovers as an alternative to beaconing.

I have a taxonomy suggestion to make.

The method we currently have in the -01 version BGPSEC spec draft is really
the Origin Signature Expire Time (OSET) method.
We should try to move away from calling it the "beaconing" method.
The reason is as follows.

We have been using the name "beacon" simply to refer to re-origination of a prefix.
By this definition of "beacon", both the OSET method and the Router Re-keying (RR) method use "beaconing".
In the OSET method, the re-origination is done well before the Origin Signature Expire Time is reached.
Router does re-origination of prefixes in the Router Re-keying method too, except that
it is done when a new cert (and key-pair) kicks in
and well before the previous cert's expire time (i.e., NotValidAfter) is reached. 

Each of the methods involves expire time.
The Router Re-keying method has *implicit expire time* – the update would “expire” 
(i.e., become invalid) whenever the originating router's cert expires (and/or is revoked).
The OSET method has *explicit expire time* in the BGPSEC update.

Considering all of the above, I think the following taxonomy would be preferable:
Origin Signature Expire Time (OSET) method (for what is in the current -01 spec draft), and
Router Re-keying (RR) method (proposed new method).

Sriram

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Fri, 9 Mar 2012 13:02:38 +0000

Hi Sriram

Thanks for your email.

(snif)
> Router Re-keying (RR) method (proposed new method).

I am ok with your proposal for OSET. I used "key rollover" because I wanted to be consistent with RFC 6489 which uses the term "rollover" instead of "rekeying". What do you think?

Roque

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 9 Mar 2012 08:32:07 -0500

Thanks.
I am OK with either: "key rollover" or "router rekeying". 

It is just that were using "router rekeying" in the SIDR Interim meeting discussions,
and Randy is also using it his documents: draft-ymbk-bgpsec-rtr-rekeying-00.txt

Sriram
________________________________________
From: Roque Gagliano (rogaglia) [[email-masked]]
Sent: Friday, March 09, 2012 8:02 AM
To: Sriram, Kotikalapudi
Cc: [email-masked]
Subject: Re: Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover)

Hi Sriram

Thanks for your email.

(snif)

Roque

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 9 Mar 2012 08:49:41 -0500

May seem like acronym mania but another possibility is:
RCET (Router Cert Expire Time) method :)

We are basically imposing an expire time on BGPSEC announcements
either by the router cert's expire time (RCET)
or by an explicit Origin Signature Expire Time (OSET).

Sriram  
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sriram, Kotikalapudi [[email-masked]]
Sent: Friday, March 09, 2012 8:32 AM
To: Roque Gagliano (rogaglia)
Cc: [email-masked]
Subject: Re: [sidr] Taxonomy suggestion (draft-rogaglia-sidr-bgpsec-rollover)

Thanks.

Sriram

Hi Sriram

Thanks for your email.

(snif)

Roque

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Mar 2012 22:56:41 +0900

> It is just that were using "router rekeying" in the SIDR Interim
> meeting discussions, and Randy is also using it his documents:
> draft-ymbk-bgpsec-rtr-rekeying-00.txt

and it is used for replay protection.

randy

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 9 Mar 2012 09:45:18 -0500

Just so we understand that they are distinct issues.  How to key, re-key
routers and reflect that in the RPKI is necessary even if we don't take on
the "stale update problem".

If rekeying is our approach to control the validity period of stale
updates, then the issues become inter-related.  If we use other methods to
control validity periods, they are not.

dougm
-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Mar 2012 23:54:44 +0900

> updates, then the issues become inter-related.

shame you could not make the san diego interim

randy

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Fri, 9 Mar 2012 10:10:48 -0500

At least part of my quantum state was there.

If draft-rogaglia-sidr-bgpsec-rollover-00 becomes the way to control stale
updates, the two issues will be intertwined.

I was just pointing out that you need the ability to key, re-key anyway,
independent of its use in the above.

Wonder where else my qbits were that week?

dougm

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 12 Mar 2012 11:03:06 +0000

Hi Douglas,

> independent of its use in the above.

Agreed, and I though we captured it with Sections 1 and 2 of the document.

Roque.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 12 Mar 2012 17:12:36 -0400

At 9:45 AM -0500 3/9/12, Montgomery, Douglas wrote:
>Doug Montgomery - Mgr. Internet & Scalable Systems Research / ITL / NIST

Doug,

A minor quibble.

Whether we view router cert validity intervals as the primary way to manage
signed advertisement lifetimes, or not, the two are related, at least 
in principle.

Steve

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 12 Mar 2012 17:26:30 -0400

Sure.

Put another way, validity of an PATH_SIG can expire, whether we intended
it to, or not.

dougm