Deleted the protocol description.
This commit is contained in:
parent
d0ba34ccae
commit
12adf1af54
1 changed files with 1 additions and 262 deletions
263
doc/tinc.texi
263
doc/tinc.texi
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue