One document matched: draft-adan-idr-tidr-01.txt
Differences from draft-adan-idr-tidr-00.txt
Network Working Group Juan Jose Adan
Internet Draft GISS
Expiration Date: April 2007
November 2006
Tunneled Inter-domain Routing (TIDR)
draft-adan-idr-tidr-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this paper we propose a new hierarchical method to enhance
the current routing and forwarding paradigm for the Internet
called Tunneled Inter-Domain Routing (TIDR). We will present the
way in which TIDR permits to establish tunnels to the edge of
the network, and how they will be used to forward traffic to
stub networks. These tunnels will be explicitly signaled by
using a new transitive BGP attribute called LOCATOR. This new
routing and forwarding paradigm provides, among others, the
following benefits: global routing table reduction, inter-domain
routing infrastructure protection, improved multi-homing of edge
networks, numerous forwarding decisions for a particular address
prefix, it stops the AS number consumption, and it can be
smoothly deployed.
J.J. Adan [Page 1]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Identifiers and Locators in TIDR . . . . . . . . . . . . . . . 3
3. Tunneled Inter-domain Routing . . . . . . . . . . . . . . . . 4
4. Relativity of Identifiers and Locators . . . . . . . . . . . . 5
5. Using TIDR in the Internet . . . . . . . . . . . . . . . . . . 5
5.1. Initial Questions and Primordial Idea . . . . . . . . . . . . 5
5.2. TIDR Basic Mechanism for a Single-Homed Site . . . . . . . . 6
5.3. TIDR Basic Mechanism for a Multi-Homed Site . . . . . . . . . 7
6. Locators of Locators for a Hierarchical Internet: The Onion Model
8
7. TIDR Benefits for the Internet . . . . . . . . . . . . . . . . 9
7.1. Size Reduction of the Global RIB Table . . . . . . . . . . . 9
7.2. Deterministic Customer Traffic Engineering for Incoming Traffic
9
7.3. Numerous Forwarding Decisions for a Particular Address Prefix 9
7.4. TIDR Stops AS Number Space Depletion . . . . . . . . . . . . 9
7.5. Improved BGP Convergence . . . . . . . . . . . . . . . . . . 10
7.6. Protection of the Inter-domain Routing Infrastructure . . . . 10
7.7. Easy Separation of Control Traffic and Transit Traffic . . . 10
7.8. Different Layer-2 Protocol-IDs for Transit and Non-Transit
Traffic . . . . . . . . . . . . . . .. . . . . . . . . . . . 10
7.9. Multihoming Resilience . . . . . . . . . . . . . . . . . . . 11
7.10. New Address Families and Tunneling Techniques . . . . . . . 11
7.11. TIDR for IPv4 or IPv6, and Migration to IPv6 . . . . . . . . 11
7.12. Scalability, Stability and Reliability . . . . . . . . . . . 12
7.13. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.14. Faster Inter-domain Routing. . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
8.1. Identifier prefixes authentication . . . . . . . . . . . . . 13
8.2. Locator prefixes authentication . . . . . . . . . . . . . . . 13
8.3. Finer DoS attacks mitigation . . . . . . . . . . . . . . . . 14
9. Futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16
15. Intellectual Property . . . . . . . . . . . . . . . . . . . . 16
J.J. Adan [Page 2]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
1. Introduction
Routing protocols install all subnet prefixes in the routing table
in the same manner, without taking into consideration the place
where these subnets reside within the network. Because of this fact,
every time there is a change in a stub network the RIB is always
rebuilt again, thus possibly causing an instability to the routing
system:
1) In the Internet, prefixes of a multi-homed non-transit domain,
i.e. an autonomous system not participating in true inter-domain
routing, are given the same treatment as the prefixes of a transit
domain. Irrespective of the type of domain all prefixes are
installed by BGP [1] in the same global routing table, also known
as the global routing information base (RIB).
2) Within a single domain, stub network prefixes are installed by
interior gateway protocols (IGPs), like OSPF [2] or IS-IS [3],
in the same routing table (RIB) where they install transit
networks, whether stub network prefixes are installed as a
result of a full SPF run or a partial SPF run.
Tunneled Inter-Domain Routing (TIDR) modifies both the usual routing
and forwarding processes currently used in IP networks by treating
stub networks in a different way than transit networks. This special
treatment is twofold: stub network prefixes will not be installed in
the RIB; and traffic for stub networks will be sent over tunnels
established to the edge of the network. We will show how this special
treatment of stub network prefixes is nothing else but an easy
solution to the identifier-location split problem, and some of the
many benefits that such a split provides in terms of scalability,
stability and the introduction of new routing features.
2. Identifiers and Locators in TIDR
It is well known that IP addresses are semantically overloaded because
they carry information on both the location and the identity of a device.
The need to split these two roles has been discussed many times in many
different forums with regard to (a) the possible introduction of a new
hierarchical routing paradigm in the Internet [4] [5] [6], (b) as a way
to provide scalable site multi-homing [7], or (c) the introduction of a
new addressing architecture [8], among other benefits.
Some have pointed out that NAT is the feature that finally breaks the
semantic overload of the IP address as both a locator and a global
identifier [9] but what NAT really does is to translate global
identifiers into another set of identifiers, namely private
identifiers, which is precisely the reason why the end-to-end principle
is broken by NAT. TIDR clearly differentiates the use of locators and
identifiers and does not impede the use of either identifiers or new
mechanisms for endpoint identification within the applications.
J.J. Adan [Page 3]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
The split of identifiers and locators in IP routing has failed so far
because no simple method has been found to associate locators to
identifiers. The use of tunnels for IP routing according to TIDR permits
to base routing solely in locators while still providing transport-layer
survivability between endpoint identifiers. We will show how locators are
assigned to identifiers in TIDR by means of an in-depth analysis of current
routing protocols. This analysis will allow us to identify stub networks
and their possible locators, so as to modify the usual stub network
installation in the RIB as well as to explain the new forwarding paradigm
that we will use for them.
In this paper we will focus on the use of TIDR within the Internet. We
will show below how TIDR locators are assigned to identifiers by means of
a new transitive BGP attribute called LOCATOR. This paper sets out some
of the ideas initially presented in [10]. The use of the TIDR paradigm
with IGPs will be the focus of a subsequent paper [11].
3. Tunneled Inter-domain Routing
Do we really need stub networks prefixes for actual IP routing?. TIDR
permits to send traffic for stub networks over tunnels established to
the edge of the network. But, where is the edge of a network?. In TIDR,
the edge of a network will be the place where stub networks are attached.
And the exact meaning of "stub network" will be relative to the environment
we are analyzing: the Internet or an enterprise domain.
TIDR proposes a new method that current routing protocols will use to
manage stub networks. In TIDR stub networks will not be installed in the
RIB, as usual, but in a new table called Tunnel Information Base (TIB).
Afterwards, when routing a packet to the destination prefix, the TIB will
be searched first to perform tunnel imposition, and secondly the RIB for
actual routing. After the edge router performs tunnel imposition, all
routers in the middle will route this packet until the router being the
tail-end of the tunnel.
All we need is to find a way for a router to tell it is able to receive
tunneled traffic for a given prefix. For that purpose we will analyze
current routing protocols to find out what information can be used as a
locator for a specific stub network. Once we find a possible locator then
we will be able to send tunneled traffic for that stub network, provided
that both the router performing tunnel imposition and the router receiving
the tunneled packet are TIDR-aware. Therefore, the receiving router, in
addition to the IP address of the tunnel destination (locator), will have
to tell the types of encapsulations it supports for a particular prefix,
and the router performing tunnel imposition will have to support that
specific encapsulation method, a multipoint GRE tunnel for instance.
J.J. Adan [Page 4]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
4. Relativity of Identifiers and Locators
As we have already mentioned, IP addresses are semantically overloaded
because they provide information on the location where a device is and on
the identity of the endpoint. TIDR permits to split both functions very
smoothly because a normal IP address will become identifier or locator
depending on the way we will use it: it will become just a mere endpoint
identifier as long as there exists a locator to which we can tunnel its
traffic. And similarly, a normal IP address will become a locator whenever
it is used as a tunnel destination. This does not mean that this IP works
as a locator only, but it means that it will work as a locator in TIDR
routing (i.e. it will be in the RIB). Then, the role of an IP address as an
identifier or as a locator is relative to the use we decide to do with it.
5. Using TIDR in the Internet
5.1. Initial Questions and Primordial Idea.
Why do we need to assign a public autonomous system number (AS) to
non-transit multi-homed domains when the fact is that they do not
participate in inter-domain routing?. Do we really need the prefixes
residing within non-transit multi-homed domains for inter-domain routing
when they are beyond the inter-domain routing infrastructure?. We will
show how TIDR allow us to get rid of these two needs.
Let's start by looking at the AS_Path attribute received in the BGP
advertisement for one of these customer prefixes: if the right-most AS in
the path would be able to accept tunneled traffic for each and every prefix
originated by that AS, then we could move all of these prefixes from the
global RIB to the TIB. All we need is to assign an IP address to that AS
for using it as the tunnel destination for all the traffic sent to that AS.
This IP could be formed using a spare /8 prefix and the AS number for second
and third octets, and it would be used as an anycast address assigned to a
tunnel interface in every border router. Obviously, this IP address would
have to be stored in the global RIB. This approach would permit to reduce the
global RIB size but it would not provide new features to the inter-domain
routing system.
Let's continue to look at the AS_Path attribute: if the penultimate AS in the
path would be able to accept tunneled traffic for that prefix then we could
again move the prefix from the RIB to the TIB. But the penultimate AS-es in
the AS_Path of all the BGP updates received for a customer prefix turn to be
the upstream providers for the customer AS. This second approach, in addition
to reduce the size of the global RIB, will provide new features as we will
show below.
Therefore we need to find a way for the provider AS to tell it is able to
receive tunneled traffic for a given customer prefix. For that purpose we
will use a new transitive BGP attribute that we will call LOCATOR and that
the transit AS will add to the announcement of the customer prefix. The
J.J. Adan [Page 5]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
LOCATOR attribute will contain, among other things, the IP address of the
tunnel destination (i.e. the locator) as well as the types of encapsulations
it supports for a particular prefix. This tunnel could be for instance a
multipoint GRE tunnel.
To better understand the way TIDR works for inter-domain routing we will
explain roughly this mechanism for a single-homed site to get the basic idea,
and later we will extend the explanation for a multi-homed site.
5.2. TIDR Basic Mechanism for a Single-Homed Site.
Let's consider a site single-homed to upstream provider ISP1 that uses a
provider-independent prefix, what implies its presence in the BGP global RIB.
Let´s suppose now that ISP1 is TIDR-aware, which means it will advertise the
prefix using a new transitive BGP attribute called LOCATOR to tell other
autonomous systems that ISP1 is willing to receive traffic for its customer
using a specific tunnel encapsulation.
When this BGP announcement arrives to the routers of the TIDR-aware ISP2,
they will install the prefix in the RIB as usual, but they will also install
the prefix in the TIB. Later, when one of these routers receives a packet for
the single-homed site it will check the TIB before the RIB and, since it will
get a match, it will encapsulate the IP packet according to the tunnel
encapsulation that ISP1 specified in the LOCATOR attribute and that was
stored in the TIB. Any ISP in the path from ISP2 to ISP1 will only have to
look up ISP1 prefixes to route the packet towards ISP1. Upon receipt of the
encapsulated packet, ISP1 will extract the original IP packet and deliver it
to the single-homed site.
When all autonomous systems in the Internet are TIDR-aware the final result
is that all routers having full-routing will have the customer prefix both in
the RIB and the TIB. When a new packet is sent to the customer only the first
TIDR-aware router will have to look up the TIB+RIB whereas the rest of the
transit routers will only have to look up the RIB. In other words, the router
performing tunnel imposition will use the TIB+RIB, and the others will use
the RIB.
Therefore, in a TIDR-aware Internet, we just need to store the single-homed
site prefixes in the TIB of the edge routers, i.e. ISP routers connecting to
the customers. And we no longer need to store them in the TIB of transit
routers. So, we have just moved prefixes from the global RIB to the global
TIB, thus reducing the size of the global RIB. And, since only edge routers
perform tunnel imposition using the TIB, this table is not necessary for pure
transit routers.
In summary: (1) prefixes announced with a LOCATOR attribute will become pure
endpoint identifier prefixes in terms of inter-domain routing because they
will not be needed for inter-domain routing, and they will be stored in the
TIB; and (2) inter-domain routing will be only based on the locator prefixes
stored in the RIB that TIDR-aware ISPs assigned to the customer prefixes by
means of the LOCATOR attribute.
In short, the TIB is for identifiers and the RIB for locators.
J.J. Adan [Page 6]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
5.3. TIDR Basic Mechanism for a Multi-Homed Site.
Let's consider now a site multi-homed to two TIDR-aware ISPs, ISP1 and ISP2.
Whether this customer uses a provider-independent or provider-assigned prefix
both ISP1 and ISP2 will have to announce the prefix to the rest of the
Internet. But now, since they are TIDR-aware, they will advertise the
customer prefix adding the LOCATOR attribute. ISP1 advertisement will have a
LOCATOR attribute pointing to an ISP1 tunnel interface, and ISP2
advertisement will have a LOCATOR pointing to an ISP2 tunnel interface. Even
more, each LOCATOR will include in a field called REMOTE-PREFERENCE the
preference that the customer wants to assign to each specific advertisement.
How the customer will specify this is not considered in this document, but a
simple method would be to run BGP with a private AS number and send specific
communities that ISP1 and ISP2 would map to specific REMOTE-PREFERENCE
values.
When these two BGP announcements arrive to the routers of the TIDR-aware ISP3
they will install the prefix in the RIB as usual, but they will also install
the prefix in the TIB. Later, when one of these routers receives a packet for
the multi-homed site it will check the TIB before the RIB and it will find
two locators. By comparing the REMOTE-PREFERENCE of the two locators it will
choose the best locator and will encapsulate the packet according to the
information stored in the TIB. Let´s suppose that ISP1 sent the LOCATOR
having the highest REMOTE-PREFERENCE. Then, any ISP in the path from ISP3 to
ISP1 will only have to look up ISP1 prefixes to route the packet towards
ISP1.
As in the single-homed case, in a TIDR-aware Internet we just need to store
the multi-homed site prefixes in the TIB of the edge routers, i.e. ISP
routers connecting to the customers. And we no longer need to store them in
the TIB of transit routers. So, we have just moved prefixes from the global
RIB to the TIB. But in the multi-homed case, TIDR provides an additional
benefit, namely that the customer will be able to specify through which of
its ISPs wants to receive incoming traffic for a specific prefix.
To avoid that only one of the locators arrives to ISP3 because of the effect
of the BGP best path selection algorithm somewhere in the path, we will need
to slightly modify this algorithm so that a TIDR-aware router will include in
the announcement of the best path all the locators that were present in the
updates that it used to determine the best path. Therefore, the BGP best path
selection algorithm will have to be modified in the following sense: if a
router receives two announcements for prefix X, the first announcement having
Locator1 and the second announcement having Locator2, the BGP best path
algorithm will work as usual BUT it will have to add both Locator1 and
Locator2 to the bestpath. These two locators will be carried within the same
LOCATOR attribute, i.e. the LOCATOR attribute permits to announce several
locators at the same time, and having different tunneling techniques (GRE,
IP-in-IP, MPLS LSP, IPSec, ...).
This and the structure of the LOCATOR attribute can be found in [12].
J.J. Adan [Page 7]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
6. Locators of Locators for a Hierarchical Internet: The Onion Model
If by using TIDR locators we can reduce the size of the global inter-domain
routing table, couldn´t we apply the same idea again to assign also locators
to locator prefixes and obtain this way a hierarchy of locators?. Let's
consider a customer network multi-homed to two different regional ISPs (ISP1
and ISP2). ISP1 is, in turn, multi-homed to two transit providers ISP-101 and
ISP-102. ISP1 will generate identifier prefixes for its customers´ prefixes
and will generate locator prefixes to announce its TIDR tunnel destinations.
Let's suppose now that ISP-101 supports hierarchical TIDR (H-TIDR), which
means that ISP-101 will assign new locators to the locator prefix that ISP1
announced to the Internet. The LOCATOR attribute for this locator prefix will
now contain as tunnel destination an IP address of ISP-101, and the LOCATOR
attribute will mark this new locator as a level-2 locator. When this BGP
announcement arrives to a level-2 aware AS, it will not install the locator
prefix in the TIB as with any identifier locator but it will install the
locator prefix in the RIB and it will mark it to know that a level-2 locator
is available for it. This level-2 locator will be installed in a new table
called RIB-2. Later, when ISP-101 receives traffic which is tunneled with the
level-1 locator it will perform either a second tunnel imposition using the
level-2 locator (telescoping) or even it could swap the incoming level-1
tunnel encapsulation with a new level-2 tunnel encapsulation (tunnel
swapping).
If ISP-102 doesn't support level-2 locators it will not add any locator to
the locator prefix it receives from ISP1 nor will it use the locator that
ISP-101 added. It will just install the locator prefix in the RIB and ignore
the level-2 locator included in the LOCATOR attribute received.
In the case of telescoping the second tunnel could even use a different
tunneling technique than the one used for the level-1 locator. Traffic
entering the core level-2 domain could be encapsulated using a tunneling
technique not available for instance in the core level-1 domain. As an
example, there could be a level-2 domain in which all the AS-es exchange MPLS
labels between them in some way, so that traffic coming from the core level-1
domain would be forwarded using MPLS label switching within the core level-2
domain.
In the case of tunnel swapping both incoming and outgoing packets will need
to have the same tunneling encapsulation for the receiver AS to be able to
detunnel the packet, unless it supports more than one type of encapsulation.
In summary, hierarchical TIDR would permit: (1) a new global structure for
the Internet, an onion model for a hierarchical Internet based on levels so
that all providers in level N will have to perform core level-N routing using
the level-N locators stored in the RIB-N table; (2) new possibilities for
inter-domain routing can be devised, either based on tunnel stacking
(telescoping) or tunnel swapping, two mechanisms that will have to be further
investigated; (3) a more consistent classification of providers based on the
levels of core routing they support, different from the current
classification of tier-1, tier-2 and tier-3 providers; and (4) new types of
transit and peering relationships between providers and customers.
J.J. Adan [Page 8]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
7. TIDR Benefits for the Internet
Let's briefly list the benefits that TIDR would provide to the Internet
global routing system [10]:
7.1. Size Reduction of the Global RIB Table
TIDR reduces the size of the global RIB because in a full TIDR-aware Internet
only locator prefixes will be stored in the RIB, which is the table that is
actually used for inter-domain routing.
7.2. Deterministic Customer Traffic Engineering for Incoming Traffic
Traffic engineering for the incoming traffic can be hardly achieved in
practice by using AS-PATH prepending or limiting the scope of outgoing
announcements. As it was shown above, TIDR permit customers to specify in a
deterministic way the path that incoming traffic will take for a specific
prefix by means of the REMOTE-PREFERENCE. Although the sending AS will use
LOCAL-PREFERENCE to decide which outgoing path the tunneled traffic will
take, by selecting the locator with the highest REMOTE-PREFERENCE for
tunneling, we will get the receiving AS to receive that traffic through the
desired incoming path.
7.3. Numerous Forwarding Decisions for a Particular Address Prefix
In TIDR identifier prefixes, which are stored in the TIB, are not used for
routing but only for tunnel imposition. To have numerous forwarding decisions
for an address prefix the only thing we need is to enrich the type of objects
that we can store in the TIB. Let's define for this purpose two new address
families: FECv4 for IPv4 forwarding equivalence classes, and FECv6 for IPv6
forwarding equivalence classes. A FECv4 or FECv6 object will be made up of a
range of IP addresses, a range of transport protocols, and a range of ports
basically. For example, a FECv4 object could be: IP=192.0.2.1, protocol=TCP,
port=80; and a second FECv4 object could be: IP=192.0.2.1, protocol=UDP,
ports=(16384-32767). To get BGP to distribute these new NLRI types we will
need to assign new AFI-SAFI combinations for FECv4 and FECv6 NLRIs
respectively. Finally, by assigning different locators to these two objects
we will get different inter-domain routing for them so that, for instance,
HTTP traffic and VoIP traffic will be received via different providers, or to
apply different QoS policies to them.
7.4. TIDR Stops AS Number Space Depletion.
With TIDR we can devise a situation in which a customer network will be able
to control its routing policy without using a public AS number but a private
AS number. Let's see how.
J.J. Adan [Page 9]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
In the current Internet, the reason why a non-transit multi-homed AS needs to
run BGP using a public AS number is twofold. Firstly to exchange routing
information with its providers so as to learn external routes and to announce
its own prefixes. And secondly to be able to manipulate BGP attributes. The
aim is to carry out a specific inter-domain routing policy so that the multi-
homed site can decide which exit outgoing traffic to a certain target will
take, and to try to influence in the entry point that incoming traffic will
use.
First goal can also be achieved if the customer network runs BGP using a
private AS number with its providers. Once the customer receives the external
routes from its providers, it will be able to set the right LOCAL-PREFERENCE
values to select the path for outgoing traffic. The problem with using a
private AS number comes from the fact that the customer will not be able to
influence on the path that incoming traffic will take. But in TIDR there is a
deterministic way to select this: the customer routers will send specific BGP
communities to its providers which they will use to set concrete values to
the REMOTE-PREFERENCE in the LOCATOR attribute that they will send to the
Internet.
7.5. Improved BGP Convergence
Improved BGP convergence speed because of (1) a smaller global RIB; and
(2) shorter AS_Paths, the latter being a consequence of the previous point.
7.6. Protection of the Inter-domain Routing Infrastructure:
Inter-domain routing in the TIDR paradigm is based on locators that identify
tunnel destinations so that traffic from customer networks is tunneled as it
enters the inter-domain infrastructure. As a consequence, customer traffic
directly sent to a TIDR locator should be discarded so as to protect TIDR
tunnel destinations.
7.7. Easy Separation of Control Traffic and Transit Traffic
Transit traffic will be received as tunneled traffic whereas control traffic
will not be tunneled. This fact permits for instance to apply different rate
limiting techniques to control traffic than to transit traffic. And since we
can assign different locators to different identifier prefixes we will be
able to apply different QoS features to the different sent/received traffics.
7.8. Different Layer-2 Protocol-IDs for Transit and Non-Transit Traffic.
A further security mechanism to differentiate transit from control traffic
could be the utilization of two different layer-2 protocol-IDs, for tunneled
and non-tunneled traffic respectively. Using different layer-2 protocol-IDs
between adjacent routers we can also optimise packet switching because
traffic received with a specific layer-2 protocol-ID will be switched using
its corresponding table: the RIB for tunneled traffic, and the TIB+RIB for
non-tunneled traffic and control traffic.
J.J. Adan [Page 10]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
7.9. Multihoming Resilience
Let's suppose that a customer network is multi-homed to two different
upstream providers ISP1 and ISP2 which announce the customer prefix
192.0.2.0/24 with locators L1 and L2 respectively. Let's also suppose that L1
has a higher REMOTE-PREFERENCE than L2. Therefore, a remote AS will be using
locator L1 to send tunneled traffic to hosts covered by the aforementioned
prefix. If for some reason the customer network looses connectivity with
ISP1, ISP1 will detect the loose of connectivity and, after some specific
time, will send a BGP update to remove locator L1 from the global TIB. In the
meantime, ISP1 may continue to receive tunneled traffic for its customer but,
instead of dropping these packets, ISP1 will first detunnel the traffic and
then perform a new tunnel imposition using the locator L2 that ISP2 announced
to the Internet.
7.10. New Address Families and Tunneling Techniques
The separation between identifiers and locators according to TIDR also
allows us to use different address families for them. We will be able for
example to use IPv6 for identifiers while still keeping IPv4 for locators.
Even more, since in TIDR inter-domain routing is based only on locators we
could use several address families for identifiers simultaneously. This
result in not very surprising because it is well known that some tunneling
techniques (like GRE or MPLS) are multiprotocol.
And we can use several encapsulations at the same time with a tunnel endpoint
(locator). As it was mentioned above, within the LOCATOR structure it is
specified the various types of tunneling techniques that we can use for a
specific tunnel destination, GRE or IP-in-IP for instance, and both could be
used with the same locator.
By decoupling locators addressing from identifiers addressing TIDR leaves
open the possibility of using either new encapsulation techniques as soon as
they are available, or any existing encapsulation technique once it is found
the way to integrate its use within TIDR. Lastly, in a hierarchical multi-
level core Internet different technologies could be deployed so that
technologies which are available at one level are not available or
appropriate for other levels.
7.11. TIDR for IPv4 or IPv6, and Migration to IPv6
What we have presented on TIDR is valid for both IPv4 and IPv6. TIDR permits
easily to transport IPv6 traffic over the current IPv4 infrastructure, and
viceversa. For example, IPv6 identifier prefix 2001:DB8::/32 could be
assigned an IPv4 locator Lv4=2.2.2.2, and the IPv4 identifier prefix
192.0.2.0/24 could be assigned an IPv6 locator Lv6=2000::1. Furthermore,
there is no problem in assigning at the same time IPv4 and IPv6 locators to
the same prefix so that different AS-es use the locator they want: in the
migration to IPv6 there may be AS-es running IPv6 in their backbone whereas
some others continue to use IPv4.
J.J. Adan [Page 11]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
TIDR tunnels provide an easy transport of IPv6 over an IPv4 infrastructure,
and there is no need for renumbering when a site is multihomed to a new
different provider: the change will only affect to the TIB, whereas the RIB
will remain the same thus not affecting at all to the interdomain routing
system.
7.12. Scalability, Stability and Reliability
We have already shown (1) how changes in the customer prefixes will only
affect the TIB, not the RIB, so that the interdomain routing system will not
be affected by customer prefixes instabilities, and (2) how TIDR could be
further employed to establish a hierarchical Internet with different levels
of locators in the core routing domain. The former is based on moving
prefixes from the RIB to the TIB, while the latter moves locators from the
RIB to the RIB-2 and so on. This results in a enormous increase of the
scalability and stability of the global routing system which will based on a
set of tables TIB (=RIB-0), RIB, RIB-2, etc. whose scalability and stability
are independent of each other. And, in the same way that the interdomain
routing system based on level-1 locators will not be affected by identifier
prefixes instabilities, the core level-2 locators will not be affected by
level-1 locators instabilities.
Moreover, if we use anycast locators, i.e. we configure the same tunnel
endpoints in several routers, a higher reliability is endowed for the global
routing system so that transit traffic which is tunneled to a specific
locator will continue to be dispatched in the event of a failure in one of
the routers having that tunnel endpoint defined.
7.13. Mobile IP
TIDR tunneling can be also used for mobile IP. The mobile node (MN) will be
assigned a locator by its home agent (HA) and as soon as it moves to a
foreign network the HA will authorize the foreign agent (FA) to issue a new
locator that will permit the FA to receive tunneled traffic for the MN.
7.14. Faster Inter-domain Routing
Although the use of TIDR tunnels has also its drawbacks, e.g. original
packets are increased in size as they enter the interdomain routing
infrastructure, since the size of the global table will be smaller we will
get firstly a destination IP address lookup much faster, and in a second
place a simplification of unicast reverse path forwarding (RPF) checking.
Some companies have developed special linecards to process big amounts of GRE
tunnels in hardware and routers with hard disk will be able to accommodate
big TIB tables where the interdomain routing policy for identifier prefixes
will be stored.
J.J. Adan [Page 12]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
8. Security Considerations
In addition to protection of the interdomain routing infrastructure and the
separation of transit traffic from control traffic, TIDR can be used to
provide additional security mechanisms for the routing information
distributed by BGP. Remember that in a TIDR-aware Internet interdomain
routing is based only on locators. These are some of the possible mechanisms:
8.1. Identifier prefixes authentication:
Each locator included in the LOCATOR attribute structure can be stored
together with the digital signature generated by the AS that is originating
that specific locator. The originator AS will sign this locator using its
private key, and any other AS receiving this locator will check its validity
using the public key of the originator AS to determine if the locator is
valid or not. The digital signature will authenticate that a specific locator
is a valid locator for a particular identifier prefix. And we will say that
an identifier prefix is authenticated only when it has at least an
authenticated locator.
Let's see this with an example: if a TIDR-aware router receives the
identifier prefix P=192.0.2.0/24 with a LOCATOR attribute containing locator
L=2.2.2.2 and L is originated by AS1, (i.e. AS1 is at the rightmost position
of the AS-PATH attribute of the locator prefix announcement), the router will
have to check using the public key of AS1 that the digital signature of this
locator says that locator L is a valid locator for prefix P. But there is
drawback: how do we know that AS1 has the right to employ locator L?. See
next paragraph.
8.2. Locator prefixes authentication:
Since in a TIDR-aware Internet transit traffic forwarding is based solely on
locators it is extremely important to make sure that an ISP is authorized to
use a specific locator prefix, and that only the authorised ISP can use it.
A possible double-check mechanism to guarantee that locator prefixes are
originated by the right AS could be achieved if there were specific IP
address ranges for locators in every AS. For example, Class E addresses
having 240 as the first octet could be assigned per AS, so that the 16 bits
of the AS number are used for second and third octets of the Class E address
range.
Then, a locator prefix received in an BGP announcement will be valid if its
second and third octets together are equal to the AS number of the AS that
originated the prefix. Furthermore, to make sure that a locator prefix is
really originated by its corresponding AS, this will add a LOCATOR attribute
with a null locator in it, and will sign the locator as in the previous
section. And an AS will not accept a locator prefix announcement received
from a contiguous AS whose AS-PATH shows a different originator than that AS
or that it is not duly signed.
In the case of an IPv6 locator prefix per AS we could even accommodate 4-byte
AS numbers and at the same time provide a great number of locators per AS.
J.J. Adan [Page 13]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
8.3. Finer DoS attacks mitigation:
As we have seen above, with TIDR we can have numerous forwarding
decisions for a particular address prefix so that different applications
can be treated differently. This permits not only to achieve different
interdomain routing results for different applications but also to apply
different QoS to them, or to improve the use of blacklists for DoS attack
mitigation by selecting the specific application which is causing the
problem instead of rejecting all the traffic coming from that IP address.
By using FEC-based blackhole routing instead of prefix-based blackhole
routing the network can protect legitimate traffic like VoIP traffic during
a DoS attack.
9. Futures
The clear separation between identifiers and locators that TIDR introduces
allows us to divide the whole internetwork in three routing domains: (i) Core
Routing Domains which use locators stored in the RIBs; (ii) Peripheral
Routing Domains which use the identifiers; and (iii) Private Routing Domains
which are behind NAT devices. This separation can be again used within each
of these domains.
When BGP-4 was first introduced in the Internet back in 1994 there were less
than 20,000 routes in the global RIB. Today this number is close to reach
200,000, so roughly speaking it has increased ten-fold. During these 12 years
CPUs processing power, computer memory sizes and link capacities have
increased more than that. It is well known that if we want to have better
routing services in the Internet we will have to distribute much more policy
information for both routing and signaling. Although some of this information
could be stored in data repositories (like the DNS, or HTTP or Radius
servers), we have shown how TIDR allows us to store this inter-domain routing
policy information in new tables that BGP will manage.
TIDR defines a new tunnel-based mechanism that permits to smoothly deploy a
new routing paradigm in the Internet and in an incremental way. By using a
new transitive BGP attribute called LOCATOR we can distribute new routing
objects that will provide many benefits to the global routing system in terms
of scalability, stability, resilience, quality of service, traffic
engineering and security.
Maybe in the future we will be able to move some of these functions beyond
the edge of the interdomain infrastructure, storing some of this information
in a big data repository like the DNS so that hosts, after performing name
resolution, will also query the repository for tunnel resolution so as to
perform tunnel imposition by themselves.
10. IANA Considerations
None at this moment.
J.J. Adan [Page 14]
Internet Draft draft-adan-idr-tidr-01.txt November 2006
11. Acknowledgments
12. References
[1] Y. Rekhter and T. Li, S. Hares (Eds) , "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[2] J. Moy, "OSPF Version 2", RFC 2328, April 1998.
[3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.
[4] P. Gross, P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.
[5] I. Castineyra, N. Chiappa, M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[6] G. Huston, "Commentary on Inter-Domain Internet", RFC 3221, December 2001.
[7] IETF 57th, MULTI6 WG Meetings, Vienna (Austria), July 2003.
[8] A. Doria, E. Davies, F. Kastenholz (Eds), "Requirements for Inter-Domain Routing", draft-irtf-routing-reqs-03.txt, July 2004.
[9] T. Hain, "Architectural Implications of NAT", RFC 2993, November 2000.
[10] J.J. Adán Luengo: "Tunneled Inter-domain Routing (TIDR): A Proposal for a New Internet Routing Paradigm", M-007465/2005, September 2005. Unpublished.
[11] J.J. Adán Luengo: "Using Tunneled Inter-Domain Routing (TIDR) with IGPs. A New Routing and Forwarding Architecture for IP Networks". Work in progress.
[12] J.J. Adán Luengo, "TIDR - The LOCATORS Attribute", work in progress.
13. Author's Address
Juan Jose Adan
Gerencia de Informatica de la Seguridad Social (GISS)
c/ Doctor Tolosa Latour s/n
E-28041 Madrid, Spain
Email: juan-jose.adan@giss.seg-social.es
J.J. Adan [Page 15]
Internet Draft draft-adan-idr-tidr-01.txt October 2006
14. Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
15. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
J.J. Adan [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 07:32:29 |