For what it's worth, one of the implementations I am using allows a
UDP packet to get up two just under 2 MTU before fragmenting at the
RELOAD layer. So if the MTU is 1500, the peer might send a 2500 bytes
UDP packet and just depend on the network to reassemble the fragment.
The packet loss rates on the network this is running on are good
enough to run VoIP on it so the extra impact of this fragmentation at
the IP layer is not causing problems.
On Sep 30, 2009, at 9:08 PM, jc wrote:
On Sep 30, 2009, at 7:25 PM, Michael Chen wrote:
Julian,
My point is that what's left for Reload payload is 1492-1292 = 200
bytes. Many Reload messages will have to be fragmented.
I don't see the problem because TLS over TCP will be doing the same.
You will most likely be fragmenting 100% of all application level
messages and some percentage of RELOAD messages. Also DTLS has a bit
better performance than TLS over TCP.
--Michael
jc wrote:
This is greater than the MTU of an xbox 360 but less than your
averge router at 1492. Doesn't DTLS in OpenSSL already have the
real path MTU after the handshake? If not I know it can do this
for you. You can use that MTU and fragment your packets.
Julian
Sent from my iPhone
On Sep 30, 2009, at 10:50 AM, Michael Chen
<[email protected]> wrote:
Julian,
I have no scientific data, just a personal concern. Consider a
Reload STORE request with your 691 byte cert, the total fat (non-
payload) on the wire for a UDP/DTLS transport is:
DTLS header (13 bytes)
Reload header
Forward header (38 bytes)
Destination list (18 bytes, single hop)
Reload Message
STORE (SIP_REGISTRATION)
AOR
RSA Signature (256 bytes)
Reload Security Block
Certificates (691 bytes)
Signer ID (20+ bytes)
RSA Signature (256 bytes)
DTSL MAC and padding (20+ bytes)
These are rough numbers, and it total 1292 bytes excluding the
AOR. It is very close to the 1500 byte network packet size (MTU).
--Michael
jc wrote:
On Sep 24, 2009, at 9:35 PM, Michael Chen wrote:
I also want to point out that even with the most simple
encoding (JDK keytool), a 1024 bit RSA public key certificate
takes up 619 bytes. A production strength 2048 bit RSA cert is
880 bytes. If a peer can only be reached via UDP, the overhead
of DTLS + Reload Signature on message leaves very little room
for the relevant data fragment (e.g. 1500 packet size), which
means UDP transport may be very inefficient. Transport
overhead should be a separate discussion thread.
In my RELOAD implementation a 2048 bit RSA public key is 691
bytes long, see output below. Do you have statistics that show
the current fragmentation algorithm to be sub-optimal?
Julian
*
*
*Running 1 test case...*
*......................+++*
*........................+++*
*debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded
generating RSA key.*
*..............................+++*
*..............+++*
*debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded
generating RSA key.*
*debug: X509_NAME* junglecat::x509::allocate_common_name(const
char*): Allocated*
*debug: X509_NAME* junglecat::x509::allocate_common_name(const
char*): Allocated*
*debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*,
const char*, const char*, unsigned int, const EVP_MD*): Success*
*Certificate:*
* Data:*
* Version: 3 (0x2)*
* Serial Number: 1253857645 (0x4abc596d)*
* Signature Algorithm: sha1WithRSAEncryption*
* Issuer: CN=common_name_issuer*
* Validity*
* Not Before: Sep 25 05:47:25 2009 GMT*
* Not After : Sep 25 06:47:25 2009 GMT*
* Subject: CN=common_name*
* Subject Public Key Info:*
* Public Key Algorithm: rsaEncryption*
* RSA Public Key: (2048 bit)*
* Modulus (2048 bit):*
* 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:
02:*
* 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:
43:b2:b0:*
* aa:1a:7c:46:32:ad:93:b3:80:1b:dd:
62:d7:72:14:*
* aa:0e:43:7c:6b:
00:a6:56:f3:62:ed:b5:d4:ff:c4:*
* da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:
9d:f0:f3:6f:*
* d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:
1d:c7:*
* e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:
44:*
* 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:
04:8e:*
* 46:5c:13:1a:
85:68:d8:48:01:f9:03:75:98:e9:1f:*
* a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:
21:73:94:*
* 66:dd:d6:4a:13:79:7b:
19:91:75:f8:14:0e:ba:dd:*
* 01:79:83:0e:3f:e1:9a:10:ea:
98:cc:ae:d5:41:d7:*
* 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:
0c:ef:*
* b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:
3a:ca:*
* d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:
29:e8:1b:*
* cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:
05:2d:*
* 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:
74:aa:*
* 0a:d3*
* Exponent: 65537 (0x10001)*
* Signature Algorithm: sha1WithRSAEncryption*
* 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:*
* dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:*
* 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:*
* 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:*
* af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:*
* f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:*
* b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:*
* 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:*
* ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:*
* cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:*
* 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:*
* 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:*
* 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:*
* d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:*
* 8d:2a:7b:21*
*X509 structure size: 92*
*RSA structure size: 88*
len:691
**** No errors detected*
*
*
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
