Review Request of JDK Enhancement Proposal: DTLS

Matthew Hall mhall at mhcomputing.net
Sat Mar 22 06:48:46 UTC 2014


The following bug and source code [1] are present in OpenSSL:

http://rt.openssl.org/Ticket/Display.html?id=1929

I think something similar could be done in the JDK, by making some tweaks to 
the SocketOptions classes to expose some more options. I'm pretty sure 
something relating to this will work in POSIX JDK for Linux, Solaris, OS X, 
but not sure what different magic would be needed for Windows.

Then there could be some kind of way to generate the right discovery 
datagrams, figure out the result, and feed it to the DTLSEngine for 
packetization purposes.

Also, there is some DTLS capability in Bouncy Castle, we could see what they 
allow in terms of packetization as well, though I doubt they'll have what 
OpenSSL has, since IP_MTU_DISCOVER is probably not available to them either.

I am glad you guys are working on this... I already have some use cases in 
mind for it! :-D

Matthew.

Reference [1]:

        case BIO_CTRL_DGRAM_MTU_DISCOVER:
#if defined(OPENSSL_SYS_LINUX) && defined(IP_MTU_DISCOVER) && defined(IP_PMTUDISC_DO)
                addr_len = (socklen_t)sizeof(addr);
                memset((void *)&addr, 0, sizeof(addr));
                if (getsockname(b->num, &addr.sa, &addr_len) < 0)
                        {
                        ret = 0;
                        break;
                        }
                switch (addr.sa.sa_family)
                        {
                case AF_INET:
                        sockopt_val = IP_PMTUDISC_DO;
                        if ((ret = setsockopt(b->num, IPPROTO_IP, IP_MTU_DISCOVER,
                                &sockopt_val, sizeof(sockopt_val))) < 0)
                                perror("setsockopt");
                        break;
#if OPENSSL_USE_IPV6 && defined(IPV6_MTU_DISCOVER) && defined(IPV6_PMTUDISC_DO)
                case AF_INET6:
                        sockopt_val = IPV6_PMTUDISC_DO;
                        if ((ret = setsockopt(b->num, IPPROTO_IPV6, IPV6_MTU_DISCOVER,
                                &sockopt_val, sizeof(sockopt_val))) < 0)
                                perror("setsockopt");
                        break;
#endif


On Fri, Mar 21, 2014 at 07:46:22PM -0400, Christos Zoulas wrote:
> On Mar 22,  7:38am, xuelei.fan at oracle.com (Xuelei Fan) wrote:
> -- Subject: Re: Review Request of JDK Enhancement Proposal: DTLS
> 
> | Networking experts, any suggestion?
> 
> I have not seen pmtu exposed at the application layer before. Has anyone
> else?
> 
> christos
> 
> | 
> | Xuelei
> | 
> | On 3/21/2014 8:28 AM, Matthew Hall wrote:
> | > On Fri, Mar 21, 2014 at 06:58:50AM +0800, Xuelei Fan wrote:
> | >> here. Although MTU is not PMTU, but it is normally "correct".
> | > 
> | > I would state, not "normally correct", but "frequently correct".
> | > 
> | > In case of IPSEC, SSL VPN, IPv6, GRE, etc. this will not be true. Many of 
> | > these are used for Site-to-Site VPN, which will appear often in the context of 
> | > RTP packets and SRTP packets, which happen to travel over VPNs.
> | > 
> | >> It would be great if there is PMTU discovery API in Java, which can
> | >> simplify the implementation of DTLS.
> | > 
> | > Without it, I think there will be a lot of odd bugs occurring.
> | > 
> | > Matthew.
> | > 
> | 
> | 
> | --------------090406030702020009070402
> | Content-Type: message/rfc822;
> |  name="Attached Message"
> | Content-Transfer-Encoding: 7bit
> | Content-Disposition: attachment;
> |  filename="Attached Message"
> | 
> | Message-ID: <532A3B53.6000407 at oracle.com>
> | Date: Thu, 20 Mar 2014 08:50:27 +0800
> | From: Xuelei Fan <xuelei.fan at oracle.com>
> | User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
> | MIME-Version: 1.0
> | To: Matthew Hall <mhall at mhcomputing.net>
> | CC: OpenJDK <security-dev at openjdk.java.net>
> | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS
> | References: <532A25EA.7040802 at oracle.com> <20140320003158.GA5754 at mhcomputing.net>
> | In-Reply-To: <20140320003158.GA5754 at mhcomputing.net>
> | Content-Type: text/plain; charset=ISO-8859-1
> | Content-Transfer-Encoding: 7bit
> | 
> | PMTU is a key point of the design.  I was wondering to expose this
> | application layer as a configurable parameter.  If it is too big (or not
> | configured), DTLSEngine(let call it temporarily) will downgrade the size
> | automatically, just as the previous messages get lost.
> | 
> | It's good point that need a separate spec to determine the PMTU. I will
> | see what we can do here.
> | 
> | Thanks,
> | Xuelei
> | 
> | On 3/20/2014 8:31 AM, Matthew Hall wrote:
> | > Xuelei,
> | > 
> | > Is there an existing method for determining valid PMTU from inside of Java? If 
> | > not then supplying correct segment size to whatever DTLSEngine (or however 
> | > it's named) class would be non-trivial and could require native code.
> | > 
> | > If there is not such support, then a separate spec would be needed to add that 
> | > support, before it would be possible to get the new DTLS support to work very 
> | > reliably.
> | > 
> | > Matthew.
> | > 
> | > On Thu, Mar 20, 2014 at 07:19:06AM +0800, Xuelei Fan wrote:
> | >> Hi,
> | >>
> | >> Please review the JDK Enhancement Proposal, Support Datagram Transport
> | >> Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the
> | >> JSSE API and the SunJSSE security provider. Detailed, please refer to
> | >> the draft JEP:
> | >>
> | >> http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt
> | >>
> | >> Feel free to make comment and send your feedback to the alias.
> | >>
> | >> Thanks,
> | >> Xuelei
> | 
> | 
> | --------------090406030702020009070402--
> -- End of excerpt from Xuelei Fan
> 
> 



More information about the security-dev mailing list