[102684] in North American Network Operators' Group
Re: IX port security
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Sun Feb 24 20:14:28 2008
Cc: "Patrick W. Gilmore" <patrick@ianai.net>
From: "Patrick W. Gilmore" <patrick@ianai.net>
To: nanog list <nanog@nanog.org>
In-Reply-To: <9AF243BB-8AC8-491F-B0CD-91B0D0BB87D4@grrrrreg.net>
Date: Sun, 24 Feb 2008 19:34:04 -0500
Errors-To: owner-nanog@merit.edu
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
