NatT protocol
DavidXanatos (Talk | contribs) m (→Connection Begin =) |
DavidXanatos (Talk | contribs) (→NAT Tunneling) |
||
| Line 23: | Line 23: | ||
<----------------- ping | <----------------- ping | ||
handshake ................ | handshake ................ | ||
| + | </pre> | ||
| + | |||
| + | Keep alive ping is sent from one of the 2 connection participants and contains a flag that determines weather the ping should be answered or not, it also contains additional informations used for connection establishment, and for obfuscation. The packet may be sent completely empty if no answer is requested and no data are appended. | ||
| + | <pre> | ||
| + | [uint8] pOPS // bit Field | ||
| + | // 6 reserved | ||
| + | // 3 IdKind | ||
| + | // 1 req answer | ||
| + | [ID] // variable length determined by the Ping Options above | ||
| + | [Obfiscation] // uint8 obfuSetings | ||
| + | // hash128 userHash | ||
</pre> | </pre> | ||
Revision as of 15:00, 16 July 2007
THIS IS NOT FINAL... If you have any suggestions please post them on the discussion page
Contents |
Introduction
NAT (Network Address Translation) Traversal allows Low ID to Low ID connections. There are different techniques to achieve this, like STUN (Simple Traversal of UDP through NATs), or TURN (Traversal Using Relay NAT). For obvious reasons TURN is not suitable for any kind of file sharing applications. The NatT for eMule uses there for STUN, as well as a attempt to become a High ID by reusing the Listening port for outgoing connections, if the NAT device is a Full Cone this technique will make the client fully connectable, but it works only in a few cases. The main implementation using STUN can connect even through hardware firewalls, it only fails on Symmetric NAT’s, there are as well methods to penetrate these but they require to much overhead and are there fore like TURN not suitable for file sharing.
Protocol
The implementation is separated in 2 main segments: the Nat Traversal itself and a reliable streaming connection called User Mode TCP.
NAT Tunneling
To establish a communication tunnel from Alice to Bob through a NAT or a firewall Alice (A) sends first an call-back request to Carlo (C) witch records Alice’s UDP port and IP and relays them together with the request to Bob (B). At this point Bob knows all he needs but Alice does not know enough (she does not know his UDP port). Now Bob tries to contact Alice directly over UDP (now his NAT/FW is open for messages form Alice) if she is behind a Full Cone Nat, she will get the message and will be able to reply. If she don’t answers after a short time Bob sends an own call-back request to Carlo or Dave (this depends on the later described different call-back relay schemes), he does the same as before and tells Alice the UDP port and IP of Bob. Now she can send him messages and he will receive them (this fails only if one of the two have a symmetric NAT, see the appendix for explanation). If everything works they now have a working tunnel, to not loose it they exchange ping messages every few seconds as long as they need the tunnel.
A C B
Callback Req -----> ----->
[BLOCKED] <----------------- ping [OPENED]
<----- <----- Callback Req
ping [OPENED] ----------------->
<----------------- ping
handshake ................
Keep alive ping is sent from one of the 2 connection participants and contains a flag that determines weather the ping should be answered or not, it also contains additional informations used for connection establishment, and for obfuscation. The packet may be sent completely empty if no answer is requested and no data are appended.
[uint8] pOPS // bit Field
// 6 reserved
// 3 IdKind
// 1 req answer
[ID] // variable length determined by the Ping Options above
[Obfiscation] // uint8 obfuSetings
// hash128 userHash
Callback Methods
Text to be added
eServer (Official)
Text to be added
Kad (*Unofficial*)
Text to be added
XS (Neo & Co)
Text to be added
User Mode TCP
Du to the lack of reliability in UDP communication it is necessary to implement a streaming protocol that will be able to handle packet lost and retransmit missing ones. This implementation is basically a kind of self coded TCP with small modifications, it is called User Mode TCP and have almost all relevant features of the real TCP included (like congestion control).
Connection Begin
To establish a connection Alice (A) sends an NAT_SYN packet to Bob (B) over UDP. Bob answers on this request with an NAT_SYN_ACK, on the moment the Packet is received the connection is considered Established.
A B SYN ---> OnConnect(0) OnConnect(0) <--- SYN_ACK OnSend(0) [Connection Established]
Booth packets have the same content, like following:
[uint8] version [uint32] MAXFRAGSIZE (obtional)
Communication
All send data segments are equipped with a unique sequence number indicating their position in the data stream. When Bob (B) receives a NAT_DATA segment form Alice (A) he acknowledges it with an NAT_DATA_ACK, if Alice don’t get the acknowledgment she will resend the segment, she will also resend it if she gets acknowledgments for 3 segments with an higher sequence Number when the, while the a acknowledgment for the older segment is still missing (Fast retransmission).
A B
...
DATA ---> OnRecived(0)
OnSend(0) <--- DATA_ACK
...
The NAT_DATA packet have the following format:
[uint32] Sequence Nr. [Data] (obtional)
The NAT_DATA_ACK packet have the following format:
[uint32] Sequence Nr. [uint32] Receiving Window Size
Lost packets are handled as following:
A B
...
DATA1 ---> [LOST]
DATA2 --->
<--- DATA_ACK2
DATA3 --->
<--- DATA_ACK3
DATA4 --->
<--- DATA_ACK4
DATA1 ---> // fast retransmission
<--- DATA_ACK1
DATA5 --->
<--- DATA_ACK5
...
...
...
DATAn ---> [LOST]
TimeOut
DATAn ---> // regular retransmission
<--- DATA_ACKn
Alice never sends more data segments to Bob that would fit in the last Advertised receiving Window Size of Bob. When she can not send any data she sends empty NAT_DATA packets with the Sequence Nr set to 0, as soon as Bob will have some space in his receiving buffer he will answer with an NAT_DATA_ACK with sequence Nr set to 0 and a new > 0 Window Size. Than Alice will resume, to send data segments.
Alice uses some sophisticated techniques to determine a timeout time for the data segments as well as to determine how much segments she can sent before an acknowledgement arrives, this is called congestion control and designed basing on the normal TCP implementations, for further details please look into the NatT source code.
Connection End
To close a connection in the usual way Alice (A) sends an NAT_FIN packet to Bob (B), he replies with an NAT_FIN_ACK, on the moment the Packet is received the connection is considered Closed.
A B FIN ---> OnClose(0) OnClose(0) <--- FIN_ACK [Connection Closed]
Booth Packets have no content.
To terminate an errorless connection Alice (A) Sends an NAT_RST, packet and considers the connection closed, Bob (B) don’t answers on this packet and as well considers the connection closed at this point.
A B OnClose(err) RST ---> OnClose(err) [Connection Terminated]
The packet may contain an uint32 error code that is parsed to the OnClose function.
[uint32] ErrorCode
Appendix
NAT Types (from http://www.voip-info.org/wiki-STUN)
- Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
- Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
- Port Restricted Cone: A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
- Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host.
Spelling Note
All text I post here will be checked with M$ Word's spell checker, there for all spelling mistakes are the intellectual property of M$ ;)
