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....@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.6000...@oracle.com>
> | Date: Thu, 20 Mar 2014 08:50:27 +0800
> | From: Xuelei Fan <xuelei....@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 <mh...@mhcomputing.net>
> | CC: OpenJDK <security-dev@openjdk.java.net>
> | Subject: Re: Review Request of JDK Enhancement Proposal: DTLS
> | References: <532a25ea.7040...@oracle.com>
> <20140320003158.ga5...@mhcomputing.net>
> | In-Reply-To: <20140320003158.ga5...@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
>
>
