[c-nsp] PPPoE client answers PADI?

[Andre Beck]

Re,

On Wed, Jun 29, 2005 at 09:02:58AM -0400, Robert E.Seastrom wrote:
> Andre Beck <cisco-nsp at ibh.net> writes:
> 
> > now try to stay vertical: The box that answered the PADI with a PADO
> > wasn't some rogue PPPoE server deployed by evil persons but actually
> > one of our own deployed Cisco 831 PPPoE clients!
> 
> While that's clearly misbehavior on the part of the 831 and something
> that you should take up with Cisco, it's also something you should
> take up with your wireless equipment vendor; hostile customers should
> be considered a likely, as opposed to an unlikely, eventuality.

In the given network, hostile customers are less likely as we force
the customers to have CPEs under our control. Of course that still
constitutes a problem, as the really bad customer can disconnect
the CPE and do evil things anyway, but it isn't as hostile an
environment as one where every customer is supposed to access with
the hardware and PPPoE software of his choice. Anyway, PPPoE borders
are active or at least planned in large parts of the network. The
reason for this particular failure was that both the new box trying
to get a PPPoE session as well as the established box that illegally
answered the PADIs are connected to a common switch at a remote
location.

The 831 in question ceased to answer PADIs after an upgrade to newer
IOS, so yes this was a Cisco problem and it seems fixed. Just bad there
is nothing about it in Bug Toolkit, would have made things a lot easier
to track down.
 
> I'm continually depressed with the feature set I find on wireless
> equipment, and haven't been too happy with the "big picture" clue
> level I've found among the software developers (no, I'm not going to
> name names here).  It seems that the model for a lot of them has
> evolved from roots of "outdoor 802.11 deployment", and that
> requirements such as "PADI can only go from customer unit to AP and
> PADO vice-versa" are met with blank stares, or more humorously, I'm
> told that it would be "too difficult" or "too much of a performance
> hit" to implement such a feature.  Please!  Discovery frames have a
> different ether type (0x8863) than session frames (0x8864), so 99.99%
> of packets don't have to be looked at beyond the ether_type.  Probably
> a dozen lines of code to implement, and you don't even really have to
> include a facility for turning it off.  Of course, their spec sheet
> says that their equipment "supports RFC-2516 - PPPoE", but I'm not
> sure what that's supposed to mean aside from the fact that the packets
> go through.

You would expect that of a bridge anyway, so naming it is likely
sally rubbish. From those guys who write colorful product "data
sheets" to those who can't make decisions without such checklists.
Probably a result of multiple choice exams ;)

> And don't even get me started on priority queueing
> schemes that break if the encapsulation is PPPoE rather than ARPA,
> because someone was too lazy to check the ether_type and add a fixed
> offset to where it expects the start of the IP header to live before
> it does its classification.

Well, that isn't really just laziness. There is no fixed offset, as PPP
can come in various ways (with or without AC/PC, with or without MP)
and even can become completely opaque (CCP). PPPoE might rule out the
AC/PC case, but MP and CCP still can apply, making it hard to do this
in hardware or even to do it at all. Preclassification prior to
encapsulation and mapping to a set of Ethernet CoS might help that,
but of course this is again going to fail in hostile environments of
the do-it-yourself kind. Might work with controlled CPEs, though.
 
> And then there are shitty DHCP clients

Or rogue DHCP servers that are real fun.

> and ethernet chips that are
> only capable of 10 meg HDX and can't do 802.1q (um, HELLO, it is 2005,
> in what antique store did you find the spec sheet for this chip when
> you were designing this unit last year?), but that's a rant for
> another day.

Live in the networking business gives you and endless supply of sources
for rants, at least something...
 
> Beat up your wireless vendor.  :)

Thank <insert Superior Beeing here> we are responsible for L3+ in this
network and L2- is not really our problem (it turns out to become our
problem more than often, but formally it's not our business). The problem
is well known and partially under control, but details are always more
hairy.

Thanks,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-