ReTurn ToDo List

From reSIProcate
Revision as of 13:32, 14 January 2009 by Sgodin (talk | contribs)
Jump to navigation Jump to search

General TODO

  • reduce library use - remove BOOST and/or rutil requirement - remove ASIO for client??
  • allow multiple interfaces to be used for relay
  • per user allocation quota enforcement
  • move TLS server settings to configuration
  • cleanup stun message class so that there are accessors for all data members
  • Configuration Framework
  • Multi-threaded support
  • Bandwidth check
  • TCP Relay
  • Short Term passwords do not make any sense in reTurnServer (outside of RFC3489 backcompat) - they need to be supported on client APIs


  • CreatePermission requests can contain multiple addresses - need to modify StunMessage in order to support this
  • Clients need to install permissions before data can be sent - need to queue outbound data until CreateChannel response is received
  • ChannelData messages must be padded to a multiple of 4 bytes, the padding is not to be reflected in the encoded length
  • When client receives a Data Ind - it should ensure it is from an endpoint that it believes that it has installed a permission for, otherwise drop
  • It is recommended that the client check if a permission exists towards the peer that just send a ChannelData message, if not - discard
  • Could add checking that ChannelData messages always begin with bits 0b01, since bits 0b10 and 0b11 are reserved
  • Need to give clients the ability to add Don't Fragment header to Allocate request
  • If request with Don't Fragment fails with 420 code, then it can be retried without Don't Fragment (this will likely remain the responsibilty of the reTurn client application)
  • It is recommended that the server impose limits on both the number of allocations active at one time for a given username and on the amount of bandwidth those allocations use. - 486 (Allocation Quota Exceeded)
  • Port allocation algorithm should be better to ensure we won't run into collisions with other applications - port allocations should be random
  • If the client receives a 400 response to a channel-bind request, then it is recommended that the allocation be deleted, and the client start again with a new allocation

RFC53389 TODO's

  • Username must contain UTF-8 sequence of bytes, and must have been processed by SASLprep
  • Realm qdtext or quoted-pair - It must UTF-8 encoded and MUST be less than 128 characters (which can be as long as 763 bytes), and must be processed by SASLprep
  • Nonce qdtext or quoted-pair - MUST be less than 128 characters (which can be as long as 763 bytes)
  • Software must be a UTF-8 sequence of less than 128 characters (which can be as long as 763 byes)
  • The Password used in the HMAC key must be SASLprep processed
  • remove quotes and trailing nulls from username, realm. remove trailing nulls from password before forming MD5 hash for message integrity
  • Errorcode Reason Phrase must be a UTF-8 sequence of less than 128 characters (which can be as long as 763 byes)
  • need handling for 300 Try Alternate response - currently applications responsibility
  • the following values should be configurable
    • Initial RTO (default 500ms)
    • Rc (default 7)
    • Rm (default 16)
  • actual RTO should be calculated
  • UDP retransmissions should stop if a hard ICMP error is seen
  • need to do client side TLS certificate hostname checks after successful handshake
  • DNS SRV Discovery - currently only does host record lookup (using ASIO) - _stun._udp, _stun._tcp, _stuns._tcp, _turn._udp, _turn._tcp, _turns._tcp

Client TODO

  • rework synchronous sockets to use Asynchrous sockets to unify implementation better
  • keepalive usage??
  • add option to require message integrity - depends on usage - ICE
  • add ability to install a permission or binding without sending data

Client Notes

  • retries should be paced at 500ms, 1000ms, 2000ms, etc. - after 442, 443, or 444 response - currently applications responsibility
  • If a client receives a 437 allocation mismatch response to an allocate, then it should retry using a different client transport address - it should do this 3 times (this will likely remain the responsibilty of the reTurn client application)
  • To prevent race conditions a client MUST wait 5 mins after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number (within the same allocation?).