IX port security

Sun Feb 24 23:12:53 UTC 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