[bcop] Mutually beneficial or altruistic?

Hi,

On 17/01/2017 17:52, Steve Nash wrote:
> Some thoughts on BCOP TF objectives.
>
> 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.
>
> 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.

Altruism is also very welcome, self-interest a little bit less :)

>
> I happen to be employed by Arbor Networks so I hear a lot about bad
> things that happen across the Internet.
>
> Considerations for BCOPs that could be worked on:
>
>   * 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)

Agree.

>   * 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)

Censorship. ISP should not deal with L4 filtering.

>   * 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)

Agree. It's about self-protection.

>   * 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)

Interesting one. Are there any known measurements and tests for this HW 
capability?

>   * Discuss Flowspec opportunities with your peers and transit providers
>     to give yourself as many opportunities as possible for traffic
>     engineering to achieve mitigation. (altruistic)

Good set of bullet points needed for that discussion would be useful.

>   * 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)

This one can be hard to generalize, as every ISP is different. Worth 
trying anyway.

>   * 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)

Not sure I understand this one... Which ISP gives to their customers 
free access?

>
> Regards

any volunteers in the group to take on and help with any of the above ideas?

Cheers, Jan