Subject: Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt

From: [email-masked] (Noel Chiappa)
Date: Wed, 3 Oct 2007 09:54:06 -0400 (EDT)

> From: <[email-masked]>

    >> Second, you're talking about potentially orders of magnitude more
    >> data: for each destination, there are worldwide likely hundreds (or
    >> more) of ISP's which are likely to be viable backbone transits.
    >> ...
    >> With ISP's which are directly connected with a customer, one can
    >> assume that there's an implicit authorization, but what about steps
    >> past that? If one further assumes that by p connecting to q, p is
    >> transitively authorizing q (with respect to [destination] A), then
    >> that can be done with straightforward (albeit complex and expensive)
    >> security on routing. However, if you go that way, then you lose the
    >> ability for A to make assertions about which q's are not acceptable.
    >> However, if you go that way, then you lose the ability for A to 
    >> assertions about which q's are not acceptable. If you add that back in
    >> as a policy knob ...

    > We have the technology to deal with orders of magnitude more data,
    > assuming that the task is delegated to servers, not to routers.

I guess I wasn't explicit enough; I made a reference to "straightforward
(albeit complex and expensive) security on routing", referring to automatic
mechanisms, but didn't specifically describe them as automatic; nor did I
specifically refer to the "policy knob" as being something that was manual.

I'm talking about *configuration* data; i.e. something humans have to enter,
and maintain. The issue is not the mechanical tasks of storing and
distributing the data, but the human effort required to set up it and update
it as needed, plus the likelihood (as always, when people are involved) of
errors being introduced.

	Noel

PS: The potential size of the problem is actually worse than I described
above, because there's an additional axis of freedom. Not only do you have to
multiply the number of destinations by the number of backbone transits, you
also have to multiply by the number of destinations *again*, because
destination A may think backbone transit q is fine, with respect to
communicating with B, but not when it's communicating with C. Fundamentally,
destination-vector systems (of which path-vector, such as BGP, are a subset)
are just not suited to doing this kind of stuff.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf