[consume-thenet] Priorities for nodes and services..

[Ben Laurie]

Malcolm Cartledge wrote:
> 
> Adam Laurie wrote:
> >
> > Stephen Summerfield wrote:
> > >
> > > > -----Original Message-----
> > > > From: Kim Hawtin [mailto:ryjkavik@yahoo.com.au]
> > > > Sent: 01 March 2001 13:13
> > > >
> > > > After the talk I had with James and Matt ther other
> > > > evening, we came to the conclusion that there are
> > > > a few problems with offering an open connection
> > > > into the consume network, especially if those
> > > > people using that access are unknown and not
> > > > trustworthy ...(spamming mail servers, etc)
> > >
> > > I see that as a pretty important issue, particularly as the person who owns
> > > the Internet link will most likely be liable for any users of the link.
> > >
> > > > What it comes down to is, are we willing to give
> > > > unlimited access to the leaf nodes hanging off
> > > > the consume network?
> > > >
> > > > Some conversation with folks vary from; everything
> > > > to only specific services by trusted clients ...
> > > > and every possibility in between?
> > > >
> > > > Any ideas? Especially on authentication of
> > > > clients accessing as leaf nodes?
> > >
> > > I've had a few ideas on the nuts and bolts side of how to control client
> > > access...
> > >
> > > One was to use the capabilities of DHCP server software and have the concept
> > > of trusted (known) and untrusted (unknown/anonymous) client nodes - a
> > > trusted client would have it's MAC address registered in the access point
> > > node's configuration and given an IP address in a certain pool of addresses
> > > (or a fixed address if that has been negotiated with the node owner and
> > > along with possible special privileges). An anonymous/untrusted client would
> > > be allocated an address in a different address pool.
> > >
> > > The firewall rules could then be setup to provide different levels of
> > > service depending on whether they are trusted or untrusted - based on the
> > > IP/IP pool of the client.
> > > eg an untrusted client could be given web access, but no access to local
> > > SMTP relay, etc.
> > > You could do funky things with traffic shaping to give different
> > > clients/classes of clients different amounts of available bandwidth.
> > >
> > > You might simply force all untrusted/unknown clients to a web page that ask
> > > them to register with the node, supply certain information, contact details,
> > > MAC address (this could be automatically determined?) and agree to the
> > > T&Cs/AUP for the node. If you wanted to ensure they are members of a
> > > 'consume club' (eg when roaming) digital certificates could be used to
> > > authenticate them when they register.
> > >
> > > Two main problems I can see in using DHCP/firewall rules in this way which
> > > make it non-foolproof:
> > > a) MAC addresses can (probably) be spoofed/stolen (?) Either at the hardware
> > > level or at the IP level - ie when making DHCP requests.
> > > b) There would be nothing to stop someone manually assigning themselves an
> > > IP address and not using DHCP at all.
> > >
> > > A possibility to improve b) would be to have the DHCP server dynamically
> > > create/remove the approriate firewall rules for clients as IP addresses are
> > > allocated/expired - in a fashion similar to how the DHCP server can
> > > automatically add/remove DNS records. However this would/may require a
> > > hacked DHCP server to add this functionality.
> >
> > we would like to keep this as simple as possible, and doing stuff like
> > this inevitably will lead to different capabilities on different
> > platforms as well as a "free" network that's errr... not very free (as
> > in freedom, not cash).
> >
> > i personally will be providing free access (possibly throttled down to
> > give my machines higher priority) and dealing with problems as they
> > arrise.
> >
> > as for liability, the nice wavelan sales droid told me to plug card A
> > into slot B and the end result appears to be that anyone within 300M of
> > my house can use my internet connection. well, well... how 'bout that!
> > isn't that supposed to happen then, yer honour? are i responsible for
> > that unauthorised use, or be it megacorp limited that gave me the duff
> > advice? :)
> 
> As far as I remember insanity can be used as protection from the law,
> but not stupidity.
> 
> A barrister would no doubt point out that you could have enabled WEP to
> stop 'anyone' gaining access, and as you are a member of a technical
> group of experts, you surely could have implemented a simple firewall to
> force users to log on to your web cache or even employed various
> authentication schemes, rather than believed someone you openly describe
> as a 'droid' ;)
> 
> ...especially a droid who hasn't even read the range specification on
> his own data sheet
> 
> Seriously though, this does need a solid solution. What do some of the
> other groups that have been mentioned do?

It is not clear to me that I am liable for packets that pass through my
network. Certainly ISPs aren't, are they? It would be pretty difficult
to run the Internet at all if they were!

I'd be interested to know what my legal obligations would actually be,
really, rather than mere speculation, berore I worry about how to
achieve them. I'm copying UKCrypto in case one of the many legal types
there can enlighten us!

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/