FWIW, the other system we were referring to - TCP-MD5 - works at the TCP layer. It rejects packets within TCP, before any further TCP processing, that don't match the MD5 hash. It isn't BGP authentication.
Oh - I'd misunderstood. Yes, that sounds much harder to forge, so it's actually useful for DOS reduction.
At 03:27 AM 9/17/2004, Ian Grigg wrote:
I wouldn't think that the encryption need be opportunistic; in the BGP backbone world, as you noted, peers are known a-priori, and should have certs that could be signed by well-known, trusted CAs.
Let's see if I can make these assumptions clearer, because I still perceive that CAs have no place in BGP, and you seem to be assuming that they do. ... When we come to BGP, it seems that BGP routing parties have a very high level of trust between them. And this trust is likely to exceed by orders of magnitude any trust that a third party could generate. Hence, adding certs signed by this TTP (well known CA or not) is unlikely to add anything, and will thus likely add costs for no benefit.
If anyone tried to impose a TTP for this purpose, I'd suspect the BGP admins would ignore it. Another way of thinking about it is to ask who would the two BGP operators trust more than each other?
There are two reasons to use the CA. One is if the parties don't know each other (not a problem here), but the other is so the VPN receiver has some external validation on the data it receives, making MITM attacks harder. For applications like BGP, you don't care if the CA is Dun & Bradstreet or if it's just Alice's own CA, because it's really functioning as a shared secret but the commodity VPN hardware wants an X.509 cert for MITM protection.
----
Bill Stewart [EMAIL PROTECTED]
