Network Working Group R. White
Internet-Draft B. Akyol
Expires: August 9, 2006 Cisco Systems
N. Feamster
February 5, 2006
Considerations in Validating the Path in BGP
draft-white-pathconsiderations-06
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 August 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
A good deal of thought has gone into, and is currently being given
to, validating the path to a destination advertised by BGP. The
purpose of this work is to explain the issues in validating a BGP AS
Path, in the expectation that it will help in the evaluation of
schemes seeking to improve path validation. The first section
defines at least some of the types of questions a BGP speaker
receiving an update from a peer not in the local autonomous system
White, et al. Expires August 9, 2006 [Page 1]
Internet-Draft Path Validation Considerations February 2006
(AS) could ask about the information within the routing update. The
sections following examine the answers to these questions in
consideration of specific deployments of BGP.
The examples given in this draft are intended to distill deployments
down to their most critical components, making the examples easier to
understand and consider. In many situations, the specific path taken
in the example may not be relevant, but that does not nullify the
principles considered in each example. It has been suggested that
these examples are "red herrings," because they do not illustrate
actual problems with specific policies. On the contrary, these
examples are powerful because they are simple. Any topology in which
one of these example topologies is a subtopology will exhibit the
characteristics explained in this draft. Rather than focusing on a
specific topology, then dismissing that single topology as a "corner
case," this draft shows the basic issues with assertions about the AS
Path attribute within BGP. These generalized issues can then be
applied to more specific cases.
1. Background
With the heightened interest in network security, the security of the
information carried within routing systems running BGP, as describued
in [RFC1771], is being looked at with great interest. While there
are techniques available for securing the relationship between two
devices exchanging routing protocol information, such as [BGP-MD5],
these techniques do not ensure various aspects of the information
carried within routing protocols are valid or authorized.
The following small internetwork is used to examine the concepts of
validity and authorization within this draft, providing us with
definitions used through the remainder of the draft.
10.1.1.0/24--(AS65000)---(AS65001)--(AS65002)
Assume a BGP speaker in AS65002 has received an advertisement for
10.1.1.0/24 from a BGP speaker in AS65001, with an AS Path of {65000,
65001}.
1.1. Is the Originating AS Authorized to Advertise Reachability to the
Destination?
The most obvious question the receiving BGP speaker can ask about
this advertisement is whether or not the originating AS, in this case
AS65000, is authorized to advertise the prefix contained within the
advertisement, in this case 10.1.1.0/24. Whether or not a BGP
speaker receiving a route to 10.1.1.0/24 originating in AS65000 can
White, et al. Expires August 9, 2006 [Page 2]
Internet-Draft Path Validation Considerations February 2006
verify that AS65000 is, indeed, authorized to advertise 10.1.1.0/24
is outside the scope of this draft.
1.2. Is the Path Contained in the Advertised Routing Information Valid?
If a BGP speaker receives an advertisement from a peer outside the
local autonomous system (AS), the peer sending the update has a path
to the destination prefix in the update. Specifically, are the
autonomous systems within the internetwork connected in such a way
that the receiver, following the AS Path listed in the BGP update
itself, can reach the originating AS listed in the received AS Path?
Within this draft, this is called path validation.
Path validation, in the context of this small internetwork, asserts
that when a BGP speaker in AS65002 receives an advertisement from a
BGP speaker in AS65001 with the AS Path {65000, 65001}, the speaker
can assume that AS65001 is attached to the local AS, and that AS65001
is also attached to AS65000.
1.3. Is the Advertising Speaker Authorized to Transit Traffic Along the
Advertised AS Path?
If a BGP speaker receives an advertisement for a prefix from a
speaker not in the local AS or the originating AS, is the receiving
BGP speaker authorized to transmit traffic along the AS Path
advertised in the update towards that destination? Within this
draft, this is called path authorization.
Path authorization, in this small internetwork, asserts that if a BGP
speaker in AS65002 receives a routing advertisement with the prefix
10.1.1.0/24 and the AS Path {65000, 65001}, all speakers within
AS65000 are authorized to forward traffic through the AS Path {65000,
65001} towards 10.1.1.0/24.
1.4. Is the Advertised Address Space Atomic?
If a BGP speaker receives an advertisement for a prefix from a
speaker not in the local AS, can the receiver infer path validation
or path authorization for every possible subset of the advertised
prefix? This is a subtle version of the two questions asked in
Section Section 1.2 and 1.3; since a prefix is actually a collection
of destinations, rather than a single destination, is any policy,
authorization, or validation available on the advertised prefix also
applicable to every subset of reachable destinations within the
prefix? In this draft, this is called atomic validation.
In this example, specifically, if a router in AS65002 receives a
route from a BGP speaker in AS65001 advertising reachability to
White, et al. Expires August 9, 2006 [Page 3]
Internet-Draft Path Validation Considerations February 2006
10.1.1.0/24, and it can either validate or authorize the AS Path
contained in the advertisement, can it then imply AS Path validation
or authorization for 10.1.1.0/25 and 10.1.1.128/25?
1.5. Will Traffic Forwarded to an Advertising Speaker Follow the
Described AS Path?
If a BGP speaker receives an advertisement from a peer not in the
local AS, will traffic forwarded to the peer advertising the update
will follow the path described in the AS Path? In this draft, this
is called forwarding consistency.
In terms of the small example internetwork, if a BGP speaker in
AS65002 receives an advertisement from a peer in AS65001 for the
destination 10.1.1.0/24, with an AS Path {65000, 65001}, will traffic
forwarded to the BGP speaker in AS65001 actually be forwarded through
routers within AS65001, then AS65000, to reach their destination?
1.6. Is a Withdrawing Speaker Authorized to Withdraw the Routing
Information?
If an advertisement is withdrawn, the withdrawing BGP peer was
originally advertised the prefix (or was authorized to advertise the
prefix). This assertion is out of the scope of this draft.
2. Analysis
To begin, we review some of the concepts of routing, since we need to
keep these concepts fixed firmly in place while we examine these
questions. After this, four examples will be undertaken with BGP to
show why the second of two questions cannot be answered in a path
vector routing system. Finally, a short section on transitive
authorization in a path vector protocol is provided, which considers
the reasons behind the results we find in the examples.
2.1. A Short Analysis of Routing
Routing protocols are designed, in short, to discover a set of loop
free paths to each reachable destination within a network (or
internetwork). The loop free path chosen to reach a specific
destination may not be the shortest path, and it may not always be
the "best" path (depending on the definition of "best"), but it
should always be a loop free path, or routing, and the routing
protocol, has failed.
This sheds some light on the purpose of the path included in an path
vector protocol's routing update: the path is there to prove the path
White, et al. Expires August 9, 2006 [Page 4]
Internet-Draft Path Validation Considerations February 2006
is loop free, rather than to provide any other information. While
Dijkstra's SPF and the Diffusing Update Algorithm (DUAL) both base
their loop free path calculations on the cost of a path, path vector
protocols, such as BGP, prove a path is loop free by carrying a list
of nodes the advertisement itself has traversed. BGP specifically
uses an AS Path based mechanism to prove loop freeness for any given
update so each AS along the path may implement local policy without
risking a loop in the routing system caused by competing metrics.
We need to keep this principle in mind when considering the use of
the path carried in a path vector protocol, and its use by a
receiving BGP speaker for setting policy or gauging the route's
security level.
2.2. First Example: Manual Intervention in the Path Choice
In the small network:
+---(AS65002)---+
(AS65000)--(AS65001) (AS65004)--10.1.1.0/24
+---(AS65003)---+
A BGP speaker in AS65000 may receive an advertisement from a peer
that 10.1.1.0/24 is reachable along the path {65004, 65002, 65001}.
Based on this information, the BGP speaker may forward packets its
peer in AS65002, expecting them to take the path described. However,
within AS65001, the network administrator may have configured a
static route making the next hop to 10.1.1.0/24 the edge router with
AS65003.
It's useful to note that while [RFC1771] states: "....we assume that
a BGP speaker advertises to its peers only those routes that it
itself uses...," the definition of the term "use" is rather loose in
all known widely deployed BGP implementations. Rather than meaning:
"A BGP speaker will only advertise destinations the BGP process on
the speaker has installed in the routing table," it generally means:
"A BGP speaker will only advertise destinations that the local
routing table has a matching route installed for, no matter what
process on the local router installed the route." A naive reaction
may be to simply change the BGP specifications, and all existing
implementations so a BGP speaker will only advertise a route to a
peer if the BGP process on the router actually installed the route in
the local routing table. This, however, ignores the complex
interactions between interior and exterior gateway protocols, which
most often run on the same device, and the complexities of route
origination.
Although this is an "extreme" example, since we can hardly claim the
White, et al. Expires August 9, 2006 [Page 5]
Internet-Draft Path Validation Considerations February 2006
information within the routing protocol is actually insufficient, we
will still find it instructive to examine this example in light of
the questions outlined in Section 1:
o Is the AS Path valid? The AS Path the receiving BGP speaker in
AS65000 receives from its peer in AS65001, {65004, 65002, 65001),
does exist, and is valid.
o Is the AS Path authorized? Since we have no knowledge of any
autonomous system level policy within this network, we have no way
of answering this question. However, considering that the path
advertised by AS65002 towards AS65001 is different than the path
trafic will actually take, it's difficult to see how path
authorization could be accomplished in this situation. Even if
theBGP speaker in AS65000 could verify AS65001 is authorized to
transit AS65002 to reach 10.1.1.0/24, this implies nothing about
the authorization to transit traffic through the path traffic will
actually take, which is through AS65003.
o Is the AS Path consistent with the forwarding path (does
forwarding consistency exist)? No; the advertised AS Path is
{65004, 65002, 65001}, while the actual path is {65004, 65003,
65001}.
o Is the routing information atomic? In this example, the only
route advertised is 10.1.1.0/24, and the advertisement of this
route is consistent throughout the entire internetwork, so the
routing information is atomic.
From this example, we can see forwarding consistency is not possible
to validate in a deployed network; just because a BGP speaker
advertises a specific path to reach a given destination, there is no
reason to assume that traffic forwarded to the speaker will actually
follow the path advertised. In fact, we can reason this from the
nature of packet forwarding networks; each router along a path makes
a completely separate decision about where to forward received
traffic. Any router along the path could actually change the path
due to network conditions without notifying, in any way, upstream
routers, so at any given time, an upstream router may be forwarding
traffic along a path that no longer exists, or is no longer optimal,
and downstream routers could be correcting the forwarding decision by
placing the traffic on another available path unknown to the upstream
router.
As a corollary, we can see that authorizing transit through a
specific AS Path is not possible, either. If the source of a
specific flow cannot know what path the traffic within that flow will
take to reach the destination, then there is no meaningful sense in
which downstream routers can authorize the source to use available
paths for transiting traffic.
White, et al. Expires August 9, 2006 [Page 6]
Internet-Draft Path Validation Considerations February 2006
2.3. Second Example: An Unintended Reachable Destination
In this internetwork, we assume a single policy: The system
administrator of AS65000 would not like the destination 10.1.1.0/24
to be reachable from any autonomous system beyond AS65001. In other
words, 10.1.1.0/24 should be reachable within AS65001, but not to
autonomous systems connected to AS65001, such as AS65002.
10.1.1.0/24---(AS65000)---(AS65001)---(AS65002)
The system administrator can implement this policy by casuing BGP
speakers within AS65000 to advertise 10.1.1.0/24 to peers within
AS65001 with a signal that the BGP speakers in AS65001 should not
readvertise reachability this routing information. For example, BGP
speakers in AS65000 could advertise the route to 10.1.1.0/24 with the
NO_ADVERTISE community attached, as described in [RFC1771]. If the
BGP speakers in AS65001 are configured to correctly respond to this
community (and we assume they are for the purposes of this draft),
they should accept this advertisement, but not readvertise
reachability to 10.1.1.0/24 into AS65002.
However, unknown to the system administrator of AS65000, AS65001 is
actually advertising a default route AS65002 with an AS Path of
{65001}, and not a full routing table. If some host within AS65002,
then, originates a packet destined to 10.1.1.1, what will happen?
The packet will be routed according to the default route from AS65002
into AS65001. Routers within AS65001 it will forward the packet
along the 10.1.1.0/24 route, eventually forwarding the traffic into
AS65000.
o Is the AS Path valid? This is a difficult question to answer,
since there are actually two different advertisements in the
example. From the perspective of the BGP speaker in AS65002
receiving a default route in an advertisement from a peer in
AS65001, the AS Path to the default route is valid. However,
there is no route to 10.1.1.0/24 for the BGP speaker in AS65002 to
examine for validity, so the question appears to be out of scope
for this example.
o Is the AS Path authorized? In this case, is AS65002 authorized to
transit all destinations falling within the default route through
AS65001? Since AS65002 cannot know every possible subnet of the
default route (or longer prefix destinations within the default
route), BGP speakers within AS65002 cannot know the policy related
to each every possible destination contained within the default
route. AS Path authorization cannot be proven when information is
removed from the routing system, as the route to 10.1.1.0/24 is
removed from the advertisements transmitted to BGP speakers within
AS65002.
White, et al. Expires August 9, 2006 [Page 7]
Internet-Draft Path Validation Considerations February 2006
o Is the AS Path consistent with the forwarding path (is there
forwarding consistency)? From the perspective of a BGP speaker in
AS65002, traffic forwarded to AS65001 towards a destination within
10.1.1.0/24 is actually going to terminate within AS65002, since
that is the entire AS Path for the default route. However, this
traffic actually transits AS65001 towards AS65000. Therefore,
forwarding consistency does not exist in this example.
o Is the routing information atomic? The policies impacting
10.1.1.0/24, which is contained within, or is a part of, the
default route AS65001 is advertising to AS65002 are different than
at least some of the other destinations contained within this same
route. Therefore, the routing information is not atomic; the
policies for subsets within a route are different than the
policies for the route itself.
The basic problem here is that the system administrator assumes that
if autonomous systems beyond AS65001 do not receive routing
information for a specific destination, they will not be able to
reach that destination. While we can question the system
administrator's assumption (and security sense), this example does
point out fundamental issues in internetworks running BGP when viewed
from a system level:
o Information is routinely removed from routing systems through
aggregation, filtering, and other mechanisms. Once the
information is removed, there is no way to determine if the
removal was intentional, unintentional, or malicious. This has an
impact on the ability to assert path authorization, as we see in
the system administrator being unable to prevent AS65002 from
transiting traffic through AS65001 to 10.1.1.0/24.
o Aggregation removes atomic policy from the routing system. By
definition, an aggregate route contains any number of longer
prefix destinations, each of which may have their own
authorization or validation, in terms of their individual AS
Paths. This implies that AS Path authorization is impossible in
an environment where aggregation of routing information is taking
place.
o The concept of prefix, or rather destination, ownership, is not
clearly defined in routing systems. Any given party controlling
10.1.0.0/16 may authorize any other party to advertise
10.1.1.0/24, which is a part of (or is contained within)
10.1.0.0/16. This is called the suballocation of a block.
However, suballocation does not prevent the authorizing party from
continuing to advertise reachability to the suballocated address
space, because the authorizing party may still advertise an
aggregate containing the suballocated address space. Again,
advertised address space may not be atomic.
White, et al. Expires August 9, 2006 [Page 8]
Internet-Draft Path Validation Considerations February 2006
2.4. Third Example: Following a Specific Path
This example is slightly more complex than the last two. Given the
following small network, assume that A and D have a policy of not
transiting B to reach destinations within 10.1.1.0/25.
10.1.1.0/25--A---B---C---D
| | |
E-------F---G
Assume the following:
o A advertises 10.1.1.0/25 to B and E.
o B advertises 10.1.1.0/24 to C.
o E advertises the aggregate 10.1.1.0/24 to F.
o F advertises the aggregate 10.1.1.0/24 to C and to G.
o C advertises the aggregate 10.1.1.0/24 to D, but not the more
specific 10.1.1.0/25.
o G advertises the aggregate 10.1.1.0/24 to D.
D now has two paths to 10.1.1.0/24, both of which appear to transit
the path {F, E, A} to reach destinations within 10.1.1.0/25. What
path will traffic forwarded to C destined to hosts within 10.1.1.0/25
actually follow, however? The best path to 10.1.1.0/25 from C is
actually through B, so traffic forwarded from D to C and destined to
a host within 10.1.1.0/25 will actually transit B, which is outside
the original policy D stipulated.
o Is the AS Path valid? Both {G, F, E, A} and {C, F, E, A} are
valid AS Paths, so both AS Paths in this example are valid.
o Is the AS Path authorized? In the sense that C and G are both
authorized to transit F to reach destinations within 10.1.1.0/24,
the AS Path is authorized in this example. However, traffic
forwarded to C, and destined to 10.1.1.0/25, does not transit F,
so authorization to transit F is meaningless in this context.
Therefore, in terms of authorization to transit the actual paths
traffic will be forwarded along, the AS Path is not authorized.
o Is the AS Path consistent with the forwarding path (is there
forwarding consistency)? While C is advertising the AS Path {C,
F, E, A} to D to reach destinations within 10.1.1.0/24, it is
actually forwarding along a different path to some destinations
within this advertisement. Forwarding consistency does not exist
within this internetwork.
o Is the routing information atomic? The advertisement for
10.1.1.0/24 implicitely contains reachability information for
10.1.1.0/25. Since A and D's policies towards destinations within
10.1.1.0/25 are different than the remainder of the address space
within 10.1.1.0/24, the routing information is not atomic.
White, et al. Expires August 9, 2006 [Page 9]
Internet-Draft Path Validation Considerations February 2006
2.5. Fourth Example: Interior and Exterior Paths Mismatch
This is the most complex example we will cover in this draft. It can
be argued that the configuration described in this example is a
misconfiguration, but we have chosen this example for its simplicity,
as an illustration of the complexity of the interaction between
interior and exterior gateway protocols within an autonomous system.
BGP route reflectors, particularly when configured in a hierarchy,
provide many examples of forwarding inconsistency, but they are much
more complex than this small example.
+-----9---------------3--------+
| | |
| +--------+ |
| | |
| +---C--+ |
| | | |
A--------B +--------------E--10.1.1.0/24
| | | |
| +---D--+ |
| |
+---------------------6--7--8--+
AS1 | | AS2 | | AS5 |
In this diagram, routers are represented by letters, and autonomous
systems by numbers. So:
o Router A is in AS1
o Routers B, C, and D are in AS2
o Router E is in AS5
Each router is using, as its best path to 10.1.1.0/24:
o Router E is using its local (intra-AS) path.
o Router C is using the path through AS3.
o Router D is using the path through Router E.
o Router B is using the path through Router E.
Examining the case of Router B more closely, however, we discover
that while Router B prefers the path it has learned from Router E,
that path has been advertised with a next hop of Router E itself.
However, Router B's best path to this next hop (i.e., Router E), as
determined by the interior routing protocol, is actually through
Router C. Thus, Router B advertises the path {2, 5} to Router A, but
traffic actually follows the path {2, 3, 5} when Router B receives
it.
The system administrator of AS1 has determined there is an attacker
White, et al. Expires August 9, 2006 [Page 10]
Internet-Draft Path Validation Considerations February 2006
in AS3, and has set policy on router A to avoid any route with AS3 in
the AS_PATH. So, beginning with this rule, it discards the path
learned from AS9. It now examines the two remaining paths, learned
from AS2 (B) and AS6, and determines the best path is {2, 5}, through
AS2 (B). However, unknown to A, AS2 (B) is also connected to AS3,
and is transiting traffic to AS5 via the path {2, 3, 5}.
Returning to our questions:
o Is the AS Path valid? The AS Path {2, 3, 5} is a valid AS Path.
o Is the AS Path authorized? If A has a local policy permitting
traffic to the destination advertised to transit through AS3, then
the AS Path can be said to be authorized. However, since A does
not know that traffic is actually passing through AS3, there is no
way for A to know if AS2 is authorized to transit traffic through
AS3.
o Is the AS Path consistent with the forwarding path (is there
forwarding consistency)? The advertised AS Path is {2, 5}, while
the traffic forwarded to the destination actually transits {2, 3,
5}. Forwarding is not consistent in this example.
o Is the routing information atomic? Since only one destination is
advertised, the routing information is atomic in this example.
3. Summary
The examples given in this draft are not the only possible examples
of forwarding that is inconsistent with the advertised AS Path;
[ROUTINGLOGIC] also provides some examples, as well. [ASTRACEROUTE]
provides some interesting background on the pratical impact of
forwarding inconsistent with the advertised AS Path, in the context
of attempting to trace the actual path of packets through a large
internetwork running BGP as an exterior gateway protocol.
By surveying these examples we find the following set of factors in
common:
o In any situation where the actual path along which traffic will be
forwarded is different than the AS Path advertised by a BGP
speaker to a peer outside of the local AS, AS Path authorization
loses any meaning, since the receiving BGP speaker cannot know if
the actual path the traffic will follow is authorized, either
based on local policy, the originator's policy, or the transited
autonomous system's policy.
o In any situation where the routing information advertised by a BGP
speaker to a peer outside the local AS is not atomic, AS Path
authorization loses any meaning. This is common in cases where
routing information is aggregated, or in cases where longer prefix
White, et al. Expires August 9, 2006 [Page 11]
Internet-Draft Path Validation Considerations February 2006
advertisements are not advertised but a shorter length prefix
containing the longer prefix advertisement is advertised.
o The overlapping nature of address ownership causes serious
problems with forwarding consistency and AS Path authorization.
4. Acknowledgements
We would like to thank Steve Kent for his contributions and comments
on this draft.
5. Informative References
[ASTRACEROUTE]
Feamster, N. and H. Balakrishnan, "Towards an Accurate
ASLevel Traceroute Tool", SIGCOMM ACM SIGCOMM, 2003.
[BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[ROUTINGLOGIC]
Feamster, N. and H. Balakrishnan, "Towards a Logic for
Wide Area Routing", SIGCOMM ACM SIGCOMM Worshop on Future
Directions in Network Architecture, Germany, August 2003.
[S-BGP] Kent, S., Lynn, C., and K. Seo, "Secure Border Gateway
Protocol (Secure-BGP)", IEEE IEEE Journal on Selected
Areas in Communications, April 2000.
[SOBGP] White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)",
draft-white-sobgp-architecture-00.txt (work in progress),
April 2004.
White, et al. Expires August 9, 2006 [Page 12]
Internet-Draft Path Validation Considerations February 2006
Authors' Addresses
Russ White
Cisco Systems
Phone:
Fax:
Email: riw@cisco.com
URI:
Bora Akyol
Cisco Systems
Phone:
Fax:
Email: bora@cisco.com
URI:
Nick Feamster
Phone:
Fax:
Email: feamster@lcs.mit.edu
URI:
White, et al. Expires August 9, 2006 [Page 13]
Internet-Draft Path Validation Considerations February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
White, et al. Expires August 9, 2006 [Page 14]