[81007] in North American Network Operators' Group
Re: soBGP deployment
daemon@ATHENA.MIT.EDU (william(at)elan.net)
Mon May 23 06:32:47 2005
Date: Mon, 23 May 2005 03:31:32 -0700 (PDT)
From: "william(at)elan.net" <william@elan.net>
To: Pekka Savola <pekkas@netcore.fi>
Cc: "Steven M. Bellovin" <smb@cs.columbia.edu>,
Randy Bush <randy@psg.com>, vijay gill <vijay@umbc.edu>,
nanog@merit.edu
In-Reply-To: <Pine.LNX.4.61.0505212313490.3347@netcore.fi>
Errors-To: owner-nanog@merit.edu
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.
>> 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.
>
> Note 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.
As I described that above, it would not help with "man in the middle" if
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
william@elan.net
