Deleted the protocol description.

This commit is contained in:
Ivo Timmermans 2000-05-12 13:31:00 +00:00
parent d0ba34ccae
commit 12adf1af54

View file

@ -691,7 +691,6 @@ Output version information and exit.
@menu
* The Connection::
* Security::
* The Protocol::
@end menu
@node The Connection, Security, Technical information, Technical information
@ -768,7 +767,7 @@ the UDP data is the ``data-protocol,'' the other one is the
@c ==================================================================
@node Security, The Protocol, The Connection, Technical information
@node Security, , The Connection, Technical information
@section About tinc's encryption and other security-related issues.
@cindex tinc
@ -862,266 +861,6 @@ Now we have securely hidden our data. But a malicious cracker may still
bother you by randomly altering the encrypted data he intercepts.
@c ==================================================================
@node The Protocol, , Security, Technical information
@section Detailed protocol specifications
@menu
* Data protocol::
* Meta protocol::
@end menu
@c ==================================================================
@node Data protocol, Meta protocol, The Protocol, The Protocol
@subsection The data protocol
The data that is sent through the UDP connection is formatted as follows:
@example
bytes | Contents
----------------------
0-1 | The length of this packet, including all leading fields
2-5 | The destination IP address
6-... | The encrypted data
@end example
The method that was used to encrypt the data should be made known via
the meta-protocol, during early identification stages.
@c ==================================================================
@node Meta protocol, , Data protocol, The Protocol
@subsection The Meta protocol
This protocol consists of separate packets of information, that are
generally formatted thusly:
@example
bytes | Contents
----------------------
0 | The request ID
1-... | (Optional: arguments)
@end example
What follows is a listing of possible request IDs.
@table @samp
@item ACK
Acknowledge. This generally means that the authentication has been
accepted by the remote computer. Takes no arguments.
@example
bytes | Contents
----------------------
0 | `1'
@end example
@item AUTH_S_INIT
@itemx AUTH_C_INIT
Obsolete. Use @samp{BASIC_INFO}.
@item AUTH_S_SPP
@itemx AUTH_C_SPP
Obsolete. Use @samp{PASSPHRASE}.
@item AUTH_S_SKEY
@itemx AUTH_C_SKEY
Obsolete. Use @samp{PUBLIC_KEY}, @samp{REQ_KEY} and @samp{ANS_KEY}.
@item AUTH_S_SACK
@itemx AUTH_C_RACK
Obsolete. Use @samp{ACK}.
@item TERMREQ
A request to terminate this connection, for whatever reason.
@example
bytes | Contents
----------------------
0 | `30'
1-4 | The VPN IP address of the host that has exited
@end example
@item PINGTIMEOUT
Terminate connection, but the reason must be a ping timeout.
@example
bytes | Contents
----------------------
0 | `31'
1-4 | The VPN IP address of the host that has exited
@end example
@item PING
Send probe to the other end, if he hasn't returned a @samp{PONG} within
10 seconds, the connection is considered to be dead and will be
terminated, we should try to notify the other by sending a
@samp{PINGTIMEOUT} packet.
@example
bytes | Contents
----------------------
0 | `40'
@end example
@item PONG
See explanation for @samp{PING}
@example
bytes | Contents
----------------------
0 | `41'
@end example
@item ADD_HOST
Send an @samp{ADD_HOST} packet if you want to propagate all your current
connections to a new computer on a network. If we get this request, we
must forward it to everyone that hasn't got it yet.
@example
bytes | Contents
----------------------
0 | `60'
1-4 | The real IP address of the new host
5-8 | The VPN IP address of the new host
9-12 | The VPN netmask
13-14 | The port number that the new host listens on
@end example
@item BASIC_INFO
This packet will contain all necessary basic information about
ourselves, such as the port we listen on and our desired VPN IP address.
@example
bytes | Contents
----------------------
0 | `61'
1 | The protocol version.
| This chapter describes version 4.
2-3 | The port number that the new host listens on
4-7 | The VPN IP address of the new host
8-11 | The VPN netmask
@end example
@item PASSPHRASE
Send an encrypted passphrase. Should be encrypted with our
@strong{public} key, and it must reach us before a @samp{PUBLIC_KEY}
request.
@example
bytes | Contents
----------------------
0 | `62'
1-2 | The length of the encrypted passphrase
3-... | The encrypted passphrase
@end example
@item PUBLIC_KEY
This is only used during authentication of a new connection, later on we
may use @samp{REQ_KEY} and @samp{ANS_KEY}.
@example
bytes | Contents
----------------------
0 | `63'
1-2 | The length of the key
3-... | The public key, given in base-36
@end example
@item HOLD
@itemx RESUME
Unused.
@item CALCULATE
@itemx CALC_RES
@itemx ALMOST_KEY
Never been in use.
@item REQ_KEY
Request a public key from someone and return it to the sender of this
request using a @samp{ANS_KEY} packet. If we get such request, we must
forward it to the connection that leads to the destination.
@example
bytes | Contents
----------------------
0 | `160'
1-4 | The source VPN IP address
5-8 | The destination VPN IP address
9-14 | `0'
@end example
@item ANS_KEY
Answer to a @samp{REQ_KEY} request, forward it to the destination if it
is not meant for us.
@example
bytes | Contents
----------------------
0 | `161'
1-4 | The source VPN IP address
5-8 | The destination VPN IP address
9-12 | The expiration date/time in seconds
13-14 | The key length
15-... | The public key in base-36
@end example
@item KEY_CHANGED
The source computer wants to tell that it has regenerated its private
and public keys, so anything going there must be encrypted with a new
shared key.
@example
bytes | Contents
----------------------
0 | `162'
1-4 | The source VPN IP address
@end example
@end table
@c ==================================================================
@node About us, Concept Index, Technical information, Top
@chapter About us