potential new IETF WG on anonymous IPSec

[Bill Stewart]

At 04:05 PM 9/16/2004, Joe Touch wrote:
>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  bill.stewart at pobox.com