Short version: I don't think that souping up the interdomain routing
system, as is proposed with TARA, is the best
approach. Even if I did, and so had sufficient
motivation to try to understand TARA in complete
detail, there are many parts of the draft which
I think are impossible to to understand or evaluate
in comparison to BGP.
Hello Heiner,
Thanks for your description of TARA:
http://tools.ietf.org/html/draft-hummel-tara-00
There are several reasons why I don't think this could be a practical
solution to the routing scaling problem. In summary:
1 - Unbelievable and unsupported claims about IPv4 address space.
2 - The geographical routing arrangements do not seem to provide
operators with the control over packet flow which they need.
3 - It is far from clear how the whole scheme would work at all -
since a single 40 bit TARA Locator might apply to thousands
of TARA routers in the one square arc-second of the Earth's
surface.
4 - It is not at all clear how the new system would be more
efficient than BGP.
5 - There's no reason to believe anyone would want to adopt this
system initially - and even if they did, it is not clear how
the system could be developed alongside the existing system,
eventually to replace the old system.
6 - I find some parts of your I-D impossible to understand in any
way which makes practical sense to me.
Whenever confronted with a document that takes more than a few minutes
to read, I and I guess many people check it out to find some reason
why we don't have to bother with it at all. If we can find one
important part of it which we think is completely unrealistic, then we
can probably forget the whole thing as a serious concept and spend our
time on something else. (Nonetheless, even documents containing big
mistakes or outright lunacy can have something interesting within them
- perhaps something which prompts thoughts in a novel perspective,
leading to valuable new ideas.)
Such a judgement is easy to make for your TARA I-D, based on the
following text from page 2:
Furthermore, the IPv4 address depletion will become a non-issue,
because global uniqueness of the IPv4 address won't be required
anymore. Because the destination's IP address is not evaluated
prior having reached the TARA-ETR, its uniqueness is just
required within the local scope between TARA-ETR and egress
router.
What is the TARA-ETR? What is the egress router? There's no network
diagram or overall description of how TARA works.
There's no explicit mention of IPv4 hosts requiring new stack or
application capabilities, so the reader is entitled to assume that if
TARA was deployed fully, the above statement would apply to all
existing and future IPv4 hosts - both their unchanged stacks and
unchanged application programs.
(In section 4.1, the first option involves the sending host
doing a DNS lookup and affixing the TARA router to its outgoing
packets. This implies at least a change to the stack, and perhaps
to applications in order to ensure each application does a DNS
lookup rather than just operating with an IP address when sending
packets. The second option involves completely unmodified hosts
doing the DNS lookup, and TARA routers snooping on the reply and
later affixing the TARA header.)
Yet the entire basis of IPv4 communications on a global basis (apart
from anycast) depends on the uniqueness of global unicast IP
addresses. The hosts require this of the external world - the routing
system and other hosts.
No matter how you run the routing system, the only way you could make
hosts work with re-use of IPv4 addresses (the 0.0.0.0 to
223.255.255.255 range currently used as global unicast) would be to
drastically alter host protocols in some way. That is a complete
non-starter.
Some other statements which appear wrong, or at least unsupported by
evidence, include:
TARA will abolish the crazily excessive RIB/FIB memory consumption!
Yet there's no comparison between current requirements of a BGP router
and what would be required for a router in the same position operating
according to TARA.
Today, a BGP-router collects millions of downstream paths . . .
Meaning routes for prefixes. With ~330k prefixes, if the router has
four neighbors, it would get a route from each such neighbour for each
such prefix, meaning a million routes. Many routers have more than
four neighbors.
and yet is unable to see and utilize any upstream path - neither for
forwarding (detour), nor for traffic load handling. TARA will
abolish the crazily excessive UPDATE-churn! The hereby consumed
CPU-performance may better be used for well concerted and well
scoped traffic load notification messages.
I think you mean a router can tell others, which are sending it
packets, that it is getting congested.
As far as I know, this idea of altering routing according to
short-term traffic flows was abandoned many years ago because it was
difficult or impossible at the time to make it stable. I guess if
you want to do this, you would need to research it assiduously and
devise some very clever algorithms which extensive modelling indicated
would be stable.
How would "update churn" be reduce in TARA?
Broadly speaking, TARA consists of either creating a new interdomain
routing system to replace the BGP system, or progressively converting
the BGP system into something which works on totally different
principles. You mention using BGP to convey information between
routers: (page 3)
By means of BGP UPDATE extensions several (e.g. 5) differently
zoomed i.e. differently skimmed topologies of the entire internet
will be "produced".
but I understand you mean this to occur in a different manner
than the current BGP approach of evaluating routes offered by
neighbors for a given prefix, and then choosing one to use for packet
forwarding and as the basis of a route to to offer to neighbours.
Page 7 contains the information you want one router to send to each of
its neighbours. If that goes only to the neighbour and no further,
then that's fine. But how do the routers collectively work together,
using just these messages, so each one develops the various maps, in
various levels of detail, for each zoom level?
>From the description around page 9 I gather that there is a concept of
"flooding" information such as mentioned on page 7 to all routers
inside a geopatch - a square degree. But that could be a very large
number of routers. For each such message from a router XX, some other
router ZZ in the same geopatch could have 12 neighbours and so receive
the message from each of its 12 neighbours. Maybe this is OK if it
only needs to happen infrequently.
Key concepts of TARA include:
Geopatch Geographical areas covered by integer units of
1 degree latitude x 1 degree longitude. This is
60 nautical miles on each side, at the equator:
111.72 x 111.72 = 12,481 square km.
TARA Locator 40 bits encoding of geographical location, in
units of degrees, minutes and seconds.
At the equator, 1 arc-second is 30.8 metres.
Still, that is enough to enclose an entire
multi-storey building with thousands of unique
end-user hosts, routers and other devices.
The section "3. TARA Concept" describes a complete topologically
detailed map of all router connections in the interdomain routing
system (I think this is the case, meaning the routers which are
currently BGP routers - not including routers inside end-user networks).
Any one router knows the full detail of topology in its "local area",
however defined, and has less and less detailed maps of progressively
larger areas, with itself in the middle of each area. The highest
level area is one with the lowest detail - some kind of summary,
without detail, of the topology of the interdomain routing system of
the entire Internet (meaning the entire IPv4 Internet, or the entire
IPv6 Internet). That would be zoom level 5.
Zoom level 1 means a detailed map of every device (TARA routers - I
think) in the geopatch. But a geopatch is a huge area, for instance
about 90 km west of the centre of Manhattan and about 111 km north to
south (56 x 69 miles).
I think this approach is broadly understandable because it resembles
how we use real maps of roads etc. However, it is not so clear how
routers would use such information, even if it could be developed
collectively between them.
TARA routers (page 10) forward packets according to the 40 bit TARA
Locator in the TARA header which is affixed to all packets in the
interdomain routing system.
If the destination TARA Locator is in another geopatch, then the
router forwards it to a particular router in that geopatch. What is
to stop many or all of the routers in the world choosing the one TARA
router for this purpose in a busy geopatch, such as the one whose
eastern boundary is in the middle of Manhattan? That chosen router
would have to handle most of the packets arriving for any host in any
network in that geopatch.
I think these headers are affixed as the packet leaves an end-user or
ISP network, and goes to another AS. The router which does this needs
to be able to look up the IP address in the destination field and
obtain one or more TARA locators of routers which are handling this IP
address. I understand it does this by already having this
information, by snooping on the reply to a DNS query which was
initiated by the sending host.
So AAA is in some network NN and does a DNS lookup for the FQDN of
host BBB, which is in some other network QQ. The DNS query is assumed
to go out of NN via some TARA equipped border router BR1, and BR1 is
then supposed to look at the reply packet, which the DNS server will
ensure contains the TARA Locators of the one or more BRs of QQ which
are ready to accept packets addressed to whichever prefix matches
AAA's IP address.
I have some concerns about this:
1 - How can the DNS reply contain separate sets of TARA Locators
for each of multiple IP addresses when multiple are returned
as part of a round-robin load sharing system?
2 - BR1 would need to be sure the reply is from a genuine DNS
server. For instance, an attacker inside NN could send a
request to look up AAA's FQDN to its own malicious DNS server.
BR1 would dutifully cache the IP address and TARA Locators
in the reply. But then when a host in QQ sends a packet to
this address, BR1 will append a TARA header with one of these
bogus TARA Locators. For instance, at T=0, the host does
a DNS lookup and BR1 gets the proper TARA Locators from the
reply. At T=1, AAA sends packets to BBB, and BR1 prepends
them with a TARA header with the correct TARA Locator. Then
at T=2, the attacker does the bodgy DNS request and BR1
reads the bogus TARA Locator for this same IP address (AAA's
IP address) and subsequently affixes the bogus attacker's
TARA Locator to packets sent from AAA to BBB. So after this,
the attacker gets the packets which should have been sent to
BBB and can make itself an on-path attacker, at least in this
direction.
3 - How could you be sure that AAA would make a DNS request?
If AAA is simply replying to a packet from BBB, it would not
need to make any such request.
4 - How could you be sure that the DNS request by AAA would go out
the same BR1 that the later AAA to BBB packet would go out of,
and how could you be sure the reply would come back through
BR1 too? I suspect you can't, which would mean that all
the BRs of NN would need to share all the information they
obtain from any DNS reply. That is an instant scaling problem
for larger networks, and leads to an easy DoS vulnerability:
an attacker controlling a host in NN, or by means of
manipulating the behavior of a host in NN, can cause a large
number of DNS queries to go out, to legitimate or attacker-
controlled DNS servers. The replies can be very long, and
the BRs of NN would be required to convey the contents of each
reply to all the other BRs.
I wasn't able to completely follow the description of forwarding on
pages 10 and 11. However, since you argue that this is less
burdensome than current BGP arrangements, I think you should provide
some worst-case quantitative analysis of why this is so.
I understand (page 10) that when a TARA router receives a packet whose
destination TARA Locator is not in its own geopatch, that it looks up
a pre-computed table with an entry for each of the 64,800 geopatches
and uses GRE tunneling to send the packet to another TARA router in
the destination router's geopatch. So in addition to the TARA header,
which must be at least 40 bits long, due to the Locator being 40 bits,
there will be a GRE header as well. But does the GRE header have a
TARA header too? All these headers lead to serious problems with Path
MTU Discovery (PMTUD).
It is not clear how a network operator should determine the TARA
Locators of its routers if the router is physically mobile.
Also, since there could be thousands of TARA routers in the same
square arc-second, I don't understand how TARA could work at all.
In a single square second, there could be hundred or thousands of TARA
routers, operated by dozens or hundreds of separate organisations, all
with completely different positions in the actual topology of router
connections, and all with completely unrelated IP addresses.
In section 4.1, page 12, you contemplate a host adding a TARA header,
but the routers in its network not being TARA routers. What is the
TARA header? How could ordinary routers be expected to deal with it,
unless it begins with a conventional IPv4 or IPv6 header? If the TARA
header begins like this, then how are TARA routers supposed to
determine that this is actually the start of a TARA header, rather
than of a normal packet? They could only do this via traversing
deeper into the packet, which would be inordinately expensive for
every packet handled by the RIB.
You don't provide a diagram or definition of "TARA ETR", "TARA ITR" or
"TARA xTR".
The second paragraph in 4.2 is one of many which raise too many
questions in my mind to mention now.
Likewise, how can you (page 12) embed a TARA locator in a MAC address?
MAC addresses are 48 bits and TARA locators are 40 bits. How could
you change a MAC address when you move the device to a different place
geographically?
I will pass over 5.1 entirely.
In "5.2 Multihoming", how is the device which prepends the packet with
a TARA header meant to choose which of multiple TARA Locators to use
in that header? There could be several, each being an ETR-like TARA
router which can forward packets to the destination end-user network,
just like LISP. As with LISP, you need to create a way the header
appliers can decide which of these Locators to use - and that would be
based on which was reachable. However, the TARA router at that
locator needs to be more than reachable - it also needs to be able to
deliver packets to the destination network. The first problem is
difficult enough to solve - and I think it can't be done in a
sufficiently robust and scalable manner, with LISP or any other
approach such as TARA. The second problem is even harder to solve, at
least with LISP, since there's no way the header applier (an ITR in
LISP) can find out in a timely, robust and scalable manner whether the
ITR can send packets to the destination network. (These problems do
not occur in Ivip.)
Its not at all clear how TARA would do this - and it has to be the
TARA routers doing this "Locator liveness" testing, or if you have
TARA hosts adding the headers, it is the hosts which need to be doing
it. That would present even more scaling problems than if it was only
routers doing it, since there will typically be more sending hosts
than ITR-like routers handling their outgoing packets.
I will pass over 5.3 and the rest of the draft.
I don't understand how you can use a 40 bit geographical Locator to
forward packets, since there could be thousands of ETR-like TARA
routers in the one square arc-second.
Even if you could make all this work, how can ISPs and other networks
enforce the policy they want for forwarding packets to various
neighbors, according to which prefix the destination field matches, in
a manner which is more efficient in TARA then with the current BGP
arrangements?
On page 7 you mention the Internet has 10,000 DFZ routers. Where did
you get this figure? In August 2007 I researched this a little and
concluded tentatively that no-one really knew how many routers there
are in the DFZ, but that the estimate of 210,000 was a minimal figure:
Routers in DFZ - reliable figures from iPlane August 2007:
http://www.ietf.org/mail-archive/web/rrg/current/msg00257.html
http://www.ietf.org/mail-archive/web/rrg/current/msg00259.html
http://www.ietf.org/mail-archive/web/rrg/current/msg00261.html
http://www.ietf.org/mail-archive/web/rrg/current/msg00266.html
I have only a vague understanding of much of what you describe about
TARA. When trying to understand exactly what you mean, I think I
would need to spend many days working through the I-D sentence by
sentence, writing questions and getting you to answer them. But I
won't try this because I believe there are fundamental objections to
any approach such as this. See
http://www.firstpr.com.au/ip/ivip/#recrw
for what I think should happen.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
