Subject: [Sidr] Architecture document: narrowing the scope

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Mar 2008 00:59:41 +0200 (EET)

Hi,

As discussed in the meeting, it might make sense to scope the 
architecture document in such a manner that the document doesn't need 
to be in progress while the more specific secure routing work goes on.

I believe this recasting needs to start from the basics (preferably 
from the draft name but changing that isn't probably worth it), 
because the current Title and Abstract can be read to describe secure 
internet routing infrastructure, which it doesn't really do in the 
wider interpretation.

Replace title:

   An Infrastructure to Support Secure Internet Routing

with e.g.:

   A Public Key Infrastructure to Describe Route Origination
   Authorizations

I don't see a need to have Secure Internet Routing in the title at 
all; it is prone to mislead the user.

Similar recasting should be applied in Abstract and Introduction, e.g. 
with Abstract:

Abstract

    This document describes an architecture for an infrastructure to
    support secure Internet routing. The foundation of this architecture
    is a public key infrastructure (PKI) that represents the allocation
    hierarchy of IP address space and Autonomous System Numbers;
    certificates from this PKI are used to verify signed objects that
    authorize autonomous systems to originate routes for specified IP
    address prefixes. The data objects that comprise the PKI, as well as
    other signed objects necessary for secure routing, are stored and
    disseminated through a distributed repository system. This document
    also describes at a high level how this architecture can be used to
    add security features to common operations such as IP address space
    allocation and route filter construction.

Replace with (also summarizing it a bit):

    This document describes a public key infrastructure (PKI), the
    certificates of which could be used to verify signed objects that
    authorize autonomous systems to originate routes for specified IP
    address prefixes.  These and supporting data objects can be stored and
    disseminated through a distributed repository system.

Possibly also keep the last sentence, but this is a bit of can of 
worms because these mechanisms have already been described as 
incomplete (and to avoid this can of worms, some text in section 7.2 
and 7.3 could possibly be removed or reworded):

                                                         This document
    also describes at a high level how this architecture can be used to
    add security features to common operations such as IP address space
    allocation and route filter construction.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Danny McPherson <[email-masked]>
Date: Mon, 10 Mar 2008 17:17:24 -0600

[top post only]

I agree with Pekka's recommendations here and think
recasting it to be far more precise about what problems
we're discussing in the architecture document is very
important.

-danny

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Mar 2008 19:22:37 -0400

Pekka,

I agree that a title with a narrow scope is appropriate, but I 
believe that you suggested revision is too narrow. The RPKI is 
broader in scope than just route origination, as Geoff noted. For 
example, the SBGP and soBGP proposals,  which were debated 
extensively in RPSEC, both address path validation and both rely on 
the sort of PKI that is being covered in this document. I think some 
additional wordsmithing on the title and abstract is needed.

Steve

---

From: Danny McPherson <[email-masked]>
Date: Mon, 10 Mar 2008 17:46:05 -0600

> additional wordsmithing on the title and abstract is needed.

But RPKI provides an infrastructure *to enable those*, OR a static
route filter, or any of a number of other things.  Listing the array
of things that might be done and implying that SIDR itself provides
that capability is misleading.

-danny

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Mar 2008 20:37:52 -0400

>that capability is misleading.

Listing the capabilities that the RPKI enables seems reasonable to 
me, so long as we don't claim that the near term work items will 
yield solutions to all of them.  The RPKI is not designed to support 
"any number of things." It is designed to support a set of near and 
longer term BGP routing security solutions.

Steve

---

From: Shane Amante <[email-masked]>
Date: Mon, 10 Mar 2008 23:22:55 -0600

All,

FWIW, I agree with the sentiments echo'ed by Pekka & Danny and would 
support a narrowing of the Title, etc. to more accurately reflect the 
present architecture being discussed.

-shane