<?xml version="1.0" standalone="no"?>
                    <!DOCTYPE div SYSTEM "/www/backend/www-xml-443/dtd/caidaML.dtd">
                    <!-- do NOT ERASE the DOCTYPE declaration! --><div>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>URL:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<a href="http://www.icir.org/vern/imw-2002/imw2002-papers/217.ps.gz">http://www.icir.org/vern/imw-2002/imw2002-papers/217.ps.gz</a><br/>
<a href="http://www.icir.org/vern/imw-2002/slides/217-slides.pdf">http://www.icir.org/vern/imw-2002/slides/217-slides.pdf</a><br/>
<a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.12.8378">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.12.8378</a>
</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Entry Date:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
2003-05-14


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>Abstract:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
Despite BGP's critical importance as
the de-facto Internet inter-domain routing protocol,
there is little understanding of how BGP actually
performs under stressful conditions when dependable
routing is most needed. In this paper, we
examine BGP's behavior during one stressful period,
the Code Red/Nimda attack on September 18,
2001. The attack was correlated with a 30-fold increase
in the BGP update messages at a monitoring
point which peers with a number of Internet service
providers. Our examination of BGP's behavior during
the event concludes that BGP exhibited no significant
abnormality, and that over 40% of the observed
updates can be attributed to the monitoring
artifact in current BGP measurement settings. Our
analysis, however, does reveal several weak points
in both the protocol and its implementation, such
as BGP's sensitivity to the transport session reliability,
its inability to avoid the global propagation
of small local changes, and its certain implementation
features whose otherwise benign effects only get
amplified under stressful conditions. We also identify
areas for improvement in the current network
measurement and monitoring effort.


</font>
  </td>
</tr>


<tr bgcolor="#e9e9e9">
  <td>
<font face="helvetica,arial" size="2">
<b>Datasets:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<ul>
<li>BGP updates collected at RIPE RRC00 (12 peers) from Sep 10 to
    Sep 30, 2001</li>
<li>assign BGP updates to session resets by (1) looking in logs to find
    time at which a peering session is re-established and (2) noting
    updates that announce a given prefix for the first time in the
    ensuing 25 minutes; the authors observed that most table transfers
    finish in 10 minutes</li>
</ul>


</font>
  </td>
</tr>


<tr bgcolor="#f4f4f4">
  <td>
<font face="helvetica,arial" size="2">
<b>Results:</b>
</font>
</td>
  <td>
<font face="helvetica,arial" size="2">
<ul>
<li>monitoring point experienced many session resets during worm attacks;
    the authors attribute this to the susceptibility of multihop eBGP to
    link problems, noting that RRC04 with direct BGP sessions didn't
    experience a single reset on Sep 18th</li>
<li>40% of BGP updates during worm attacks were caused by session resets
    at the monitoring point</li>
<li>significant fraction of remaining BGP updates had no new AS paths</li>
<li>majority of BGP updates with new AS path information were originated
    by a small number of highly unstable <i>edge</i> networks (specifically,
    prefixes belonging to cable modem, DSL, or dial-up providers)</li>
<li>the authors conjecture that a flurry of implicit withdrawals announcing
    different AS paths could result from session resets between two remote
    ASes; a session failure causes one of the ASes to reannounce all prefixes
    using an alternate AS path</li>
</ul>




</font>
  </td>
</tr>
</div>

