Sorabh Hamirwasia created DRILL-5501:
----------------------------------------
Summary: Improve the negotiation of max_wrapped_size for
encryption.
Key: DRILL-5501
URL: https://issues.apache.org/jira/browse/DRILL-5501
Project: Apache Drill
Issue Type: Improvement
Reporter: Sorabh Hamirwasia
Assignee: Sorabh Hamirwasia
Fix For: Future
With 1.11 Drill will have the support for encryption using SASL framework. As
part of encryption negotiation SASL exposes bunch of parameters like QOP,
strength, maxbuffer and rawsendsize. The details on these parameters can be
found
[here|http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/javax/security/sasl/Sasl.java#Sasl].
This JIRA specifically is in reference to _maxbuffer_ and _rawsendsize_
parameter.
*rawsendsize* is the maximum plain text size which application should pass to
wrap function of a mechanism to produce an encoded buffer not exceeding
*maxbuffer* size. It is retrieved by application after negotiation is done for
_maxbuffer_.
*maxbuffer* parameter is the maximum received buffer size (encoded) that
client/server side agrees to receive. It is configurable in Drill using
*encryption.sasl.max_wrapped_size* configuration for client and bit to bit
connections. This parameter is global for all the supported mechanisms
configured. For an optimization this configuration is also used by each
connection SaslDecryptionHandler to create a pre-allocated buffer of that size.
Since each encrypted chunk will not exceed this configured value hence we can
re-use the same buffer each time to copy the encrypted chunk from wire and
decrypt it, instead of creating a buffer each time a message is received. Since
currently GSSAPI (or Kerberos) is the only available mechanism which is
supported by Drill with encryption so having this global parameter is fine. But
in future if more mechanisms are supported then it can be a issue, if the
mechanism doesn't support negotiation of this parameter instead just defines
internally to be a fixed value.
As per [SASL RFC|https://tools.ietf.org/html/rfc4422#section-3.7]:
_The maximum size that each side expects is fixed by the mechanism, either
through negotiation or by its specification_
This means this parameter can either be negotiated or can be fixed by
mechanisms. So in a case let say the parameter is configured to a value of 1MB
and there are 2 mechanisms which are configured {kerberos, custom}. custom
mechanism has defined fixed value of this parameter to be 64K whereas kerberos
can negotiate for 1MB size (since max allowed by GSSAPI is 16MB). Now each
connection will have a pre-define buffer of 1MB allocated in it's
SaslDecryptionHandler. For connection using custom mechanism there is wastage
in memory since the maximum encoded buffer it will ever receive is 64K. To
resolve this issue following solution is proposed:
1) Use the drill configuration _max_wrapped_size_ as the global value for
_maxbuffer_ parameter for all the mechanisms which support negotiation. For
mechanisms which has it's own pre-defined value of _maxbuffer_ the configured
value will be ignored.
2) In Drill we implement a factory like KerberosFactory / Plain Factory for all
the supported mechanisms. Each factory will be aware of the behavior of it's
underlying supported mechanism and use the configured value accordingly i.e.
with all the bounds checking / ignoring it totally as well. For example:
* Kerberos factory will know that it supports negotiation of _maxbuffer_ upto
max value of 16MB. So it can use the Drill configured value and perform the
bound check before setting it in SASL layer (i.e. when saslClient/saslServer
are created for negotiation)
* Custom factory will ignore this configuration value since it's underlying
mechanism has fixed defined value of _maxbuffer_ and will use that.
3) Once the Sasl layer is created the negotiation for the connection will
happen based on chosen mechanism. After negotiation is completed Drill can
retrieve the value of *maxbuffer* and corresponding *rawsendsize* using
saslClient/saslServer.getNegotiatedProperty() and set that in the
EncryptionContext instance of that connection.
4) I didn't found that the value of *maxbuffer* parameter is updated based on
negotiation internally in mechanism implementation (looked for GSSAPI) .So it
looks to me mechanism expects application to pass correct value within bounds.
Hence the need to check for bounds of configured value in corresponding factory
is needed (as mentioned in step 2), so that when the parameter value is
retrieved after negotiation the connection get's the correct value in it's
EncryptionContext.
5) Later when security handlers are added as part of each connection, it's
corresponding SaslDecryptionHandler will use the buffer size in
EncryptionContext (which was updated after negotiation) to allocate the buffer.
The above solution will resolve the issue seen in example discussed before. As
now kerberos mechanism will negotiate for 1MB MaxEncoded buffer size since it's
within it's max bound of 16MB whereas custom mechanism will ignore the
configured value and use fixed size of 64K defined by mechanism. Later when
Sasl negotiation is completed, the connection using Kerberos will set the
EncryptionContext.maxWrappedSize as 1MB and connection using custom mechanism
will set it's EncryptionContext.maxWrappedSize as 64K. And inside
SaslDecryptionHandler of each connection corresponding buffer of that size will
be allocated and there won't be any wastage of memory.
With the above approach we will achieve below:
* Have global config value for mechanism which have negotiating capability.
* We can have custom mechanism which doesn't support negotiating maxbuffer
value and not waste memory in SaslDecryptionHandler but still use the
optimization.
* Different connection using different mechanisms will have different footprint
of memory allocated as part of the re-usable buffer.
** For this we can have a counter for total memory in-use by
SaslDecryptionHandler re-usable buffer for each connection type
(user/control/data) across all such connections.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
