North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IX port security

  • From: Greg VILLAIN
  • Date: Sun Feb 24 18:37:35 2008


On Feb 24, 2008, at 4:58 PM, Andy Davidson wrote:
On 23 Feb 2008, at 11:19, Greg VILLAIN wrote:

Thinking back about this thread we've had lately around IXes, I have some extra questions.
It is I assume the IX's responsibility to protect members from harming each other through the peering LAN.

That depends what you mean by protect. Any IX participant must remember that they're sharing an infrastructure with (by and large) competitors, and that there are particular miscreant activities that you as an IX participant must guard against, which your IX operators can't completely protect you from (I'm thinking pointing default, or attacks on port-facing router interfaces.)

I've been thinking a lot about pointing defaults, I admit I think of any solution to avoid that...
Anyone any idea ? (I was initially thinking making a route server mandatory would solve that, but it actually doesn't...)


All of your suggestions are very sane, with this comment

- re 3/ should a certain number of allowed mac-addresses be configured to the port (1 or 2) ? or should the customer's port mac be explicitly configured on the port ?

This is largely down to local policy - one mac one port is sane, but depending on how your exchange has evolved and the services it offers, I can see the case for permitting different macs on different vlans too. Port security violations are normally caused by participants plugging IXes into a switch which ends up running some kind of chatty protocol, and by participants changing l3 interfaces connected to the exchange without informing IX support, rather than loops - but loops do happen, so define a policy and apply it strictly.

Got this idea of a member portal feature, where the IX member can record one or more MACs via the web interfaces. Then a robot can easily clear those on the port, read the new ones, compare to those provided on the web portal, and ultimately lock them.
That would reunite both security and flexibility for the member to change its kit on his end.
(Still, I'd need to log any changes via the portal and limit the amount of changes in a given time for DoS reasons on the platform's switches).
I've seen many ISPs do that with customer CPEs, so they don't change them.


Best wishes
Andy Davidson, www.lonap.net

Greg VILLAIN Independant Network & Telco Architecture Consultant +33 6 87 48 66 14