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

From: [email-masked] (Noel Chiappa)
Date: Tue, 2 Oct 2007 11:57:54 -0400 (EDT)

> From: Danny McPherson <[email-masked]>

    > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Wed, 3 Oct 2007 10:45:16 +0100

> This, one could imagining putting together.

The IETF has delegated this to the IANA and the RIRs. So far, the RIRs
have not done anything more than keep the antiquated whois directory
functioning. I use the word "antiquated" in reference to whois directory
services not because of the query protocol, but because of its origins
as a way of auditing network users in order to justify budget
allocations back in ARPANET days. Since that time, there has never been
a serious attempt to rethink the purpose and scope of the IP addressing
whois directory. 

One wonders whether the vastness of the IPv6 address space is sufficient
change for the IETF to write some guidance to the RIRs regarding the
purpose and scope of a whois directory. Or maybe some other method of
signalling the "ownership" of address prefixes.

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

The RIRs have taken a stab at this problem with route registry services
but it has never gotten significant support from ISPs. Since the RIRs
delegate short prefixes to ISPs, who then may delegate longer prefixes
in some way, the chain of permission to originate/transit, originates
with the RIRs. Is a new protocol needed for this to work right? Or is
there simply not enough demand.

Note that some RIRs such as RIPE, attempt to maintain a fairly detailed
route registry database as part of their whois directory.

> 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'.)

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

--Michael Dillon