At 10:47 AM -0500 3/6/02, Jeffrey Haas wrote:
>On Tue, Mar 05, 2002 at 02:35:50PM -0500, Howard C. Berkowitz wrote:
>> In general, I agree with this. What most troubles me is any implicit
>> assumption that policy repository content must be distributed by the
>> "routing protocol," for want of a better term.
>
>What's necessarily wrong with this?
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?
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.
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).
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.
Is something missing before your next couple of paragraphs? Route
validation (or a choice not to do it) is a potential requirement, but
there seems to be something missing in the transition between your
comments above and below. I'm unclear, for example, if the updates,
the policy data base, or both are signed.
>
>A couple obvious "attacks":
>1. Not propagating a "certificate" if the certificate is a separate
>packet element than the route(s) that it covers. This is a form of
>DoS.
>2. Propagating stale certificates.
>
>Many of the same issues with root certificates (ala SSL) apply.
>
>> Especially when considering initial validation of routes, there may
>> be a requirement to consult a registry in non-real time to apply
>> heuristics.
>
>It may be necessary to use routes in an untrusted fashion until
>you can finish the validation process. This might involve something
>along the lines of:
>0. Initiate peering session - get initial dump of routes and certificates.
>1. Take routes, validate them against the in-stream certificates,
> your copy of the root certificate and use them in a semi-trusted
> fashion.
>2. Validate your copy of the root certificate(s).
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.
>
>I think that completes most of the handshake that you would need.
>
>I'm aware that I've probably missed some steps - I'm not a cryptographer.
>
>> Also, if anything is digitally signed, where does the certificate
>> authority get involved?
>
>The problem set, I would expect, would be much the same as SSL. Thus,
>a boot-strapping process of getting some root certificates distributed
>is needed.
>
>--
>Jeff Haas
>NextHop Technologies
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT