Date: Thu, 15 Oct 1998 20:43:51 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brian@Awfulhak.org (Brian Somers) Cc: tlambert@primenet.com, brian@Awfulhak.org, mike@smith.net.au, rkw@Dataplex.NET, fjaccard@urbanet.ch, current@FreeBSD.ORG Subject: Re: [GIMPS] /proc/net/route needed Message-ID: <199810152043.NAA23406@usr02.primenet.com> In-Reply-To: <199810151030.LAA00689@woof.lan.awfulhak.org> from "Brian Somers" at Oct 15, 98 11:30:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Any program can configure a tun interface and multiplex the data in > whatever way it chooses. The best that could be done to control this > would be to have a central ``transport policy'' file and some API for > reading/writing how many packets have been sent over which transports. > > So, for the moment, I suspect things will remain the same; the public > interface layer will be brought up despite the lower layers not yet > being available. When something arrives at the higher layer, the > dialup is performed. The point is to allow some programs use of the network to cause the link to automatically come up, while other programs use of the network will fail instead of causing the link to come up. Basically, blocking packets from some programs, but not others, based on administrative policy decisions. For example, you might want to cause outbound mail to bring up a link any time, but since you are intermittently connected to the net, and your ISP can't bring the link up, you only want to bring the link up to check for inbound mail when there are likely to be people around to receive it. As an instance of a specific policy, consider that it doesn't matter if you dial up and ETRN the ISP every half hour all night long, or if you ETRN them just before the normal working day begins; either way, the mail will arrive before the humans to whom it's addressed are available to read it, so between 6 PM and 8 AM, all you are doing is burning money by allowing the half-hourly cron job to actually successfully bring the link up. In other words, a differential administrative policy based on some definition of "work hours". I thought of the firewall because: o Packets are what bring the link up o The firewall's job is to block packets o The firewall can keep the link from coming up o It's a nice centralized chokepoint that could be managed by a daemon, in the same way that bandwidth management works by differentially preferring protocols that have a high likelihood of having humans connected to the other end, using a single daemon to administer policy. o The code's already there, and can be abused to do the job. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810152043.NAA23406>