🚀 go-pugleaf

This is a multi-part message in MIME format.
--------------78ECDBC3B05803D57A79AF24
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

But how do you run DHCP except in an environment where the DHCP discovers can
propogate?  i.e. an environment where broadcasts can propogate.  Does the Redback
intercept these the same as the ARPs [question for me]?  Maybe what you are saying is
the Redback implementation solves most of the problems of bridging.
It still seems like a customer can steal IPs and wreak havoc if he can alter the IP
assigned under the mask.  Would the redback protect against this, i.e. does it verify
the customer is using his assigned IP?  I wouldn't think so, especially if he didn't
assign it [another question for me].
But you are still stuck with authentication via MAC, right.  So it then gets down to
the ISP who wants to do things like it is used to doing, like username/password and
Radius servers, and this means ppp to them.  Redback solved this problem for the ISPs
as well by doing the ppp over the E!   oh well...

Since pppoE only runs on a  customer's individual PVC, I can't see that its a security
problem for the network. The customer will control the access to the PVC, which he does
in any implementation.

John

James Carlson wrote:

> "Randy S." <rswitt@ufl.edu> writes:
> > Damn, John, you put that really well!   Yes, from what I understand, when you
> > scale up DHCP REALLY large you run into problems.  ARP broadcasts can become a
> > significant portion of your bandwidth, and one rogue ARP storm can take everybody
> > down.
>
> Stop bridging among customer links and the problem goes away.  What
> you're describing is a network design and implementation problem, not
> a protocol problem or even a distinction between PPPoE and DHCP.
>
> >  We had several instances of poorly designed 3rd party routers repeatedly
> > sending out DHCP requests causing all sorts of havoc.  The installation of secure
> > ARP helped fix much of this, but apparently DHCP doesn't work nearly as well on a
> > HUGE flat LAN structure (which is what DSL looks like I believe), as it does on a
> > more moderately sized one.
>
> If you're using PPPoE on a bridged LAN, you're in deep trouble.  PPPoE
> has no security it all -- read RFC 2516.  It's trivial to spoof
> messages.
>
> --
> James Carlson, Internet Engineering       <james.d.carlson@east.sun.com>
> SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp





--------------78ECDBC3B05803D57A79AF24
Content-Type: text/x-vcard; charset=us-ascii;
 name="loop.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John D Loop
Content-Disposition: attachment;
 filename="loop.vcf"

begin:vcard 
n:Loop;John 
tel;pager:jloop@bellsouthips.com
tel;fax:404 872 5329
tel;work:404 332 2232
x-mozilla-html:FALSE
org:BellSouth Telecom;Science and Technology
version:2.1
email;internet:loop@snt.bellsouth.com
title:Member Tech Staff
adr;quoted-printable:;;Room 40U95=0D=0A675 West Peachtree St=0D=0AAtlanta, GA 30375;;;;
x-mozilla-cpt:;27024
end:vcard

--------------78ECDBC3B05803D57A79AF24--