[c-nsp] Current SP Cloud Security models
Nick Hilliard
nick at foobar.org
Tue Mar 13 09:30:05 EDT 2012
On 13/03/2012 13:16, Joe Freeman wrote:
> That's exactly my argument at the moment, but I thought I'd reach out to
> minds brighter than mine to see if I've missed something somewhere.
Ask them what specific problem they are attempting to solve with 802.1x and
how .1x specifically solves this problem. If they're intent on hanging
themselves with their own policies, I would not hesitate to hand them some
rope.
Nick
> Sent from my iPhone
>
> On Mar 13, 2012, at 9:12 AM, Nick Hilliard <nick at foobar.org> wrote:
>
>> On 13/03/2012 12:59, Joe Freeman wrote:
>>> I'm working on a design for a public cloud offering and the security guys
>>> are screaming that I need to implement network access control (from what
>>> they describe, it's 802.1x) in the underlying network as they claim the
>>> VRF/MPLS/VPLS/vlan model doesn't scale well in a cloud.
>>
>> There are many scaling issues associated with virtualised environments,
>> that's for sure.
>>
>>> That all news to me. I've been doing SP networks for a long time, but have
>>> never heard of a requirement for the SP to maintain 802.1x across the
>>> network, with a master AD/Radius instance controlling access to the network
>>> by customers and hosted servers.
>>
>> Tell your security people that as soon as there are cloud systems which
>> provide L2 environments which support .1x to the client, that you'll
>> certainly look at them. But that in the interim, you have a business to run.
>>
>> As an almost unrelated aside (as this argument seems to be completely
>> political rather than technical in nature), I'm completely failing to
>> understand how .1x is relevant to your virtual network security. Most
>> environments these days support at least some level of mac address spoofing
>> control, which is all you really need. .1x is useful for large campuses
>> and enterprise environments, but it really isn't relevant at all to virtual
>> hosting so far as I can see.
>>
>> Nick
>>
>
More information about the cisco-nsp
mailing list