Internet Research Task Force L. Zhang, Ed.
Internet-Draft S. Brim, Ed.
Intended status: Informational March 29, 2008
Expires: September 30, 2008
A Taxonomy for New Routing and Addressing Architecture Designs
draft-rrg-taxonomy-00.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.
This Internet-Draft will expire on September 30, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Routing Research Group is tasked to design a new routing
architecture to meet the challenges of scalability in face of
pervasive multi-homing and inter-domain traffic engineering. A
number of solutions have been proposed. This draft describes a
taxonomy for the design space, and then uses the taxonomy to discuss
and compare the proposed solutions.
Zhang & Brim Expires September 30, 2008 [Page 1]
Internet-Draft Design Taxonomy March 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Solution Directions . . . . . . . . . . . . . . . . . . . 3
3. A functional model . . . . . . . . . . . . . . . . . . . . . . 5
4. Where to Place the Split Between TAA and TIA . . . . . . . . . 6
4.1. Mapping Inside the Host . . . . . . . . . . . . . . . . . 6
4.2. Mapping Point at Network Administrative Boundary . . . . . 7
4.3. Mapping Point at Prefix Aggregation Places . . . . . . . . 8
4.4. Granularity of Node and Common Issues . . . . . . . . . . 8
5. Where to Put in Mapping: Two Basic Choices . . . . . . . . . . 8
6. Design Space of A New Mapping System . . . . . . . . . . . . . 9
6.1. Elements in Mapping Information Distribution/Discovery . . 9
6.2. Mapping Information Distribution: Push versus Pull . . . . 10
6.3. The Mapping Information Distribution Channel . . . . . . . 12
6.4. The Selection Decision among Multiple TAAs . . . . . . . . 12
7. Failure Handling in the Presence of Mapping . . . . . . . . . 13
7.1. Failure Detection and Handling . . . . . . . . . . . . . . 13
7.2. Data Handling During Transient State . . . . . . . . . . . 14
7.3. Failures in Mapping System . . . . . . . . . . . . . . . . 14
8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Zhang & Brim Expires September 30, 2008 [Page 2]
Internet-Draft Design Taxonomy March 2008
1. Introduction
The Routing Research Group is tasked to design a new routing
architecture to meet the challenges of scalability, multi-homing, and
inter-domain traffic engineering. With the imminent exhaustion of
IPv4 address space, the discussion and some initial deployment of
IPv6 has moved from the back burner to the front stage. However, one
of the major issues concerning IPv6 deployment is its potential
impact on scalability of the already stressed routing system.
A number of approaches to scaling the Internet's routing system have
been submitted. We expect this taxonomy to facilitate discussion of
both existing and future proposals, to position each proposal in the
design space, and to help evaluation of various design tradeoffs in
all the proposals.
We identify dimensions of the design space by first identifying
various different approaches from all the proposed solutions. We
then extract out common techniques to sketch out the solution space.
To test whether we get the solution space right, we try to position
the proposals in the design space, and this step helps identify
missing issues. As one can see this approach to taxonomy development
is an iterative process. We expect that this document will continue
to be updated as our understanding of the solution space progresses.
We also hope that it can serve as input to the final decisions by the
Routing Research Group.
This draft is organized into the following parts:
o Identify the solution directions;
o Identify a common functional model;
o Identify the dimensions of the design space;
o Identify the open issues; and
o Identify the tradeoffs in each of the approaches to resolving the
open issues.
2. The Solution Directions
The fundamental goal of a scalable routing system design is to be
able to support continued growth in the number of Internet users and
flexibility in how they use the Internet. One way to control routing
system scalability in face of rapid growth is to enforce
topologically aggregatable IP address assignment. However, Internet
Zhang & Brim Expires September 30, 2008 [Page 3]
Internet-Draft Design Taxonomy March 2008
users desire topology-independent (TI) prefixes to ease changing
providers and to avoid renumbering. The common practices of
multihoming and traffic engineering also lead to prefix de-
aggregation.
Two basic directions have been proposed to solve this routing table
scalability problem: either
o Find ways to handle the large and ever growing routing tables, or
o Route on topologically aggregatable addresses only.
Several publications from academic research fall into the first
category (add ref: ROLF, compact routing). This class of solution
models the Internet as a large, flat network, where any node may
forward traffic for any other nodes. Based on this model, one can
determine the next hop for packet forwarding by applying distributed
hashing algorithms instead of maintaining a routing table. However,
because the operational Internet is an interconnect of multiple
networks under different administrations, routing policy plays an
essential role in making the routing decisions. It is not the case
that any node would be willing to forward traffic for any other
nodes, since traffic across AS boundaries means money changing hands.
Furthermore, individual ASes are also unwilling to expose their
internal topological connectivity to other domains as input to the
hash algorithms.
The proposals that have been made to the IETF/IRTF so far all fall
into the second category, i.e., scaling the routing system by only
providing routing for topologically aggregatable addresses (TAAs).
However, as we mentioned earlier, Internet users desire topology-
independent addresses (TIAs). To both scale the routing system and
satisfy user desires at the same time, there needs to be a point
where use of a TAA ends and use of a TIA starts. One important
design decision is where to engineer this split between TAAs and
TIAs. Furthermore, one must also develop a mapping system to bridge
the two.
There is also another class of approaches aiming at only providing
routing for topologically aggregatable addresses (TAAs): simply
surpress fine granularity prefixes and inject only aggregated
prefixes into the global routing. IVIP and CRIO may be considered as
example designs in this category. These approaches require that the
aggregation points be able to forward packets towards their real
destinations (and tunneling can be one means to serve that purpose).
One may view this class of aproaches as an intermediate point between
today's routing systema and the approach described in the previous
paragraph (separation and mapping between TAA and TIAs), but with the
Zhang & Brim Expires September 30, 2008 [Page 4]
Internet-Draft Design Taxonomy March 2008
split being placed at the points where prefix aggregations occur,
rather than at the user network administrative boundaries.
In the rest of this draft, we focus on developing a framework to
describe the choices of where to engineer the split, together with
the design space for the mapping system.
3. A functional model
To make the discussion more concise, we first define terminology. As
we already mentioned, we call the part of the IP address space that
is topologically aggregatable "TAA Space" and the associated prefixes
TA Prefixes. The (non-aggregatable) topology-independent addresses,
which by design will not be covered in global routing, are called TI
Addresses and TI Prefixes. This terminology is chosen to avoid
confusion.
TI addresses/prefixes have also been called EIDs, in the sense
that they IDentify Edge networks. However in a different context,
such as the work by HIP Research Group and Working Group, EID is
used to refer to End host IDentifiers. In this draft we will use
TIAs and not EIDs.
Here we sketch out an overall picture of a scalable routing system
design. Global routing runs over TA space, the Internet users by and
large operate in TI space, and a mapping function bridges the two.
In addition, there is a mapping information distribution mechanism in
one form or another.
Theoretically speaking, there are multiple places to make the TIA-TAA
split, and multiple ways to provide the mapping information between
the two. In the solutions proposed to RRG so far, the predominant
choices for the split point are either within the endpoint or at a
network administrative boundary. A closely related issue is points
to which mapping information may be distributed. So far the choices
are usually either to inform the host, or to hide the mapping
information from entire networks in TI space. These are the subjects
of the next two sections.
Stepping up a level, this split between TAA and TIA makes a subtle
change to the failure modes of the routing system. In today's
Internet, site multihoming is a common practice. BGP performs flat
routing at the inter-domain level, and dynamic routing picks one of
the working links to reach a multihomed site. In the presence of
mapping, however, the selection of entry point to a multihomed site
is done at the mapping point, be it in the source host or at source
network border. Therefore the system must be able to adjust to
Zhang & Brim Expires September 30, 2008 [Page 5]
Internet-Draft Design Taxonomy March 2008
failures (and recoveries) of the current mapping selection. We
discuss the design choices for failure handling in Section X
[reference].
The addition of a mapping system also introduces at least one new
target for malicious attacks. In today's Internet, one can hijack
data traffic by compromising the routing system. With the new
design, one might be able to hijack traffic by injecting false
information into the mapping system. One could also attempt to
damage the mapping system by a DoS attack on one of its elements. We
discuss security considerations in Section XX [reference].
4. Where to Place the Split Between TAA and TIA
There is a close coupling between how the mapping is done and where
the mapping is done. Since end hosts perform DNS resolution before
sending packets in general, a DNS-based mapping solution allows one
to set the mapping point anywhere from inside the end host to all the
way to the attachment point of an edge network. Proposals that use a
new mapping system tend to place the mapping point at network
administrative boundaries.
4.1. Mapping Inside the Host
SHIM6 is a design that uses DNS to provide mapping information. It
places the boundary between TA and TI inside an endpoint stack, at
the border between IP and transport layer. A multihomed site will
have multiple prefixes assigned to it by its providers, and SHIM6
assigns multiple IP addressees to each internal node (add SHIM6
refs).
SHIM6 lets individual hosts select one destination prefix among
multiple choices, which potentially influences the path taken by the
packets. This design aspect raised concerns from network operators
and ISPs regarding their ability to perform traffic engineering, an
important part of routing policy support.
Variations of the basic SHIM6 design have been developed to address
SHIM6's limitations. One of them is SHIM6 proxy, which addresses the
concern of having to change all the hosts. Another variation of
SHIM6 is Six/One, which addresses the traffic engineering concern.
In Six/One, end hosts perform SHIM6, but routers at the network edge
may rewrite the IP addresses to meet TE goals. Although this hybrid
solution can be used to support TE, it also introduces complexity due
to the need for coordination between end hosts and the address
rewriting routers.
Zhang & Brim Expires September 30, 2008 [Page 6]
Internet-Draft Design Taxonomy March 2008
Another design that puts the split inside the host is a proposal from
Mark Handley [reference]. Instead of hiding the multiple TAAs below
the transport layer as SHIM6 does, the Handley proposal exposes the
multiple TAAs directly to the transport layer.
4.2. Mapping Point at Network Administrative Boundary
GSE is another design that uses DNS to provide mapping information.
In some sense one may view GSE as putting the split between TAA and
TIA at the border between an edge network and its provider, although
GSE does not really provide edge networks with globally unique
topology-independent addresses. GSE cuts the IP address into three
parts, the upper part being a globally routeable prefix (called
"routing goop", or RG), the middle part representing network topology
inside a site (called the site topology partition, or STP), and the
lower part being a globally unique identifier for the host (End
System Designator, ESD). The combination of the last two parts also
makes a site-local address.
+-------------------------+
| RG | STP| ESD |
+--------+----+-----------+
GSE shelters all the internal nodes from knowing any of the prefixes
assigned by their transit providers. Inside an edge network, all
communications use site local addresses. Only packets going outside
the network will carry a full destination address. A source host
obtains the full destination address (including both the upper and
lower portions) from a DNS lookup. When the packet exits the source
network, its border router replaces the site-local prefix of the
source address with an appropriate transit prefix. When the packet
enters the destination network, the border router will keep the
source address intact so that the receiving host can send reply
packets to the source, but will replace the upper portion of the
destination address (the external prefix) with a site-local prefix,
so that nodes inside an edge network never see their own external
prefixes. This eases the change of providers since sites only need
to obtain new RG and update the DNS. However for a site with
multiple topologically diversified locations, the network management
can become difficult if each site uses the same default site-local
prefixes.
Another way to set the TA-TI split at the border between networks was
first described in Map-n-Encap (RFC1955). It assumes that border
routers can obtain or access a mapping database that maps non-
aggregatable prefixes to their routed TAA attachment points. The
border router can then use IP encapsulation to tunnel packets to the
destination border router. This approach has the advantages of (1)
Zhang & Brim Expires September 30, 2008 [Page 7]
Internet-Draft Design Taxonomy March 2008
making no changes to the existing user networks and their operational
practices, and (2) eliminating all renumbering induced by changing
providers. Several of the newly proposed solutions follow this
approach, including APT, IVIP, and LISP.
4.3. Mapping Point at Prefix Aggregation Places
[Editor's note: this section is yet to be finished.]
As we discussed in Section 2, one may consider an incremental step
towards reducing the BGP routing table by simply aggregating fine
granularity prefixes into shorter prefixes and only injecting the
aggregated prefixes to the routing system. This class of solutions
fall into the same direction as the TAA-TIA split, as the longer
prefixes being aggregated are essentially equivalent to TI prefixes.
The challengings in pursuing this direction lie at where to engineer
the aggregation points, which parties may perform the function, as
well as how to evaluate the gains and the cost.
4.4. Granularity of Node and Common Issues
One may view the different choices of where to place mapping points
as different points in the same spectrum, based on the granularity of
the "node" the TAA reaches. In the first approach, the TAA reaches
end hosts directly; in the second approach, the TAA reaches an entry
point to a network containing the end host, and the actual end host
is reached by using the entry point's TIA.
Although the above two approaches look rather different, they share a
set of common issues that arise from site multihoming: choosing a TAA
to reach the intended destination host (mapping), detecting failures
of the TAA currently in use, and recovering from the failure while
minimizing packet losses during failure recovery. Furthermore, one
must also secure the mapping distribution channel. These issues will
be discussed in Section XYZ (reference).
5. Where to Put in Mapping: Two Basic Choices
One way to get the mapping information is to utilize an existing
look-up system, and DNS makes a readily available candidate. In
today's host implementations, almost all the applications perform a
DNS lookup to get the IP address of their intended destinations.
Thus one can simply piggyback the TAA to which the destination
network is attached in a DNS reply.
Putting the mapping information into DNS is conceptually a very
simple solution, and has the advantage of avoiding any new design.
Zhang & Brim Expires September 30, 2008 [Page 8]
Internet-Draft Design Taxonomy March 2008
Furthermore, letting the end host receiving this information may
provide flexibility of engineering the TAA-TIA split at various
different places, as we will see in the next section.
However this simple solution also raises a few concerns. The
foremost is the requirement of making changes to all the end hosts.
A more subtle issue is the circular dependency between DNS and data
delivery: DNS assumes the availability of IP packet delivery, but in
the new design data delivery will require getting the mapping
information first.
A second way of providing the mapping function is to develop a new
mapping system. To avoid having to make changes to all end hosts,
all the proposed new mapping system designs put it outside the edge
networks, so that within an edge network everything can run as today
with no changes. However the proposed solutions differ in a number
of ways., which we will elaborate in later sections.
6. Design Space of A New Mapping System
At a high level, different designs can be sorted along the following
dimensions:
o Push versus pull;
o A hierarchical system versus a flat distribution system; and
o A dedicated distribution system versus laying it on top of the
existing routing system.
Different combinations of the above three dimensions cover all the
proposals currently on the table, although it is not necessarily an
exhaustive list of all the significant dimensions in the design
space. The list will be updated as new important dimensions are
identified.
6.1. Elements in Mapping Information Distribution/Discovery
Mapping information for an end host in a network must be made
available to all sources which want to send packets to that end host.
Generally speaking, one can identify the following five logical
elements in a mapping information distribution design.
1. The mapping information for a network (e.g. a mapping for a TI
prefix to one or more TAAs) is owned by the network's
administrator, the owner.
Zhang & Brim Expires September 30, 2008 [Page 9]
Internet-Draft Design Taxonomy March 2008
2. There may exist an initial distributor which is distinct from the
owner/originator of the information, so that owners do not have
to be directly involved in mapping distribution system
operations. In some cases the owner also acts as the initial
distributor.
3. The distribution channel.
4. In cases the distribution channel uses a push model, we need an
entity to hold the information for future use. This "holder" may
be the user of the mapping information itself, or a node near the
users of the information that can supply the information to them
when they need it.
5. The user of the mapping information (when it is a different
entity from the holder).
Origination of mapping information (from owner to initial
distributor) can be manual or automated by a protocol exchange.
Consideration: how to authenticate each originator of the mapping
information.
One important consideration in designing a mapping information
distribution system is how well it can scale with the number of
entries. Mapping information size is likely to grow to at least a
few orders of magnitude larger than the current BGP table size, e.g.
hundreds of millions. Such a big size imposes limitations on the
frequency of dynamic changes to mapping entries.
Prompt and reliable mapping information distribution depends on how
well the above entities -- the owner, initial distributor,
distribution channel, the holder and the user -- of the mapping
information can coordinate with each other. Because the Internet is
a collection of networks that belong to multiple parties with
potentially conflicting interests, it is important to minimize the
dependency between different parties in obtaining mapping
information.
6.2. Mapping Information Distribution: Push versus Pull
Protocol-based distribution of mapping information can be push-based,
pull-based, or a combination of the two. Generally speaking, one may
sort different types of distribution channels based on how far each
pushes the mapping information from the originator to the user.
o The initial distributor may push mapping information to all user
nodes (perhaps through intermediate steps). An example of this
Zhang & Brim Expires September 30, 2008 [Page 10]
Internet-Draft Design Taxonomy March 2008
approach is NERD [reference], where the originator injects mapping
information into one or more centralized databases, then entire
databases are pulled by user nodes to local storage.
o At the other end of design spectrum is a pure pull/look up model:
the initial distributor holds the mapping information, and the
user nodes or holders pull information when needed.
o A design can also take a middle ground, by pushing mapping
information to some intermediate holder nodes, which can then be
polled by the user nodes as needed. An example design of this
approach is APT, where the distribution channel pushes mapping
information to Default Mappers (holders) in each AS, and ITRs
(users) request mapping entries from the default mappers as
needed.
Designs based on pushing must include mechanisms to push the mapping
information out. The complexity of this step depends on where the
holders are. A centralized holder design is illustrated by NERD,
where individual originators simply submit their mapping information
to a central database (the holder) using an existing application
protocol. A distributed holder design is illustrated by APT, where a
flooding mechanism is needed for the mapping information to be pushed
from all originators to default mappers in all ASes.
An important aspect of designs based on pulling is an indexing
mechanism. Because the input to mapping are multiple millions of
unstructured TI prefixes, pull-based systems require a scalable
indexing system to direct queries to the distributors with the
requested mapping information. Again multiple design choices exist.
DHTs (dynamic hash tables) use algorithmic hashing to make the lookup
of a large number of unordered items scalable. Another design point
is illustrated by CONS, where the indexing system is a hierarchy of
TIA prefixes (in a way similar to DNS hierarchy, by replacing DNS
domains with prefix aggregations). Yet another design approach is
ALT which pushes paths to specific mapping information to users.
Just as there can be holders for pushed mapping information, there
can also be holders of another kind of index information.
Whenever a piece of mapping information is pulled to the user node,
that piece can/may be cached at the user node, and also at some
intermediate nodes along the pulling path if any such nodes exist.
Examples of utilizing caching include the LISP and APT designs where
the mapping information is pulled by ITRs and cached there. In
addition, CONS, one of LISP's mapping designs, uses a hierarchical
structure to retrieve mapping information, thus those nodes along the
pulling paths can also cache the information.
Zhang & Brim Expires September 30, 2008 [Page 11]
Internet-Draft Design Taxonomy March 2008
6.3. The Mapping Information Distribution Channel
A related, but separate, question is what to use for the distribution
channel. There are three distinguishable channel types.
The first one is to add mapping information to the DNS. In this
case, the initial distributors are the authoritative DNS servers, the
users are source hosts, and the distribution channel is pure pulling
(DNS queries), thus there is no holder.
Solutions that push the TAAs all the way to endpoint nodes, such as
SHIM6 and the Handley proposal, require no changes to the DNS RR
content. Among solutions that keep TAAs out of edge networks, GSE
does not need any major change to DNS because the TAA is the IP
address, while tunneling-based solutions will need to retrieve from
DNS the TAA for the destination TIA. An example of this approach is
an early version of eFIT (reference), where a DNS reply would carry
an ETR RR, the source host puts that value in an IP header option
field, and the ITR could use it to encapsulate the packet to the ETR.
Another approach is to establish a new and distinct mapping
distribution system. This new system can be designed from scratch,
or it can borrow from the existing DNS framework to various degrees,
ranging from using a similar hierarchical structure to directly using
DNS query protocols, even though the system is solely used for
mapping information retrieval.
A third approach is to distribute mapping information through the
routing system. This approach differs from the second one in that it
uses routers, as opposed to separate and dedicated entities, to
distribute mapping information.
6.4. The Selection Decision among Multiple TAAs
Another dimension is how a choice is made among multiple TAAs for a
destination. The answer to this question depends in part on the
distribution channel. Generally speaking, we can identify the
following three cases.
1. If the distribution is pure push, then the user node receives the
full mapping information, thus it can make its own decision based
on preferences the originator has injected into the mapping
system. An example design using this approach is NERD.
2. If the distribution is pure pull, then the originator (the owner
of the mapping information) can make the decision on whether to
provide puller-dependent or puller-independent replies to mapping
queries. Puller-independent replies can be cached at various
Zhang & Brim Expires September 30, 2008 [Page 12]
Internet-Draft Design Taxonomy March 2008
nodes along the pulling path, which can help reduce system
overhead as well as speed up future pulling replies. An example
design using this approach is CONS. On the other hand, if
mapping replies are tailored specifically for each request in
order to support sender-specific policies, they cannot be cached
in the polling paths. An example design using this approach is
ALT.
3. If the distribution channel uses a combination of push and pull,
then the mapping information holder can decide which TAAs shall
be given to which mapping point. An example of this approach is
APT, where mapping information is pushed to all default mappers
(holders) in each AS, which can then behave like policy
controllers for the AS to dictate which ITRs use which TAAs.
7. Failure Handling in the Presence of Mapping
As explained earlier, a mapping point must be able to adjust the
mapping selection upon detection of failures. Failures do not
invalidate mapping information, but only cause the selection of
mapping entries to change, perhaps temporarily until the failure is
recovered.
7.1. Failure Detection and Handling
Failure detection is directly coupled with the placement of the
mapping points. If the mapping point is inside the host, failure of
the current mapping selection can be detected by the endpoints, by
transport or upper layer protocols. Since the proposed host-based
solutions use DNS to pull mapping information, each host can also
make a decision on which alternative mapping value to choose.
One failure can affect many endpoints. Putting mapping point
inside hosts requires that all hosts detect and handle the
failures independently.
Those solutions that put the mapping point at a network
administrative boundary need new mechanisms for detecting failure at
mapping points. Possibilities include
o data-triggered detection, i.e. packets reach a dead end
o routing-triggered detection, i.e. one learns from a routing
protocol (IGP or BGP) that some TAA or TA prefix becomes
unreachable.
Once a failure is detected, one needs to notify affected parties to
Zhang & Brim Expires September 30, 2008 [Page 13]
Internet-Draft Design Taxonomy March 2008
avoid the failure. Design possibilities fall into a multi-
dimensional space: whether sending separate control packets or
piggybacking the notification on data packets; whether directly
notifying involved mapping points (those who are sending to the
failed demapping point), or notifying holders; and whether notifying
everyone, or only the affected parties at the time of the failure
(i.e. those who are actively sending).
When a failure is remedied, the mapping system may indicate so, so
that mapping points may revert to using the mappings they were before
the failure. Another consideration is which party holds the
temporary failure information, and how it can be removed when
recovery is complete.
7.2. Data Handling During Transient State
When a failure occurs, there can be in-flight packets heading towards
a failed demapping point. Another design consideration is how to
handle these in-flight packets.
7.3. Failures in Mapping System
A mapping system design must consider various possible failures in
the mapping system itself, and understand how robust the system can
be in face of the failures.
8. Security
This section is unfinished. Here are some considerations.
o What is the trust model/relationship between neighbor nodes in the
mapping distribution chain?
o How to ensure and verify mapping information authenticity?
o How possible is it that data packets will be mis-delivered.
o How possible is it that control (mapping, signaling) packets will
be mis-delivered
o Vulnerability to a flood of data packets.
o Vulnerability to a flood of control packets.
o Vulnerability of control to MITM attacks.
Zhang & Brim Expires September 30, 2008 [Page 14]
Internet-Draft Design Taxonomy March 2008
o Is it possible to physically separate control traffic from data
traffic?
o Vulnerability to scanning attacks filling cache.
9. References
9.1. Normative References
[ENDPOINTS]
"Endpoints and Endpoint Names: A Proposed Enhancement to
the Internet Architecture [unpublished]", June 1995,
<http://ana.lcs.mit.edu/~jnc/tech/endpoints.txt>.
9.2. Informative References
[PODC06] Konjevod, G., Andrea, R., and D. Xia, "Optimal-Stretch
Name-Independent Compact Routing in Doubling Metrics",
<http://www.public.asu.edu/~dxia2/papers/ PODC06.pdf>.
Authors' Addresses
Lixia Zhang (editor)
Email: lixia@cs.ucla.edu
Scott Brim (editor)
Email: swb@employees.org
Zhang & Brim Expires September 30, 2008 [Page 15]
Internet-Draft Design Taxonomy March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zhang & Brim Expires September 30, 2008 [Page 16]