<!doctypehtml PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><title>
   An Attack Tree for the Border Gateway Protocol
  </title><meta content="text/html; charset=utf-8"http-equiv=Content-Type><style>.title {
	FONT-WEIGHT: bold; FONT-SIZE: 22px; COLOR: #990000; LINE-HEIGHT: 22px; FONT-FAMILY: helvetica, arial, sans-serif; TEXT-ALIGN: right
}
.filename {
	FONT-WEIGHT: bold; FONT-SIZE: 18px; COLOR: #666666; LINE-HEIGHT: 28px; FONT-FAMILY: helvetica, arial, sans-serif; TEXT-ALIGN: right
}
P.copyright {
	FONT-SIZE: 10px; COLOR: #000000; FONT-FAMILY: verdana, charcoal, helvetica, arial, sans-serif
}
P {
	MARGIN-LEFT: 2em; MARGIN-RIGHT: 2em
}
LI {
	MARGIN-LEFT: 3em
}
OL {
	MARGIN-LEFT: 2em; MARGIN-RIGHT: 2em
}
UL.text {
	MARGIN-LEFT: 2em; MARGIN-RIGHT: 2em
}
PRE {
	MARGIN-LEFT: 3em; COLOR: #333333
}
UL.toc {
	COLOR: #000000; LINE-HEIGHT: 16px; FONT-FAMILY: verdana, charcoal, helvetica, arial, sans-serif
}
H3 {
	FONT-SIZE: 16px; COLOR: #333333; LINE-HEIGHT: 16px; FONT-FAMILY: helvetica, arial, sans-serif
}
H4 {
	FONT-SIZE: 14px; COLOR: #000000; FONT-FAMILY: helvetica, arial, sans-serif
}
TD.header {
	FONT-SIZE: 10px; COLOR: #ffffff; FONT-FAMILY: arial, helvetica, san-serif; valign: top
}
TD.author-text {
	FONT-SIZE: 10px; COLOR: #000000; FONT-FAMILY: verdana, charcoal, helvetica, arial, sans-serif
}
TD.author {
	FONT-WEIGHT: bold; FONT-SIZE: 10px; MARGIN-LEFT: 4em; COLOR: #000000; FONT-FAMILY: verdana, charcoal, helvetica, arial, sans-serif
}
A:link {
	FONT-WEIGHT: bold; COLOR: #990000; FONT-FAMILY: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif
}
A:visited {
	FONT-WEIGHT: bold; COLOR: #333333; FONT-FAMILY: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif
}
A:unknown {
	FONT-WEIGHT: bold; COLOR: #333333; FONT-FAMILY: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif
}
.link2 {
	FONT-WEIGHT: bold; FONT-SIZE: 9px; COLOR: #ffffff; FONT-FAMILY: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; TEXT-DECORATION: none
}
.RFC {
	FONT-WEIGHT: bold; FONT-SIZE: 9px; COLOR: #666666; FONT-FAMILY: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; TEXT-DECORATION: none
}
.hotText {
	FONT-WEIGHT: normal; FONT-SIZE: 9px; COLOR: #ffffff; FONT-FAMILY: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; TEXT-DECORATION: none
}</style><meta content="MSHTML 6.00.2800.1126"name=GENERATOR><body alink=#000000 bgcolor=#ffffff link=#990000 text=#000000 vlink=#666666><table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table><table border=0 cellpadding=0 cellspacing=0 width=66%><tbody><tr><td><table border=0 cellpadding=2 cellspacing=1 width=100%><tbody><tr valign=top><td bgcolor=#666666 class=header width=33%>Routing Protocol Security<td bgcolor=#666666 class=header width=33%>S. Convery<tr valign=top><td bgcolor=#666666 class=header width=33%>Requirements (rpsec)<td bgcolor=#666666 class=header width=33%>D. Cook<tr valign=top><td bgcolor=#666666 class=header width=33%>Internet-Draft<td bgcolor=#666666 class=header width=33%>M. Franz<tr valign=top><td bgcolor=#666666 class=header width=33%>Expires: May 3, 2003<td bgcolor=#666666 class=header width=33%>Cisco<tr valign=top><td bgcolor=#666666 class=header width=33%> <td bgcolor=#666666 class=header width=33%>November 2, 2002</table></table><div align=right><font face="monaco, MS Sans Serif"color=#990000 size=+3> <b> <br> <span class=title> An Attack Tree for the Border Gateway Protocol </span> </b> </font></div><div align=right><font face="monaco, MS Sans Serif"color=#666666 size=+2> <b> <span class=filename> draft-convery-bgpattack-00 </span> </b> </font></div><font face="verdana, helvetica, arial, sans-serif"size=2> <h3>Status of this Memo</h3> <p>This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p> <p>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.</p> <p>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."</p> <p>The list of current Internet-Drafts can be accessed at <a href=http://www.ietf.org/ietf/1id-abstracts.txt> http://www.ietf.org/ietf/1id-abstracts.txt </a> .</p> <p>The list of Internet-Draft Shadow Directories can be accessed at <a href=http://www.ietf.org/shadow.html> http://www.ietf.org/shadow.html </a> .</p> <p>This Internet-Draft will expire on May 3, 2003.</p> <h3>Copyright Notice</h3> <p>Copyright (C) The Internet Society (2002). All Rights Reserved.</p> <h3>Abstract</h3> <p>This I-D presents all known attack vectors into or using BGP. The data is presented in "Attack Tree" format as published by Schneier <a title="Schneier, B., Attack Trees, December 1999."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#BRUCE> [1] </a> and detailed by the CERT in "Attack Modeling for Information Security and Survivability" <a title="Moore, A., Ellison, R. and R. Linger, Attack Modeling for Information Security and
				Survivability, March 2001."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#CERT> [2] </a> . Future security improvements to BGP (whether best practices or enhancements to the protocol) should consider the attacks outlined here when determining the relative security improvements such changes provide.</p> <a name=toc> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <h3>Table of Contents</h3> <ul class=toc compact><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#anchor1> 1. </a>   Introduction <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ATTACK_TREE> 2. </a>   BGP Attack Tree <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ATOMIC_GOALS> 2.1 </a>   BGP Atomic Goals <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#COMP_MD5> 2.1.1 </a>   Compromise MD5 Authentication <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#EST_UNAUTH_BGP> 2.1.2 </a>   Establish Unauthorized BGP Session with Peer <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ORIG_UNAUTH_PREF> 2.1.3 </a>   Originate Unauthorized Prefix/Attribute into Peer Route Table <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#CHANGE_PATH> 2.1.4 </a>   Change Path Preference of a Prefix <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#CRASH_BGP> 2.1.5 </a>   Conduct Denial/Degradation of Service Attack Against BGP Process <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#RESET_BGP> 2.1.6 </a>   Reset a Single BGP Session <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#SPOOF_BGP> 2.1.7 </a>   Send Spoofed BGP Message <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ATTACK_SCENARIOS> 2.2 </a>   Attack Scenarios <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#KILL_INET> 2.2.1 </a>   Disable Critical Portions of the Internet by Disrupting Internet Routing Tables <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#FORCE_ALT_PATH> 2.2.2 </a>   Force a Multi-homed AS to use an Aternate Path to/from an Outside Network Instead of the Preferred Path <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#DISABLE_SINGLE> 2.2.3 </a>   Disable a Single-homed AS <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#DISABLE_MULTI> 2.2.4 </a>   Disable a Multi-homed AS <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#BLACKHOLE> 2.2.5 </a>   Blackhole Traffic <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#TEST> 3. </a>   Testing Considerations <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#rfc.references1> § </a>   References <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#rfc.authors> § </a>   Authors' Addresses <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#SUPPORTING> A. </a>   Supporting Atomic Goals <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#COMP_ROUTER> A.1 </a>   Compromise Router <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#DOS_ROUTER> A.2 </a>   Denial of Service (DoS) Router <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#MITM> A.3 </a>   Intercept or Modify Data Through Man-in-the-Middle (MITM) Attack <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#TCP_SEQ> A.4 </a>   TCP Sequence Number Attack <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#SNIFF> A.5 </a>   Sniff Traffic <br> </b><b> <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#rfc.copyright> § </a>   Full Copyright Statement <br> </b></ul> <br clear=all> <a name=anchor1> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <a name=rfc.section.1> </a> <h3>1. Introduction</h3> <p>BGP and other infrastructure protocols such as DNS have received significant critical attention as the overall awareness of Internet security has increased. Although BGP threat models have been published <a title="Murphy, S., BGP Security Vulnerabilities Analysis, February 2002."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#SANDY> [3] </a> that identify inherent vulnerabilities in the protocol, none have considered the full range of options available to the adversary or their relative difficulty.</p> <p>The use of attack trees focuses analysis on measurable goals that can ultimately be translated into specific tests against popular implementations. This analysis technique also encourages a structured elaboration of events that must occur for a successful intrusion. Since each node (an attacker goal) may be decomposed into subordinate nodes (sub-goals, or means of achieving the parent goal), attack trees allow security analysis to be conducted at multiple layers of abstraction. This allows common attacks to be referenced as reusable modules that apply to common network scenarios.</p> <p>Although a comprehensive discussion of attack trees is outside the scope of this I-D, it is useful to provide a general overview of their function and value. The clearest way to demonstrate this is through examples, as illustrated in <a title="Schneier, B., Attack Trees, December 1999."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#BRUCE> [1] </a> . Consider an individual trying to gain unauthorized physical access to a building. An attack tree for such an act might look like this:</p> </font><pre>Goal: Gain unauthorized physical access to building

