🚀 go-pugleaf

John D Loop <loop@snt.bst.bls.com> writes:
> Reading your new book on ppp.  Great stuff!

Thanks!

>  I read with interest your 1
> page "slam" on pppoE and wondered if you had any more recent thots on
> it.  It seems like we are stuck with it out here in ADSL land as a
> defacto standard, for better or worse.

It doesn't have to be that way.  DHCP works just fine.

> All SOHO routers pretty much do
> it now, along with pppoA.

PPP over AAL5 ("PPPoA") is a different thing.  That's a standards-
track protocol.  PPPoE is "informational," which essentially means
that it's unreviewed and proprietary.

>  And the consumers have to add pppoE clients
> to their PC if they don't have a SOHO routers - this can get dicey
> sometimes.  I can understand why it was invented [existing ppp
> infrastructures & existing ethernet LAN environments], and I can even
> see some advantages  [multiple sessions and multiple service selection].

I don't think I see the same advantages.

> The biggest problem I see is the smaller MTU breaking some connections
> when intervening routers don't allow MTU path discovery to work
> [assuming it is turned on].

Yes, that's at least one problem.  More subtly, PPPoE also breaks the
RFC 1661 default MTU.

What's worse, PPPoE's session ID assignment mechanism is badly
designed.  It assigns a single ID from the 'server' side only.
Properly designed tunneling protocols assign IDs from both sides; that
is, the client issues an ID number to the server for data inbound to
the client, and the server issues a separate ID number to the client
for data outbound from the client.  Because PPPoE doesn't do this, an
individual system that has multiple PPPoE client sessions running has
no guarantee that the assigned ID numbers don't conflict, and thus
must demultiplex on both the ID number and the MAC address of the
server.

And don't get me started on the HURL and MOTM extensions ...

-- 
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

"James Carlson" <james.d.carlson@sun.com> wrote in message
news:xoav8znc3q4u.fsf@sun.com...

<snip>

> More subtly, PPPoE also breaks the
> RFC 1661 default MTU.

> What's worse, PPPoE's session ID assignment mechanism is badly
> designed.  It assigns a single ID from the 'server' side only.
> Properly designed tunneling protocols assign IDs from both sides; that
> is, the client issues an ID number to the server for data inbound to
> the client, and the server issues a separate ID number to the client
> for data outbound from the client. Because PPPoE doesn't do this, an
> individual system that has multiple PPPoE client sessions running has
> no guarantee that the assigned ID numbers don't conflict, and thus
> must demultiplex on both the ID number and the MAC address of the
> server.

Most interesting. Allow me to take note of these details. I am going to have
to pick up a copy of your book for my own added knowledge. You certainly
appear well qualified on these matters. Thank you for the info. It is
well-appreciated.

What troubles me though, is with all the misgivings I hear (there have been
plenty abroad, TechTV included) about the PPPoE configuration as less
stable, etc. than the other packages and yet, for my own personal situation,
the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
simply woefully unreliable service situations I had in the past compared to
the virtually perfect service I have now.

Moreover, it was in fact the upper management rankings of BSFA (Bellsouth
Fast Access) that confidently prescribed my switch with assurance that this
would remedy my connections woes; my, how they were right! They all had
attached details as to what was the likely problem and as to just how this
would be the proper fix, at least per my given, specific area. [Fort
Lauderdale, Florida.]

Any idea as to why the infamous PPPoE configuration has proved for some
anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
Again, I'll have to gather up your publication per my own detailed
understanding here. Now, yes, I am certainly satisfied with my highly
dependable service I enjoy, yet, with my compassion for others here that are
not so fortunate, I would greatly like to advance my knowledge of this facet
toward learning just how my switch played such a roll and how I might assist
those others in my specific area, respectfully.

Once again, thanks for the insight.

Genuinely,

Christopher Jones

"Christopher Jones" <c2jones@bellsouth.net> writes:
> What troubles me though, is with all the misgivings I hear (there have been
> plenty abroad, TechTV included) about the PPPoE configuration as less
> stable, etc. than the other packages and yet, for my own personal situation,
> the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> simply woefully unreliable service situations I had in the past compared to
> the virtually perfect service I have now.

Implementation and protocol design are not the same thing.  It's
certainly possible to do competent implementations of lousy protocols
as well as incompetent implementations of better protocols.

I was commenting only on the design of PPPoE itself, not any
particular implementation.

> Any idea as to why the infamous PPPoE configuration has proved for some
> anyway, as the lifesaver for certain areas? Perhaps your book outlines this?

As above, I wasn't commenting on any particular implementation.  The
design of PPPoE is bad in many respects.  That doesn't mean that
replacing bug-ridden PPPoA servers with better-built PPPoE servers
wouldn't be a net gain for the average user.

-- 
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

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

Thanks for your comments, James.
You would probably get an argument about DHCP and bridging in a WAN
environment.  I believe almost all the ADSL providers started off that way
(including BellSouth), but they got away from it as fast as they could.  DHCP
works well, as long as you are in a trusted environment.  Stolen IPs,
broadcast traffic, rogue DHCP servers, using MAC address as "authentication"
proved very troublesome.  The Redbacks (which BellSouth [and the rest of the
known universe] switched to) were added by the providers who would do almost
anything to go to a more familiar PPP implementation (!), where authentication
is via username/password, traffic isolated to the ppp connection, nobody can
steal IPs.  In short, it "looks" like dialup.
In fact BellSouth still has a small group of original bridged customers, who
"lord it over the rest of us" because they don't have the pppoX drivers and
that complexity to deal with [software on top of Windoze] which has lent a
"certain amount of instability" into the ADSL picture.  So there has been a
tradeoff so far.
They (Redback) had to invent a ppp-like implementation over ethernet to pull
this off for all the ethernet NICs and ethernet bridging modems out there.
They also added the internal modems running pppoA but people still need the
Ethernet interface, for varied valid reasons.  BellSouth doesn't control the
CPE, like some providers, but it does complicate the service.
I understand your concerns about pppoE, especially that it is a proprietary
non standards track implementation, but I think the ADSL providers had little
choice [other than to go away].  The Telcos have always been big proponents of
standards [they want all this equipment to interoperate..], but market forces
forced their hand.
Also, I believe since the pppoE runs on a customer-specific PVC, the potential
for the abuse is less.
John
Still trying to learn ppp, and now l2tp.  Grief. I thot I had it under control
when I learned IP!
...I don't think I want to know about HURL and MOTM....

James Carlson wrote:

