Re: [RPSEC] BGP Security Requirements v08

[Stephen Kent <[e-mail]>]

At 10:26 AM -0400 7/17/07, Curtis Villamizar wrote:
>In message <p06240507c2c167b442a1@[128.89.89.71]>
>Stephen Kent writes:
>> 
>>  I think the question is why, if the path info received by an "island
>>  AS" has a number of unverified hops, is this path info useful, in a
>>  security sense, to the AS that receives? How does the requirement to
>>  send such info promote adoption of the protocol?
>> 
>>  Steve
>
>
>Because it is likely to be more reliable than information with no
>authentication at all.
>
>The major ISPs are fairly reliable at getting their internal routing
>right so if the non-authenticating routers in the middle are entirely
>in a set of ISPs that are known to generally not have breakins into
>their own infrastructure.  For the purposes of commercial traffic
>among other ISPs that want to distinguish their services as having
>somewhat more reliable routing due to the use of authentication, there
>is a great deal of value.
>
>It may be optimistic to think that this value would be enough to give
>any routing authentication sufficient value to gain critical mass in
>the commercial world.  If there is no value for islands of deployment
>except to authenticate within the island this is a non-starter from
>day one in the commercial world.  If so it may be a non-starter at
>router vendors without a very large influx of money from elsewhere,
>such as government funding specifically for something that is not
>being implemented because it will never get commercially deployed.  If
>you are sure that the money is out there waiting for this spec to
>publish, then fine.  Otherwise you may be wasting your time and ours
>if the requirement to add value to disconnected islands is ignored.
>
>That's just an opinion and I don't know how widely held it is today.
>This might be a good question to ask at the WG meeting.
>
>Curtis

Curtis,

I think our difference of opinion arises from the different 
perspectives we bring to the problem.

As a "security guy" I would not agree with your opening statement. 
We usually worry that mixing unverified info with verified info, in 
any context, is a recipe for trouble, as it encourages folks to 
accept the mixed info and treat it as verified.  You give an example 
of ISPs wanting to " ... distinguish their services as having 
somewhat more reliable routing due to the use of authentication ..." 
That is precisely the sort of claim most security folks would worry 
about :-).

As for what will make incremental valuable enough to ISPs to warrant 
their buy-in, I think that's a hard call for anyone to make right 
now.  One possible deployment scenario is that the biggest ISPs will 
deploy first. If so, then the fact that most of these folks have 
direct peering arrangements with one another would allow them to 
benefit, irrespective of the issue of intermediaries who are not yet 
playing. If the next set of adopters are ISPs directly connected to 
the big ISPs, and often to one another (e.g., via IXPs), then they 
too can derive benefits in many instances, even without passing 
verified path info through unverified ASes.

So, given possible deployment scenarios like these, the uncertainty 
about which deployment scenarios may happen, and the security 
principle of avoiding situations that may encourage folks to accept 
mixed data as all authentic, I feel it's inappropriate to mandate 
support for passing such data along.

Steve


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