|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: soBGP deployment
On Sat, 21 May 2005, Pekka Savola wrote: There's nothing to say the functional equivalent of certificate could also not be passed in an option or some other means as well when needed. My assumption would be that being able to use public databases would be a protocol optimization.I think people here are missing fundamental issue. It is not with how in particular signed data is passed (although that is important and certainly SBGP is doing it in more secure way then soBGP ) but with who can vouch for the signed data, i.e. its the distribution of authoritive data. It should be understood that its not only that you need to lookup policy for ASN and see if it can announce ip block but it should be possible to verify that ip block owner gave that ASN permission to announce the block, The way it should work is that ASN gives ip block owner its cert, ip block owner signs it with its private key and the new signed cert is given back to ASN. Now ASN can give this cert to anybody else and they can verify (assuming access to public key of ip block owner is available) that ASN has right to announce the block. For peer relationships it works in similar way, when ASN1 wants ASN2 to announce its routes, it asks ASN2 to give it its public cert, then ASN1 signs the cert and gives it back to ASN2. Now here is worst part, ip block owner can not be trusted just because they gave you certificate that says 192.168.0.0/24. IP block owner's certificate itself should be signed by known trusted party that can vouch for that block owner, i.e. whoever gave the ip block, i.e. RIR or another RIR that allocated the block. So to get this all in place and working we need to develop a complete root->enduser public key distribution infrastructure working all the way from RIR to the LIR to ISP and from one ISP to another and I don't see it happening. Right now RIRs only recently started offering X.509 certs for updating whois (and ARIN, for example specifically said their cert is to be used only when talking to ARIN and is not intended for anything else) so the next step is try to to test if same cert can be used for signing data related to routing policies and if it works then we should begin to be worried on how best to distribute the end-resulting signature. Regarding distribution, I think routing registry is fine for initial deployment (as long as root certificate is signed by known trusted authority, which is one of the RIRs) as that can be done faster and it is less intrusive on BGP infrastructure. Ones we have some success with routing registries and signed data, then we can work further start moving with signed data sent with BGP but that should be done slowly in the way that makes sure those who do not support it do not suffer, so basically a new parameter would be required for peering setup for both sites when they want to talk "S-BGP" and it would be necessary for all routers in the middle to support it for end-end to work. As I described that above, it would not help with "man in the middle" ifNote that there's no technical reason AFAICS not to tie the signed origin statements to the origin's AS number, i.e., if someone would want to hijack a prefix, it would need to spoof the AS number as well. Not sure if that helps a lot, of course.Let me add a word about cut-and-paste attacks. A signed origin statement asserts that some AS owns some prefix. That statement will be readily available. A nefarious site could cut that statement from some actual BGP session and prepend it to its own path announcement. That would add a hop, but many ASs will still prefer it and route towards the apparent owner through the nefarious site. The nefarious site wouldn't forward such packets, of course; it would treat the packets as its own. that middle ASN adds an appropriate origin ASN in its announcement and the path itself is not signed. But this is a good point -- I think a fundamental question that needs to be asked is whether a sufficient security could be gained by just the originator and the verifier doing the cryptographic operations, and not requring everyone in the middle also do them (adding signatures etc.). Personally I'd certainly hope so -- because the practical deployment issues with the on-the-path signing model seem prohibitive (too much 3rd party deployment required before the solution would be useful).A full solution is of course having each "middle-ASN" further sign the prefix it is transmitting, but I can only see that happening and working properly if SBGP id deployed slowly for each router and that would take long time. Quick way out that is using certificates that allow to verify peering relationship (but not necessarily actual route announcement). But that does require going through each "ASN1 ASN2" pair in routing table and trying to check if its correct - would require specially designated equipment to sort out all these relationships and cache cryptographic or verification information. -- William Leibzon Elan Networks [email protected]
|