Re: [RPSEC] BGP Security Requirements v08

Curtis writes:
>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.

Curtis, I'm not sure exactly what you mean here, but Steve was talking
about AS hops, not router hops.  I *think* that's what you mean, also,
but I'm not sure.

Steve, I strongly believe that incremental deployment scenarios WILL
include cases where non-upgradable ASs will be provided with other,
operational or algorithmic, protections, so that ISPs in the know will
trust paths that come to them from those ASs.  I am less strongly
convinced that incremental deployment scenarios MUST include such cases.
But I see no way to provide benefit in incremental deployment otherwise.

I do not think that you are saying that solutions COULD NOT provide
benefit when island hopping.  The work being done in the sidr wg
(to provide an infrastructure that would provide authorization for
prefix origination) would be an example of protections that would
still provide benefit when island hopping, as the origin authorization
check is of value no matter how many clueless ASs touch the UPDATE.

I believe that you are arguing whether solutions should be REQUIRED
to provide benefit when island hopping.  And Curtis is arguing that
they should, because otherwise incremental deployment will be very
very unattractive.

The choices seem to boil down to MUST or SHOULD.

--Sandy

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec