Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!news.uoknor.edu!ns1.nodak.edu!netnews.nwnet.net!news.clark.edu!spool.mu.edu!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!netcomsv!netcomsv!calcite!vjs
From: vjs@calcite.rhyolite.com (Vernon Schryver)
Subject: Re: PPP under BSD (have a heart)
Message-ID: <Ctwxz7.Cr3@calcite.rhyolite.com>
Organization: Rhyolite Software
Date: Tue, 2 Aug 1994 15:06:42 GMT
References: <bakulCttyCM.7n@netcom.com> <Ctv3tI.7yE@calcite.rhyolite.com> <bakulCtw9DA.B61@netcom.com>
Lines: 124
In article <bakulCtw9DA.B61@netcom.com> bakul@netcom.com (Bakul Shah) writes:
>vjs@calcite.rhyolite.com (Vernon Schryver) writes:
>>>What is needed is to transparently keep the if interface up while
>>>the serial line goes up and down. Probably a bunch of additional
>>>ioctls. When a line is idle for a (configurable) period of time,
>>>the if_ppp driver signals pppd.
>
>>I prefer having the daemon do the counting based on traffic indications
>>from the kernel.
>
>I agree. But... won't this get unwieldy when you have a zillion
>such connections? The daemon has to poll all these Z interfaces!
Poll? What polling? The kernel drivers send periodic indications up
the STREAM to the daemon. These indications range from "line X of
multi-link bundle lost carrier" to "all transmit queues have been full
for the last Y seconds". It's nice to limit the number of such "beeps"
to one every 5 or 10 seconds.
Like all UNIX PPP implementations I've heard of, in my code each bundle
(i.e. if_* interface with 0 or more active serial lines) has its own
daemon.
>>No additional machinery is needed. Simply use whatever you used
>>to autheticate the peer when the connection was set up initially,
>>probably PAP, CHAP, and/or getty/login.
>
>Don't know about PAP & CHAP but getty/login are not enough unless
>you put some additional constraints. What happens when the
>same person dials in twice, once to run PPP and once to login
>and run a shell?
You use different usernames for each purpose, each with an appropriate
"shell".
> What happens when both logins are for PPP?
>Which one gets connected? What happens if I dial in for PPP
>from machine A at work, then I go home without breaking the
>connection and now login from machine B?
If you are using PPP, you can do IPCP chatting to discover the IP address
of the other end.
Of course, contrary to the naive (in my opinion) hopes of some in the
IETF PPP working group, if you have more than one machine, you must have
more than one IP address. You cannot be connected to a PPP hub more
than once and use a single IP address.
Some in the working group want an additional identification scheme.
The application somehow involves having people share usernames and
passwords. Most of the working group participants are convinced that
any such identification scheme is exactly equivalent to assigning
different login/getty user names and by convention using the last
character or two of the user name to do the sub-identifying. (Actually,
the argument involved non-UNIX clients and PAP or CHAP, but the principle
is the same.)
> ...
>The key issue [for multi-link] is identifying that the peer on a
>new link is the
>same entity as the one currently talking to us. Apart from
>policies, the only other issue is how the interface code keeps
>all the links equally busy.
That's not the key issue. It's no problem at all. You must do reasonable
authentication of the identity of the peer. You must be sure that the
peer is authorized to use the IP address(es) you're about to use. While
you're doing that, you can notice if you already have a link to the
peer, and bundle the link into the existing bundle.
The IETF working group had plenty of discussion of cases when you do
not want to bundle a new link into an existing bundle.
The other issue, keeping lines equally busy can be handled for IP however
you want: IP fragment in the PPP driver, pick the shortest queue, round-
robin or whatever tickles your fancy. You don't need to tell the other
end what you're doing for BF&I IP mult-link. (brute force & ignorance,
my favorite) Other protocols which require that packets not be reordered
are harder, and one of the reasons the PPP multi-link protocol involves
fragmenting packets. The other reason is that if you fragment packets,
you can reduce latency.
> ...
>>Another thing you've missed is the mechanism to decide which traffic
>>counts as activity. [etc.]
>
>I agree! So.... is this all written up and agreed upon by the
>IETF PPP WG?!
The IETF PPP WG agreed that those other issues are too had to deal with.
They're all local policy issues, and so plausibly not subject to
standardization.
To see how various implementations handle those issues, read some
representative manuals.
>Identifying the peer entity is such a central and/or useful
>concept in all sorts of situations that it makes sense to me to
>have a completely separate standard way of doing it and just use
>that in every case (perhaps with a varying level of trust and
>inversely varying speed of identification).
Is it something in the Seattle water? One of the main groups favoring
the crazy (in my opinion) desire for weak and redundant authentication
and authorization outside of PAP and CHAP is a very big software outfit
in the Northwest.
After you've done PAP or CHAP or login/getty, you better know exactly
who is on the other end of the line. In case you want many people to
share the same login-secret (ie. PAP password and username, CHAP secret,
or login/getty password and username) as the Washington people do,
you either
1. rely on IPCP address negotiating to disambiguate.
2. subdivide the username by local convention, assigning significance
to the parts of it. For example, "joe" would be his shell
account, "joe-ppp" his PPP account, and "joe-slip" his SLIP
account.
Vernon Schryver vjs@rhyolite.com