> John D Loop <loop@snt.bst.bls.com> writes:
> > Reading your new book on ppp.  Great stuff!
>
> Thanks!
>
> >  I read with interest your 1
> > page "slam" on pppoE and wondered if you had any more recent thots on
> > it.  It seems like we are stuck with it out here in ADSL land as a
> > defacto standard, for better or worse.
>
> It doesn't have to be that way.  DHCP works just fine.
>
> > All SOHO routers pretty much do
> > it now, along with pppoA.
>
> PPP over AAL5 ("PPPoA") is a different thing.  That's a standards-
> track protocol.  PPPoE is "informational," which essentially means
> that it's unreviewed and proprietary.
>
> >  And the consumers have to add pppoE clients
> > to their PC if they don't have a SOHO routers - this can get dicey
> > sometimes.  I can understand why it was invented [existing ppp
> > infrastructures & existing ethernet LAN environments], and I can even
> > see some advantages  [multiple sessions and multiple service selection].
>
> I don't think I see the same advantages.
>
> > The biggest problem I see is the smaller MTU breaking some connections
> > when intervening routers don't allow MTU path discovery to work
> > [assuming it is turned on].
>
> Yes, that's at least one problem.  More subtly, PPPoE also breaks the
> RFC 1661 default MTU.
>
> What's worse, PPPoE's session ID assignment mechanism is badly
> designed.  It assigns a single ID from the 'server' side only.
> Properly designed tunneling protocols assign IDs from both sides; that
> is, the client issues an ID number to the server for data inbound to
> the client, and the server issues a separate ID number to the client
> for data outbound from the client.  Because PPPoE doesn't do this, an
> individual system that has multiple PPPoE client sessions running has
> no guarantee that the assigned ID numbers don't conflict, and thus
> must demultiplex on both the ID number and the MAC address of the
> server.
>
> And don't get me started on the HURL and MOTM extensions ...
>
> --
> 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

--
Question posed to Arthur C. Clarke:
How do you keep up with the new advances?
"I don't, of course - who can? And it makes me sorry.  I can't read fiction
anymore, I just don't have time for it.  The entire time is spent e-mailing!"


--------------EA61CE4760BB99F7A08C5FF8
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

--------------EA61CE4760BB99F7A08C5FF8--

John D Loop wrote:

> Thanks for your comments, James.
> You would probably get an argument about DHCP and bridging in a WAN
> environment.  I believe almost all the ADSL providers started off that way
> (including BellSouth), but they got away from it as fast as they could.  DHCP
> works well, as long as you are in a trusted environment.  Stolen IPs,
> broadcast traffic, rogue DHCP servers, using MAC address as "authentication"
> proved very troublesome.  The Redbacks (which BellSouth [and the rest of the
> known universe] switched to) were added by the providers who would do almost
> anything to go to a more familiar PPP implementation (!), where authentication
> is via username/password, traffic isolated to the ppp connection, nobody can
> steal IPs.  In short, it "looks" like dialup.
> In fact BellSouth still has a small group of original bridged customers, who
> "lord it over the rest of us" because they don't have the pppoX drivers and
> that complexity to deal with [software on top of Windoze] which has lent a
> "certain amount of instability" into the ADSL picture.  So there has been a
> tradeoff so far.
> They (Redback) had to invent a ppp-like implementation over ethernet to pull
> this off for all the ethernet NICs and ethernet bridging modems out there.
> They also added the internal modems running pppoA but people still need the
> Ethernet interface, for varied valid reasons.  BellSouth doesn't control the
> CPE, like some providers, but it does complicate the service.
> I understand your concerns about pppoE, especially that it is a proprietary
> non standards track implementation, but I think the ADSL providers had little
> choice [other than to go away].  The Telcos have always been big proponents of
> standards [they want all this equipment to interoperate..], but market forces
> forced their hand.
> Also, I believe since the pppoE runs on a customer-specific PVC, the potential
> for the abuse is less.
> John
> Still trying to learn ppp, and now l2tp.  Grief. I thot I had it under control
> when I learned IP!
> ...I don't think I want to know about HURL and MOTM....
>

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.  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.  PPPoE helps address some of these issues.  I believe
PPPoA does as well, though apparently PPPoE supports some features that PPPoA does
not, something along the line of being able to run seperate PPPoE sessions to
seperate providers simultaneously.  Of course this is not to say that PPPoE is the
solution to everything, I think the problem is that DHCP really just won't cut it
in these large-scale applications and they needed something to replace it.  PPPoE
was available, and it interfaced nicely with existing authentication software and
hardware.

Randy S.

John D Loop <loop@snt.bst.bls.com> writes:
> Thanks for your comments, James.
> You would probably get an argument about DHCP and bridging in a WAN
> environment.  I believe almost all the ADSL providers started off that way
> (including BellSouth), but they got away from it as fast as they could.  DHCP
> works well, as long as you are in a trusted environment.  Stolen IPs,
> broadcast traffic, rogue DHCP servers, using MAC address as "authentication"
> proved very troublesome.

PPPoE has absolutely no security whatsoever.  It's in worse shape than
DHCP, since at least with DHCP, there's ongoing effort to add
security.

>  The Redbacks (which BellSouth [and the rest of the
> known universe] switched to) were added by the providers who would do almost
> anything to go to a more familiar PPP implementation (!), where authentication
> is via username/password, traffic isolated to the ppp connection, nobody can
> steal IPs.  In short, it "looks" like dialup.

Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
use these forged packets to highjack user sessions or snipe them out
of existence as long as you have bridging at the Ethernet layer.

Security through obscurity is no security at all.

> They (Redback) had to invent a ppp-like implementation over ethernet to pull
> this off for all the ethernet NICs and ethernet bridging modems out there.

I strongly disagree.  It wasn't necessary at all.  Treat each ADSL
link as a separate Ethernet segment, and you're in business.  There's
no reason on earth to be bridging among separate ADSL links

I think you're confusing implementation with protocol design.

> I understand your concerns about pppoE, especially that it is a proprietary
> non standards track implementation, but I think the ADSL providers had little
> choice [other than to go away].  The Telcos have always been big proponents of
> standards [they want all this equipment to interoperate..], but market forces
> forced their hand.
> Also, I believe since the pppoE runs on a customer-specific PVC, the potential
> for the abuse is less.

If you can do that with PPPoE, you can do it with DHCP.

> Still trying to learn ppp, and now l2tp.  Grief. I thot I had it under control
> when I learned IP!
> ...I don't think I want to know about HURL and MOTM....

OK; I won't tell you.

-- 
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

"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

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--

"James Carlson" <james.d.carlson@sun.com> wrote in message
news:xoavvgqeg4n9.fsf@sun.com...

> The design of PPPoE is bad in many respects. That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.

Hmm. Well this may very well be the situation with the specific per my area.
At leas it makes as much (and more) sense than any previously acquired
explanations toward this regard. Knowing for sure is the real question,
then. Might the technical parties that dealt with me have been aware of the
"incompetent," or "bug-ridden PPPoA servers" per my area and therefore,
recommended the "better-built PPPoE servers" toward a fix for the
connectivity woes suffered? Most likely.

Perhaps the bottom-line factor here is just what you have suggested. It is
"possible to do competent implementations of lousy protocols as well as
incompetent implementations of better protocols." I may have witnessed
direct evidence of this. Just how I can use this for the aid of others
though, remains uncertain.

How would I know just which areas have competent implementations and which
do not?

Thanks again.

