potential new IETF WG on anonymous IPSec

[Ian Grigg]

Joe Touch wrote:
> Ian Grigg wrote:

>> On the backbone, between BGP peers, one would have thought
>> that there are relatively few attackers, as the staff are
>> highly trusted and the wires are hard to access - hence no
>> active attacks going on and only some passive eavesdropping
>> attacks.  Also, anyone setting up BGP routing knows the other
>> party, so there is a prior relationship.
> 
> 
> My understanding of the attacks this past spring is that:
>     a) they were indeed on the backbone BGP peers
>     b) that those peers had avoided setting up
>        preshared keys or getting mutually-authenticatable
>        certificates because of the configuration overhead
>        (small on a per-pair basis, but may be large
>        in aggregate)
> 
> While inspired by this issue, there may be other solutions (e.g., IMO 
> IPsec) which are more appropriate for BGP peers.


Thanks for the clarification.  Re-reading (all) of
the above, I noticed that these are DOS attacks.
(That changes things - crypto protocols don't really
a priori stop or defeat DOS attacks.  They can help,
or they may not, it all depends.)

It's then important to examine the threat here.  Who is
the attacker and what motives and tools does he have
available?  It would be annoying to do all the work,
only to discover that he has other tools that are just
as easy...  (This is called what's-your-threat-model,
sometimes abbreviated to WYTM?)

>> The whole point of the CA model is that there is no prior
>> relationship and that the network is a wild wild west sort
>> of place
> 
> 
> Except that certs need to be signed by authorities that are trusted.

Right, in that the CA model seeks to add trust
to the wild wild west by the provision of these
signed / trusted certs.  Whether it achieves that
depends on the details.  It is not wise to just
assume it succeeds because someone said so.

>> - both of these assumptions seem to be reversed
>> in the backbone world, no?  So one would think that using
>> opportunistic cryptography would be ideal for the BGP world?
>>
>> iang
> 
> 
> 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.

In the world of PKIs, there are some big assumptions.  Here's
two of them:

    Alice and Bob don't know each other, and don't necessarily
    trust each other.

    There exists a central stable party that *both* Alice and
    Bob know better than each other and can be trusted to pass
    the trust on.  Known as a trusted third party, TTP, or a
    certificate authority, CA, in particular.

This situation exists in large companies for example - the
company knows Alice and Bob better than they may know each
other.  (In theory.)

Now, whether it exists in any real world depends on which
world pertains.  In the world of browsing, it is .. assumed
to exist, but that can be challenged.  In the world of email,
it pretty clearly doesn't exist - almost all (desired) email
is done between known parties, and the two parties generally
have much better ways of establishing and bootstrapping a
crypto relationship than asking for some centralised party
to do it.  (Hence, the relative success of PGP over S/MIME.)
Ditto for the world of secure systems administration (SSH).

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?

In such a world, a CA-signed certificate is an encumberance
only, and seems to be matched by comments in the AnonSec
draft that they are unlikely to be deployed.

iang

PS: on the general issue of doing what you call anonSec,
I'd say, fantastic, definately overdue, could save IPSec
from an embarrassingly slow adoption!  I do concur with all
the other posts about how "anon" is the wrong word, but I'd
say that getting the right term is not so important as doing
the work!

On the point of what the right word is, that depends on
the technique chosen.  I haven't got that far in the draft
as yet.