North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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
I've seen many ISPs do that with customer CPEs, so they don't change
Andy Davidson, www.lonap.net
Independant Network & Telco Architecture Consultant
+33 6 87 48 66 14