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

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 1 Aug 2006 11:23:26 +0200

On 31-jul-2006, at 16:14, [email-masked] wrote:

>> 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.
>> ...
>> At the same time, IDR shouldn't be dependent on external services

> So it sounds like you are arguing against yourself, here.

Someone has to do it.  :-)

> I understand the issues with carrying security info in-band through
> the unaware gaps.

> I also understand the issues with necessitating BGP contact external
> (aka out of band) services in order to function.

> I don't see an easy resolution.  Do you?

Not in the sense that one size fits all, no.

Currently, routing information is exchanged by routers. If you remove  
the links to the rest of the network from a router, it will no longer  
have the rest of the world in its various tables. We can model  
security information in the same way, such that it's injected at the  
point of origin and then follows the path the packets flow in the  
opposite direction. For some types of security information this will  
probably be necessary, but for others, such as the AS<->prefix  
mapping authentication information, this is certainly not a  
requirement: you don't really care where this information comes from,  
as long as it checks out.

One way to utilize this property is by jumping from one secure island  
to another using tunnels or multihop sessions. Since the AS<->prefix  
mapping authentication info doesn't have to follow the same path as  
routing, a couple of multihop paths from a secure island to the  
secure core are enough.

But that's only one way to do it.

In the situation where only something like half of the ASes inject  
AS<->prefix authentication information directly into inter-domain  
routing, it would be helpful to find this information somewhere else.  
The RIRs are currently working on a way to publish this information,  
so one way would be import this information and inject it into IDR.  
It makes sense that the RIRs do this so that everyone can enjoy the  
results, but maybe some people prefer to do this themselves and pre- 
process the information before injecting it into their routers. An  
ISP has a business relationship with its customers and would  
certainly want to translate that business relationship in a set of  
IDR security attestations that are generated in some central place  
and then pushed into the routing system.

All of this means that there can be security information that starts  
life in the routing system, but also security information that starts  
life outside the routing system and is injected into it at some  
point. The next logical step is that people start to exchange  
security information out of band so that it can be preprocessed  
before injecting it into the routing system. But the situation where  
the routing security servers can't work because routing is down and  
routing is down because the routing security servers don't work must  
of course be avoided.

Fortunately, a failure to have secure routing doesn't necessarily  
mean that there is no routing: we can fall back on routing that isn't  
secured. An obvious way to do this is to assign a higher local  
preference to routing information for which the security checks out.  
In such a situation, it would be possible to have the routers either  
not exchange any security information with external ASes at all, or  
only with / for a subset of all external ASes, and have no secure  
routing or only partial secure routing until security servers inject  
the security information and the authenticated routing information is  
given higher priority.

Does this make sense??

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

---

From: Guy Tal <[email-masked]>
Date: Fri, 4 Aug 2006 15:49:32 -0700 (MST)

> But that's only one way to do it.

Would this involve creating multihop sessions to customers of your
customers, or customers of your peers? If so, this could quickly get out
of hand administratively for some networks.

> routing is down because the routing security servers don't work must

Huge problem actually. A true out of band method for exchanging this
information would be quite costly and would non-insignificantly increase
the cost of interconnection.

> the security information and the authenticated routing information is

I'm not certain that networks would be willing to use as large of a hammer
as local preference to delineate between compliant and non-compliant
networks, especially when a transit relationship is involved.

I apologize that I'm just making objections instead of in turn offering
alternatives, but I can't think of feasible alternatives right now.

Regards,
Guy Tal

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 5 Aug 2006 11:32:58 +0200

> of hand administratively for some networks.

No, the idea is that you have islands of ASes that talk the secure  
protocol, and then you only need to link the islands, not individual  
ASes.

In theory, you and a customer of a customer could run secure IDR  
while your direct customer doesn't and you'll want a multihop session  
to that customer of a customer, but in practice I don't think people  
will be prepared to do this for exactly the reason you mention. It's  
much easier to talk that customer of a customer into having a non- 
multihop session.  :-)

> A true out of band method for exchanging this

I meant out of band with regard to BGP, not in the sense that we'd  
build a new layer 1/2/3 network for this.

> networks, especially when a transit relationship is involved.

Using local preference for this is already pretty weak because it  
allows for a kind of bidding down attack where an attacker disrupts  
the secure protocol, for instance, with a DDoS attack, and then  
injects incorrect information into the insecure protocol which will  
then be accepted.

Possibly using insecure over secure information makes the whole  
exercise rather pointless, IMO.

You may be right that some people will not want to prefer secure  
information over insecure information, but I don't see what the point  
of running the secure protocol is in those cases, except maybe  
because up/downstream ASes want to exchange secure routing information.

> alternatives, but I can't think of feasible alternatives right now.

(-:

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 09 Aug 2006 11:27:04 -0400

In message <[email-masked]>
Guy Tal writes:
>  [snip]

Lets not get into analysizing a particular solution at this point.

There is a good requirement here.  We've already seemingly agreed that
all proposed solutions MUST provide an analysis of their use in a
non-contiguous deployment.  What this adds a possible further
requirement that all proposed solutions MUST provide an analysis of
their use in a sparse non-contiguous deployment.  In a sparse
deployment, the issue of building a web of multihop sessions quickly
becomes infeasible but this would only be discussed if there was a
requirement to analyze a proposed solution in a sparse deplyment as
well as a non-contiguous deployment.

Curtis