Re: IX port security

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

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.

> - more importantly, is there any other standard
precaution that I'm  
> missing and that should be considered ?

Euro-IX are working on a bcp of exchange recommendations,
including  
this point.  Perhaps we should have a conversation offlist
about these  
topics, and perhaps I can introduce you to the euro-ix
members working  
on the document.

Best wishes
Andy Davidson, www.lonap.net

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