Attack:
OR  1. Unlock door with key
    2. Pick lock
    3. Break window
    4. Follow authorized individual into building
			</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>This simple tree should be read as follows: to gain unauthorized physical access to a building, the adversary must unlock the door with a key, pick the lock, break a window, or follow an authorized individual into the building. The "OR" operator defines that only one is required. In the same tree, replacing the "OR" with "AND" would require that all subordinate goals be achieved to realize the parent goal. Attack trees at this level of detail are of limited use. Their true value comes in understanding how an adversary can execute one of the listed subordinate goals. This requires the following, more detailed, attack tree:</p> </font><pre>Goal: Gain unauthorized physical access to building

Attack:
OR  1. Unlock door with key
    OR  1. Steal Key
        2. Social Engineering
        OR  1. Borrow key
            2. Convince locksmith to unlock door
    2. Pick lock
    3. Break window
    4. Follow authorized individual into building
    OR  1. Act like you belong and follow someone else
        2. Befriend someone authorized outside a building
        3. Appear in need of assistance (such as carrying a large box)
    AND 4. Wear appropriate clothing for the location
			</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>Now the various sub nodes of the tree are better defined. In order to "unlock door with key" you need to either steal the key or perform some type of social engineering. Sub goal 4 (Follow authorized individual into building) illustrates the use of "OR" and "AND" at the same level of the tree. This should be read as follows: In order to follow an individual into the building the adversary needs to do one of the first 3 listed items, and wear appropriate clothing for the location.</p> <p>The use of attack trees also allows comparison between technical and non-technical means of attack, and leads to a more comprehensive analysis of threats and vulnerabilities. Even without extensive elaboration, we learn in this tree that following someone into a building is probably the easiest way of gaining entrance with the lowest amount of cost or risk to the adversary. This class of attacks collectively known as "social engineering" is listed but not elaborated throughout this I-D. In many cases social engineering is the easiest form of attack and could result in the greatest damage.</p> <p>This I-D illustrates a simple BGP attack tree: subsequent analysis should assign attributes (and possibly values) to each node of the tree. This allows more quantitative methods to be used in analyzing the attack tree data. These attributes could include:</p> <ul class=text><li>Impact of the attack<li>Ease of attack execution<li>Cost of the attack<li>Presence of countermeasures (such as best practices)<li>Access/trust requirements to conduct attack</ul> <p></p> <p>Analysis of this data will yield the subset of attacks that result in the most damage, are the easiest to launch, the least costly, have the least access requirements, and are unlikely to be mitigated by current best practices. Addressing these attacks should be the initial focus of any improvements to BGP or relevant best practices.</p> <p>Computer security terms used in this I-D are in accordance with <a title="Shirey, R., Internet Security Glossary, RFC 2828, December 1999."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#2828> RFC 2828 </a> [4].</p> <a name=ATTACK_TREE> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <a name=rfc.section.2> </a> <h3>2. BGP Attack Tree</h3> <p>This I-D divides the attack tree into three main sections to reduce redundancy and provide greater portability into subsequent trees defined in other I-Ds. When another section of this I-D is referenced within a specific tree, the tree located at the referenced section should be attached at the point the reference is made.</p> <p>The first section details BGP Atomic Goals of an adversary and is detailed in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ATOMIC_GOALS> BGP Atomic Goals </a> . BGP Atomic Goals are defined in this I-D as the narrowest form of attack by an adversary specifically directed against BGP. BGP Atomic Goals consist of unique attack techniques and Supporting Atomic Goals as detailed in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#SUPPORTING> Supporting Atomic Goals </a> . Supporting Atomic Goals are common network attack methods used in more than one BGP Atomic Goal. The third main section of the document details higher level adversary goals that make use of BGP Atomic Goals (and therefore supporting atomic goals as well). These goals are referred to as Attack Scenarios and are detailed in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ATTACK_SCENARIOS> Attack Scenarios </a> .</p> <p>It is worth noting that the inclusion of an attack in this attack tree says nothing with regard to the likelihood such an attack will occur or even the reasonable possibility it could occur. Future testing and analysis, as mentioned earlier, is required to accurately interpret the data in this tree.</p> <a name=rfc.section.2.1> </a> <h4><a name=ATOMIC_GOALS> 2.1 </a>  BGP Atomic Goals</h4> <p>The following atomic goals are defined and used throughout the attack tree:</p> <ul class=text><li>Compromise MD5 authentication<li>Establish unauthorized BGP session with peer<li>Originate unauthorized prefix into peer route table<li>Change path preference of a prefix<li>Conduct denial/degradation of service against BGP process<li>Reset single BGP session<li>Spoof a BGP message</ul> <p><a name=rfc.section.2.1.1> </a></p> <h4><a name=COMP_MD5> 2.1.1 </a>  Compromise MD5 Authentication</h4> <p>The common-sense view is that most adversaries will choose the path of least resistance, so that all but the most sophisticated threats would target a BGP speaker whose sessions are not protected by RFC 2385 <a title="Heffernan, A., Protection of BGP Sessions via the TCP MD5 Signature Option, RFC 2385, August 1998."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#2385> [5] </a> authentication. Nevertheless, attempting a compromise of MD5 authenticated BGP messages could be done as follows:</p> </font><pre>				
Attack:
OR  1. Use social engineering to obtain MD5 password
    2. Capture Password 
    OR  1. Keystroke logger
        AND  1. Compromise/gain access to administrative host
             2. Install hostile application on administrative host
             3. Observe MD5 password as it is typed/viewed on screen
        2. Sniff MD5 password from management traffic (Appendix A.4)
        3. Capture password from router configuration
        OR   1. Compromise network management server
             OR  1. View unencrypted router configuration
                 2. Decrypt encrypted router configuration
             2. Compromise router (Appendix A.1)
    3. Brute-Force MD5 password
    OR  1. Active attack - attempt to connect with 
        OR  1. Send to peer that generates hashed response
            AND  1. Send segment with RFC 2385 option to router
                 2. Observe response from router to determine if your hash
                 was valid
                 3. Gain physical/local access to link between peers
        2. Passive Attack
        AND 1. Obtain hashed packet (to facilitate offline attack)
            2. Use RFC 2385 cracking tool to discover password
    5. Discover implementation flaw in RFC 2385 
    6. Discover new attack against MD5
    7. Exploit hash collision attack against MD5 

</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>To validate our assumptions about the relative difficulty of attacking RFC2385 authentication, we must have test data that measures the relative ease/difficulty of such attacks (or the side effects of unsuccessful attacks) against popular BGP/TCP implementations. When observing the response from an RFC 2385 authenticated session, sniffing will be necessary if using a spoofed SYN.</p> <a name=rfc.section.2.1.2> </a> <h4><a name=EST_UNAUTH_BGP> 2.1.2 </a>  Establish Unauthorized BGP Session with Peer</h4> <p>Establishing an unauthorized BGP session with a peer is defined by achieving a peering arrangement without the knowledge or permission of both sides of the session. This includes peering sessions established by routers and/or any other device capable of being a BGP speaker.</p> </font><pre>Attack:
OR  1. Establish session with permissive router
    OR  1. Find available local BGP speaker
        OR  1. Port Scan
            2. Social Engineering
        2. Find available remote (EBGP-multi) speaker
        OR  1. Port Scan
            2. Social Engineering
    AND 3. Establish peering relationship with discovered router
    2. Compromise router and reconfigure to allow peering session
    AND 1. Compromise Router (Appendix A.1)
        2. Configure router to allow peering from attacking router
    3. Simulate BGP Session from non-router
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>Once a peering session has been established, the adversary can much more easily launch attacks that not only effect the peer, but the entire network.</p> <a name=rfc.section.2.1.3> </a> <h4><a name=ORIG_UNAUTH_PREF> 2.1.3 </a>  Originate Unauthorized Prefix/Attribute into Peer Route Table</h4> <p>To accomplish this goal, an adversary must insert a new prefix into a peer's routing table. This attack can be used to change traffic patterns in a network in the case that the prefix is more specific than the route previously used to direct traffic. This can lead to stolen or blackholed traffic across the network.</p> </font><pre>Attack:
OR  1. Send from valid Router
    OR  1. Misconfigured
        2. Compromise router (Appendix A.1)
    2. Send from Invalid Router
    AND 1. Gag valid router
        OR  1. Kill Router
            OR  1. Power Off/Physical Layer
                2. Crash and prevent reboot
                3. Conduct denial of service against router (Appendix A.2)
	        2. Steal IP Addr
            OR  1. ARP Spoof
                2. Steal MAC
        2. Introduce rogue router (Assume IP)
        OR  1. Steal IP Addr (section 2.1.3.1.2)
            2. IGP More Specific Route Introduction
            3. Establish unauthorized BGP session w/peer (Section 2.1.2)
    3. Send spoofed BGP Update from Non-Router
    OR  1. Conduct TCP Sequence Number Attack (Appendix A.4)
        2. Conduct Man-in-the-Middle (Appendix A.3)
AND 4. Craft BGP Message
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>This is one of several attacks that can be caused by misconfiguration as opposed to a deliberate attack.</p> <a name=rfc.section.2.1.4> </a> <h4><a name=CHANGE_PATH> 2.1.4 </a>  Change Path Preference of a Prefix</h4> <p>Changing the path preference of a prefix can lead to the same types of attacks that occur by inserting a new prefix into a peer's routing table. This atomic goal is defined by altering the attributes of a prefix so that the BGP decision process is affected. This goal is different from originating an unauthorized prefix in that altering the attributes implies that the prefix already exists in the BGP table. There are different methods that can be used to accomplish each of these goals so they will be analyzed separately.</p> </font><pre>Attack:
OR  1. Modify (AS-PATH, Next-Hop, MED, local-pref, communites)
    OR  1. Valid BGP Speaker 
        OR  1. rogue transit implementation
            2. compromise edge (origin/recipient) router
        2. Man-in-the-middle attack (Appendix A.3)
        3. Compromise router (Appendix A.1)
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>In reality, any attribute could be altered to change the path preference. The five listed are the most common.</p> <a name=rfc.section.2.1.5> </a> <h4><a name=CRASH_BGP> 2.1.5 </a>  Conduct Denial/Degradation of Service Attack Against BGP Process</h4> <p>BGP routing processes are susceptible to a variety of attacks which can prevent establishment of new sessions, exchange of routing updates, or cause the router itself to become inoperable.</p> </font><pre>Attack:
OR  1. Denial of service against router (Appendix A.2)
    2. TCP Resource Exhaustion against Port 179
    OR  1. SYN Flood - exhaust SYN_RCVD state in TCP stack
        2. Connect() - repeated full (3-way handshake) connections
        3. LAST_ACK - complete 3-way handshake, then FIN-ACK
    3. Invalid BGP Messages
        1. OPEN
        2. UPDATE
        3. KEEPALIVE
        4. NOTIFICATION        
    4. Valid BGP Messages
        1. Send /32 routes
        2. Update flooding
        3. Update/Withdraw Flooding
        4. MD5 Resource Exhaustion
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>Given the nearly infinite number of attacks and operational conditions that could cause a routing process to stop performing as expected, a significant testing effort will be needed to increase the level of assurance in popular BGP implementations.</p> <a name=rfc.section.2.1.6> </a> <h4><a name=RESET_BGP> 2.1.6 </a>  Reset a Single BGP Session</h4> <p>In this attack, the adversary is trying to cause a current BGP session in the established state to reset. Such an attack could be launched over and over again to prevent two peers from reliably exchanging routing information.</p> </font><pre>Attack:
OR  1. Send message to router causing reset
    OR  1. Send RST message to TCP stack
        2. Send BGP Message
        OR  1. Notify
            2. Open
            3. Keepalive
    AND 3. TCP Sequence number Attack (Appendix A.4)
    2. Alter configuration via. compromised router (Appendix A.1)
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>It is unknown why an adversary would choose to reset a session via <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#RESET_BGP> Reset a Single BGP Session </a> .1.2. Since the preconditions of attack <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#RESET_BGP> Reset a Single BGP Session </a> .1.1 are required in order to be successful. Also, it should be noted that the sequence number attack detailed in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#TCP_SEQ> TCP Sequence Number Attack </a> is far from trivial to properly execute.</p> <a name=rfc.section.2.1.7> </a> <h4><a name=SPOOF_BGP> 2.1.7 </a>  Send Spoofed BGP Message</h4> <p>An adversary could send a BGP message to a BGP speaker and potentially alter the behavior of the routing process. This attack is mainly designed to insert false information into a BGP session, or to reset a session.</p> </font><pre>Attack:

OR  1. TCP Sequence number Attack (Appendix A.4)
    2. Intercept or Modify Data Through Man-in-the-Middle (MITM)
    Attack (Appendix A.3)
AND 3. Build a valid BGP packet
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>This attack assumes that the adversary is able to cause the BGP speaker to accept a message without establishing a peering relationship. Spoofing the message is the primary mechanism to accomplish this.</p> <a name=rfc.section.2.2> </a> <h4><a name=ATTACK_SCENARIOS> 2.2 </a>  Attack Scenarios</h4> <p>The attack scenarios represent larger goals an adversary may have which use BGP as a means to accomplish them. These attacks use the atomic goals discussed in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#ATOMIC_GOALS> BGP Atomic Goals </a> as a mechanism to reduce the duplication of information within each tree.</p> <p>The following attack scenarios are defined:</p> <ul class=text><li>Disable critical portions of the Internet by disrupting Internet routing tables<li>Force a multi-homed AS to use an alternate path to/from an outside network instead of the preferred path<li>Disable a single-homed AS<li>Disable a multi-homed AS<li>Blackhole traffic</ul> <p><a name=rfc.section.2.2.1> </a></p> <h4><a name=KILL_INET> 2.2.1 </a>  Disable Critical Portions of the Internet by Disrupting Internet Routing Tables</h4> <p>Common concerns regarding BGP have described scenarios where large section of the Internet become unreachable due to the lack of security features in BGP. In theory, the attack can be done in one of three main ways: physical destruction, social engineering, or routing attacks.</p> </font><pre>Attack:
OR  1. Physical Destruction
    OR  1. Destroy Peering Points
        2. Strategic Link Destruction (backhoe)
    2. Social Engineering
    3. Routing Attacks
    OR  1. Alter global Internet routing table
        OR  1. Insert unauth prefix into route table (Section 2.1.3)
            2. Establish unauthorized BGP session with peer (Section 2.1.2)
        AND 3. Ensure propagation in spite of prefix filtering
            4. Repeat for ASs at multiple ISP
        2. Disable critical core routers
        OR  1. Router overload leading to crash
            OR  1. DDoS
                2. Worm
                3. Loops
                4. Change prefix paths (Section 2.1.4)
            2. Exploit pervasive implementation flaw on router
            OR  1. Memory exhaustion
                2. CPU exhaustion
                3. Magic packet (buffer overflow, etc.)
            3. DoS BGP Process (Section 2.1.5)
            4. Exploit routing table memory limitations
            AND 1. Find unfiltered routing distribution point
                2. Send the most specific routes that will be accepted and
                propagated upstream
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>Since this I-D is focused on BGP, this tree elaborates on the routing related portion of the tree. Any of the above listed attack goals are non-trivial and would require extensive coordination and potentially insider involvement.</p> <a name=rfc.section.2.2.2> </a> <h4><a name=FORCE_ALT_PATH> 2.2.2 </a>  Force a Multi-homed AS to use an Aternate Path to/from an Outside Network Instead of the Preferred Path</h4> <p>Another way that BGP can be compromised is by forcing a multihomed AS to change the normal path preference. This can result in the entire AS using a suboptimal path, or using links that cost the AS more money. In the extreme case, changing the path preference could cause a link to become oversubscribed and result in the loss of data or control traffic.</p> </font><pre>Attack:
OR  1. Force traffic from outside network to use alternate path
    OR  1. Lower preference of preferred path
        OR  1. Change path preference of a prefix (Section 2.1.4)
            2. DoS BGP Process (Section 2.1.5)
            3. Reset BGP Session (Section 2.1.6)
            4. Compromise Router (Appendix A.1)
        2. Raise preference of alternate path (Section 2.1.4)
    2. Force traffic going to outside network to use alternate path
    OR  1. Lower preference of preferred path
        OR  1. Change path preference of a prefix (Section 2.1.4)
            2. DoS BGP Process (Section 2.1.5)
            3. Reset BGP Session (Section 2.1.6)
            4. Compromise Router (Appendix A.1)
        2. Raise preference of alternate path (Section 2.1.4)
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <a name=rfc.section.2.2.3> </a> <h4><a name=DISABLE_SINGLE> 2.2.3 </a>  Disable a Single-homed AS</h4> <p>This attack is a smaller scale version of the attack described in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#KILL_INET> Disable Critical Portions of the Internet by Disrupting Internet Routing Tables </a> . Here the adversary need only prevent a single-homed AS from communicating with the rest of the Internet.</p> </font><pre>Attack:
OR  1. Disable provider link
    OR  1. Physical link destruction
        2. Social engineering
        3. Turn off the link by compromising the upstream
        router (Appendix A.1)
    2. Disable AS via routing protocol attack
    OR  1. DoS BGP Process (Section 2.1.5)
        2. Reset BGP Session (Section 2.1.6)
        3. Compromise router (Appendix A.1)
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>Any crashes or resets initiated by the adversary in <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#DISABLE_SINGLE> Disable a Single-homed AS </a> .2.1 or .2.2 would usually require the attack be generated continually to prevent the router from reestablishing proper communications with its peer.</p> <a name=rfc.section.2.2.4> </a> <h4><a name=DISABLE_MULTI> 2.2.4 </a>  Disable a Multi-homed AS</h4> <p>This attack is a combination of <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#DISABLE_SINGLE> Disable a Single-homed AS </a> and <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#KILL_INET> Disable Critical Portions of the Internet by Disrupting Internet Routing Tables </a> . The number of links the AS under attack has with other ASs will dictate the type of attack necessary to most efficiently achieve the adversary's objectives. This attack sequence, in particular, would benefit from further testing through lab simulation and the association of attributes to each of the leaf nodes.</p> </font><pre>Attack:
OR  1. Disable links 1...N (Section 2.2.3)
    2. Disable critical portions of the ASs network (Section 2.2.1)
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>To summarize, the adversary can either consider the attack like disabling several individually connected single-homed ASs, or as a smaller version of the Internet as a whole.</p> <a name=rfc.section.2.2.5> </a> <h4><a name=BLACKHOLE> 2.2.5 </a>  Blackhole Traffic</h4> <p>BGP can be used to blackhole traffic. If an adversary has access to the forwarding path of the target system, he can quietly discard the traffic while continuing to function as a BGP speaker. The adversary could also affect the BGP tables of his neighbors using BGP advertisements so that they would send traffic to the incorrect destination. One way this could be accomplished is through the unauthorized origination of a prefix.</p> </font><pre>Attack:
OR  1. Drop traffic on the wire itself (Section 2.1.4.1.2)
    2. Drop traffic on a router (without using BGP)
    OR  1. Policy route to null
        2. Static route to null
    AND 3. Gain administrative access to the router
        OR  1. Rouge router
            2. Misconfigured router
            3. Compromise router (Appendix A.1)
    3. Drop traffic using bogus BGP messages
    OR  1. Establish unauthorized BGP session with peer (Section 2.1.2)
        2. Originate unauthorized prefix/attribute (Section 2.1.3)
        3. Compromise router (Appendix A.1)
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <a name=TEST> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <a name=rfc.section.3> </a> <h3>3. Testing Considerations</h3> <p>BGP design decisions (such as the selection of TCP as the transport protocol) certainly impact the security of the Internet routing infrastructure. However, operational considerations and the quality of the BGP implementations may have a greater impact on Internet security. Testing (as the ultimate determination of relative difficulty of an attack) is especially critical for threat/vulnerability analyses that use attack trees. This is because the likelihood, criticality, and access requirements of leaf nodes determine which are the most likely paths through the tree.</p> <p>As discussed earlier, test procedures and results could be released in a subsequent I-D. Such analysis should be environment specific. For example, the analysis of this attack tree will be fundamentally different for Internet service provider networks and enterprise networks. The same can also be said of the differences in attack methods between a remote blind adversary and a trusted insider.</p> <a name=rfc.references1> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <h3>References</h3> <table border=0 width=99%><tbody><tr><td class=author-text valign=top><b> <a name=BRUCE> [1] </a> </b><td class=author-text>Schneier, B., " <a href=http://www.ddj.com/documents/s=896/ddj9912a/9912a.htm> Attack Trees </a> ", December 1999.<tr><td class=author-text valign=top><b> <a name=CERT> [2] </a> </b><td class=author-text>Moore, A., Ellison, R. and R. Linger, " <a href=http://www.cert.org/archive/pdf/01tn001.pdf> Attack Modeling for Information Security and Survivability </a> ", March 2001.<tr><td class=author-text valign=top><b> <a name=SANDY> [3] </a> </b><td class=author-text>Murphy, S., " <a href=http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-01.txt> BGP Security Vulnerabilities Analysis </a> ", February 2002.<tr><td class=author-text valign=top><b> <a name=2828> [4] </a> </b><td class=author-text>Shirey, R., " <a href=http://www.ddj.com/documents/s=896/ddj9912a/9912a.htm> Internet Security Glossary, RFC 2828 </a> ", December 1999.<tr><td class=author-text valign=top><b> <a name=2385> [5] </a> </b><td class=author-text>Heffernan, A., " <a href=http://www.ietf.org/rfc/rfc2385.txt> Protection of BGP Sessions via the TCP MD5 Signature Option, RFC 2385 </a> ", August 1998.<tr><td class=author-text valign=top><b> <a name=RFC1948> [6] </a> </b><td class=author-text>Bellovin, S., " <a href=http://www.ietf.org/rfc/rfc1948.txt> Defending Against Sequence Number Attacks, RFC 1948 </a> ", May 1996.<tr><td class=author-text valign=top><b> <a name=NEWSHAM> [7] </a> </b><td class=author-text>Newsham, T., " <a href=http://comsec.theclerk.com/CISSP/The%20Problem%20with%20Random%20Increments_4_30_01_final.PDF> The Problem With Random Increments </a> ", March 2001.<tr><td class=author-text valign=top><b> <a name=REKHTER> [8] </a> </b><td class=author-text>Rekhter, Y. and T. Li, " <a href=http://www.ietf.org/rfc/rfc1771.txt> A Border Gateway Protocol 4 (BGP-4), RFC 1771 </a> ", March 1995.</table> <a name=rfc.authors> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <h3>Authors' Addresses</h3> <table border=0 cellpadding=0 cellspacing=0 width=99%><tbody><tr><td class=author-text> <td class=author-text>Sean Convery<tr><td class=author-text> <td class=author-text>Cisco Systems, Inc.<tr><td class=author-text> <td class=author-text>170 W. Tasman Dr.<tr><td class=author-text> <td class=author-text>San Jose, CA 95134<tr><td class=author-text> <td class=author-text>US<tr><td align=right class=author>Phone: <td class=author-text>+1 408 853 8753<tr><td align=right class=author>EMail: <td class=author-text><a href=mailto:sean@cisco.com> sean@cisco.com </a><tr cellpadding=3><td> <td> <tr><td class=author-text> <td class=author-text>David Cook<tr><td class=author-text> <td class=author-text>Cisco Systems, Inc.<tr><td class=author-text> <td class=author-text>7025 Kit Creek Rd.<tr><td class=author-text> <td class=author-text>Research Triangle Park, NC 27709<tr><td class=author-text> <td class=author-text>US<tr><td align=right class=author>Phone: <td class=author-text>+1 919 392-8772<tr><td align=right class=author>EMail: <td class=author-text><a href=mailto:dacook@cisco.com> dacook@cisco.com </a><tr cellpadding=3><td> <td> <tr><td class=author-text> <td class=author-text>Matthew Franz<tr><td class=author-text> <td class=author-text>Cisco Systems, Inc.<tr><td class=author-text> <td class=author-text>12515 Research Blvd.<tr><td class=author-text> <td class=author-text>Austin, TX 78759<tr><td class=author-text> <td class=author-text>US<tr><td align=right class=author>Phone: <td class=author-text>+1 512 378 1648<tr><td align=right class=author>EMail: <td class=author-text><a href=mailto:mfranz@cisco.com> mfranz@cisco.com </a></table> <a name=SUPPORTING> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <a name=rfc.section.A> </a> <h3>Appendix A. Supporting Atomic Goals</h3> <a name=rfc.section.A.1> </a> <h4><a name=COMP_ROUTER> A.1 </a>  Compromise Router</h4> <p>Although outside the scope of routing protocol security, if the routers themselves can be compromised the routing infrastructure can be subverted.</p> </font><pre>Attack:
OR  1. Gain physical access to router
    AND 1. Gain physical access to data center
        2. Guess passwords
    OR  3. Perform password recovery
    2. Gain logical access to router
    OR  1. Compromise network manager system
        OR  1. Exploit application layer vulnerability in server
            2. Hijack management traffic
        2. Login to router
        OR  1. Guess password
            2. Sniff password
            3. Hijack management session
            OR 1. Telnet
               2. SSH
               3. SNMP
            4. Social engineering
        3. Exploit implementation flaw in protocol/application in router
        OR  1. Telnet
            2. SSH
            3. SNMP
            4. Proprietary management protocol
			
			</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>The ability of an adversary to compromise a BGP speaker is largely dependent on operational best practices: use of secure management protocols and authentication mechanisms, use of intrusion detection systems, etc.</p> <a name=rfc.section.A.2> </a> <h4><a name=DOS_ROUTER> A.2 </a>  Denial of Service (DoS) Router</h4> <p>Denial/degradation of service attacks can be conducted against network devices using a variety of well-known techniques.</p> </font><pre>Attack:
