RE: [RPSEC] BGP Security Requirements v08

["James Ko" <[e-mail]>]

Indeed, ideally incoming data should be "authentic" and "verifiable",
otherwise we are back to square one and this work is no different but to
give bad guys a window of opportunity to run man-in-the-middle attacks,
or inject bogus routes.



James Ko, CISA CISM CISSP-ISSAP GCFW GCIH
OAM & Security 
Nortel
[e-mail]
phone [phone] (ESN 393 6920)

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Tuesday, July 17, 2007 11:10 AM
To: [e-mail]
Cc: [e-mail]; Russ White
Subject: Re: [RPSEC] BGP Security Requirements v08

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


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