Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Mon, 28 Nov 2005, Randy Bush wrote: proof of identity S(withRIRkey, AS_A_key, AS_A) or S(withwebofttrustkeys, AS_A_key, AS_A) maybe Randy is saying this is two steps, not an "OR" S(withRIRkey, someNonRIRidentity, asA) Good idea. And this "someNonRIRidentity" may actually be another region RIR! (which solves problem for those involved with multiple RIRs but who prefer to maintain one primary identity for all regions). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> proof of identity > S(withRIRkey, AS_A_key, AS_A) > or > S(withwebofttrustkeys, AS_A_key, AS_A) > maybe Randy is saying this is two steps, not an "OR" S(withRIRkey, someNonRIRidentity, asA) i.e. the rir attests that the entity whose identity is externally certified has been issued asA (or prefixP). the isp may have gotten their identity from thawte, some web of trust, or santa claus. the point, as smb notes, is that the public cert of the isp is given to the rir(s) as part of the business contract. it has no need to be rir-generated, though the rirs offering cert generation as a service will likely be useful to small lirs who have no other corporate buiness/privacy preferences. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On 25 nov 2005, at 02.07, Sean Donelan wrote: Although techincal folks may think its just about math, unfortunately some people think certificates and signatures mean more than just mathmatical formulas. I'm a bit confused why people think network service providers will be willing to "certify" transitive trust relationships about business relationships between third-parties. Given that ISPs even refuse or manipulate their AS objects to hide real peering or transit details for business reasons, getting them to sign certificates for these relationships might prove even harder... - kurtis -
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On 24 nov 2005, at 03.54, George Michaelson wrote: If you want to see member-certificates which gate access to RIR/NIR specific services common across all registries, I think you want to get that onto an RIR meeting agenda Randy. We currently have no cross-certification activity in member identity. I was arguing for this when RIPE was introducing the X.509 auth for the LIR portal. And I clearly remember multi-RIR customers asking for the same thing for exactly the same reason (I think it was Nigel and Neil), as was Randy. So it's certainly been on the agenda... - kurtis -
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Wed, 23 Nov 2005, Steven M. Bellovin wrote: > I think the problem is both easier and harder than painted. First, you > need a business agreement that you will accept each others' assertions > of member identities, aka certificates. Second, you have to agree on a > common format and meaning for certain fields, including thinks like > CRLs. > > I'm not sure if I think the technical specs or the business agreement > are the hard parts... Ah the business issues start bubbling to the surface. Have you noticed for various reasons network service providers don't like to "sign" or "certify" the business activities of other entities. In the 1990's several network service providers (AT&T, BBN, etc) established PKIs, but now very few network service provider will "certify" S/MIME e-mail, SSL web, or other type of third-party activity. Although techincal folks may think its just about math, unfortunately some people think certificates and signatures mean more than just mathmatical formulas. I'm a bit confused why people think network service providers will be willing to "certify" transitive trust relationships about business relationships between third-parties.
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>the rir attests to the delegation of the prefix and an asn to the >identified isp. > >the isp signs, using their isp identity to > o originating from the asn > o originating that prefix (in sbgp, toward another isp) Looks to me like: proof of allocation: S(withRIRkey, Prefix_p_key, prefix_p) as Steve pointed out, there could be two of these, one with CA bit set for use in suballocation and one without the CA bit set for use in routing proof of identity S(withRIRkey, AS_A_key, AS_A) or S(withwebofttrustkeys, AS_A_key, AS_A) maybe Randy is saying this is two steps, not an "OR" proof of origination authorization: S(withPrefix_p_key, authr_origin_AS_#, prefix_p) proof of origination authentication: S(withAS_A_key, (AS_A,prefix_p)update) could be S(withAS_A_key, (AS_A,prefix_p)||proofoforiginationauthr) The binding between the proof of origination authorization and the proof of origination authentication is that the AS_A in the proof of identity mapping AS_A to the AS_A_key must be the same as the authr_origin_AS_# in the proof of origination authorization. [Future complication of this would have to decide what to do with ISPs that own more than one AS #. (make "authr_origin_AS_#" a list?)] --Sandy who really should be baking
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[EMAIL PROTECTED]>, Randy Bush writes: >> We need prefix ownership certs; these need a special field identifying the >> prefix owned. (See RFC 3779, which also describes AS certificates). We >> need the latter in CA form, for delegation. > >sorry to complicate, by iana allocates as ranges which are then >subbed to rirs. so the ca bit could be set on these > I thought I'd mentioned earlier that we may want two different forms of prefix cert, with with CA and one without. The one without goes in the routers; the one with CA is used to issue certs to downstreams. Rationale for the two certs: if a router is badly 0wned, someone can steal its private key and use it for address hijacking. But that sort of gross abuse of an entire prefix is likely to be noticed. A CA cert can be used to issue certs for longer prefixes, i.e., target one customer, rather than an entire ISP. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Wed, 23 Nov 2005 17:42:21 -1000 Randy Bush <[EMAIL PROTECTED]> wrote: > > We need prefix ownership certs; these need a special field > > identifying the prefix owned. (See RFC 3779, which also describes > > AS certificates). We need the latter in CA form, for delegation. yes. the resource certs we are making, the test certs, have CA bit set, and include RFC3779 fields for ASN, IPv4 and IPv6 ranges, using the range ASN.1 notation for ASN ranges. > > sorry to complicate, by iana allocates as ranges which are then > subbed to rirs. so the ca bit could be set on these for the APNIC resource certificates in test, they are. cheers -George > > randy > -- George Michaelson | APNIC Email: [EMAIL PROTECTED]| PO Box 2131 Milton Phone: +61 7 3858 3150 | QLD 4064 Australia Fax: +61 7 3858 3199 | http://www.apnic.net
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> We need prefix ownership certs; these need a special field identifying the > prefix owned. (See RFC 3779, which also describes AS certificates). We > need the latter in CA form, for delegation. sorry to complicate, by iana allocates as ranges which are then subbed to rirs. so the ca bit could be set on these randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[EMAIL PROTECTED]>, Randy Bush writes: > We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be. >>> >>> if it is not common across registries, and if my certs do not >>> work across registries, then something is very very broken, >>> and a major pita at the isps', aka your members', expense. >> >> If you want to see member-certificates which gate access to >> RIR/NIR specific services common across all registries, I think >> you want to get that onto an RIR meeting agenda Randy. > >i have been whining about the problems of cross-registry operation >for over a decade, formally, informally, presos, ... i have had it >on every rir's meeting agenda (except lacnic) for many years. do i >need to iterate for every ort of service the registries provide? > >we are the registries' customers. many of us, especially the ones >who pay the registries the most, have to deal with multiple >registries. can the registries please get over the inter-registry >rivalry and make life more reasonable for us, the paying members? > >> We currently have no cross-certification activity in member identity. > >where as before i was merely inclined, this has just made me an >extremely strong proponent of the isp web of trust identity model. > I think the problem is both easier and harder than painted. First, you need a business agreement that you will accept each others' assertions of member identities, aka certificates. Second, you have to agree on a common format and meaning for certain fields, including thinks like CRLs. I'm not sure if I think the technical specs or the business agreement are the hard parts... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[EMAIL PROTECTED]>, George Michaelson writes : > >On Wed, 23 Nov 2005 17:54:44 -0800 (PST) >"william(at)elan.net" <[EMAIL PROTECTED]> wrote: > >> >> >> On Thu, 24 Nov 2005, George Michaelson wrote: >> >> > According to what I understand, there have to be two certificates >> > per entity: >> > >> >one is the CA-bit enabled certificate, used to sign >> > subsidiary certificates about resources being given to other people >> > to use. >> > >> >the other is a self-signed NON-CA certificate, used to sign >> >route assertions you are attesting to yourself: you make >> > this cert using the CA cert you get from your logical parent. >> >> So how is the 2nd one different from the first? > >the important distinction is that the certificate used to sign resource >assertions doesn't have the CA bit set. > More generally To a 0th and even a 1st approximation, a certificate is just a binding of a public key to an identity. But there's far more complexity, much of it actually necessary, to real X.509 certificates, or the PKIX working group wouldn't have churned out 32 RFCs... One thing important here is the usage fields. For example, I just went to https://www.microsoft.com and looked at its cert. Under "Certificate Key Usage", it says "Signing" and "Key Encipherment". There's another field, "Extended Key Usage", that Firefox can't decode. There are other certificates, issued by Microsoft, that are identified as code-signing certificates. Here, we need several forms. One is just for communicating with the RIR(s); that's a pretty ordinary identity cert. We need an AS cert (at least for some proposals); that coudl be an identity cert, but with a name of a special form. We need prefix ownership certs; these need a special field identifying the prefix owned. (See RFC 3779, which also describes AS certificates). We need the latter in CA form, for delegation. There are probably a few more, depending on just how we decide to secure BGP. The purpose of all of these distinctions is to permit control over how certificates are used, without relying on special-format names. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>>> We are discussing how we can do subsidiary certificate services like >>> this in APNIC but I think this goes outside of routing policy and >>> into registry business practices which are unlikely to be common >>> for all RIR and NIR in the ways that resource certificates *have* >>> to be. >> >> if it is not common across registries, and if my certs do not >> work across registries, then something is very very broken, >> and a major pita at the isps', aka your members', expense. > > If you want to see member-certificates which gate access to > RIR/NIR specific services common across all registries, I think > you want to get that onto an RIR meeting agenda Randy. i have been whining about the problems of cross-registry operation for over a decade, formally, informally, presos, ... i have had it on every rir's meeting agenda (except lacnic) for many years. do i need to iterate for every ort of service the registries provide? we are the registries' customers. many of us, especially the ones who pay the registries the most, have to deal with multiple registries. can the registries please get over the inter-registry rivalry and make life more reasonable for us, the paying members? > We currently have no cross-certification activity in member identity. where as before i was merely inclined, this has just made me an extremely strong proponent of the isp web of trust identity model. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Wed, 23 Nov 2005 16:39:11 -1000 Randy Bush <[EMAIL PROTECTED]> wrote: > >> [0] - i'll want the business cert to have the ca bit if i am > >> large enough to have internal authorization process, and > >> thus want to create and manage different certs for dns, > >> billing, ... > > > > We are discussing how we can do subsidiary certificate services like > > this in APNIC but I think this goes outside of routing policy and > > into registry business practices which are unlikely to be common > > for all RIR and NIR in the ways that resource certificates *have* > > to be. > > if it is not common across registries, and if my certs do not > work across registries, then something is very very broken, > and a major pita at the isps', aka your members', expense. > > randy If you want to see member-certificates which gate access to RIR/NIR specific services common across all registries, I think you want to get that onto an RIR meeting agenda Randy. We currently have no cross-certification activity in member identity. cheers -George
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>> [0] - i'll want the business cert to have the ca bit if i am >> large enough to have internal authorization process, and >> thus want to create and manage different certs for dns, >> billing, ... > > We are discussing how we can do subsidiary certificate services like > this in APNIC but I think this goes outside of routing policy and into > registry business practices which are unlikely to be common for all RIR > and NIR in the ways that resource certificates *have* to be. if it is not common across registries, and if my certs do not work across registries, then something is very very broken, and a major pita at the isps', aka your members', expense. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Wed, 23 Nov 2005 16:03:35 -1000 Randy Bush <[EMAIL PROTECTED]> wrote: > > According to what I understand, there have to be two certificates > > per entity: > > > > one is the CA-bit enabled certificate, used to sign > > subsidiary certificates about resources being given to other people > > to use. > > > > the other is a self-signed NON-CA certificate, used to sign > > route assertions you are attesting to yourself: you make > > this cert using the CA cert you get from your logical parent. > > probably more. smb has convinced me that the (possibly ca[0]) cert > i get from the rir, with which i do business with the rir (dns, > ip requests, billing), should be different than that which i use > for routing info. At APNIC the cert we expect you to identify yourself with to transact with the registry is not the same as the cert which identifies resource utilization. But we (APNIC) also expect to use a different root CA for these 'identity' certs anyway. the test APNIC resource certificates are using an interim self-signed CA, and will be moving to a hardware-token secured CA shortly. The hardware is the same as our identity certificates used in MyAPNIC, but a different trust anchor and CA identity will be used for resource certificate processes. We probably need to make this explict in our policies in this area. We've always cheers -George > > randy > > --- > > [0] - i'll want the business cert to have the ca bit if i am > large enough to have internal authorization process, and > thus want to create and manage different certs for dns, > billing, ... We are discussing how we can do subsidiary certificate services like this in APNIC but I think this goes outside of routing policy and into registry business practices which are unlikely to be common for all RIR and NIR in the ways that resource certificates *have* to be. cheers -George
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> According to what I understand, there have to be two certificates per > entity: > > one is the CA-bit enabled certificate, used to sign subsidiary > certificates about resources being given to other people to use. > > the other is a self-signed NON-CA certificate, used to sign > route assertions you are attesting to yourself: you make this > cert using the CA cert you get from your logical parent. probably more. smb has convinced me that the (possibly ca[0]) cert i get from the rir, with which i do business with the rir (dns, ip requests, billing), should be different than that which i use for routing info. randy --- [0] - i'll want the business cert to have the ca bit if i am large enough to have internal authorization process, and thus want to create and manage different certs for dns, billing, ...
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Wed, 23 Nov 2005 17:54:44 -0800 (PST) "william(at)elan.net" <[EMAIL PROTECTED]> wrote: > > > On Thu, 24 Nov 2005, George Michaelson wrote: > > > According to what I understand, there have to be two certificates > > per entity: > > > > one is the CA-bit enabled certificate, used to sign > > subsidiary certificates about resources being given to other people > > to use. > > > > the other is a self-signed NON-CA certificate, used to sign > > route assertions you are attesting to yourself: you make > > this cert using the CA cert you get from your logical parent. > > So how is the 2nd one different from the first? the important distinction is that the certificate used to sign resource assertions doesn't have the CA bit set. -George
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Thu, 24 Nov 2005, George Michaelson wrote: According to what I understand, there have to be two certificates per entity: one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use. the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent. So how is the 2nd one different from the first? In both cases you give permission to certain use of a resource under your control. If you look at it the only difference is: - To authorize reallocations you sign request based on another entity's ORG object, - To authorize announcement you sign request based on another entity's ASN object (can be your own ASN). But in general ASN object is also basically a type of ORG with extra data (i.e. ASN# and ASN name), so I don't see why you can't use one cert (if somebody does not list AS# for their org I guess they can't route independently). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[EMAIL PROTECTED]>, George Michaelson writes : > > >According to what I understand, there have to be two certificates per >entity: > > one is the CA-bit enabled certificate, used to sign subsidiary > certificates about resources being given to other people to use. > > the other is a self-signed NON-CA certificate, used to sign > route assertions you are attesting to yourself: you make this > cert using the CA cert you get from your logical parent. > Or your parent could have a CA and issue you two certs, one for signing route assertions and one for signing certificates you issue to your downstreams. That in turn has another interesting implication: an ISP can *enforce* a contract that prohibits a downstream from reselling connectivity, at least if the resold connectivity includes a BGP announcement -- the ISP would simply decline to sign a CA certificate for its customer, thereby depriving it of the ability to delegate portions of its address space. (N.B. Certificates include usage fields that say what the cert is good for.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
According to what I understand, there have to be two certificates per entity: one is the CA-bit enabled certificate, used to sign subsidiary certificates about resources being given to other people to use. the other is a self-signed NON-CA certificate, used to sign route assertions you are attesting to yourself: you make this cert using the CA cert you get from your logical parent. -George
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> So when one receives an update, which part is it that you verify with > the certificate derived from the RIR chain and which part is it that you > verify with the certificate derived from the web-of-trust? I'm guessing > the answer in part is that there's a signature attesting to the > prefix origination based on the RIR-rooted certificate, but I'm not > certain what you are suggesting you would sign with the web-of-trust > based ISP identity certificate (the origination announcement, indicating > that it is not only authorization to originate but also source > authentication?) something like the rir attests to the delegation of the prefix and an asn to the identified isp. the isp signs, using their isp identity to o originating from the asn o originating that prefix (in sbgp, toward another isp) o possibly delegating a subset of that prefix o passing other prefixes on (in sbgp, toward ...) but either you, smb, or jis should be able to get it more correctly than i. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>My issue is that if ISPs a) only announce networks that they know >(for different values of know - but hopefully based on some kind of >trust in the RIR's data) they are authorized to announce, and b) took >responsibility for the behavior of the paths or prefixes they >announce, and the bits that are originated in those paths or >prefixes, and took action to stop the bad behavior, the issue of >trust paths might not be so critical. Problems with bad routing behavior have been around since the very earliest days of the Arpanet - I think we'd be mad to rely on that going away. (As long as everybody was honest, there'd be no need for fraud laws and law enforcement and courts lost cause, there.) One of the hoped for goals of the various security solutions is the ability to make your own check of what you are being told, so if someone along the way is less than correct and less than diligent in checking what they are propagating, you the diligent one can stop the problems. --Sandy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>in operation, this means that there could be isp- (or ufo-)centric >isp identity certification (a la web of trust, for example) which >could have a very separate cert chain from that of address space >allocation, which, aside from the legacy issue, could come via the >rirs. So when one receives an update, which part is it that you verify with the certificate derived from the RIR chain and which part is it that you verify with the certificate derived from the web-of-trust? I'm guessing the answer in part is that there's a signature attesting to the prefix origination based on the RIR-rooted certificate, but I'm not certain what you are suggesting you would sign with the web-of-trust based ISP identity certificate (the origination announcement, indicating that it is not only authorization to originate but also source authentication?) If the RIR-rooted certificate says that ISP XYZ is allocated prefix P, does the web-of-trust ISP identify certificate have to say exactly "ISP XYZ"? Is that exact match the link between what the RIR-rooted cert is proving and what the web-of-trust identify cert is proving? --Sandy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
Rodney Joffe wrote: As another thought: - Love 'em or hate 'em, the PSTN doesn't have this problem. Uh, PSTN does have this problem too. If you are part of SS7 you can totally fake call origination information. This has been and still is abused for criminal-malicous activities and 'billing-optimization'. Remember the lawsuit of SBC et al against WCOM regarding termination charge misrepresentation? In the actual PSTN routing of a call the destination information is not authenticated either. The national regulators run registries where the carrier-owner of each number block is registered. Very much like in the RIR system. Depends on country a bit though. In some it's more strict and in others less. -- Andre
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> My issue is that if ISPs a) only announce networks that they know > (for different values of know - but hopefully based on some kind of > trust in the RIR's data) they are authorized to announce, and b) took > responsibility for the behavior of the paths or prefixes they > announce, and the bits that are originated in those paths or > prefixes, and took action to stop the bad behavior, the issue of > trust paths might not be so critical. agreed up to the last clause. but my base concern is not config problems, but rather intentional attacks on the routing system. not to deny that there are config problems, they're rife and a major pita. but i suspect that the most agregious will be dealt with by direct approaches to the security issues, e.g. ip address ownership, as-path intent, etc. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Nov 23, 2005, at 11:09 AM, Randy Bush wrote: not exactly. there are two trusts here. i have to accept that asns as incompetent at configuration as i are attesting to prefixes and paths or i won't be able to get to a large part of the net. but this is orthogonal to my trust in their competence to attest to the identity of other asns by cross-signing others' certs. i could have a business relationship with an asn whose routing competence i question. What happened to responsibility? Where does it fit in to the issue? responsibility for what? sorry to be slow/cryptic. My issue is that if ISPs a) only announce networks that they know (for different values of know - but hopefully based on some kind of trust in the RIR's data) they are authorized to announce, and b) took responsibility for the behavior of the paths or prefixes they announce, and the bits that are originated in those paths or prefixes, and took action to stop the bad behavior, the issue of trust paths might not be so critical. I am not arguing in any way with your views or thoughts related to trust models. I was merely drifting back to the original issue of rogue players in the path, and suggesting that there is an alternative method of mitigating the problems caused by those players that doesn't require protocol work. Ignore the deviation in the thread. /rlj
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>> not exactly. there are two trusts here. i have to accept that >> asns as incompetent at configuration as i are attesting to prefixes >> and paths or i won't be able to get to a large part of the net. >> >> but this is orthogonal to my trust in their competence to attest to >> the identity of other asns by cross-signing others' certs. i could >> have a business relationship with an asn whose routing competence i >> question. > > What happened to responsibility? Where does it fit in to the issue? responsibility for what? > As much as they enjoy sharing brew sessions, I don't think I've often > seen or heard of 701 and 2914 ever having to point out downstream > misbehavior to each other. And I *think* they both have sticks that > are big enough that they never have to be waved. So if we can assume > that this is true of the other folks of "similar" size, then which > are the large parts of the net you can't or won't be able to reach? > Or are your peers not prepared to own responsibility for their > announcements? And if not, why not? And I refuse to accept the > reasoning that seems to have smothered pushback - Networks don't have > to deploy new code or equipment or capabilities to control internal > or downstream announcements. uh, i really do not follow what you are saying. the point is that the trust model for attestation of identity need not be the same trust model for the attestation of prefix ownership or of as-path. in operation, this means that there could be isp- (or ufo-)centric isp identity certification (a la web of trust, for example) which could have a very separate cert chain from that of address space allocation, which, aside from the legacy issue, could come via the rirs. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Nov 22, 2005, at 2:59 PM, Randy Bush wrote: [ you know all this, but i think it is worth going through the exercise ] That said, I think the problem is that we need an algebra of trust that will let a program, not a human, decide whether or not to trust a certficate. You don't want to accept something if it's a twisty loop of subsidiaries or allied evil ASs vouching for each other. OTOH, there are some situations where we know that absolute trust is indicated -- say, 701 signing 702's certificate, or an upstream signing the address certificate for a customer. And it's not just honesty, it's competence you're assessing -- we've all seen problems when major ISPs didn't get their filters straight. not exactly. there are two trusts here. i have to accept that asns as incompetent at configuration as i are attesting to prefixes and paths or i won't be able to get to a large part of the net. but this is orthogonal to my trust in their competence to attest to the identity of other asns by cross-signing others' certs. i could have a business relationship with an asn whose routing competence i question. What happened to responsibility? Where does it fit in to the issue? And if not, why not? Pushback comes to mind ;-) As much as they enjoy sharing brew sessions, I don't think I've often seen or heard of 701 and 2914 ever having to point out downstream misbehavior to each other. And I *think* they both have sticks that are big enough that they never have to be waved. So if we can assume that this is true of the other folks of "similar" size, then which are the large parts of the net you can't or won't be able to reach? Or are your peers not prepared to own responsibility for their announcements? And if not, why not? And I refuse to accept the reasoning that seems to have smothered pushback - Networks don't have to deploy new code or equipment or capabilities to control internal or downstream announcements. To save some resulting noise on the list; Pointing to the example of spam is mostly a red herring. Today's spam is mostly generated by the hundreds of thousands of compromised machines that originate most of it, which creates its own difficult problems for the geeks who work at that layer. Nonetheless, to a large extent enforced responsibilty has worked for spam. The problem has changed. Paths and prefixes are a lot different to the current spam problem. NOTE: This is *not* an invitation to start a thread on spam or the botnets that enable them. It doesn't belong on this list, so take it elsewhere. As another thought: - Love 'em or hate 'em, the PSTN doesn't have this problem. Is there anything helpful to learn from there, ignoring the perennial layer9 discussion ratholes? /rlj
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Tue, 22 Nov 2005, Randy Bush wrote: > > the idea is that the *end-user* is supposed to know what's legit > > and what isn't. > > no. all asn admins, including tier 1 through tier 42 and leaf > asns. Bah. Forgive my stupidity, please. We got into the discussion of PKI and PGP-style trust models and I failed to remember the TLA in the subject. You're right, my comment doesn't apply to BGP (at least not for most end-users I know). -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> the idea is that the *end-user* is supposed to know what's legit > and what isn't. no. all asn admins, including tier 1 through tier 42 and leaf asns. users are not involved in routing, except of course when the ivtf is desperate to shim up v6. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Tue, 22 Nov 2005, william(at)elan.net wrote: > I also seem to remember Bill Woodcock suggesting this at some ARIN > meeting in 2001 or 2002. If I recall he proposed that this be somewhat > like a document trust with no operations (beyond providing NS service) > and when somebody needs a service the ip block would have to be moved > to regional RIR. Right. The idea was to lock down things which were in the legacy space, unless people were prepared to undergo the full scrutiny of having them transferred into an RIR (basically dampen the rash of hijackings), give ARIN a clear way around the free-services-to-legacy-holders issue, and give legacy holders a way around the threat-of-ARIN-trying-to-charge- them issue. Seemed like a good idea to a lot of ARIN folks at the time, and it was starting to get some headway, when the RIPE and APNIC folks realized that it would deprive them of the future possiblity of reclaiming legacy space, which they promptly nabbed using the extraordinarily ill-considered ERX policy, which just took the problem and multiplied it by five. Basically irreversibly. So as nice an idea as it was, I'm not sure it has legs in this post-ERX world. -Bill
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Tue, 22 Nov 2005, Randy Bush wrote: [ before you say it, i have suggested that a pseudo-rir be created for legacy asns and prefixes ] I also seem to remember Bill Woodcock suggesting this at some ARIN meeting in 2001 or 2002. If I recall he proposed that this be somewhat like a document trust with no operations (beyond providing NS service) and when somebody needs a service the ip block would have to be moved to regional RIR. If your proposal for separate legacy RIR is different, then you need to have a model on how it would be run and how its operations would be financed (especially security procedures associated with assigning certs, etc). -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
On Tue, 22 Nov 2005, Bora Akyol wrote: Furthermore, given that a trust algebra may yield a trust value, rather than a simple 0/1, is it reasonable to use that assessment as a BGP preference selector? That would tie the security very deeply -- too deeply? -- into BGP's guts. If you take the web of trust model, I think a security value can be assigned to announced information based on a couple variables: 1) Distance from an absolute trusted authority. Who is your absolute trusted authority? May this role possibly be filled by whoever allocates ip addresses to everyone? 2) The feedback rating of the announcer (like Ebay ;-) Why am I suddenly feeling like some parts of the internet are "better" then others (and that I'll even be able to tell which ones to some absolute value)? I wonder how quickly this would lead to fragmentation of the net 3) A statically configured metric based on a field match with a set of extracted fields from the ID presented by the announcer. Did you mean to say a filter based announcer BGP communities? Or a combination of both. I think this was discussed in detail in the pre-formation stages of the BGP Sec. Req. document. And its not in the produced requirements document as far as I can see. I also remember reading about a paper on a PGP like trust mesh with variable trust values assigned based on distance etc, but I can't recall the authors. Web of trust metrics for PGP have been discussed in several papers (don't think it was ever for BGP). One of the problems is that it requires some central server that has access to list to all relationships and is able to quickly calculate trust metric from you to somebody else. Reliance on such central service can be a bit of a problem i.e. a single central point for attack, etc. (This is not say that RIR signed do not present some similar issues as they would have to distribute revocation data, but those can go as CRLs and at not necessarily queried for every path calculation like it would be with central server). You can also just distribute all the relationship certs but then amount of data you have to distribute is going to be huge and each end-node would have to calculate the metrics (which calculation is going to be on the order of trying to use Dijkstra SPF with 50,000+ nodes in single OSPF area - never tried anything close but I don't think such network would converge quickly) where as single server can at least cache the previous results although I think the problem would still be there (it can work at least it appears to be possible with PGP). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
Randy: > >for how many years have i been asking you and your evil-minded cert > >designing friends for a pgp-like web of trust cert that could be > >used for just this application? > > Steven B: > of subsidiaries or allied evil ASs vouching for each other. OTOH, > there are some situations where we know that absolute trust is > indicated -- say, 701 signing 702's certificate, or an upstream signing > the address certificate for a customer. Well, there's the rub. You know who runs AS701 and AS702. Presumably most of us do (although I don't know who runs 702 off the top of my head. 701 is UUNET/MCI, no? I don't do BGP). I like the web 'o' trust idea, but the idea is that the *end-user* is supposed to know what's legit and what isn't. In most cases, we're not the end-users. -- Steve Sobol, Professional Geek 888-480-4638 PGP: 0xE3AE35ED Company website: http://JustThe.net/ Personal blog, resume, portfolio: http://SteveSobol.com/ E: [EMAIL PROTECTED] Snail: 22674 Motnocab Road, Apple Valley, CA 92307
RE: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Steven M. Bellovin > Sent: Tuesday, November 22, 2005 12:54 PM > To: Randy Bush > Cc: [EMAIL PROTECTED] > Subject: Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security) > <..> > Furthermore, given that a trust algebra may yield a trust > value, rather than a simple 0/1, is it reasonable to use that > assessment as a BGP preference selector? That would tie the > security very deeply -- too deeply? -- into BGP's guts. If you take the web of trust model, I think a security value can be assigned to announced information based on a couple variables: 1) Distance from an absolute trusted authority. 2) The feedback rating of the announcer (like Ebay ;-) 3) A statically configured metric based on a field match with a set of extracted fields from the ID presented by the announcer. Or a combination of both. I think this was discussed in detail in the pre-formation stages of the BGP Sec. Req. document. I also remember reading about a paper on a PGP like trust mesh with variable trust values assigned based on distance etc, but I can't recall the authors. All in all, this is not totally different from Viterbi decoding of digital signals in the presence of noise in the way the trust values would be constructed.
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
[ you know all this, but i think it is worth going through the exercise ] > That said, I think the problem is that we need an algebra of trust > that will let a program, not a human, decide whether or not to trust a > certficate. You don't want to accept something if it's a twisty loop > of subsidiaries or allied evil ASs vouching for each other. OTOH, > there are some situations where we know that absolute trust is > indicated -- say, 701 signing 702's certificate, or an upstream > signing the address certificate for a customer. > And it's not just honesty, it's competence you're assessing -- we've > all seen problems when major ISPs didn't get their filters > straight. not exactly. there are two trusts here. i have to accept that asns as incompetent at configuration as i are attesting to prefixes and paths or i won't be able to get to a large part of the net. but this is orthogonal to my trust in their competence to attest to the identity of other asns by cross-signing others' certs. i could have a business relationship with an asn whose routing competence i question. the bottom line is which would i trust more in the latter sense, an asn cert signed by an external hierarchy or a cert signed by one or more of 70x, 1239, 2914, ...? it seems more natural if the identity trust is congruent with the trust of business relationships. a similar reason for my prefering sbgp-like architectures, the attestation model is congruent with the routing model. it turns out most folk have a business relationsip with an rir. but some don't, e.g. jis. and those who do not have become very worried about their ability to route on the internet being at the mercy of organizations some of which have specifically said that legacy cert renewal would be tied directly to the isp or entity paying the rir as if they had gotten the legacy address space from the rir (i think i have sensed some backing off from this rather extreme position). but the point is that some folk are not happy with their identity being controlled by an external party with no skin in the game with whom they would otherwise have no relationship. [ before you say it, i have suggested that a pseudo-rir be created for legacy asns and prefixes ] in particular, i have a business relationship with 1239 and 2914, but no business relationship with ripe. should i trust ripe's signing the identity of anja's asn more or less than 666 signing it and 666's identity being attested to by 1239 and 701, the latter likely being cross-signed by 1239 and 2914? > Furthermore, given that a trust algebra may yield a trust value, > rather than a simple 0/1, is it reasonable to use that assessment > as a BGP preference selector? That would tie the security very > deeply -- too deeply? -- into BGP's guts. i am aware of other research proposals where routing trust is ordinal or even real depending on various distances. randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[EMAIL PROTECTED]>, Randy Bush writes: I believe a web of trust can be operationally feasible only if the web is more like a forest - if there are several well known examples of "tops" to the web. Otherwise, you have to be storing a plethora of different signers' certificates to be able to validate all the institution's certificates that come in. >>> >>> you need those certs to verify the live data anyway >>> >> Right. The real issue is the trust determination -- how do you know >> that the certificate corresponds to something resembling reality >> (whatever that is)? > >for how many years have i been asking you and your evil-minded cert >designing friends for a pgp-like web of trust cert that could be >used for just this application? > Actually, I don't do certs; it's my evil-minded friends... That said, I think the problem is that we need an algebra of trust that will let a program, not a human, decide whether or not to trust a certficate. You don't want to accept something if it's a twisty loop of subsidiaries or allied evil ASs vouching for each other. OTOH, there are some situations where we know that absolute trust is indicated -- say, 701 signing 702's certificate, or an upstream signing the address certificate for a customer. And it's not just honesty, it's competence you're assessing -- we've all seen problems when major ISPs didn't get their filters straight. Furthermore, given that a trust algebra may yield a trust value, rather than a simple 0/1, is it reasonable to use that assessment as a BGP preference selector? That would tie the security very deeply -- too deeply? -- into BGP's guts. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>>> I believe a web of trust can be operationally feasible only if the web >>> is more like a forest - if there are several well known examples of >>> "tops" to the web. Otherwise, you have to be storing a plethora of >>> different signers' certificates to be able to validate all the >>> institution's certificates that come in. >> >> you need those certs to verify the live data anyway >> > Right. The real issue is the trust determination -- how do you know > that the certificate corresponds to something resembling reality > (whatever that is)? for how many years have i been asking you and your evil-minded cert designing friends for a pgp-like web of trust cert that could be used for just this application? randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>Otherwise, you have to be storing a plethora of >> different signers' certificates to be able to validate all the >> institution's certificates that come in. > >you need those certs to verify the live data anyway Yes, the reason why you want to validate the institution's certificates is so you can verify the data signed with that cert (signed with the private key associated with the public key in the cert, to be explicit). --Sandy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
In message <[EMAIL PROTECTED]>, Randy Bush writes: > >> I believe a web of trust can be operationally feasible only if the web >> is more like a forest - if there are several well known examples of >> "tops" to the web. Otherwise, you have to be storing a plethora of >> different signers' certificates to be able to validate all the >> institution's certificates that come in. > >you need those certs to verify the live data anyway > Right. The real issue is the trust determination -- how do you know that the certificate corresponds to something resembling reality (whatever that is)? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
> I believe a web of trust can be operationally feasible only if the web > is more like a forest - if there are several well known examples of > "tops" to the web. Otherwise, you have to be storing a plethora of > different signers' certificates to be able to validate all the > institution's certificates that come in. you need those certs to verify the live data anyway randy
Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)
>Hierarchical relationships breed "reptiles" because of the inherent >asymmetric business relationship that results. >... >Frankly, I am quite impressed with the address registries. How would you feel about having the registries serve as the root of a hierarchical certificate system? >So an institution would have its "certificate" signed >by its upstream (or one of its upstream) providers. How is this relationship not a hierarchical, asymmetric business relationship? What happens in this paradigm in de-peering situations?Are you are intending to exclude peering relationships from this web of trust? >The providers could cross-certificate to build a "root free" (as in >"default free" zone) mesh (aka "Web of Trust."). I believe a web of trust can be operationally feasible only if the web is more like a forest - if there are several well known examples of "tops" to the web. Otherwise, you have to be storing a plethora of different signers' certificates to be able to validate all the institution's certificates that come in. After all, there are thousands of different providers out there. If every bgp speaker uses a different certificate in signing updates to provider A than in signing updates to provider B, then the validation can be quite complex. Any trust relationship model would have to deal with (a) Provider independent space (b) Multi-homed organizations, with and without AS's (c) Organizations that are mobile - they might change their attachment point frequently or abruptly. Authorities exist for some number resources - e.g., those registries hand out addresses - should that be validated by the web of trust? (The authority says the address is allocated to A but I've got an update showing the address originating from B validated by my best peer's three best peers' peers) (Sometimes authorities are needed - if you were buying a car from Joe Doe, would you prefer a title signed by the DMV or the testimony of your favorite body shops that Joe Doe has been their customer for this car for awhile now.) That authority extends downward through sub-allocations in a tree, not a mesh. (But the web of trust might be useful for those current special cases that don't devolve from the existing registries, aka legacy space, until that situation can be fixed.) --Sandy
