Comments (8)
Revise getsockopt(MTU) to query the MTU from the IP layer, and return MTU - KTLS_DTLS_OVERHEAD to the user
How would you obtain the MTU from the IP layer?
Do not truncate records that above MTU size length. Instead, allow fragmentation to occur.
I think that is a reasonable approach.
from af_ktls.
How would you obtain the MTU from the IP layer?
I'm not too sure. It looks like TCP has some kind of "PMTU probe." but I think that may be too complicated for our purposes. Instead, I think we need only implement this:
The DTLS record layer SHOULD allow the upper layer protocol to
discover the amount of record expansion expected by the DTLS
processing. Note that this number is only an estimate because of
block padding and the potential use of DTLS compression.
We can change setsockopt(MTU) to take a MTU and return MTU - KTLS_DTLS_OVERHEAD from getsockopt(MTU), and let userspace decide how big the records should be.
from af_ktls.
Right now in KTLS, if the MTU is 1500, and the user tries to send a message of length 1501 over UDP, only 1500 bytes is transmitted in order to avoid IP fragmentation. In other words, KTLS is actively cutting down the size of records to avoid fragmentation.
The current implementation is performing such thing for sendfile(2)
(kernel_sendpage() respectively) for both TLS/TCP and DTLS/UDP: https://github.com/ktls/af_ktls/blob/master/af_ktls.c#L318 It was implemented since we were testing it with splice(2)
.
Note however that UDP (DTLS) is quiet tricky in this case. If we split a message "AABB" into "AA" + "BB" because of MTU transparently to user space, a receiver can read "BBAA" since DTLS is not dealing with out of order delivery.
Personally I would stick with returning an error code (such as E2BIG) and let user space deal with possible fragmentation (which could be in many cases application specific) - the user space should explicitly know about the risk here. IIRC, GnuTLS is doing something similar.
In general, DTLS's philosophy is to leave MTU discovery to the application.
That's also an argument why we should leave such setsockopt(2)
call.
... and let userspace decide how big the records should be.
Yes, that was the purpose of letting userspace to set MTU (according to possible MTU discovery).
from af_ktls.
Note however that UDP (DTLS) is quiet tricky in this case. If we split a message "AABB" into "AA" + "BB" because of MTU transparently to user space, a receiver can read "BBAA" since DTLS is not dealing with out of order delivery.
That's correct, but note that Lance was proposing sending the larger packet as a singleton and let IP framentation work in the middle routers. The end host will defragment such packets and thus the whole packet will be received in the correct order/size by the peer.
However letting the lower layer know is important as you mention. Currently in UDP this is done by applications setting the MTU discovery setsockopt() in the fd, informing the kernel to return EMSGSIZE if something is larger than the known MTU. I guess we could rely on the userspace app to set that option to the original fd, and propagate any error? For sure we need quite some tests around that.
from af_ktls.
I'm in favor of removing setsockopt MTU, and just dealing with it using MSG_MORE flag
from af_ktls.
Setting MTU was useful mostly for sendfile() where you get up to page size bytes in a one call. Without setting MTU it would be not possible to use DLTS - you would send up to 4096B+DTLS overhead in a one single UDP datagram, which is not doable on most networks.
from af_ktls.
Without setting MTU it would be not possible to use DLTS - you would send up to 4096B+DTLS overhead in a one single UDP datagram, which is not doable on most networks.
I don't understand why not? IP fragmentation exists for the purpose of sending large datagrams. UDP can send up to 65k messages using fragmentation, and like Nikos said, the end host can defragment the packets and thus the application layer receives packets as a whole. See the frag_list field in struct sk_buff.
from af_ktls.
Ah, ok. We can then use IP fragmentation and get rid of MTU setsockopt as Dave pointed out.
from af_ktls.
Related Issues (20)
- Test suite HOT 6
- new ciphersuite: chacha20-poly1305 HOT 1
- license is GPLv3
- Copy data from multiple TLS records to userspace buffer HOT 9
- Buffer changes HOT 6
- kernel fault when decrypting to user buffer HOT 7
- Crypto API scatterwalk copy HOT 2
- Allocating too many pages HOT 1
- Sleeping with lock held HOT 1
- possible lock inversion surrounding splice HOT 2
- Remove rx async work HOT 6
- Race condition in KTLS_RECV_READY HOT 2
- peek tcp data using tcp_read_sock HOT 2
- check sock_queue_rcv_skb return value HOT 4
- DTLS sliding window should always advance
- Investigate using a single FD
- DTLS window check needs to happen after decrypt
- Support async crypto API
- Paper might also wish to cite Plan 9's devtls as related work HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from af_ktls.