<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Some thoughts on BCOP TF objectives.</p>
    <p>The current statements of BCOP TF Charter and activities do not
      make distinctions between Practices that are good for the Internet
      (mutually beneficial) and Practices that are good recommendations
      for the individual Operator (altruistic).  MANRS clearly sits in
      the former, but does contain some altruistic recommendations
      also.  <br>
    </p>
    <p>I suggest that the BCOP TF charter should be clarified to state
      clearly whether its scope is solely BCOPs that are mutually
      beneficial.  There seem to me to be a lot of opportunities for
      more altruistic output, but these are not being discussed.<br>
    </p>
    I happen to be employed by Arbor Networks so I hear a lot about bad
    things that happen across the Internet.<br>
    <br>
    Considerations for BCOPs that could be worked on:<br>
    <ul>
      <li>Amplification attacks.  Avoid being an Amplifier.  Do not
        respond to connectionless service requests from outside of your
        own address space.  DNS, NTP, Chargen...  Configure your servers
        and ingress filters accordingly. (mutually beneficial)</li>
      <li>For Internet Access providers, consider offering, as the
        default entry level Internet Access Service, something which
        does not allow external DNS / NTP resolution, to limit some of
        the methods available to 'malware' that gets on to consumer
        systems. (mutually beneficial)</li>
      <li>Implement a separate network for monitoring and managing your
        network.  Otherwise, a large traffic anomaly, like a DoS attack,
        may flood your internal links and make your network invisible
        and uncontrollable.  A physically separate network is best
        because virtual networks have to have classifiers that decide
        the priority/VLAN for arriving traffic and these can also be
        overwhelmed by large anomalies, with the same bad results.
        (altruistic)</li>
      <li>When acquiring routers and networking equipment, pay attention
        to the need to monitor.  Can a new device generate flow reports
        and process SNMP requests at useful rates without impairing your
        forwarding performance below the level you need?  Be prepared
        for exceptional packet rates, not just bit rates. (altruistic)</li>
      <li>Discuss Flowspec opportunities with your peers and transit
        providers to give yourself as many opportunities as possible for
        traffic engineering to achieve mitigation. (altruistic)</li>
      <li>Customer contracts and DoS attacks.  Make it clear that the
        customer is contracting to receive a limited amount of bandwidth
        (and packet rate).  If they attract a higher rate of traffic,
        the ISP will HAVE to drop some traffic randomly, and may need to
        drop all traffic to protect its other customers.  Consider
        offering mitigation services to customers that wish to protect
        themselves against these incidents.  (altruistic)</li>
      <li>Customers that have totally free access to the Internet
        represent additional risk to you, the ISP.  For customers that
        want the full experience, cover your additional risk mitigation
        costs. (altruistic)</li>
    </ul>
    <p>Regards</p>
    <p>Steve<br>
    </p>
  </body>
</html>