North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Interesting new spam technique - getting a lot more popular.

  • From: Danny McPherson
  • Date: Mon Jun 19 15:56:38 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