BEREC Net Neutrality Guidelines: good news for security

BEREC, the board of European Telecoms Regulators, has just published its updated guidance on enforcing the Network Neutrality Regulation. Jisc has been working with the Forum of Incident Response and Security Teams (FIRST) for nearly five years to ensure that this legislation and guidance didn’t discourage legitimate practices to secure the operation of networks: this new version suggests our advice has been heard and taken.

Article 3(3) of the Regulation permits “blocking, slowing down, altering, restricting, interfering with, degrading or discriminating” only in three specific circumstances, one of which (covered in Article 3(3)(b) is where this is necessary to “preserve the integrity and security of the network, of services provided by that network, and of the terminal equipment of end-users”.

The new guidance (para 83) identifies “typical attacks and threats that will trigger integrity and security measures”:

  • flooding network components or terminal equipment with traffic to destabilise them (e.g. Denial of Service attack);
  • spoofing IP addresses in order to mimic network devices or allow for unauthorised communication;
  • hacking attacks against network components or terminal equipment;
  • distribution of malicious software, viruses etc.

Paragraph 84 lists “typical examples of … traffic management measures”:

  • blocking of IP addresses, or ranges of them, because they are well-known sources of attacks;
  • blocking of IP addresses from which an actual attack is originating;
  • blocking of IP addresses/IAS showing suspicious behaviour (e.g. unauthorised communication with network components, address spoofing);
  • blocking of IP addresses where there are clear indications that they are part of a bot network;
  • blocking of specific port numbers which constitute a threat to security and integrity.

Paragraphs 85 and 86 note that the need to enable for such measures might be identified by the network’s own monitoring, or by reports/complaints from end-users or blocking lists from recognised security organisations.

And, as discussed in the earlier post on the consultation paper, paragraph 85 also explains why permanently configured blocks, such as for BCP-38 spoofing, do not contravene the Regulation’s “only when needed” requirement, as the block only takes effect when an offending packet is seen.

Although the Regulation doesn’t apply to Janet and private networks within our customers, it’s good to have such explicit confirmation of our security practices. If other networks follow them, then there should be less hostile traffic for us all to deal with.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published. Required fields are marked *