I think this discussion is turning into a nice demonstration that
there can be one set of requirements and multiple architectures.
Requirement 1: At the level of abstraction, there is a difference between
routing policy and routes. The means of their distribution
and validation are architectural decisions.
Requirement 2: There MUST be the ability to select between
an "optimistic" rule that routes can be used before
the associated policy is validated, or a "pessimistic" rule
that policies must be validated before a route can be used.
Requirement 3: There MUST be a configurable capability to have routes signed.
It must be possible to configure whether the route is
acceptable before its certificate is validated. This is
different than #2 above, because it deals with routes, not
policies.
Think of the difference is that route validation implies that
the route update was indeed transmitted by the originated
domain, while policy validation implies the route was a
legitimate route for the domain to transmit.
Requirement 4: There MUST be a practical means of certificate distribution.
At 6:02 PM -0500 3/6/02, Jeffrey Haas wrote:
>On Wed, Mar 06, 2002 at 01:21:01PM -0500, Howard C. Berkowitz wrote:
>> At an abstract level, not much. On a real level, I would be concerned
>> about the performance implication. Does one domain, for example,
>> send all its policy rules to another, or does the receiving design
>> request the ones it needs?
>
>Theoretically, you could just flood all certificates at the
>start of your peering session and any updates to them (highly
>infrequent?) at the start of your peering session. You only
>need propagate certificates for the routes you are using and
>propagating.
>
>> Perhaps there's an analogy here to ORF, but outbound policy filters.
>> I'm not prejudging, but just as we often want to avoid the transfer
>> of a whole RIB, we may want to prevent the transfer of an entire
>> domain policy.
>
>See above.
>
>> There are certainly several ways to avoid this. Something like ORF in
>> the "routing protocol," or a client/server ability to request policy,
>> perhaps in the spirit of source demand routing (SDR).
>
>No different really. You only get that which the other guy is using.
>
>> But I'm drifting into the area of protocol. The broad requirement, I
>> believe, is that policy distribution should not have an appreciable
>> effect on the performance of what, for lack of a better term, I'll
>> call the real-time control plane.
>
>But that *is* a protocol issue. If its distributed in-band, its
>going to delay convergence. If the protocol says to process the
>certificates synchronously with installing the routes, thats an
>issue. Out of band certificate reception also forces things
>to be asynchronous with respect to validation and propagation of
>routes. The exact mechanisms aren't important, but the generalities
>are - they specify the architecture.
>
>> Is something missing before your next couple of paragraphs?
>
>About 6 hours of sleep. Sorry.
>
>> I'm unclear, for example, if the updates,
>> the policy data base, or both are signed.
>
>Some elements may require signing. I'm generically referring to the
>signature method as "certificates" although that particular mechanism
>may not be appropriate. More analysis is required.
>
>> That is one potential requirement, which I'll call the optimistic
>> case. There may be a different but equal pessimistic case where
>> routes are not used until validated. A requirement document could
>> very well identify these as alternate choices.
>
>Or leave the route usage pre- or post- validation as a matter of
>choice with the requirement that you indicate that you've
>validated your validation of it or not. In the case of
>nested signatures, this is pretty apparent.
>
>--
>Jeff Haas
>NextHop Technologies
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT