[
https://issues.apache.org/jira/browse/HADOOP-10768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242567#comment-15242567
]
Dian Fu commented on HADOOP-10768:
----------------------------------
Hi [~drankye],
Thanks a lot for your comments. Have attached the design doc.
{quote}
I guess it's all about and for performance. Do you have any number to share?
{quote}
Correct. It's all about performance. I will post the performance data later
today.
{quote}
What's the impact? Does it mean to upgrade RPC version? Can external clients
still be able to talk with the server via SASL? How this affect downstream
components?
{quote}
The patch is backward compatible and so downstream components won't be
affected. So I think there is no need to upgrade RPC version as well.
{quote}
Looks like the work is mainly in SASL layer, when Kerberos is enabled, will it
still favor the GSSAPI mechanism? If not or it's bypassed, what encryption key
is used and how it's obtained?
{quote}
It still relies on GSSAPI mechanism or DIGEST-MD5 mechanism to do
authentication. At the end of the original SASL handshake, a pair of encryption
keys will be generated by RPC server randomly and sent to RPC client via the
secure SASL channel.
{quote}
Would you break it down? This one can be the umbrella.
{quote}
Good advice. I will split the patch to ease the review.
> Optimize Hadoop RPC encryption performance
> ------------------------------------------
>
> Key: HADOOP-10768
> URL: https://issues.apache.org/jira/browse/HADOOP-10768
> Project: Hadoop Common
> Issue Type: Improvement
> Components: performance, security
> Affects Versions: 3.0.0
> Reporter: Yi Liu
> Assignee: Dian Fu
> Attachments: HADOOP-10768.001.patch, HADOOP-10768.002.patch, Optimize
> Hadoop RPC encryption performance.pdf
>
>
> Hadoop RPC encryption is enabled by setting {{hadoop.rpc.protection}} to
> "privacy". It utilized SASL {{GSSAPI}} and {{DIGEST-MD5}} mechanisms for
> secure authentication and data protection. Even {{GSSAPI}} supports using
> AES, but without AES-NI support by default, so the encryption is slow and
> will become bottleneck.
> After discuss with [~atm], [~tucu00] and [~umamaheswararao], we can do the
> same optimization as in HDFS-6606. Use AES-NI with more than *20x* speedup.
> On the other hand, RPC message is small, but RPC is frequent and there may be
> lots of RPC calls in one connection, we needs to setup benchmark to see real
> improvement and then make a trade-off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)