Hi all, 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. For that purpose, the IX has to do some minimum sanity checks before letting a member in into the production VLAN, for instance by using a quarantine VLAN to probe its traffic first. Then, once those checks are done, the IX shall apply a minimum security configuration to each member port: 1/ limiting broadcast/unknown unicast on each member port 2/ filtering bpdu 3/ locking mac addresses Here are my questions: - re 1/, any clue about the PPS or %bandwidth values to be configured to limit broadcast/unknown unicast ? - 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 ? - more importantly, is there any other standard precaution that I'm missing and that should be considered ? cheers, Greg VILLAIN Independant Network/Telco Architecture Consultant
Here are my questions: - re 1/, any clue about the PPS or %bandwidth values to be configured to limit broadcast/unknown unicast ? - 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 ? - more importantly, is there any other standard precaution that I'm missing and that should be considered ?
You might want to have a look at the DE-CIX technical requirements, http://www.de-cix.net/info/DE-CIX_technical_requirements.pdf Even though I disagree with a few of the points (e.g. turning off autoneg for GigE), on the whole I think the requirements make a lot of sense. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
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 24.02.2008 16:58 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.)
both is imho not inherent to an IXP environment but may also happen on private peerings. Best regards, Arnold -- Arnold Nipper, AN45
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
On Feb 24, 2008, at 6:12 PM, Greg VILLAIN wrote:
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...)
There are many. At the last NANOG peering BoF, a solution was presented by cisco, others were discussed, and we compared / contrasted other vendors' solutions as well. But hey, who wants a peering BoF any more....
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.
Some IXes already do this. Look at TorIX. -- TTFN, patrick
participants (5)
-
Andy Davidson -
Arnold Nipper -
Greg VILLAIN -
Patrick W. Gilmore -
sthaug＠nethelp.no