On Tue, 13 Feb 2001 13:22:36 -0500, Christopher Jones
<c2jones@bellsouth.net> wrote:
>
>Hmm. Well this may very well be the situation with the specific per my
>area. At leas it makes as much (and more) sense than any previously
>acquired explanations toward this regard. Knowing for sure is the real
>question, then. Might the technical parties that dealt with me have
>been aware of the "incompetent," or "bug-ridden PPPoA servers" per my
>area and therefore, recommended the "better-built PPPoE servers" toward
>a fix for the connectivity woes suffered? Most likely.

I believe oE and oA are running off the same server. Some areas (BSIS)
may have multiple servers, but each server handles both oE/oA. If you
switch from one to the other protocol, you are not changing servers
AFAIK.

-- 
Hal B
 hal@foobox.net
 hal@burgiss.net
 hburgiss@bellsouth.net
--

James Carlson <james.d.carlson@sun.com> wrote:
> John D Loop <loop@snt.bst.bls.com> writes:
>> Thanks for your comments, James.
>> You would probably get an argument about DHCP and bridging in a WAN
>> environment.  I believe almost all the ADSL providers started off that way
>> (including BellSouth), but they got away from it as fast as they could.  DHCP
>> works well, as long as you are in a trusted environment.  Stolen IPs,
>> broadcast traffic, rogue DHCP servers, using MAC address as "authentication"
>> proved very troublesome.

> PPPoE has absolutely no security whatsoever.  It's in worse shape than
> DHCP, since at least with DHCP, there's ongoing effort to add
> security.

>>  The Redbacks (which BellSouth [and the rest of the
>> known universe] switched to) were added by the providers who would do almost
>> anything to go to a more familiar PPP implementation (!), where authentication
>> is via username/password, traffic isolated to the ppp connection, nobody can
>> steal IPs.  In short, it "looks" like dialup.

> Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
> use these forged packets to highjack user sessions or snipe them out
> of existence as long as you have bridging at the Ethernet layer.

For what it's worth, I've been experimenting with PPPoE encrypted sessions
(using home-brewed extensions to the Roaring Penguin implementation) and
it works a treat.  Anyone fancy a 128-bit cypher on *all* their traffic?
With a few trivial extensions to the rfc2516 I believe it would be possible
to offer a highly-secure service, without sniffing, interception, or DoS
concerns.

cheers, josh.

josh.howlett@bris.ac.uk


 

"Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
news:G8prup.GCw@bath.ac.uk...
| James Carlson <james.d.carlson@sun.com> wrote:
| > John D Loop <loop@snt.bst.bls.com> writes:
| >> Thanks for your comments, James.
| >> You would probably get an argument about DHCP and bridging in a WAN
| >> environment.  I believe almost all the ADSL providers started off that way
| >> (including BellSouth), but they got away from it as fast as they could.  DHCP
| >> works well, as long as you are in a trusted environment.  Stolen IPs,
| >> broadcast traffic, rogue DHCP servers, using MAC address as "authentication"
| >> proved very troublesome.
|
| > PPPoE has absolutely no security whatsoever.  It's in worse shape than
| > DHCP, since at least with DHCP, there's ongoing effort to add
| > security.
|
| >>  The Redbacks (which BellSouth [and the rest of the
| >> known universe] switched to) were added by the providers who would do almost
| >> anything to go to a more familiar PPP implementation (!), where authentication
| >> is via username/password, traffic isolated to the ppp connection, nobody can
| >> steal IPs.  In short, it "looks" like dialup.
|
| > Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
| > use these forged packets to highjack user sessions or snipe them out
| > of existence as long as you have bridging at the Ethernet layer.
|
| For what it's worth, I've been experimenting with PPPoE encrypted sessions
| (using home-brewed extensions to the Roaring Penguin implementation) and
| it works a treat.  Anyone fancy a 128-bit cypher on *all* their traffic?
| With a few trivial extensions to the rfc2516 I believe it would be possible
| to offer a highly-secure service, without sniffing, interception, or DoS
| concerns.
|
| cheers, josh.
|
| josh.howlett@bris.ac.uk
|
|

I'm curious, I haven't installed myself yet, but at the Windows Update site their is an
option to install 128 bit on DUN.

Is this the same?

Michael
_____________

Ooh...ooh...I get to beat James to one.  :)

Thus spake John D Loop
>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]?

Yeah, its called DHCP relay...works like a champ.

>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.

Nope, they can't...it really and truly does work with RedBack.  I'm
doing it.

>Would the redback protect against this, i.e.  does it verify the
>customer is using his assigned IP?  

It doesn't verify explicitely that I'm aware of, but it knows (either
from RADIUS, DHCP, static config, and probably other options that I'm
not thinking of off the top of my head) what IP addresses are on what
"circuits" (RedBack terminology for a PVC or other type of "session")
and will only send arps for that IP address down that "circuit" so only
that customer can respond to the arp request.

>I wouldn't think so, especially if he didn't assign it [another
>question for me].  

It can learn the assignment by participating in the DHCP relay, or by a
RADIUS request when the PVC comes up, static config, etc.

>But you are still stuck with authentication via MAC, right.

Nope, I can see what MAC someone has on their ethernet card in the arp
cache, but I never look at that because I have no need to.  It learns
the IP <-> circuit mapping via RADIUS, DHCP, static config, etc.

>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.

Nope, please don't make the mistake of assuming that RADIUS and PPP are
in any way inherently linked.  They are commonly used together, but
there is no reason that this is required.  RedBack AOS can create RADIUS
requests based on a PVC switching from down to up.  This can be used
with a RADIUS server to auto-configure PVCs for customers.

>Redback solved this problem for the ISPs as well by doing the ppp over
>the E! oh well...

I agree with James...PPPoE sucks and I won't touch it with a 39 1/2 foot
pole.  I think he's done a rather competent job of explaining why.
-- 
Jeff McAdams                            Email: jeffm@iglou.com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Yes, Jeff
Beating James to an answer seems to be quite a feat in here...
(comp.protocols.ppp)  
Ah yes, DHCP relay, now I remember, should have remembered that. 
And you have helped clarify quite a few things... 
But why are all the providers (almost all) implementing this stuff? 
I don't get it.  Can you splain this?   
Quick, before James gets back..
John


Jeff Mcadams wrote:
> 
> Ooh...ooh...I get to beat James to one.  :)
> 
> Thus spake John D Loop
> >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]?
> 
> Yeah, its called DHCP relay...works like a champ.
> 
> >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.
> 
> Nope, they can't...it really and truly does work with RedBack.  I'm
> doing it.
> 
> >Would the redback protect against this, i.e.  does it verify the
> >customer is using his assigned IP?
> 
> It doesn't verify explicitely that I'm aware of, but it knows (either
> from RADIUS, DHCP, static config, and probably other options that I'm
> not thinking of off the top of my head) what IP addresses are on what
> "circuits" (RedBack terminology for a PVC or other type of "session")
> and will only send arps for that IP address down that "circuit" so only
> that customer can respond to the arp request.
> 
> >I wouldn't think so, especially if he didn't assign it [another
> >question for me].
> 
> It can learn the assignment by participating in the DHCP relay, or by a
> RADIUS request when the PVC comes up, static config, etc.
> 
> >But you are still stuck with authentication via MAC, right.
> 
> Nope, I can see what MAC someone has on their ethernet card in the arp
> cache, but I never look at that because I have no need to.  It learns
> the IP <-> circuit mapping via RADIUS, DHCP, static config, etc.
> 
> >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.
> 
> Nope, please don't make the mistake of assuming that RADIUS and PPP are
> in any way inherently linked.  They are commonly used together, but
> there is no reason that this is required.  RedBack AOS can create RADIUS
> requests based on a PVC switching from down to up.  This can be used
> with a RADIUS server to auto-configure PVCs for customers.
> 
> >Redback solved this problem for the ISPs as well by doing the ppp over
> >the E! oh well...
> 
> I agree with James...PPPoE sucks and I won't touch it with a 39 1/2 foot
> pole.  I think he's done a rather competent job of explaining why.
> --
> Jeff McAdams                            Email: jeffm@iglou.com
> Head Network Administrator              Voice: (502) 966-3848
> IgLou Internet Services                        (800) 436-4456

I am interested ... What is the title of James Carlson 's book
is it available @ Barnes & Noble ?

John D Loop wrote:
> 
> James Carlson,
> Reading your new book on ppp.  Great stuff!  I read with interest your 1
> page "slam" on pppoE and wondered if you had any more recent thots on
> it.  It seems like we are stuck with it out here in ADSL land as a
> defacto standard, for better or worse. All SOHO routers pretty much do
> it now, along with pppoA.  And the consumers have to add pppoE clients
> to their PC if they don't have a SOHO routers - this can get dicey
> sometimes.  I can understand why it was invented [existing ppp
> infrastructures & existing ethernet LAN environments], and I can even
> see some advantages  [multiple sessions and multiple service selection].
> 
> The biggest problem I see is the smaller MTU breaking some connections
> when intervening routers don't allow MTU path discovery to work
> [assuming it is turned on].
> John

John Loop wrote:

> Yes, Jeff
> Beating James to an answer seems to be quite a feat in here...
> (comp.protocols.ppp)
> Ah yes, DHCP relay, now I remember, should have remembered that.
> And you have helped clarify quite a few things...
> But why are all the providers (almost all) implementing this stuff?
> I don't get it.  Can you splain this?
> Quick, before James gets back..
> John
>

I'm with you John.  All the previous explanations seem to make sense, I
personally had no idea that the Redbacks could isolate and automatically
authenticate DHCP broadcasts quite so well.  But in that case, why PPPoE at
all?  As it was explained to me, most of the reasons for PPPoE were just what
you explained DHCP can do in conjunction with the Redbacks.  There must be
SOME type of motive here.  I can't believe they'd do it JUST to make things a
pain in the ass for their customers ;-).

Randy S.

fivie wrote:

> I am interested ... What is the title of James Carlson 's book
> is it available @ Barnes & Noble ?

I can answer that one:

http://shop.barnesandnoble.com/booksearch/results.asp?WRD=PPP+Design&userid=4R7PW2EQAM

Randy S.

Thus spake John Loop
>Beating James to an answer seems to be quite a feat in here...
>(comp.protocols.ppp)

I think I've beaten him once or twice before.  But then again, I've
beaten him and then have him correct me, so I don't know how important
being quick is.  :)

>Ah yes, DHCP relay, now I remember, should have remembered that.  And
>you have helped clarify quite a few things...

Glad to help.  :)

>But why are all the providers (almost all) implementing this stuff?  I
>don't get it.  Can you splain this?

Uhm...'cause they're dumb?  No...about the only benefit that I can think
of for PPPoE that isn't available via the DHCP stuff in the RedBack is
to do any sort of multiplex'ing, or any sort of dynamic service
selection.  Now, I'll say these are dubious wins for PPPoE, and based on
the number of providers that I've seen actually *using* these
capabilities (lemme count....uhm...none, though I suspect there are a
few out there), I'm not sure they justify the cruftyness that is PPPoE.
Particularly, when, at least in theory, though maybe not yet in
implementation, much of the same could be done with some other,
standards track, and better thought out, tunneling protocol (L2TP, PPTP,
and IPSec all could be used to provide similar types of functionality,
and all three...well...at least two...are better thought out and more
robust in design, I'm not saying they're great, but they're better)

>Quick, before James gets back..

*looks over shoulder*  I think I made it.  :)
-- 
Jeff McAdams                            Email: jeffm@iglou.com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

John Loop wrote:
>
> But why are all the providers (almost all) implementing this stuff?
> I don't get it.  Can you splain this?


It's called marketing, and the {A}DSL providers bought it,
hook, line, and sinker.

Many advantages of PPPoE are a marketing illusion.  Much of which
can be implemented with technically better alternatives.
Multiple sessions?  Allocate another IP address.  Multiple
service providers?  Associate IPs with a service provider.
Perhaps use virtual LAN concepts, one per provider.  Username
and password authentication?  Silly.  When was the last time a
password was required before using residential telephone service?


From this users point of view, PPPoE is a real nuisance.

It emulates dial-up service in this day and age when internet
service should be always on.
"Now you can have an always-on ADSL service that can mysteriously
disconnect.  And will disconnect if you reboot your computer."

It requires custom software for Windows PCs, and unusual work
arounds for professionals with UNIX, Linux, Solaris, Beos, MacOS,

It can potentially create obscure, and difficult to troubleshoot
problems due to protocol design deficiencies.

What is the password?  Why is it necessary?


At least there exist competing cable-tv internet service
providers who can provide the more desirable, unaltered
ethernet connectivity.  As for some of the ADSL providers out
there, still too little (and it's PPPoE), too late, and for
too many dollars.  Competition is a good thing.

(Gee, I hope my rantings can make a difference)
Just another author's opinion. . .

-- 
"Using & Managing PPP," http://www.oreilly.com/catalog/umppp

Thus spake Andrew Sun
>It's called marketing, and the {A}DSL providers bought it, hook, line,
>and sinker.

Bingo.

>Many advantages of PPPoE are a marketing illusion.  Much of which can
>be implemented with technically better alternatives.  Multiple
>sessions?  Allocate another IP address.  

Or use a different tunneling protocol.

>From this users point of view, PPPoE is a real nuisance.

>It emulates dial-up service in this day and age when internet service
>should be always on.

Heh...you want the ultimate user nuisance experience provided by a LEC?
Check out Cincinnati Bell's Zoomtown DSL service.  Good grief.  If
you've experienced this abomination, then this is enough said...if you
haven't...be glad you're only dealing with PPPoE crap.

>At least there exist competing cable-tv internet service providers who
>can provide the more desirable, unaltered ethernet connectivity.

BWHAHAHAHAHAHAHA

You're serious about saying there are cable-tv providers providing
"unaltered ... connectivity?"  What a joke!

>As for some of the ADSL providers out there, still too little (and it's
>PPPoE), too late, and for too many dollars.  Competition is a good
>thing.

There are those of us out there that are providing Internet Access over
DSL, and doing so in a sane, well thought out way...unfortunately, I
fear we are way too few and far between.

>(Gee, I hope my rantings can make a difference) Just another author's
>opinion. . .

Preach it brother.
-- 
Jeff McAdams                            Email: jeffm@iglou.com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Michael wrote:
> 
> "Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
> news:G8prup.GCw@bath.ac.uk...
> | James Carlson <james.d.carlson@sun.com> wrote:
> | > John D Loop <loop@snt.bst.bls.com> writes:

> |
> | > Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
> | > use these forged packets to highjack user sessions or snipe them out
> | > of existence as long as you have bridging at the Ethernet layer.

James,

(Great Book, BTW!)

With a Redback configuration and PPPoE, you've got a private PVC between
the customer and the Redback...no bridging involved.  Thus, I assume
session hijacking isn't an issue.

Trust me, I have tons of concerns regarding the current poor
implementation of PPPoE (e.g. disconnects, packet size mis-matches, slow
login times, etc..) but from hands-on experience, it does solve many of
the issues you get with RFC1483/bridging once you scale to a few
thousand users per router interface.


As an example, I constantly saw Cisco 6400s (DSL aggregation router)
taken to their knees due to 5-6 customer using Vicomsoft (connection
sharing software) sending constant 5-6 ARP Broadcasts/second.

Let's just hope the implementation get better, soon.

lb.
-------------------------
Lawrence Baldwin
Protocol Scientist
678-624-0924
http://www.mynetwatchman.com/about.htm - I'm under attack, now what?

Are we talking about Redback here, ..ah I think they were the early
proponent of pppoE [correct me Jeff and James].  Why didn't Redback
market their ..other.. great approach discussed here?
Still not sure I get it!  
John


Jeff Mcadams wrote:
> 
> Thus spake Andrew Sun
> >It's called marketing, and the {A}DSL providers bought it, hook, line,
> >and sinker.
> 
> Bingo.
> 
> >Many advantages of PPPoE are a marketing illusion.  Much of which can
> >be implemented with technically better alternatives.  Multiple
> >sessions?  Allocate another IP address.
> 
> Or use a different tunneling protocol.
> 
> >From this users point of view, PPPoE is a real nuisance.
> 
> >It emulates dial-up service in this day and age when internet service
> >should be always on.
> 
> Heh...you want the ultimate user nuisance experience provided by a LEC?
> Check out Cincinnati Bell's Zoomtown DSL service.  Good grief.  If
> you've experienced this abomination, then this is enough said...if you
> haven't...be glad you're only dealing with PPPoE crap.
> 
> >At least there exist competing cable-tv internet service providers who
> >can provide the more desirable, unaltered ethernet connectivity.
> 
> BWHAHAHAHAHAHAHA
> 
> You're serious about saying there are cable-tv providers providing
> "unaltered ... connectivity?"  What a joke!
> 
> >As for some of the ADSL providers out there, still too little (and it's
> >PPPoE), too late, and for too many dollars.  Competition is a good
> >thing.
> 
> There are those of us out there that are providing Internet Access over
> DSL, and doing so in a sane, well thought out way...unfortunately, I
> fear we are way too few and far between.
> 
> >(Gee, I hope my rantings can make a difference) Just another author's
> >opinion. . .
> 
> Preach it brother.
> --
> Jeff McAdams                            Email: jeffm@iglou.com
> Head Network Administrator              Voice: (502) 966-3848
> IgLou Internet Services                        (800) 436-4456

Damn...
You qualify as the "James Carlson of this group" , Randy.  [that was a
compliment BTW].
John

"Randy S." wrote:
> 
> fivie wrote:
> 
> > I am interested ... What is the title of James Carlson 's book
> > is it available @ Barnes & Noble ?
> 
> I can answer that one:
> 
> http://shop.barnesandnoble.com/booksearch/results.asp?WRD=PPP+Design&userid=4R7PW2EQAM
> 
> Randy S.

In article <3A89E8E8.A629D758@mynetwatchman.com>,
Lawrence Baldwin  <baldwinlSPAMMENOT@mynetwatchman.com> wrote:
>Michael wrote:
>> 
>> "Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
>> news:G8prup.GCw@bath.ac.uk...
>> | James Carlson <james.d.carlson@sun.com> wrote:
>> | > John D Loop <loop@snt.bst.bls.com> writes:
>
>> |
>> | > Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
>> | > use these forged packets to highjack user sessions or snipe them out
>> | > of existence as long as you have bridging at the Ethernet layer.
>
>James,
>
>(Great Book, BTW!)
>
>With a Redback configuration and PPPoE, you've got a private PVC between
>the customer and the Redback...no bridging involved.  Thus, I assume
>session hijacking isn't an issue.

Uh, excuse me, but if you have a *private PVC*, what's the point of using
this garbage *at all*?

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
    And now he couldn't remember when this passion had flown, leaving him so
  foolish and bewildered and astray: can any man?
						   William Styron

Jim,

How familiar are you with Elastics Networks?

Jack

Jim Fincher wrote:

> What a great dialogue... wish the heck I could keep up with ALL of it !
>
> Any thoughts here on Etherloop ?..... Elastic Networks/Nortel's supposed
> "next generation DSL"............????
>
> Sure would like some opinions..... www.elastic.com is their site....
>
> Jim
>
> John D Loop wrote:
>
> > James Carlson,
> > Reading your new book on ppp.  Great stuff!  I read with interest your 1
> > page "slam" on pppoE and wondered if you had any more recent thots on
> > it.  It seems like we are stuck with it out here in ADSL land as a
> > defacto standard, for better or worse. All SOHO routers pretty much do
> > it now, along with pppoA.  And the consumers have to add pppoE clients
> > to their PC if they don't have a SOHO routers - this can get dicey
> > sometimes.  I can understand why it was invented [existing ppp
> > infrastructures & existing ethernet LAN environments], and I can even
> > see some advantages  [multiple sessions and multiple service selection].
> >
> > The biggest problem I see is the smaller MTU breaking some connections
> > when intervening routers don't allow MTU path discovery to work
> > [assuming it is turned on].
> > John

What a great dialogue... wish the heck I could keep up with ALL of it !

Any thoughts here on Etherloop ?..... Elastic Networks/Nortel's supposed
"next generation DSL"............????

Sure would like some opinions..... www.elastic.com is their site....

Jim

John D Loop wrote:

> James Carlson,
> Reading your new book on ppp.  Great stuff!  I read with interest your 1
> page "slam" on pppoE and wondered if you had any more recent thots on
> it.  It seems like we are stuck with it out here in ADSL land as a
> defacto standard, for better or worse. All SOHO routers pretty much do
> it now, along with pppoA.  And the consumers have to add pppoE clients
> to their PC if they don't have a SOHO routers - this can get dicey
> sometimes.  I can understand why it was invented [existing ppp
> infrastructures & existing ethernet LAN environments], and I can even
> see some advantages  [multiple sessions and multiple service selection].
>
> The biggest problem I see is the smaller MTU breaking some connections
> when intervening routers don't allow MTU path discovery to work
> [assuming it is turned on].
> John

Michael <mgbaker@bellsouth.net> wrote:

> "Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
> | For what it's worth, I've been experimenting with PPPoE encrypted sessions
> | (using home-brewed extensions to the Roaring Penguin implementation) and
> | it works a treat.  Anyone fancy a 128-bit cypher on *all* their traffic?
> | With a few trivial extensions to the rfc2516 I believe it would be possible
> | to offer a highly-secure service, without sniffing, interception, or DoS
> | concerns.
> |
> | cheers, josh.
> |
> | josh.howlett@bris.ac.uk
> |
> |

> I'm curious, I haven't installed myself yet, but at the Windows Update site their is an
> option to install 128 bit on DUN.

> Is this the same?

No.  The MS stuff probably runs over PPTP.

josh.

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

Oh yes,
Your book is even more marked up than James' book!  Does everybody who
participate in this group have to write a book?  Guess I better get
busy.  I think I could write a great novel about ADSL.
PPPoX can be quite an add-on hassle right now.  But I remember when
TCP/IP was an add-on hassle on Windows.
There are people who have big plans for the multiple session capabilities
of PPPoE, so hang on for a bumpy ride.  Nobody will splain to me why
pppoE is all over the map.  They can only splain why it is crummy!
Well, Windows [should I capitalize that?] is crummy and it is all over
the map.  Why do I have to deal with all this crummy stuff?
John

Andrew Sun wrote:

> John Loop wrote:
> >
> > But why are all the providers (almost all) implementing this stuff?
> > I don't get it.  Can you splain this?
>
> It's called marketing, and the {A}DSL providers bought it,
> hook, line, and sinker.
>
> Many advantages of PPPoE are a marketing illusion.  Much of which
> can be implemented with technically better alternatives.
> Multiple sessions?  Allocate another IP address.  Multiple
> service providers?  Associate IPs with a service provider.
> Perhaps use virtual LAN concepts, one per provider.  Username
> and password authentication?  Silly.  When was the last time a
> password was required before using residential telephone service?
>
> From this users point of view, PPPoE is a real nuisance.
>
> It emulates dial-up service in this day and age when internet
> service should be always on.
> "Now you can have an always-on ADSL service that can mysteriously
> disconnect.  And will disconnect if you reboot your computer."
>
> It requires custom software for Windows PCs, and unusual work
> arounds for professionals with UNIX, Linux, Solaris, Beos, MacOS,
>
> It can potentially create obscure, and difficult to troubleshoot
> problems due to protocol design deficiencies.
>
> What is the password?  Why is it necessary?
>
> At least there exist competing cable-tv internet service
> providers who can provide the more desirable, unaltered
> ethernet connectivity.  As for some of the ADSL providers out
> there, still too little (and it's PPPoE), too late, and for
> too many dollars.  Competition is a good thing.
>
> (Gee, I hope my rantings can make a difference)
> Just another author's opinion. . .
>
> --
> "Using & Managing PPP," http://www.oreilly.com/catalog/umppp




--------------0596A94431979B4AF09C0F4B
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

--------------0596A94431979B4AF09C0F4B--

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

Touche, that's easy:
You just made an argument for ATM to the desktop... [since the WAN was ATM].
There are those who thot the whole ADSL implementation should have been with an
ATM NIC - no ethernet!  This was the early preachings of Alcatel.  Unfortunately
our American (that's us) providers told us that Ethernet had already won the
desktop war and that nobody was going to buy an ATM NIC card for $300 when they
could buy an ethernet card for $30.  So there you have it, ethernet in the LAN,
ATM in the WAN [of course I'm simplifying here], and we will live the consequences
for probably a generation.  I think Ameritech actually started ADSL with an ATM
NIC a couple years ago.
John

Thor Lancelot Simon wrote:

> In article <3A89E8E8.A629D758@mynetwatchman.com>,
> Lawrence Baldwin  <baldwinlSPAMMENOT@mynetwatchman.com> wrote:
> >Michael wrote:
> >>
> >> "Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
> >> news:G8prup.GCw@bath.ac.uk...
> >> | James Carlson <james.d.carlson@sun.com> wrote:
> >> | > John D Loop <loop@snt.bst.bls.com> writes:
> >
> >> |
> >> | > Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
> >> | > use these forged packets to highjack user sessions or snipe them out
> >> | > of existence as long as you have bridging at the Ethernet layer.
> >
> >James,
> >
> >(Great Book, BTW!)
> >
> >With a Redback configuration and PPPoE, you've got a private PVC between
> >the customer and the Redback...no bridging involved.  Thus, I assume
> >session hijacking isn't an issue.
>
> Uh, excuse me, but if you have a *private PVC*, what's the point of using
> this garbage *at all*?
>
> --
> Thor Lancelot Simon                                           tls@rek.tjls.com
>     And now he couldn't remember when this passion had flown, leaving him so
>   foolish and bewildered and astray: can any man?
>                                                    William Styron

--
Question posed to Arthur C. Clarke:
How do you keep up with the new advances?
"I don't, of course - who can? And it makes me sorry.  I can't read fiction
anymore, I just don't have time for it.  The entire time is spent e-mailing!"


--------------86DDD8AA6DA00F9234D0D38B
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

--------------86DDD8AA6DA00F9234D0D38B--

Thus spake John Loop
>Are we talking about Redback here, ..ah I think they were the early
>proponent of pppoE [correct me Jeff and James].  Why didn't Redback
>market their ..other.. great approach discussed here?  Still not sure I
>get it!  

Good question...and one that I've given them a *very* hard time over
since we started working with them.  If I *had* to hazard a guess, its
because they were strongly marketing the dynamic service selection
stuff, and you really can't do that with only DHCP and rfc14(83|90)
encapsulation, you have to run some sort of tunneling protocol or
something to get the service selection (at least, I haven't come up with
a way to do it).
-- 
Jeff McAdams                            Email: jeffm@iglou.com
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

Jim,

Reason I asked because a friend of mine was an engineer with the company..

Jack

Jim Fincher wrote:

> Jack,
>
> Just a bit.... a friend is working for them in sales.... sure looks interesting
> to me... definitely has to be some new generation stuff out there...etherloop
> ????
>
> Jim
>
> jP wrote:
>
> > Jim,
> >
> > How familiar are you with Elastics Networks?
> >
> > Jack
> >
> > Jim Fincher wrote:
> >
> > > What a great dialogue... wish the heck I could keep up with ALL of it !
> > >
> > > Any thoughts here on Etherloop ?..... Elastic Networks/Nortel's supposed
> > > "next generation DSL"............????
> > >
> > > Sure would like some opinions..... www.elastic.com is their site....
> > >
> > > Jim
> > >
> > > John D Loop wrote:
> > >
> > > > James Carlson,
> > > > Reading your new book on ppp.  Great stuff!  I read with interest your 1
> > > > page "slam" on pppoE and wondered if you had any more recent thots on
> > > > it.  It seems like we are stuck with it out here in ADSL land as a
> > > > defacto standard, for better or worse. All SOHO routers pretty much do
> > > > it now, along with pppoA.  And the consumers have to add pppoE clients
> > > > to their PC if they don't have a SOHO routers - this can get dicey
> > > > sometimes.  I can understand why it was invented [existing ppp
> > > > infrastructures & existing ethernet LAN environments], and I can even
> > > > see some advantages  [multiple sessions and multiple service selection].
> > > >
> > > > The biggest problem I see is the smaller MTU breaking some connections
> > > > when intervening routers don't allow MTU path discovery to work
> > > > [assuming it is turned on].
> > > > John

Jack,

Just a bit.... a friend is working for them in sales.... sure looks interesting
to me... definitely has to be some new generation stuff out there...etherloop
????

Jim

jP wrote:

> Jim,
>
> How familiar are you with Elastics Networks?
>
> Jack
>
> Jim Fincher wrote:
>
> > What a great dialogue... wish the heck I could keep up with ALL of it !
> >
> > Any thoughts here on Etherloop ?..... Elastic Networks/Nortel's supposed
> > "next generation DSL"............????
> >
> > Sure would like some opinions..... www.elastic.com is their site....
> >
> > Jim
> >
> > John D Loop wrote:
> >
> > > James Carlson,
> > > Reading your new book on ppp.  Great stuff!  I read with interest your 1
> > > page "slam" on pppoE and wondered if you had any more recent thots on
> > > it.  It seems like we are stuck with it out here in ADSL land as a
> > > defacto standard, for better or worse. All SOHO routers pretty much do
> > > it now, along with pppoA.  And the consumers have to add pppoE clients
> > > to their PC if they don't have a SOHO routers - this can get dicey
> > > sometimes.  I can understand why it was invented [existing ppp
> > > infrastructures & existing ethernet LAN environments], and I can even
> > > see some advantages  [multiple sessions and multiple service selection].
> > >
> > > The biggest problem I see is the smaller MTU breaking some connections
> > > when intervening routers don't allow MTU path discovery to work
> > > [assuming it is turned on].
> > > John

Well we (company i do support for) have a couple of corporate customers that have ATM
to the desktop.... they have boat loads of network problems and both are
planning/moving away from it .... going to ethernet lans with atm backbones.... lots
of problems with software...

Jim

John D Loop wrote:

> Touche, that's easy:
> You just made an argument for ATM to the desktop... [since the WAN was ATM].
> There are those who thot the whole ADSL implementation should have been with an
> ATM NIC - no ethernet!  This was the early preachings of Alcatel.  Unfortunately
> our American (that's us) providers told us that Ethernet had already won the
> desktop war and that nobody was going to buy an ATM NIC card for $300 when they
> could buy an ethernet card for $30.  So there you have it, ethernet in the LAN,
> ATM in the WAN [of course I'm simplifying here], and we will live the consequences
> for probably a generation.  I think Ameritech actually started ADSL with an ATM
> NIC a couple years ago.
> John
>
> Thor Lancelot Simon wrote:
>
> > In article <3A89E8E8.A629D758@mynetwatchman.com>,
> > Lawrence Baldwin  <baldwinlSPAMMENOT@mynetwatchman.com> wrote:
> > >Michael wrote:
> > >>
> > >> "Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
> > >> news:G8prup.GCw@bath.ac.uk...
> > >> | James Carlson <james.d.carlson@sun.com> wrote:
> > >> | > John D Loop <loop@snt.bst.bls.com> writes:
> > >
> > >> |
> > >> | > Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
> > >> | > use these forged packets to highjack user sessions or snipe them out
> > >> | > of existence as long as you have bridging at the Ethernet layer.
> > >
> > >James,
> > >
> > >(Great Book, BTW!)
> > >
> > >With a Redback configuration and PPPoE, you've got a private PVC between
> > >the customer and the Redback...no bridging involved.  Thus, I assume
> > >session hijacking isn't an issue.
> >
> > Uh, excuse me, but if you have a *private PVC*, what's the point of using
> > this garbage *at all*?
> >
> > --
> > Thor Lancelot Simon                                           tls@rek.tjls.com
> >     And now he couldn't remember when this passion had flown, leaving him so
> >   foolish and bewildered and astray: can any man?
> >                                                    William Styron
>
> --
> Question posed to Arthur C. Clarke:
> How do you keep up with the new advances?
> "I don't, of course - who can? And it makes me sorry.  I can't read fiction
> anymore, I just don't have time for it.  The entire time is spent e-mailing!"

Well we (company i do support for) have a couple of corporate customers that have ATM
to the desktop.... they have boat loads of network problems and both are
planning/moving away from it .... going to ethernet lans with atm backbones.... lots
of problems with software...

Jim

John D Loop wrote:

> Touche, that's easy:
> You just made an argument for ATM to the desktop... [since the WAN was ATM].
> There are those who thot the whole ADSL implementation should have been with an
> ATM NIC - no ethernet!  This was the early preachings of Alcatel.  Unfortunately
> our American (that's us) providers told us that Ethernet had already won the
> desktop war and that nobody was going to buy an ATM NIC card for $300 when they
> could buy an ethernet card for $30.  So there you have it, ethernet in the LAN,
> ATM in the WAN [of course I'm simplifying here], and we will live the consequences
> for probably a generation.  I think Ameritech actually started ADSL with an ATM
> NIC a couple years ago.
> John
>
> Thor Lancelot Simon wrote:
>
> > In article <3A89E8E8.A629D758@mynetwatchman.com>,
> > Lawrence Baldwin  <baldwinlSPAMMENOT@mynetwatchman.com> wrote:
> > >Michael wrote:
> > >>
> > >> "Josh Howlett" <bujfxh@shark.cse.bris.ac.uk> wrote in message
> > >> news:G8prup.GCw@bath.ac.uk...
> > >> | James Carlson <james.d.carlson@sun.com> wrote:
> > >> | > John D Loop <loop@snt.bst.bls.com> writes:
> > >
> > >> |
> > >> | > Looks can be deceiving.  It's trivial to forge packets on PPPoE, and
> > >> | > use these forged packets to highjack user sessions or snipe them out
> > >> | > of existence as long as you have bridging at the Ethernet layer.
> > >
> > >James,
> > >
> > >(Great Book, BTW!)
> > >
> > >With a Redback configuration and PPPoE, you've got a private PVC between
> > >the customer and the Redback...no bridging involved.  Thus, I assume
> > >session hijacking isn't an issue.
> >
> > Uh, excuse me, but if you have a *private PVC*, what's the point of using
> > this garbage *at all*?
> >
> > --
> > Thor Lancelot Simon                                           tls@rek.tjls.com
> >     And now he couldn't remember when this passion had flown, leaving him so
> >   foolish and bewildered and astray: can any man?
> >                                                    William Styron
>
> --
> Question posed to Arthur C. Clarke:
> How do you keep up with the new advances?
> "I don't, of course - who can? And it makes me sorry.  I can't read fiction
> anymore, I just don't have time for it.  The entire time is spent e-mailing!"

James...

I followed the threads on pppoe and wanted to throw out another topic I'm really
interested in.... Etherloop.... as in elastic networks.....

........ any thoughts/ ideas/ ?????????

Jim

James Carlson wrote:

> "Christopher Jones" <c2jones@bellsouth.net> writes:
> > What troubles me though, is with all the misgivings I hear (there have been
> > plenty abroad, TechTV included) about the PPPoE configuration as less
> > stable, etc. than the other packages and yet, for my own personal situation,
> > the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> > simply woefully unreliable service situations I had in the past compared to
> > the virtually perfect service I have now.
>
> Implementation and protocol design are not the same thing.  It's
> certainly possible to do competent implementations of lousy protocols
> as well as incompetent implementations of better protocols.
>
> I was commenting only on the design of PPPoE itself, not any
> particular implementation.
>
> > Any idea as to why the infamous PPPoE configuration has proved for some
> > anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
>
> As above, I wasn't commenting on any particular implementation.  The
> design of PPPoE is bad in many respects.  That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.
>
> --
> 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

James...

I followed the threads on pppoe and wanted to throw out another topic I'm really
interested in.... Etherloop.... as in elastic networks.....

........ any thoughts/ ideas/ ?????????

Jim

James Carlson wrote:

> "Christopher Jones" <c2jones@bellsouth.net> writes:
> > What troubles me though, is with all the misgivings I hear (there have been
> > plenty abroad, TechTV included) about the PPPoE configuration as less
> > stable, etc. than the other packages and yet, for my own personal situation,
> > the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> > simply woefully unreliable service situations I had in the past compared to
> > the virtually perfect service I have now.
>
> Implementation and protocol design are not the same thing.  It's
> certainly possible to do competent implementations of lousy protocols
> as well as incompetent implementations of better protocols.
>
> I was commenting only on the design of PPPoE itself, not any
> particular implementation.
>
> > Any idea as to why the infamous PPPoE configuration has proved for some
> > anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
>
> As above, I wasn't commenting on any particular implementation.  The
> design of PPPoE is bad in many respects.  That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.
>
> --
> 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

James...

I followed the threads on pppoe and wanted to throw out another topic I'm really
interested in.... Etherloop.... as in elastic networks.....

........ any thoughts/ ideas/ ?????????

Jim

James Carlson wrote:

> "Christopher Jones" <c2jones@bellsouth.net> writes:
> > What troubles me though, is with all the misgivings I hear (there have been
> > plenty abroad, TechTV included) about the PPPoE configuration as less
> > stable, etc. than the other packages and yet, for my own personal situation,
> > the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> > simply woefully unreliable service situations I had in the past compared to
> > the virtually perfect service I have now.
>
> Implementation and protocol design are not the same thing.  It's
> certainly possible to do competent implementations of lousy protocols
> as well as incompetent implementations of better protocols.
>
> I was commenting only on the design of PPPoE itself, not any
> particular implementation.
>
> > Any idea as to why the infamous PPPoE configuration has proved for some
> > anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
>
> As above, I wasn't commenting on any particular implementation.  The
> design of PPPoE is bad in many respects.  That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.
>
> --
> 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

James...

I followed the threads on pppoe and wanted to throw out another topic I'm really
interested in.... Etherloop.... as in elastic networks.....

........ any thoughts/ ideas/ ?????????

Jim

James Carlson wrote:

> "Christopher Jones" <c2jones@bellsouth.net> writes:
> > What troubles me though, is with all the misgivings I hear (there have been
> > plenty abroad, TechTV included) about the PPPoE configuration as less
> > stable, etc. than the other packages and yet, for my own personal situation,
> > the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> > simply woefully unreliable service situations I had in the past compared to
> > the virtually perfect service I have now.
>
> Implementation and protocol design are not the same thing.  It's
> certainly possible to do competent implementations of lousy protocols
> as well as incompetent implementations of better protocols.
>
> I was commenting only on the design of PPPoE itself, not any
> particular implementation.
>
> > Any idea as to why the infamous PPPoE configuration has proved for some
> > anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
>
> As above, I wasn't commenting on any particular implementation.  The
> design of PPPoE is bad in many respects.  That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.
>
> --
> 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

James...

I followed the threads on pppoe and wanted to throw out another topic I'm really
interested in.... Etherloop.... as in elastic networks.....

........ any thoughts/ ideas/ ?????????

Jim

James Carlson wrote:

> "Christopher Jones" <c2jones@bellsouth.net> writes:
> > What troubles me though, is with all the misgivings I hear (there have been
> > plenty abroad, TechTV included) about the PPPoE configuration as less
> > stable, etc. than the other packages and yet, for my own personal situation,
> > the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> > simply woefully unreliable service situations I had in the past compared to
> > the virtually perfect service I have now.
>
> Implementation and protocol design are not the same thing.  It's
> certainly possible to do competent implementations of lousy protocols
> as well as incompetent implementations of better protocols.
>
> I was commenting only on the design of PPPoE itself, not any
> particular implementation.
>
> > Any idea as to why the infamous PPPoE configuration has proved for some
> > anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
>
> As above, I wasn't commenting on any particular implementation.  The
> design of PPPoE is bad in many respects.  That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.
>
> --
> 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

James...

I followed the threads on pppoe and wanted to throw out another topic I'm really
interested in.... Etherloop.... as in elastic networks.....

........ any thoughts/ ideas/ ?????????

Jim

James Carlson wrote:

> "Christopher Jones" <c2jones@bellsouth.net> writes:
> > What troubles me though, is with all the misgivings I hear (there have been
> > plenty abroad, TechTV included) about the PPPoE configuration as less
> > stable, etc. than the other packages and yet, for my own personal situation,
> > the PPPoE switch (from my former PPPoA) has been a real gem of a fix for the
> > simply woefully unreliable service situations I had in the past compared to
> > the virtually perfect service I have now.
>
> Implementation and protocol design are not the same thing.  It's
> certainly possible to do competent implementations of lousy protocols
> as well as incompetent implementations of better protocols.
>
> I was commenting only on the design of PPPoE itself, not any
> particular implementation.
>
> > Any idea as to why the infamous PPPoE configuration has proved for some
> > anyway, as the lifesaver for certain areas? Perhaps your book outlines this?
>
> As above, I wasn't commenting on any particular implementation.  The
> design of PPPoE is bad in many respects.  That doesn't mean that
> replacing bug-ridden PPPoA servers with better-built PPPoE servers
> wouldn't be a net gain for the average user.
>
> --
> 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