From owner-freebsd-current@FreeBSD.ORG Tue Oct 21 16:35:30 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A426516A4B3 for ; Tue, 21 Oct 2003 16:35:30 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBAF143FAF for ; Tue, 21 Oct 2003 16:35:28 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h9LNYcMg035974; Tue, 21 Oct 2003 19:34:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h9LNYbi6035971; Tue, 21 Oct 2003 19:34:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 21 Oct 2003 19:34:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Peter Jeremy In-Reply-To: <20031021202618.GE1668@cirb503493.alcatel.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: ethercons: ethernet console driver for 5-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2003 23:35:30 -0000 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 ", 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