At 9:52 AM +0100 12/3/08, Robert Kisteleki wrote:
Hi,
Robert,
Thanks for the clarification., but I still have some serious
concerns that I think need to be addressed as we progress this as a
WG item.
I looked at your document and I see that section 5 is a "Minimum
set of Signed Attributes." To try to prevent the problem I cited,
it really needs a definitive list of the objects and attributes
that MAY be signed, with a prohibition on signing any other
objects/attributes. This is the opposite of what your text says,
as it allows the signer to include whatever other attributes the
signer wishes.
The name of an AS is NOT something that can be validated using the
RPKI, and this needs to made clear to folks using this mechanism.
The same is true for net name, org, country and status. The
simplest thing to do would be to exclude these as signed
attributes. I am not very familiar with the attributes you listed
for the four object types, but I suspect that a more of them will
fall into this category.
The intention here is that the owner of the resources can make
verifiable statements. They can claim, by constructing and signing
RPSL objects, that certain facts are true regarding the use of the
resource; in other words, this mechanism allows the holder of the
resources to bind their resources and other info together. So it's
really intentional that other attributes such as org name, AS name,
import/export attributes, contact info, ... can be covered by the
signature, even though these are not number resources.
The problem is that the RPKI cert(s) used to verify such signed
assertions do not attest to the accuracy of the other attributes.
This means that we are allowing (really encouraging) relying parties
to accept as accurate the data verified using RPKI certs, and that is
dangerous. It creates potential liabilities for the CAs in the RPKI.
For example, if an ISP asserts in a signed object that it's name is
Foo Corp, when in reality its name is Bar Co., this could create a
liability for the registry that issued the CA cert to Bar Co. We have
tried to avoid this sort of liability by restricting the subject
names in resource certs to be non-meaningful, and this proposal
reintroduces this liability.
If we state that the only attributes that can be signed are the ones
that carry number resources, and which can also be found in the
covering certificate (ie. your "maximum set" approach, if I
understand correctly), then there is no practical gain for the
signature. The only only meaning for such an object in my
interpretation would be "The resource holder has spoken. They said
they have an object." without any verifiable claims about the actual
content of the object.
I think you are underestimating what could be done, but maybe I don't
know enough about RPSL. Let me give an example:
If an ISP signs an object that asserts that it announces
routes for several prefixes, then this assertion could be verified
using a combination of the ROAs that attest to the origin AS info for
each prefix, plus the transitive verification of similar records
signed by other ISPs. That would provide the sort of static
connectivity verification that soBGP proposed. This is an example of
a set of assertions that could be verified using data to which the
RPKI attests.
Based on this, I believe that the current "minimum set"
specification is the right approach.
I have to disagree. I think the proposal suffers from many of the
same security problems that arise if one uses (non-resource) certs
for authentication of RPSL data today, i.e., what you enable is an
authenticated entity to make arbitrary assertions about arbitrary
data.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
