Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Oct 2009 12:23:52 -0600

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-masked]> 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-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Oct 2009 12:47:06 -0600

I think there is text about this in section 10.3. It says the  
information is in SubjectAltName field of the cert with an entry of  
type rfc822Name for user names and of type URI for node ids. The URI  
is as described in 13.12. It's all pretty terse but if you think more  
is needed, send me some text.

On Sep 17, 2009, at 3:08 AM, jc wrote:

> I looked at some other areas and the problem is the draft doesn't  
> clearly state fields that X509 certificates MUST contain or  
> misrepresents them case-wise.
>
> For instance:
>
> 7.  Certificate Store Usage
> user name
> Node-ID
>
> 12.5.1. Authorization
> User name
> Node-ID
> Serial
>
> There are several other references as well. Since this is a string  
> variable inside of an X509 certificate the names need to be case  
> normalized.
>
> Julian
>
> On Sep 16, 2009, at 10:30 PM, jc wrote:
>
>> Hi,
>> States "MAY contain any user name of the user choice",  this is  
>> subjectAltName?
>
> User name or user name?
>
>>
>> Julian

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Oct 2009 12:47:11 -0600

On Sep 24, 2009, at 3:01 PM, neil.young wrote:

> Probably the discussion you raised is worth a separate thread. I'm  
> currently in the situation to evaluate whether RELOAD is the way to  
> go or not (for our project). The scattered postings in this group  
> may lead to the conclusion, that RELOAD has no relevance at all. I  
> would be glad to hear, that this isn't the case.

Neil, this is the not case. Hope you are glad now.