OR  1. Physical destruction of router
    2. Link layer attacks
    OR  1. Protocol attack using link layer protocol
        2. Physical link attack
    3. ARP attacks
    4. IP attacks
    OR  1. ICMP Message
        OR 1. Flooding
           2. Malformed
        2. IP Fragmentation Attack
    5. UDP attacks
    6. TCP attacks
    OR  1. SYN Flood
        2. Connect()
        3. LAST_ACK
        4. New/undiscovered DoS against TCP
    7. Application-Layer DoS 
    OR  1. Telnet
        2. SSH
        3. SNMP
        4. Other aplication layer protocol
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>All of these attacks are outside the scope of BGP design or implementation and ultimately depend on the survivability of the routing device itself, its ability withstand attack, and the proper configuration of the device based on published best-practices.</p> <a name=rfc.section.A.3> </a> <h4><a name=MITM> A.3 </a>  Intercept or Modify Data Through Man-in-the-Middle (MITM) Attack</h4> <p>Man in the middle attacks against cryptographic protocols or application layer protocols allow an adversary to effectively proxy communication between two parties allowing any data to either be read or altered. Although not impossible to conduct after a session has been established, the attack is easier done prior to session initiation.</p> </font><pre> 
Attack: 
AND 1. Gain write access to network segment of one or more peers 
    2. Subvert address infrastructure
    OR  1. ARP/MAC spoofing 
        2. DNS spoofing
    3. Proxy BGP sessions between BGP speakers
</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>The goals of a MITM attack against BGP are almost identical to a <a href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#TCP_SEQ> TCP Sequence Number Attack </a> against a BGP session. DNS Spoofing may be unlikely because many implementations/configurations are unlikely to use hostnames in router configurations.</p> <a name=rfc.section.A.4> </a> <h4><a name=TCP_SEQ> A.4 </a>  TCP Sequence Number Attack</h4> <p>TCP suffers from well-known design flaws which make it possible to hijack or terminate applications that use it as their transport protocol.</p> </font><pre>Attack:
OR  1. Blind Spoofing Attack
    AND  1. Guess sequence number use by a BGP speaker
         2. Inject valid BGP message 
    2. Non-Blind Spoofing attack
    AND  1. Sniff Traffic (Appendix A.5)
         2. Inject valid BGP message based on sequence numbers
	     		</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p></p> <p>Adequate initial sequence number randomness <a title="Bellovin, S., Defending Against Sequence Number Attacks, RFC
1948, May 1996."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#RFC1948> [6] </a> should mitigate most blind attacks, although some research <a title="Newsham, T., The Problem With Random Increments, March 2001."href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#NEWSHAM> [7] </a> suggests blind attacks may be easier that previously thought, especially if only a single spoofed RST is needed.</p> <p></p> <a name=rfc.section.A.5> </a> <h4><a name=SNIFF> A.5 </a>  Sniff Traffic</h4> <p>Depending on the network topology, there are many ways of gaining read-access to a network to conduct passive attacks. The most common method would be to compromise a system (typically a general purpose operating system) on the segment and install software the puts a network interface card in promiscuous mode and captures traffic.</p> </font><pre>Attack:
OR  1. Gain local network access to a segment
    AND  1. Compromise server 
         2. Install sniffing software
    2. Tap physical medium
    3. Redirect traffic through a compromised host
				</pre><font face="verdana, helvetica, arial, sans-serif"size=2> <p>ARP/MAC spoofing may be necessary to sniff traffic on switched networks and many tools are available which make this a trivial task.</p> <a name=rfc.copyright> <br> <hr shade=0 size=1> </a> <table align=right border=0 cellpadding=0 cellspacing=2 height=15 width=30><tbody><tr><td align=middle bgcolor=#990000 height=15 width=30><a class=link2 href=http://trinux.sourceforge.net/draft-convery-bgpattack-00.html#toc> <font face="monaco, MS Sans Serif"color=#ffffff size=1> <b>  TOC  </b> </font> </a> <br></table> <h3>Full Copyright Statement</h3> <p class=copyright>Copyright (C) The Internet Society (2002). All Rights Reserved.</p> <p class=copyright>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.</p> <p class=copyright>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p> <p class=copyright>This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.</p> <h3>Acknowledgement</h3> <p class=copyright>Funding for the RFC Editor function is currently provided by the Internet Society.</p> </font>