Subject: Re: [RPSEC] Discontiguous Deployment...

From: [email-masked]
Date: Fri, 28 Jul 2006 11:17:13 -0400 (EDT)

>A-B-C-D-E
>   |   |
>   +---+
>
>Assuming a model not unlike soBGP B and D could exchange security
>messages but not actual routing information over a multihop BGP
>session. 

Yes, a multihop session across the gap allows the security info
to flow between islands of non-contiguous deployment.

This can work if the gaps are relatively small and infrequent.

But in initial deployment, that might not be the case, like:

S1-A-B-C-D-E-S2-F-G-H-I-J-K-L-S3

where S1, S2, and S3 are security aware and the rest aren't.

It would be hard for S1/S2/S3 to know of each others' existance
to set up multi-hop sessions.

You could say that in very sparce deployment we can create a
central repository.  But I don't think it is a good idea to create
one means of distributing security info for use initially with a 
plan to change to another when deployment is more ubiquitous.
And a central repository could be bad - not responsive enough for
some security uses or when the deployment is widespread, etc.

--Sandy

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Russ White <[email-masked]>
Date: Fri, 28 Jul 2006 16:43:39 -0400

> S1-A-B-C-D-E-S2-F-G-H-I-J-K-L-S3

The average hop length in the Internet, today, is about 4. I don't think
many of the gov't networks I'm working on will be much longer than that,
and I can't think of any enterprise network much longer than that,
either (?).

I suppose my point is that the usefulness of different mechanisms for
discontiguous deployment are also going to depend on the actual network
involved. That doesn't mean discontiguous deployment isn't useful, it's
just that you have to consider the model provided against the networks
the mechanism is likely to run in....

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Jul 2006 23:27:18 +0200

[Apologies in advance for venturing into solution space]

> This can work if the gaps are relatively small and infrequent.

I don't think it's limited to that. If you look at the PGP web of  
trust and identify interconnected islands where there is a path from  
one key to another, you'll see that there is one huge set of  
interconnected keys and the next biggest one is orders of magnitude  
smaller. As islands grow, the chance of it interconnecting with a  
bigger one approach certainty, with the likelihood of hitting any  
particular island being relative to that island's size.

With secure inter-domain routing the same dynamic will exist to some  
degree, and additionally, people will find it beneficial to identify  
and interconnect with the largest islands. (And the most relevant  
ones too, of course.) Only at the very beginning things will be harder.

> to set up multi-hop sessions.

I guess that's true a little after the very beginning when secure  
ASes start popping up more or less randomly, after some coordinated  
testing at the very beginning.

There are several ways to solve this, including having a small new  
path attribute that signals the new securit capability and maybe  
points to a rendezvous point where the security information can be  
obtained.

> some security uses or when the deployment is widespread, etc.

The RIRs are apparently working on a distributed database for prefix<- 
 >AS mappings. It would make sense to import this information and  
then somehow inject it into the secure inter-domain routing protocol.  
I think an intermediate system would be beneficial here, in order to  
pre-process the information as much as possible. Also, having a small  
number of "idr security servers" could make it possible to not have  
secret keys with inter-AS significance in routers. (See the key  
rollover issues with TCP MD5. As long as you still have a secret key  
in the router you're vulnerable and as long as you can't roll it over  
unilaterally key rollover is too painful to do on a regular basis.)

At the same time, IDR shouldn't be dependent on external services, so  
it SHOULD be possible for the inter-domain routing system to operate  
autonomously as soon as the security information has been injected  
into the system.

Last but not least: I expect that if the new security stuff is any  
good, it will be deployed within large ISP networks fairly quickly  
(relative to how fast changes happen in such networks) because that  
way they can much more easily filter their customers and peers than  
they can today. So I expect it will mostly be the smaller networks /  
end-users that will take a wait-and-see approach because they often  
don't filter today and have less IDR expertise and less beefy hardware.