UDP Terminal Protocol

On 12/26/2016 3:34 PM, Robert Wessel wrote:
> On Thu, 15 Dec 2016 11:06:19 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> My read of the OP's comments was that he wanted a means of talking with
>> the "command/control console" of his device, remotely, using network
>> fabric instead of a dedicated "serial" link.
>>
>> E.g., in a data center environment, this would be used for LOM -- in
>> lieu of a "display and keyboard".
>
> While it's moot at this point, I need to support more low-level stuff
> than an operational console.  Think BIOS setup screens.

That was the sort of application that inspired my "screen" comment:
    "Does the interface have to be interactive?  E.g., you could leverage
    something akin to TFTP to push a "screen" of data to/from a console
    device (treat the screen as a "form" that is filled in instead of
    as a STREAM)."

But, your other requirements suggest you *also* need a stream-oriented
interface.

While you can layer a *screen* oriented interface atop a stream, the
opposite is a bit tougher.

When you also throw in the need to transit network segments, it seems
the only practical approach is to implement a pared down TCP and
RLOGIN (or TELNET, depending on the clients you have available).

On Mon, 26 Dec 2016 23:00:41 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 12/26/2016 3:34 PM, Robert Wessel wrote:
>> On Thu, 15 Dec 2016 11:06:19 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> My read of the OP's comments was that he wanted a means of talking with
>>> the "command/control console" of his device, remotely, using network
>>> fabric instead of a dedicated "serial" link.
>>>
>>> E.g., in a data center environment, this would be used for LOM -- in
>>> lieu of a "display and keyboard".
>>
>> While it's moot at this point, I need to support more low-level stuff
>> than an operational console.  Think BIOS setup screens.
>
>That was the sort of application that inspired my "screen" comment:
>    "Does the interface have to be interactive?  E.g., you could leverage
>    something akin to TFTP to push a "screen" of data to/from a console
>    device (treat the screen as a "form" that is filled in instead of
>    as a STREAM)."
>
>But, your other requirements suggest you *also* need a stream-oriented
>interface.
>
>While you can layer a *screen* oriented interface atop a stream, the
>opposite is a bit tougher.
>
>When you also throw in the need to transit network segments, it seems
>the only practical approach is to implement a pared down TCP and
>RLOGIN (or TELNET, depending on the clients you have available).


As I mentioned, it's moot.  For devices where we're going to have to
support those functions via TCP, we're almost certain to do HTTP.  It
does mean rewriting the configuration screens handling code, but in
many cases that will be less than painful - there's usually already an
abstraction layer around the actual VT-100 driver code that implements
a panel.  Having that output HTML will typically be straight-forward.
Even for the devices that only have a command line ("TTY") interface,
you can fake that up with HTTP with little effort (OTOH, improving
that would likely be a goal).

In article <o2sfro$psh$1@dont-email.me>,
Don Y  <blockedofcourse@foo.invalid> wrote:
>On 12/14/2016 1:03 PM, Robert Wessel wrote:
>> On Tue, 13 Dec 2016 12:53:57 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>>> OTOH, despite looking, I just don't see any standards for doing that
>>>> sort of thing.  Am I just missing it?  Is there a defacto standard
>>>> even if there's no RFC?
>>>
>>> RLOGIN is much lighter-weight than TELNET (YMMV).  But, as with TELNET,
>>> runs atop TCP.
>>
>> Not really sure I'd agree with that, but both are pretty simple.  If I
>> had TCP, doing either TELNET or RLOGIN (or HTTP) is not much of an
>> issue.  OTOH, there doesn't really seem to be much advantage for doing
>> RLOGIN over TELNET.
>
>Just to make sure there's no misunderstanding, RLOGIN runs over TCP;
>you'd use it in lieu of TELNET.  (a full TELNET implementation is
>many thousands of lines of code -- much of which you probably won't
>need if you just want to emulate a serial port)

