ietf
[Top] [All Lists]

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

2007-10-02 09:12:22
    > From: Danny McPherson <danny(_at_)tcb(_dot_)net>

    > where's the authoritative source for who owns what prefixes

This, one could imagining putting together.

    > and who's permitted to originate/transit what prefixes?

This is a whole different kettle of bits.

For one thing, there's no guaranteed-uniquely-definitive answer: entity A
might have one idea of how it wants packets to flow from it to a given other
entity B (say, 'don't use provider X because we despise them'), but entity B
might disagree. Who should win that dispute? So the whole notion of 'allowed
to transit' is a potential tussle space; mind, I'm not saying there always
will be this sort of issue, but it's *possible*.

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. (By 'backbone transit', I
mean ISP's/AS's which are not even directly connected to the organization
which is the source or destination of the packets; e.g. customer A is
connected to ISP p which is connected to ISP q which is connected to ISP r
which is connected to customer B; q is a 'backbone transit'.)

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 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. If you add that back in as a policy knob, then you're back to
"potentially orders of magnitude more data".

        Noel

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf