Date: Tue, 21 Oct 2003 19:34:37 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: current@freebsd.org Subject: Re: ethercons: ethernet console driver for 5-current Message-ID: <Pine.NEB.3.96L.1031021181529.35338A-100000@fledge.watson.org> In-Reply-To: <20031021202618.GE1668@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Oct 2003, Peter Jeremy wrote:
> On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote:
> > After reading a FREENIX
> >paper this summer on a Linux ethernet console driver, I took a pass at
> >implementing ethernet console support for FreeBSD.
>
> A very worthy cause. I'm sure this has come up before but I think
> you're the first person to produce actual code. Something that you
> don't seem to address is security - which surprised me.
Well, in a sense I did: the environment I use the ethernet console in is
one of trust of the link layer. I use DHCP, PXE, and NFS roots on the
boxes in question. That said, I should have more carefully documented the
security assumptions: that there will be no malicious attackers on the
wire, and because it's a link layer protocol, there will be no routing of
the packets in question from untrusted segments.
I did look at introducing cryptographic protections, but there are a
number of problems with this:
(1) I wanted to minimize the amount of transient protocol state. The
current implementation does not make any reliable transmission
guarantees. In order to prevent replay attacks, we would need to rely
on reliable timestamps or sequence numbers. In order to establish
sequence number legitimacy, we'd need to have a protocol component
that establishes freshness.
(2) It introduces the issue of key management. In my environment, since
the system configuration is shipped in the clear anyway, the keying
material would also get transfered in the clear, which would make the
whole arrangement somewhat moot.
The minimalist solution would introduce just keyed integrity, perhaps
using HMAC-MD5 and a shared secret. The problem does come back to
sequencing: if you assume the LAN is subject to replay and monitoring,
timestamps aren't sufficient, you actually need sequencing and freshness.
This means doing a Needham-Schroeder shared key exchange or a related
notion to get a session key. This requires the client and server to
detect and handle reboots, for example. I am willing to do the
implementation, but without a wire protocol worth committing to yet, I was
unwilling to invest the time.
> > This driver is similar >to the Linux driver, although not
> binary-compatible on the wire, >... >As with the Linux driver,
> communication happens at the ethernet link >layer, using protocol number
> 0x0666 (entertaining choice).
>
> If Linux is using 0x0666, we should probably pick a different number
> since we're not wire compatible. Though coming up with a common
> protocol would be even better.
The problem with the Linux protocol was that it had no concept of
direction. I'm still hopeful I'll find a better wire protocol to model
the implementation on.
> > In general, the wire protocol is
> >probably the weakest part of the endeavor, but I'm having trouble finding
> >documentation for a decent wire console protocol that doesn't come with an
> >entire network stack attached.
>
> MOP (as you point out later) or LAT have the advantage of being more
> standard, but I'm not sure how well documented they are.
I have found some documentation of MOP and LAT, although it's not clear to
me there's enough information to do an independent implementation without
referencing an existing one. There is a Linux implementation, so I'll
take a look at that. One of my concerns here is that it could be these
protocols require a fairly deep DECnet stack, and I'm not all that
interested in building big protocol stacks. However, until I'm done with
the reading, I can't commit myself either way :-).
> > A series of tunables and sysctls is available to tune the
> >behavior of ethercons:
> >kern.ethercons.ifnet_raise
> >kern.ethercons.interface_preference
> >kern.ethercons.target
>
> Is there any way to specify ifconfig options? "media" and "mediaopts"
> in particular may need to be specified to get the interface to talk to
> the associated switch.
Currently, no. If we do want to add this sort of infrastructure, we might
want to provide common infrastructure for both the diskless booting
environment, which also attempts to raise the interface before getting to
the userland configuration.
> I presume kern.ethercons.target only specifies the MAC address inserted
> into transmitted packets. Is there any way to restrict the src
> address(es) of received packets? Does ethercons have any concept of a
> current session or will it accept incoming packets from anywhere at any
> time? The latter case would seem undesirable as (IMHO) it makes it too
> easy to accidently send a command to the wrong system
Right now, ethercons defaults to a broadcast for outgoing, and accepts any
locally destined packet on the inbound. There is no notion of session.
This is both an upside and a downside: I've actually taken advantage of
this behavior to monitor using a common monitoring host, and then used an
interactive session simultaenously from another host. However, my hosts
all have fairly different ethernet addresses, making the chance of an
accidental collisions and "sending a command to the wrong machine" low. It
would be quite easy to add another configurable entry to say "only accept
input from address <x>", however. Per my comments earlier in this e-mail,
my goal in the current implementation has been to avoid the complexity of
higher levels of the stack: complex addressing, session management, etc.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031021181529.35338A-100000>