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
