2000-03-26 00:33:07 +00:00
|
|
|
/*
|
|
|
|
|
protocol.h -- header for protocol.c
|
2006-04-26 13:52:58 +00:00
|
|
|
Copyright (C) 1999-2005 Ivo Timmermans,
|
2013-08-13 18:38:57 +00:00
|
|
|
2000-2013 Guus Sliepen <guus@tinc-vpn.org>
|
2000-03-26 00:33:07 +00:00
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
|
the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
2009-09-24 22:01:00 +00:00
|
|
|
You should have received a copy of the GNU General Public License along
|
|
|
|
|
with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
2000-03-26 00:33:07 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __TINC_PROTOCOL_H__
|
|
|
|
|
#define __TINC_PROTOCOL_H__
|
|
|
|
|
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
#include "ecdsa.h"
|
|
|
|
|
|
2011-07-05 19:19:48 +00:00
|
|
|
/* Protocol version. Different major versions are incompatible. */
|
2000-09-11 10:05:35 +00:00
|
|
|
|
2011-07-05 19:19:48 +00:00
|
|
|
#define PROT_MAJOR 17
|
Add MTU_INFO protocol message.
In this commit, nodes use MTU_INFO messages to provide MTU information.
The issue this code is meant to address is the non-trivial problem of
finding the proper MTU when UDP SPTPS relays are involved. Currently,
tinc has no idea what the MTU looks like beyond the first relay, and
will arbitrarily use the first relay's MTU as the limit. This will fail
miserably if the MTU decreases after the first relay, forcing relays to
fall back to TCP. More generally, one should keep in mind that relay
paths can be arbitrarily complex, resulting in packets taking "epic
journeys" through the graph, switching back and forth between UDP (with
variable MTUs) and TCP multiple times along the path.
A solution that was considered consists in sending standard MTU probes
through the relays. This is inefficient (if there are 3 nodes on one
side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU
discoveries taking place at the same time, while technically only
3+3=6 are needed) and would involve eyebrow-raising behaviors such as
probes being sent over TCP.
This commit implements an alternative solution, which consists in
the packet receiver sending MTU_INFO messages to the packet sender.
The message contains an MTU value which is set to maximum when the
message is originally sent. The message gets altered as it travels
through the metagraph, such that when the message arrives to the
destination, the MTU value contained in the message can be used to
send packets while making sure no relays will be forced to fall back to
TCP to deliver them.
The operating principles behind such a protocol message are similar to
how the UDP_INFO message works, but there is a key difference that
prevents us from simply reusing the same message: the UDP_INFO message
only cares about relay-to-relay links (i.e. it is sent between static
relays and the information it contains only makes sense between two
adjacent static relays), while the MTU_INFO cares about the end-to-end
MTU, including the entire relay path. Therefore, UDP_INFO messages stop
when they encounter static relays, while MTU_INFO messages don't stop
until they get to the original packet sender.
Note that, technically, the MTU that is obtained through this mechanism
can be slightly pessimistic, because it can be lowered by an
intermediate node that is not being used as a relay. Since nodes have no
way of knowing whether they'll be used as dynamic relays or not (and
have no say in the matter), this is not a trivial problem. That said,
this is highly unlikely to result in noticeable issues in realistic
scenarios.
2015-03-08 18:54:50 +00:00
|
|
|
#define PROT_MINOR 6 /* Should not exceed 255! */
|
2000-09-26 14:06:11 +00:00
|
|
|
|
2003-07-29 22:59:01 +00:00
|
|
|
/* Silly Windows */
|
|
|
|
|
|
|
|
|
|
#ifdef ERROR
|
|
|
|
|
#undef ERROR
|
|
|
|
|
#endif
|
|
|
|
|
|
2000-09-11 10:05:35 +00:00
|
|
|
/* Request numbers */
|
|
|
|
|
|
2003-07-22 20:55:21 +00:00
|
|
|
typedef enum request_t {
|
2012-10-10 15:17:49 +00:00
|
|
|
ALL = -1, /* Guardian for allow_request */
|
2002-09-09 21:25:28 +00:00
|
|
|
ID = 0, METAKEY, CHALLENGE, CHAL_REPLY, ACK,
|
|
|
|
|
STATUS, ERROR, TERMREQ,
|
|
|
|
|
PING, PONG,
|
|
|
|
|
ADD_SUBNET, DEL_SUBNET,
|
|
|
|
|
ADD_EDGE, DEL_EDGE,
|
|
|
|
|
KEY_CHANGED, REQ_KEY, ANS_KEY,
|
|
|
|
|
PACKET,
|
2012-07-19 23:02:51 +00:00
|
|
|
/* Tinc 1.1 requests */
|
2009-11-07 22:43:25 +00:00
|
|
|
CONTROL,
|
2012-07-19 23:02:51 +00:00
|
|
|
REQ_PUBKEY, ANS_PUBKEY,
|
2015-05-10 17:05:19 +00:00
|
|
|
SPTPS_PACKET,
|
Add MTU_INFO protocol message.
In this commit, nodes use MTU_INFO messages to provide MTU information.
The issue this code is meant to address is the non-trivial problem of
finding the proper MTU when UDP SPTPS relays are involved. Currently,
tinc has no idea what the MTU looks like beyond the first relay, and
will arbitrarily use the first relay's MTU as the limit. This will fail
miserably if the MTU decreases after the first relay, forcing relays to
fall back to TCP. More generally, one should keep in mind that relay
paths can be arbitrarily complex, resulting in packets taking "epic
journeys" through the graph, switching back and forth between UDP (with
variable MTUs) and TCP multiple times along the path.
A solution that was considered consists in sending standard MTU probes
through the relays. This is inefficient (if there are 3 nodes on one
side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU
discoveries taking place at the same time, while technically only
3+3=6 are needed) and would involve eyebrow-raising behaviors such as
probes being sent over TCP.
This commit implements an alternative solution, which consists in
the packet receiver sending MTU_INFO messages to the packet sender.
The message contains an MTU value which is set to maximum when the
message is originally sent. The message gets altered as it travels
through the metagraph, such that when the message arrives to the
destination, the MTU value contained in the message can be used to
send packets while making sure no relays will be forced to fall back to
TCP to deliver them.
The operating principles behind such a protocol message are similar to
how the UDP_INFO message works, but there is a key difference that
prevents us from simply reusing the same message: the UDP_INFO message
only cares about relay-to-relay links (i.e. it is sent between static
relays and the information it contains only makes sense between two
adjacent static relays), while the MTU_INFO cares about the end-to-end
MTU, including the entire relay path. Therefore, UDP_INFO messages stop
when they encounter static relays, while MTU_INFO messages don't stop
until they get to the original packet sender.
Note that, technically, the MTU that is obtained through this mechanism
can be slightly pessimistic, because it can be lowered by an
intermediate node that is not being used as a relay. Since nodes have no
way of knowing whether they'll be used as dynamic relays or not (and
have no say in the matter), this is not a trivial problem. That said,
this is highly unlikely to result in noticeable issues in realistic
scenarios.
2015-03-08 18:54:50 +00:00
|
|
|
UDP_INFO, MTU_INFO,
|
2012-10-10 15:17:49 +00:00
|
|
|
LAST /* Guardian for the highest request number */
|
2003-07-22 20:55:21 +00:00
|
|
|
} request_t;
|
2000-03-26 00:33:07 +00:00
|
|
|
|
2002-03-21 23:11:53 +00:00
|
|
|
typedef struct past_request_t {
|
2012-05-08 14:44:15 +00:00
|
|
|
const char *request;
|
2002-09-09 21:25:28 +00:00
|
|
|
time_t firstseen;
|
2002-03-21 23:11:53 +00:00
|
|
|
} past_request_t;
|
|
|
|
|
|
2003-11-17 15:30:18 +00:00
|
|
|
extern bool tunnelserver;
|
2010-03-01 23:18:44 +00:00
|
|
|
extern bool strictsubnets;
|
2011-07-11 19:54:01 +00:00
|
|
|
extern bool experimental;
|
2003-11-17 15:30:18 +00:00
|
|
|
|
Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 16:31:10 +00:00
|
|
|
extern ecdsa_t *invitation_key;
|
|
|
|
|
|
2005-06-03 10:16:03 +00:00
|
|
|
/* Maximum size of strings in a request.
|
|
|
|
|
* scanf terminates %2048s with a NUL character,
|
|
|
|
|
* but the NUL character can be written after the 2048th non-NUL character.
|
|
|
|
|
*/
|
2000-11-22 19:55:53 +00:00
|
|
|
|
2005-06-03 10:16:03 +00:00
|
|
|
#define MAX_STRING_SIZE 2049
|
2002-02-26 23:26:41 +00:00
|
|
|
#define MAX_STRING "%2048s"
|
2000-11-22 19:55:53 +00:00
|
|
|
|
2003-07-22 20:55:21 +00:00
|
|
|
#include "edge.h"
|
|
|
|
|
#include "net.h"
|
|
|
|
|
#include "node.h"
|
|
|
|
|
#include "subnet.h"
|
|
|
|
|
|
2002-02-10 21:57:54 +00:00
|
|
|
/* Basic functions */
|
2000-09-11 10:05:35 +00:00
|
|
|
|
2003-07-30 21:52:41 +00:00
|
|
|
extern bool send_request(struct connection_t *, const char *, ...) __attribute__ ((__format__(printf, 2, 3)));
|
2012-05-08 14:44:15 +00:00
|
|
|
extern void forward_request(struct connection_t *, const char *);
|
|
|
|
|
extern bool receive_request(struct connection_t *, const char *);
|
2000-03-26 00:33:07 +00:00
|
|
|
|
2002-03-22 11:43:48 +00:00
|
|
|
extern void init_requests(void);
|
|
|
|
|
extern void exit_requests(void);
|
2012-05-08 14:44:15 +00:00
|
|
|
extern bool seen_request(const char *);
|
2002-03-22 11:43:48 +00:00
|
|
|
|
2002-02-10 21:57:54 +00:00
|
|
|
/* Requests */
|
|
|
|
|
|
2003-07-22 20:55:21 +00:00
|
|
|
extern bool send_id(struct connection_t *);
|
|
|
|
|
extern bool send_metakey(struct connection_t *);
|
2011-07-07 20:30:55 +00:00
|
|
|
extern bool send_metakey_ec(struct connection_t *);
|
2003-07-22 20:55:21 +00:00
|
|
|
extern bool send_challenge(struct connection_t *);
|
|
|
|
|
extern bool send_chal_reply(struct connection_t *);
|
|
|
|
|
extern bool send_ack(struct connection_t *);
|
2003-07-24 12:08:16 +00:00
|
|
|
extern bool send_status(struct connection_t *, int, const char *);
|
2012-05-08 14:44:15 +00:00
|
|
|
extern bool send_error(struct connection_t *, int, const char *);
|
2003-07-22 20:55:21 +00:00
|
|
|
extern bool send_termreq(struct connection_t *);
|
|
|
|
|
extern bool send_ping(struct connection_t *);
|
|
|
|
|
extern bool send_pong(struct connection_t *);
|
2003-07-24 12:08:16 +00:00
|
|
|
extern bool send_add_subnet(struct connection_t *, const struct subnet_t *);
|
|
|
|
|
extern bool send_del_subnet(struct connection_t *, const struct subnet_t *);
|
|
|
|
|
extern bool send_add_edge(struct connection_t *, const struct edge_t *);
|
|
|
|
|
extern bool send_del_edge(struct connection_t *, const struct edge_t *);
|
2011-05-28 21:36:52 +00:00
|
|
|
extern void send_key_changed(void);
|
2009-04-02 23:05:23 +00:00
|
|
|
extern bool send_req_key(struct node_t *);
|
|
|
|
|
extern bool send_ans_key(struct node_t *);
|
2011-05-28 21:36:52 +00:00
|
|
|
extern bool send_tcppacket(struct connection_t *, const struct vpn_packet_t *);
|
Add UDP_INFO protocol message.
In this commit, nodes use UDP_INFO messages to provide UDP address
information. The basic principle is that the node that receives packets
sends UDP_INFO messages to the node that's sending the packets. The
message originally contains no address information, and is (hopefully)
updated with relevant address information as it gets relayed through the
metagraph - specifically, each intermediate node will update the message
with its best guess as to what the address is while forwarding it.
When a node receives an UDP_INFO message, and it doesn't have a
confirmed UDP tunnel with the originator node, it will update its
records with the new address for that node, so that it always has the
best possible guess as to how to reach that node. This applies to the
destination node of course, but also to any intermediate nodes, because
there's no reason they should pass on the free intel, and because it
results in nice behavior in the presence of relay chains (multiple nodes
in a path all trying to reach the same destination).
If, on the other hand, the node does have a confirmed UDP tunnel, it
will ignore the address information contained in the message.
In all cases, if the node that receives the message is not the
destination node specified in the message, it will forward the message
but not before overriding the address information with the one from its
own records. If the node has a confirmed UDP tunnel, that means the
message is updated with the address of the confirmed tunnel; if not,
the message simply reflects the records of the intermediate node, which
just happen to be the contents of the UDP_INFO message it just got, so
it's simply forwarded with no modification.
This is similar to the way ANS_KEY messages are currently
overloaded to provide UDP address information, with two differences:
- UDP_INFO messages are sent way more often than ANS_KEY messages,
thereby keeping the address information fresh. Previously, if the UDP
situation were to change after the ANS_KEY message was sent, the
sender would virtually never get the updated information.
- Once a node puts address information in an ANS_KEY message, it is
never changed again as the message travels through the metagraph; in
contrast, UDP_INFO messages behave the opposite way, as they get
rewritten every time they travel through a node with a confirmed UDP
tunnel. The latter behavior seems more appropriate because UDP tunnel
information becomes more relevant as it moves closer to the
destination node. The ANS_KEY behavior is not satisfactory in some
cases such as multi-layered graphs where the first hop is located
before a NAT.
Ultimately, the rationale behind this whole process is to improve UDP
hole punching capabilities when port translation is in effect, and more
generally, to make tinc more reliable in (very) hostile network
conditions (such as multi-layered NAT).
2015-01-03 17:46:33 +00:00
|
|
|
extern bool send_udp_info(struct node_t *, struct node_t *);
|
Add MTU_INFO protocol message.
In this commit, nodes use MTU_INFO messages to provide MTU information.
The issue this code is meant to address is the non-trivial problem of
finding the proper MTU when UDP SPTPS relays are involved. Currently,
tinc has no idea what the MTU looks like beyond the first relay, and
will arbitrarily use the first relay's MTU as the limit. This will fail
miserably if the MTU decreases after the first relay, forcing relays to
fall back to TCP. More generally, one should keep in mind that relay
paths can be arbitrarily complex, resulting in packets taking "epic
journeys" through the graph, switching back and forth between UDP (with
variable MTUs) and TCP multiple times along the path.
A solution that was considered consists in sending standard MTU probes
through the relays. This is inefficient (if there are 3 nodes on one
side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU
discoveries taking place at the same time, while technically only
3+3=6 are needed) and would involve eyebrow-raising behaviors such as
probes being sent over TCP.
This commit implements an alternative solution, which consists in
the packet receiver sending MTU_INFO messages to the packet sender.
The message contains an MTU value which is set to maximum when the
message is originally sent. The message gets altered as it travels
through the metagraph, such that when the message arrives to the
destination, the MTU value contained in the message can be used to
send packets while making sure no relays will be forced to fall back to
TCP to deliver them.
The operating principles behind such a protocol message are similar to
how the UDP_INFO message works, but there is a key difference that
prevents us from simply reusing the same message: the UDP_INFO message
only cares about relay-to-relay links (i.e. it is sent between static
relays and the information it contains only makes sense between two
adjacent static relays), while the MTU_INFO cares about the end-to-end
MTU, including the entire relay path. Therefore, UDP_INFO messages stop
when they encounter static relays, while MTU_INFO messages don't stop
until they get to the original packet sender.
Note that, technically, the MTU that is obtained through this mechanism
can be slightly pessimistic, because it can be lowered by an
intermediate node that is not being used as a relay. Since nodes have no
way of knowing whether they'll be used as dynamic relays or not (and
have no say in the matter), this is not a trivial problem. That said,
this is highly unlikely to result in noticeable issues in realistic
scenarios.
2015-03-08 18:54:50 +00:00
|
|
|
extern bool send_mtu_info(struct node_t *, struct node_t *, int);
|
2002-02-10 21:57:54 +00:00
|
|
|
|
|
|
|
|
/* Request handlers */
|
|
|
|
|
|
2012-05-08 14:44:15 +00:00
|
|
|
extern bool id_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool metakey_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool challenge_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool chal_reply_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool ack_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool status_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool error_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool termreq_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool ping_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool pong_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool add_subnet_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool del_subnet_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool add_edge_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool del_edge_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool key_changed_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool req_key_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool ans_key_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool tcppacket_h(struct connection_t *, const char *);
|
|
|
|
|
extern bool control_h(struct connection_t *, const char *);
|
Add UDP_INFO protocol message.
In this commit, nodes use UDP_INFO messages to provide UDP address
information. The basic principle is that the node that receives packets
sends UDP_INFO messages to the node that's sending the packets. The
message originally contains no address information, and is (hopefully)
updated with relevant address information as it gets relayed through the
metagraph - specifically, each intermediate node will update the message
with its best guess as to what the address is while forwarding it.
When a node receives an UDP_INFO message, and it doesn't have a
confirmed UDP tunnel with the originator node, it will update its
records with the new address for that node, so that it always has the
best possible guess as to how to reach that node. This applies to the
destination node of course, but also to any intermediate nodes, because
there's no reason they should pass on the free intel, and because it
results in nice behavior in the presence of relay chains (multiple nodes
in a path all trying to reach the same destination).
If, on the other hand, the node does have a confirmed UDP tunnel, it
will ignore the address information contained in the message.
In all cases, if the node that receives the message is not the
destination node specified in the message, it will forward the message
but not before overriding the address information with the one from its
own records. If the node has a confirmed UDP tunnel, that means the
message is updated with the address of the confirmed tunnel; if not,
the message simply reflects the records of the intermediate node, which
just happen to be the contents of the UDP_INFO message it just got, so
it's simply forwarded with no modification.
This is similar to the way ANS_KEY messages are currently
overloaded to provide UDP address information, with two differences:
- UDP_INFO messages are sent way more often than ANS_KEY messages,
thereby keeping the address information fresh. Previously, if the UDP
situation were to change after the ANS_KEY message was sent, the
sender would virtually never get the updated information.
- Once a node puts address information in an ANS_KEY message, it is
never changed again as the message travels through the metagraph; in
contrast, UDP_INFO messages behave the opposite way, as they get
rewritten every time they travel through a node with a confirmed UDP
tunnel. The latter behavior seems more appropriate because UDP tunnel
information becomes more relevant as it moves closer to the
destination node. The ANS_KEY behavior is not satisfactory in some
cases such as multi-layered graphs where the first hop is located
before a NAT.
Ultimately, the rationale behind this whole process is to improve UDP
hole punching capabilities when port translation is in effect, and more
generally, to make tinc more reliable in (very) hostile network
conditions (such as multi-layered NAT).
2015-01-03 17:46:33 +00:00
|
|
|
extern bool udp_info_h(struct connection_t *, const char *);
|
Add MTU_INFO protocol message.
In this commit, nodes use MTU_INFO messages to provide MTU information.
The issue this code is meant to address is the non-trivial problem of
finding the proper MTU when UDP SPTPS relays are involved. Currently,
tinc has no idea what the MTU looks like beyond the first relay, and
will arbitrarily use the first relay's MTU as the limit. This will fail
miserably if the MTU decreases after the first relay, forcing relays to
fall back to TCP. More generally, one should keep in mind that relay
paths can be arbitrarily complex, resulting in packets taking "epic
journeys" through the graph, switching back and forth between UDP (with
variable MTUs) and TCP multiple times along the path.
A solution that was considered consists in sending standard MTU probes
through the relays. This is inefficient (if there are 3 nodes on one
side of relay and 3 nodes on the other side, we end up with 3*3=9 MTU
discoveries taking place at the same time, while technically only
3+3=6 are needed) and would involve eyebrow-raising behaviors such as
probes being sent over TCP.
This commit implements an alternative solution, which consists in
the packet receiver sending MTU_INFO messages to the packet sender.
The message contains an MTU value which is set to maximum when the
message is originally sent. The message gets altered as it travels
through the metagraph, such that when the message arrives to the
destination, the MTU value contained in the message can be used to
send packets while making sure no relays will be forced to fall back to
TCP to deliver them.
The operating principles behind such a protocol message are similar to
how the UDP_INFO message works, but there is a key difference that
prevents us from simply reusing the same message: the UDP_INFO message
only cares about relay-to-relay links (i.e. it is sent between static
relays and the information it contains only makes sense between two
adjacent static relays), while the MTU_INFO cares about the end-to-end
MTU, including the entire relay path. Therefore, UDP_INFO messages stop
when they encounter static relays, while MTU_INFO messages don't stop
until they get to the original packet sender.
Note that, technically, the MTU that is obtained through this mechanism
can be slightly pessimistic, because it can be lowered by an
intermediate node that is not being used as a relay. Since nodes have no
way of knowing whether they'll be used as dynamic relays or not (and
have no say in the matter), this is not a trivial problem. That said,
this is highly unlikely to result in noticeable issues in realistic
scenarios.
2015-03-08 18:54:50 +00:00
|
|
|
extern bool mtu_info_h(struct connection_t *, const char *);
|
2002-02-10 21:57:54 +00:00
|
|
|
|
2012-10-10 15:17:49 +00:00
|
|
|
#endif /* __TINC_PROTOCOL_H__ */
|
