Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03

Russ,

>...
>>  agreed, which is why I think it makes sense to consider these
>>  (necessarily) vague considerations as goals, but not requirements.
>
>Hmmm... I would think that if this is something that's required for any
>system to have a realistic opportunity of actually being deployed, then
>it's still at least a SHOULD. Perfectly undeployable perfect systems are
>not really solutions at all. :-)

yes, but vague comments about performance and manageability are just 
fodder for debate, not objective metrics that should be described as 
"requirements." :-)

>
>>>  UPDATE frequency as such doesn't help much.  You need to consider the
>>>  protential update frequency -- e.g., what would happen if the session
>>>  was reset or flapping and basically all the prefixes would need to be
>>>  processed at once one or more times.
>
>>  When I said UPDATE frequency I was considering this as well. When a
>>  session is reset and one receives a lot of UPDATEs from a peer, it is
>>  not necessary to verify the signatures on all of them, if one uses a
>>  mechanism based on signed UPDATEs. One shoud look at each UPDATE and ask
>>  "if this UPDATE is authentic, does it cause me to change my LocRIB?" If
>>  the answer is no, then there is no need to peform crypto verification on
>>  the UPDATE at that time.
>
>If you lose a peer, you have to clear your RIB for all information
>previously received from that peer, receive all updates, and then
>reinstall all of them into your RIB. It's not always clear when an
>update will change you RIB or not--there's no implementation I know of
>that evaluates whether or not a route would win if installed before
>processing the route, they all choose their best route, and attempt to
>install the route, seeing if it actually is installed when the attempt
>is completed. (I know, just a nit, but the closer we are to reality in
>our understanding of how implementations actually work, the closer we
>can mold requirements so they will be do-able in the real world).

Which RIB?

The AdjRIB for the peer in question can be populated with unverified 
advertisements safely, so long as no unverified routes are selected 
for use in the LocRIB. When a route is selected as the "best" for the 
NLRI in question, then it needs to be verified before it can be used 
safely.

What aspect of this heuristic do you feel is inconsistent with how 
implementations actually work?

Steve

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