Open ShadowJonathan opened 2 years ago
The handshakers would probably want to decrease their MTU every time it retransmits, and store this suggestion value for the connection to use.
Though, i'll also want to make that MTU variable available to be altered on the connection objects, if the application discovers it can send bigger datagram packets then the connection objects are currently doing.
Also, i'd like a better name for the connection objects, "connection" is probably the wrong word, maybe "session"?
Also, i'd like a better name for the connection objects, "connection" is probably the wrong word, maybe "session"?
Draft 43 of DTLS v1.3 seems to define some terminology, I think it's best to have the names follow from these terms.
This is a draft for the API design I currently have in mind, i'm currently thinking of 5 main objects;
DClientAgent
, a handshaker state machine that performs in much the same wayrustls::ClientCommon
does, my current idea is as follows;poll()
, "i got an error", in quick succession, writing the fatal but buffering the error until next call?)poll()
will return with "success, here's your connection object"DClientSession
, a IO object for which the application can supply datagram packets, and supply it chunks of bytes it want to encode.rustls::ClientCommon
, only that it supplies exact datagrams, and no streams of data.write_tls
,read_tls
,wants_write
, etc. I don't believewants_read
is really needed, as all records are supposed to fit into one datagram, though i'll have to consult the RFC for that again.Read + Write
traitsDServerListener
, an object that handles all incoming "leftover" packets that do not belong to a connection, handlesClientHello
s withHelloVerifyRequest
s, verifiesClientHello
s with cookies, and if successful, then produces a handshaker object for the application to continue verifying with.DServerAgent
, pretty much the same asDClientAgent
, only on the different side of the transaction.DServerSession
, ditto.These objects basically give an entirely hands-off buffer-based black-box approach to DTLS connection handling, with the application being who needs to handle underlying
UdpSocket
multiplexing, routing, buffering, and more.This is to ensure this encryption layer can work over any kind of channel that is unreliable, unordered, but framed, this last guarantee is the most important one, and i'm not sure how to encode that into the IO. Rust doesn't give standard traits or libraries that "understand" a connections "framed-ness". Though luckily objects like
UdpSocket
don't provideWrite + Read
at all, and instead require manual polling of therecv
andsend
functions, so i think it's plenty okay to leave that functionality to a wrapping connection manager (such astokio-rustls
is torustls
)