**********************************************************************
FTSC FIDONET TECHNICAL STANDARDS COMMITTEE
**********************************************************************
Publication: FSP-1011
Revision: 3
Title: Binkp - a protocol for transferring FidoNet mail over
reliable connections
Authors: Dima Maloff
Nick Soveiko
Maxim Masiutin
Revision Date: 31 July 2000
Expiry Date: 31 July 2002
----------------------------------------------------------------------
Abstract
--------
This specification defines binkp - a protocol to handle a session
between two Fidonet Technology systems over a reliable connection.
Assumption that the connection is reliable makes possible to
eliminate error-checking and unnecessary synchronization steps,
achieving both ease of implementation and major performance
improvement over connections with large unpredictable delays (e.g.
Internet).
Status of this document
-----------------------
This document is a Fidonet Standards Proposal (FSP).
This document specifies an optional Fidonet standard protocol for
the Fidonet community, and requests discussion and suggestions for
improvements.
This document is released to the public domain, and may be used,
copied or modified for any purpose whatever.
Available formats
-----------------
Binkp Specification is also available in HTML format at
http://www.ritlabs.com/binkp/
Table of contents
-----------------
1. Background
1. Objectives
2. Motivation for a New Protocol
2. Definitions
3. Protocol Overview
4. Frame Format
1. Notation
2. Examples
5. Protocol Commands and Their Arguments
1. Classification
2. File Name Issues
3. Non-ASCII Characters in Command Argument symbol string
4. Binkp Commands
5. Example of Frame Exchange in a Simple binkp Session
6. Protocol States
1. Session Setup Stage
1. Originating Side
2. Answering Side
2. File Transfer Stage
3. Session Termination
7. Recommended Protocol Extensions
1. Non-Reliable Mode
2. Multiple Batch Mode
3. Multiple Passwords Mode
4. Keyed Hashing Challenge-Response Authentication Mechanism
1. Overview
2. Sequence of Steps
3. Generating and Transmitting Challenge Data
4. Producing and Transmitting a Digest
5. Indicating CRAM Capabilities
6. Example of Frame Exchange During CRAM Authentication
7. Notes on Hash Function Algorithms
8. License
9. Glossary
10. References
11. Acknowledgements
A. Author Contact Data
B. History
---------------------------------------------------------------
1. Background
-------------
1.1 Objectives
--------------
It's been a long time since a new Fidonet protocol has been
developed, [EMSI] definitions being published last time in 1991,
not speaking about basic standards, [FTS-0001] and [FTS-0006].
Fidonet is evolving everyday and new transport layers are being
introduced into practice. This led to a situation when in certain
Fidonet Regions a visible portion of traffic, especially long
distance traffic generating high toll, is being carried by means of
protocols that formally are not Fidonet standards. This creates an
ambiguity for such systems in indicating their additional
capabilities in Fidonet nodelist and in some instances, from being
listed in the nodelist at all.
This document attempts to document the current practice for
communication between two Fidonet systems via a reliable channel,
provide technical reference for Fidonet software developers and
eventually improve Fidonet connectivity.
1.2 Motivation for a new protocol
---------------------------------
Existing Fidonet Technical Standards and Fidonet Reference Library
documents [FTS-0001], [FTS-0006], [EMSI] specify both session
handshake procedures and transmission capabilities that imply:
* non-reliable communication channel between mailers
* low round-trip times in the communication channel between
mailers.
This was commonplace a few years ago, when Fidonet systems were not
using transport other than direct dial-up on a visible basis.
Things have changed today, when other communication media becomes
widely available on a day-to-day basis. This communication media
typically provides implementation of Physical, Data Link, Network
and Transport layers of the ISO/OSI Reference Model and facilitates
relieving Session layer of inappropriate functions, such as error
control, flow control, call management and data transparency
[Halsall95]. Examples of such communication media are TCP/IP socket
connection and HDLC family protocol connection.
New communication media can be generally characterized by the
reliable transmission service offered by it to the Session layer
protocol. Reliable transmission implies that:
* Data link and/or Transport layer protocols are responsible for
error control and delivery of frames in correct sequence
* Session layer and higher layer protocols are operating on top
of connection-oriented mode
* Quality of Service provisions (if any) result in unspecified
delays between transmitter and receiver
* connections are rarely aborted.
Combination of these factors imposed the following requirements for
the new Fidonet protocol:
* error control can be eliminated throughout the session layer
protocol for both handshake and default file transfer method
* session setup procedure should minimize number of
synchronization points for fast handshake
* protocol should be insensitive to delays and robust with
respect to timeouts
* application flow control should be moved to file level;
individual data frames do not need to be error checked nor
acknowledged
* protocol should be independent from both higher and lower layer
protocols
* protocol should be reasonably easy to implement and allow
future extensions.
2. Definitions
--------------
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
in this document are to be interpreted as specified in [FTA-0006].
However, for readability, these words may sometimes not appear in
all uppercase letters in this specification. Although it should not
impact minimal realization of binkp protocol, it must be noted that
Protocol Extensions may override, update or obsolete requirement
levels indicated by the above keywords in chapters from 3 to 6
inclusive.
Calling party in this document is referred to as the Originating
side and called party is referred to as the Answering side.
Originating side here is the party that initiates the connection
between two systems.
Mailer in this document is a software that implements the protocol.
Words "frame", "packet", and "block" when used in this document
refer to binkp's Frames, unless explicitly stated otherwise.
Other definitions that are not local to this document can be found
in the Glossary.
This document is organized as following:
Frames section defines binkp's frames. Binkp/1.0 commands and their
arguments section provides detailed description of all defined
protocol commands together with recommendations for their usage.
Actual binkp implementation may match it's own diagrams provided
that such implementation remains fully compatible with current
specification. Protocol states section gives rigorous state
diagrams for the minimum realization of binkp. All mailers MUST
support this minimum realization. Recommended Protocol Extensions
section documents most important extensions to the basic protocol
that are in use as of the time of this writing. The License,
Glossary and References sections can be found at the end of this
document.
3. Protocol Overview
--------------------
Binkp is a Fidonet session layer protocol intended for use over
data transparent bi-directional channels with reliable
transmission. There are no other requirements for the service
provided by the underlying protocol suite. Presentation and
application layer protocols are not discussed here. Whenever TCP/IP
socket is used, IANA registered port number for binkp 24554 SHOULD
be used (as registered with the Internet Assigned Numbers
Authority).
Functionality of the minimum protocol realization makes provision
for:
* password protected sessions
* 4D/5D addressing for Fidonet and technology compatible networks
* exchange of Type 2 [FTS-0001], Type 2.2 [FSC-0045], Type 2+
[FSC-0039] and [FSC-0048], Type 3 [FSC-0081] packets and
[FTS-0006] arcmail in both directions, including poll and mail
pickup, as well as transfer of any binary or ASCII files
* handling WaZOO [FTS-0006] file requests
* ensuring integrity of transmitted mail and files
* simultaneous bi-directional transmission
* maximizing performance over packet switched data networks
Binkp uses only one synchronization point during session startup,
that is password exchange. This feature facilitates fast session
startup for high latency links. Sliding window flow control is
incorporated on the file level. This ensures that a batch of small
files is transmitted with the same efficiency as a one large file.
4. Frame Format
---------------
Binkp is defined in terms of sending and receiving specifically
formatted data blocks. We call them frames.
Command frames carry protocol commands and may change protocol
state. Data frames are usually appended to files being received by
mailers or may be discarded, depending on the protocol state.
The particular way of mapping an octet stream or a datagram stream
of the transport layer into binkp frames may depend on the
underlying protocol suite. At this time, we define such mapping for
TCP/IP socket connection which can also be used for similar
transports as well.
The socket stream is being split into binkp frames in the following
manner:
7 6543210 76543210
+-+-------+--------+--- ................ ---+
|T| SIZE | DATA |
+-+-------+--------+--- ................ ---+
|<- 2 octets ->|<- up to 32767 octets ->|
(frame header) (frame data)
If T bit is 0, this is a data frame.
If T bit is 1, this is a command frame.
15 bits marked SIZE carry the size of the DATA part of the frame in
octets (with the bit marked 0 being the least significant). That
is, the actual length of a binkp frame is SIZE+2.
The size of the DATA part may vary between 1 and 32767 octets. A
correct realization should never set SIZE to 0. Upon receiving of a
packet header with the SIZE field set to 0, the total length of the
incoming packet must be treated as 2, this packet must be dropped,
and the event should be logged.
The first octet of a command frame data is the command ID. The ID
must be between 0 and 127 inclusive.
Other octets carry command arguments. Command arguments are an
arbitrary symbol string that may be null-terminated. Treating of a
null character in the middle of a command depends on realization
(with the options being "treat as whitespace" or "treat as
end-of-line"). The terminating null character (if any) is either
stripped or used by mailers internally as an end-of-line marker.
4.1 Notation
------------
As stated before, command ID is a small number between 0 and 127.
Every binkp command defined in this document has a symbolic name in
the form M_XXX. Symbolic names are defined in binkp commands
section. We will use symbolic names and not numeric command IDs to
refer to commands everywhere in this document.
The following notation is used to describe binkp's command frames:
M_XXX "Data string"
The actual numeric command ID for the command with the symbolic
name of M_XXX should be written into the first octet of the DATA
area of a binkp frame. "Data string" is a string to be copied into
DATA area starting at second octet. SIZE should be set to the total
length of "Data string" plus one for the octet to store the command
number. T bit should be set to 1.
4.2 Examples
------------
M_OK "":
7 6543210 76543210 76543210
+-+-------+--------+--------+
|1| 0 1| 4|
+-+-------+--------+--------+
| | +----- command ID (no arguments)
| +-------- frame length
+- command frame flag
M_NUL "TEST":
+-+-------+--------+--------+-------+--------+--------+--------+
|1| 0 5| 0| T E S T |
+-+-------+--------+--------+-------+--------+--------+--------+
5. Protocol Commands and Their Arguments
----------------------------------------
5.1 Classification
------------------
Protocol commands may be classified the following way:
* By argument type: