Interesting new spam technique - getting a lot more popular.

Danny McPherson danny at tcb.net
Mon Jun 19 19:55:23 UTC 2006



On Jun 15, 2006, at 7:06 AM, Kristal, Jeremiah wrote:

> I don't think it was Extreme that filed it, or at least they didn't
> write it.  It was the good folks at Qwest engineering who came up with
> the idea, which was implemented (for some low value of implemented) by
> Extreme.  The authors had moved on by the time the RFC was published,
> but they were certainly Qwesties (and probably CSN before that).

Nope, not at all CSN..

> I
> *think* the same idea was floated to Cisco at the same time; their  
> PVLAN
> was offered in beta not long after Extreme moved super/sub-VLANs into
> public release.

Yep, pointer here, for folks interested in the current state of that
work within the IETF:

http://www.ietf.org/internet-drafts/draft-sanjib-private-vlan-05.txt

> Unfortunately for those of us who had to actually implement said
> abomination, it didn't quite work as well as promised.  In fact I was
> just trying to decide which was more painful, taking over a hosting
> network with 90% of their hosts in one VLAN (VLAN2, they asked for  
> free
> advice when they first started to attempt to migrate), or supporting
> super/sub-VLANs in an operational environment.  Customers hated both,
> but at least they saw better performance once the hosting network was
> broken up per-customer VLANs.

Indeed, as there's a discernible gap there from concept to  
implementation,
implementation to network engineering, beta/EFT, and from network
engineering & beta/EFT  to deployment & operationalizing any such
technology.  If you disregard any of these phases, for whatever reason,
it'll likely to come back to bite you.

> Customers hated it because of some very serious operational flaws.   
> Some
> stuff was to be expected, like seeing broadcast traffic in all subs
> under a super-VLAN.

As with any new technology, some amount of education is often
required when change occurs.  In this case, a reasonable response
would be to first ask if anything was broken as a result, and if not,
then to explain the benefits such a service model provides from
a billing, Internet address conservation and security perspective.
Customers hating something simply because they liked and are no
longer seeing broadcast traffic seems a bit intractable to me.  This
is the perfect example where a small amount of education can go
a long way.

Now, if something is broken, OTOH, that's different.

> Some stuff was truly flawed, like having some small
> percentage of packets leaking across sub-VLANs.

>   Residential customers
> don't mind, and probably would never notice.  Large corporate clients
> who are putting important servers in a hosting environment get rather
> concerned when you start seeing traffic (including cleartext login  
> info)
> from their neighbors on their interfaces.

Indeed, and this is clearly an implementation bug, and potentially,
a security vulnerability, if an attacker could determine how to elicit
such a behavior.

> Trying to convince your vendor that this (and other) flaw exists when
> you're the only client using it in production, and you're pushing
> several orders of magnitude more traffic than their labs, can be
> slightly frustrating.

Again, this is why it's important to be able to clearly articulate
such a problem, and why phases 2 & 3 above are so critical,
and why each new application of such a mechanism requires
revisiting the entire process.

> I personally felt that this was a solution in search of a problem.   
> The
> enterprise hosting division on an RBOC was probably not the best place
> to deploy it.

IIRC, the "enterprise hosting solution of an RBOC" wasn't the
intended initial application, though I do suspect such a solution
would provide considerable advantages in a deployment such as
that - again, assuming it was engineered and operationalized
appropriately.

> The current low-end hosting environment is a problem that fits pretty
> well, but based on my experience in that segment, there is a much  
> bigger
> return on investment in paying a couple of engineers well enough to
> manage your VLAN allocations correctly and use existing (generally
> secondary market) hardware and tools.

While I'm not sure about any of the deployment details beyond the
initial problem set, which falls pretty much squarely within your "that
fits pretty well" category, I would be interested in hearing what your
solution to such a problem is?  Certainly, some amount of engineering
needs to be applied, and customers that justify their own IP subnets
should be handled as such, but in this day and age, I'd hope that
most folks separate customers into different Link layer broadcast
domains, and employ some bit of cognition WRT Internet address
space conversation.

-danny



More information about the NANOG mailing list