Minimal telnet is just sending a handful of bytes as soon as
the session is established, and then just use the raw tcp. You
would want to turn off the default line-mode, and set character
mode. That is just one small printf/echo/print/whatever as soon
as you have the session set up.

You would need a retransmit timer, but it can be _very_simple, e.g.
6 seconds if you haven't seen an ack. You need to handle four
window pointers, one for how far we have sent and one for how
far we have received, for both transmit and receive. They are
set in the initial syn-ack-synack dialogue. You would need to
implement fin-finack-fin2 to terminate the session as well.

>>> What criteria do you place on the operating environment?  E.g., you
>>> can't run a bare "serial port" 1000km.
>>
>> No, but one would hope to do something with a bit more range than a
>> serial port (which is what's there now), and a bit more convenient
>> infrastructure-wise.  Design "range" should be something on the
>> data-center to campus scale.  One of the prime considerations is the
>> ability to manage many devices without the complexity of attaching to
>> many serial ports scattered around the data center.
>
>Once you "leave the room", things typically get complicated (unless
>you're willing to live with a 100m cable limitation).  And, once you
>start trying to talk to existing fabric, you have even less leeway
>in terms of the corners you can cut (e.g., what happens if some
>host tries to ping your node?  open an FTP connection?  etc -- even
>if wrong in attempting to do so).
>
>Many years ago (10+) I put together a proposal for a low cost "console server"
>(essentially a one-port terminal server) to facilitate LOM in a datacenter
>environment.  At the time, I could enhance security and cut cost by
>bastardizing the network protocols with the caveat:  all of these devices will
>reside on an isolated internet (so they didn't have to contend with the
>variety of traffic they might encounter on a "live" internet).
>
>Nowadays, SoC's have far more resources so even a complete stack isn't
>going to break the bank (unless you're *really* scraping the bottom
>of the cost/commodity barrel).
>
>>>  Are you just trying to exploit
>>> an existing connector (RJ45) for a secondary purpose with a LOCAL
>>> "console"?  I.e., do you need flow control, fragmentation/packet reassembly,
>>> routing, etc.?  Or, will you just slap some "special device" on the
>>> wire "in close proximity to" the device in question?
>>
>> I don't really want a special device, although a PC with special
>
>The "PC" was the intent of my reference  :>  The point being, it's not
>an OTS solution (you still need to "develop" that end of the link).
>
>> software is reasonable, but at worst case you'd want that PC to need
>> to be no closer than somewhere on the local LAN (data center or
>> campus, as mentioned above, would be better).  If you didn't mind a
>> special device, there are RS-232-to-TELNET devices you could just plug
>> into the serial port, and define the whole problem away.  As to flow
>> control and whatnot, those issue should be kept to a minimum (again
>> TFTP is a parallel), but since this has been done before, I'm trying
>> to figure out if there's existing practice to piggyback on.  If, for
>> example, there's a semi-standard way to do this, there are likely
>> terminal emulators that already support that.
>
>There have been lots of attempts at making "console servers" (my
>reference above).  HP had a "Secure Web Console" that presented
>a "terminal emulator" in a web browser window that was tethered
>to the remote device's serial port.
>
>[It was a poorly designed product, though -- particularly the
>laughable "secure" aspect of it!  :> ]
>
>You can buy single port terminal servers in a package not
>much larger than a DB25 backshell (the proposal I outlined above
>called for a DB9 backshell package as most servers now have 9 pin
>serial ports so you don't have room for a "box" behind the server)
>
>> The big advantage to going "whole hog" and doing TCP and TELNET (or
>> TCP and HTTP), is that you open this up to the whole Internet, and an
>> untold number of existing clients for any conceivable platform.
>
>As Devil's Advocate, I'd point out that you now present a larger
>attack surface and a (potentially) bigger adversary pool; one
>thing with which a simple serial port didn't have to contend!
>
>> Physically, the idea would be to replace the serial port with an
>> Ethernet port.  It would be nice to be able to still connect without
>> any network infrastructure at all (beyond, possibly, a crossover
>> Ethernet cable).
>
>It might be interesting to consider putting serial port *and* ethernet
>on the same connector (I'd have to consider the hardware consequences
>to see if there's a "cheap" way of doing so).
>
>>> Does the interface have to be interactive?  E.g., you could leverage
>>> something akin to TFTP to push a "screen" of data to/from a console
>>> device (treat the screen as a "form" that is filled in instead of
>>> as a STREAM).
>>
>> The model under consideration is a replacement of a serial console
>> assumed to be a VT-100 compatible device.  I don't think a hack like
>> you're suggesting is viable.  At that point we're talking about custom
>> software on both ends, so a "proper" TELNET-ish* protocol over UDP
>> would be simpler.  Developing such a (new) protocol is no problem.
>
>If you were willing to make the "special device" a PC, then this
>just changes the nature of the software running in the PC (given
>that the "device end" is already negotiable).
>
>I offer it only because I've frequently designed "screen oriented"
>user interfaces (think: menu/dialog system atop curses(1)) so the
>UI is always a ~2KW buffer in the device's memory that just gets
>painted (via ANSI escape sequences) onto the hardware TTY.  Pushing
>those 4KB out through a set of ~8 UDP packets (on demand any time
>user asks for the screen to be repainted) would be a piece of cake;
>much simpler than the curses stack residing in the device -- or the
>ANSI emulator in the PC!
>
>[The Sun Ray operated in a similar fashion; and, AFAICT, the Pano
>cubes (no CPU -- entirely FPGA based) use a similar approach to
>"painting a screen"]
>
>> *And let's not get too hung up on the specifics of TELNET here - some
>> bits of handshake information probably need to be exchanged at the top
>> of the session, and then it's just a packaging of the bi-directional
>> serial stream.
>
>If you want to interoperate with other devices, you may have to implement
>bits of the protocol that you'd hoped you could elide.  E.g., MS's
>TELNET client is a PITA for me to use, here -- so I install third-party
>TELNET clients that "work".
>
>>> You can also implement a much pared-back network stack by putting
>>> other constraints on how you plan to USE that stack (limit number
>>> of open sockets, window size, etc.)  E.g., my devices are intended to
>>> talk to specific *other* devices so I don't have to maintain ARP
>>> caches, multiple endpoints, etc.
>>
>> Sure: I'd like to pare-back the network stack by not implementing TCP.
>> ;-)  Limited UDP-only on top of Ethernet is pretty trivial.
>
>But, even with TCP, there are economies available.  If you try to
>cheap out and port an existing stack (FOSS), you will typically end
>up with more resources (and features) than you might otherwise need.
>
>IMO, the biggest downside is you'll typically insulate yourself from
>the inner workings of the stack and, thus, not be aware of the sorts of
>exploits that lie in wait.  Or, the costs (space/performance) that you
>are bearing.
>
>Thereafter, you have to track new releases of that codebase to see
>if/when to fold them into one of your "updates".  This could result in
>your taking on additional functionality/resource requirements that
>you might not want.
>
>OTOH, if you "take ownership" of such a codebase (i.e., start tweeking
>it to *fit* your needs), then you're still stuck watching the releases
>and now have to merge "pertinent" changes into your codebase.
>
>[I.e., you quickly start to feel like the dog's *tail*!]
>
>If you haven't, already, Comer's XINU (vol2) is a lightweight introduction
>to the stacks; followed by his _Internetworking with TCP/IP_ series.
>With those behind you, Stevens' _TCP/IP Illustrated_ is by far the best
>reference.
>
>[Though Stevens' texts tend to describe more efficient (from the
>standpoint of performance) implementations; Comer's tend to be much
>easier to visualize -- more *discrete* layers (and, thus, less
>efficient)]
>
>And, watch the CERT advisories to see how profoundly varied attacks
>on stacks can be, in practice!

You would employ such a server behind one or more firewalls, I am sure.
Just filter it from anyone that doesn't belong there.

This is for console access, not any big user community.

-- mrr