You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Masakazu Kitajo <ma...@apache.org> on 2025/02/08 01:21:15 UTC
[API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Hi,
I'd like to propose a new TS API to access information from PROXY protocol.
ATS supports PROXY protocol, which carries connection information between a
client and a LB (basically the 5-tuple). And I recently added the support
for PROXY protocol version 2 TLV (Type-Length-Value) fields, which carry
additional information such as TLS parameters. However, the information
received is currently only available inside ATS core.
It'd be useful to export the information so that ATS plugins can access it.
An example use case is the Rate Limit plugin. The plugin is currently
almost useless if PROXY protocol is used, because the IP address that the
plugin can use is always the address of a LB, and there's no way to access
the server name in TLS SNI extension if the LB terminates TLS.
Here's the proposal:
TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char **value,
int *length);
TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
*value);
enum TSVConPPInfoKey {
TS_PP_INFO_VERSION = 0x10000,
TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
TS_PP_INFO_SRC_PORT,
TS_PP_INFO_DST_ADDR,
TS_PP_INFO_DST_PORT,
TS_PP_INFO_PROTOCOL,
TS_PP_INFO_SOCK_TYPE,
};
The function type signatures basiclly align with TSHttpTxnInfoIntGet.
The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
integer on PROXY protocol spec. This is to have a single interface to
access both the 5-tuple and TLV field values. Key value less than 0x10000
(65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
expected to cast the returned pointer accordingly or parse the returned
data.
I considered using the existing APIs with auto data source switching inside
the functions, but it's probably not a good idea because ATS will not be
able to access the information from the immediate connection. And TLV
fields can have arbitrary data, thus, we need a new API anyway. So, I think
the existing APIs should work as they are (i.e. returns information from
the immediate connection) so plugins can choose which one to use.
Thoughts?
PROXY protocol:
https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
Rate Limit plugin:
https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
-- Masakazu
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Masakazu Kitajo <m4...@gmail.com>.
I created a PR for this.
https://github.com/apache/trafficserver/pull/12032
Having ProxyProtocol in the name would be a bit confusing. One could read
it like VConnProxy and ProtocolInfo.
PROXY is an option, but not my preference.
I kept PP on the PR.
-- Masakazu
On Sun, Feb 9, 2025 at 11:19 AM Brian Neradt <br...@gmail.com> wrote:
> That’s another idea. I suppose between PROXY and PP I’d stick with PP.
>
> Brian
>
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
>
> On Sun, Feb 9, 2025 at 11:32 AM Leif Hedstrom <zw...@apache.org> wrote:
>
> > I’m +1 too.
> >
> > Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
> > case) instead of PP, which is how it’s spelled.
> >
> > — Leif
> >
> > On Sat, Feb 8, 2025 at 20:03 Brian Neradt <br...@gmail.com>
> wrote:
> >
> >> +1
> >>
> >> My preference would be to spell out ProxyProtocol in the API instead of
> >> PP. But I don't feel that strongly about it though. +1 either way.
> >>
> >> On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'd like to propose a new TS API to access information from PROXY
> >>> protocol.
> >>>
> >>> ATS supports PROXY protocol, which carries connection information
> >>> between a client and a LB (basically the 5-tuple). And I recently
> added the
> >>> support for PROXY protocol version 2 TLV (Type-Length-Value) fields,
> which
> >>> carry additional information such as TLS parameters. However, the
> >>> information received is currently only available inside ATS core.
> >>>
> >>> It'd be useful to export the information so that ATS plugins can access
> >>> it. An example use case is the Rate Limit plugin. The plugin is
> currently
> >>> almost useless if PROXY protocol is used, because the IP address that
> the
> >>> plugin can use is always the address of a LB, and there's no way to
> access
> >>> the server name in TLS SNI extension if the LB terminates TLS.
> >>>
> >>> Here's the proposal:
> >>>
> >>> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
> >>> **value, int *length);
> >>> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
> >>> *value);
> >>>
> >>> enum TSVConPPInfoKey {
> >>> TS_PP_INFO_VERSION = 0x10000,
> >>> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
> >>> TS_PP_INFO_SRC_PORT,
> >>> TS_PP_INFO_DST_ADDR,
> >>> TS_PP_INFO_DST_PORT,
> >>> TS_PP_INFO_PROTOCOL,
> >>> TS_PP_INFO_SOCK_TYPE,
> >>> };
> >>>
> >>> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
> >>>
> >>> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
> >>> integer on PROXY protocol spec. This is to have a single interface to
> >>> access both the 5-tuple and TLV field values. Key value less than
> 0x10000
> >>> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
> >>> expected to cast the returned pointer accordingly or parse the returned
> >>> data.
> >>>
> >>> I considered using the existing APIs with auto data source switching
> >>> inside the functions, but it's probably not a good idea because ATS
> will
> >>> not be able to access the information from the immediate connection.
> And
> >>> TLV fields can have arbitrary data, thus, we need a new API anyway.
> So, I
> >>> think the existing APIs should work as they are (i.e. returns
> information
> >>> from the immediate connection) so plugins can choose which one to use.
> >>>
> >>> Thoughts?
> >>>
> >>> PROXY protocol:
> >>> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
> >>>
> >>> Rate Limit plugin:
> >>>
> >>>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
> >>>
> >>> -- Masakazu
> >>>
> >>
> >>
> >> --
> >> "Come to Me, all who are weary and heavy-laden, and I will
> >> give you rest. Take My yoke upon you and learn from Me, for
> >> I am gentle and humble in heart, and you will find rest for
> >> your souls. For My yoke is easy and My burden is light."
> >>
> >> ~ Matthew 11:28-30
> >>
> >
>
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Brian Neradt <br...@gmail.com>.
That’s another idea. I suppose between PROXY and PP I’d stick with PP.
Brian
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
On Sun, Feb 9, 2025 at 11:32 AM Leif Hedstrom <zw...@apache.org> wrote:
> I’m +1 too.
>
> Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
> case) instead of PP, which is how it’s spelled.
>
> — Leif
>
> On Sat, Feb 8, 2025 at 20:03 Brian Neradt <br...@gmail.com> wrote:
>
>> +1
>>
>> My preference would be to spell out ProxyProtocol in the API instead of
>> PP. But I don't feel that strongly about it though. +1 either way.
>>
>> On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> I'd like to propose a new TS API to access information from PROXY
>>> protocol.
>>>
>>> ATS supports PROXY protocol, which carries connection information
>>> between a client and a LB (basically the 5-tuple). And I recently added the
>>> support for PROXY protocol version 2 TLV (Type-Length-Value) fields, which
>>> carry additional information such as TLS parameters. However, the
>>> information received is currently only available inside ATS core.
>>>
>>> It'd be useful to export the information so that ATS plugins can access
>>> it. An example use case is the Rate Limit plugin. The plugin is currently
>>> almost useless if PROXY protocol is used, because the IP address that the
>>> plugin can use is always the address of a LB, and there's no way to access
>>> the server name in TLS SNI extension if the LB terminates TLS.
>>>
>>> Here's the proposal:
>>>
>>> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
>>> **value, int *length);
>>> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
>>> *value);
>>>
>>> enum TSVConPPInfoKey {
>>> TS_PP_INFO_VERSION = 0x10000,
>>> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
>>> TS_PP_INFO_SRC_PORT,
>>> TS_PP_INFO_DST_ADDR,
>>> TS_PP_INFO_DST_PORT,
>>> TS_PP_INFO_PROTOCOL,
>>> TS_PP_INFO_SOCK_TYPE,
>>> };
>>>
>>> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>>>
>>> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
>>> integer on PROXY protocol spec. This is to have a single interface to
>>> access both the 5-tuple and TLV field values. Key value less than 0x10000
>>> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
>>> expected to cast the returned pointer accordingly or parse the returned
>>> data.
>>>
>>> I considered using the existing APIs with auto data source switching
>>> inside the functions, but it's probably not a good idea because ATS will
>>> not be able to access the information from the immediate connection. And
>>> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
>>> think the existing APIs should work as they are (i.e. returns information
>>> from the immediate connection) so plugins can choose which one to use.
>>>
>>> Thoughts?
>>>
>>> PROXY protocol:
>>> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>>>
>>> Rate Limit plugin:
>>>
>>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>>>
>>> -- Masakazu
>>>
>>
>>
>> --
>> "Come to Me, all who are weary and heavy-laden, and I will
>> give you rest. Take My yoke upon you and learn from Me, for
>> I am gentle and humble in heart, and you will find rest for
>> your souls. For My yoke is easy and My burden is light."
>>
>> ~ Matthew 11:28-30
>>
>
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Brian Neradt <br...@gmail.com>.
That’s another idea. I suppose between PROXY and PP I’d stick with PP.
Brian
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
On Sun, Feb 9, 2025 at 11:32 AM Leif Hedstrom <zw...@apache.org> wrote:
> I’m +1 too.
>
> Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
> case) instead of PP, which is how it’s spelled.
>
> — Leif
>
> On Sat, Feb 8, 2025 at 20:03 Brian Neradt <br...@gmail.com> wrote:
>
>> +1
>>
>> My preference would be to spell out ProxyProtocol in the API instead of
>> PP. But I don't feel that strongly about it though. +1 either way.
>>
>> On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> I'd like to propose a new TS API to access information from PROXY
>>> protocol.
>>>
>>> ATS supports PROXY protocol, which carries connection information
>>> between a client and a LB (basically the 5-tuple). And I recently added the
>>> support for PROXY protocol version 2 TLV (Type-Length-Value) fields, which
>>> carry additional information such as TLS parameters. However, the
>>> information received is currently only available inside ATS core.
>>>
>>> It'd be useful to export the information so that ATS plugins can access
>>> it. An example use case is the Rate Limit plugin. The plugin is currently
>>> almost useless if PROXY protocol is used, because the IP address that the
>>> plugin can use is always the address of a LB, and there's no way to access
>>> the server name in TLS SNI extension if the LB terminates TLS.
>>>
>>> Here's the proposal:
>>>
>>> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
>>> **value, int *length);
>>> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
>>> *value);
>>>
>>> enum TSVConPPInfoKey {
>>> TS_PP_INFO_VERSION = 0x10000,
>>> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
>>> TS_PP_INFO_SRC_PORT,
>>> TS_PP_INFO_DST_ADDR,
>>> TS_PP_INFO_DST_PORT,
>>> TS_PP_INFO_PROTOCOL,
>>> TS_PP_INFO_SOCK_TYPE,
>>> };
>>>
>>> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>>>
>>> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
>>> integer on PROXY protocol spec. This is to have a single interface to
>>> access both the 5-tuple and TLV field values. Key value less than 0x10000
>>> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
>>> expected to cast the returned pointer accordingly or parse the returned
>>> data.
>>>
>>> I considered using the existing APIs with auto data source switching
>>> inside the functions, but it's probably not a good idea because ATS will
>>> not be able to access the information from the immediate connection. And
>>> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
>>> think the existing APIs should work as they are (i.e. returns information
>>> from the immediate connection) so plugins can choose which one to use.
>>>
>>> Thoughts?
>>>
>>> PROXY protocol:
>>> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>>>
>>> Rate Limit plugin:
>>>
>>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>>>
>>> -- Masakazu
>>>
>>
>>
>> --
>> "Come to Me, all who are weary and heavy-laden, and I will
>> give you rest. Take My yoke upon you and learn from Me, for
>> I am gentle and humble in heart, and you will find rest for
>> your souls. For My yoke is easy and My burden is light."
>>
>> ~ Matthew 11:28-30
>>
>
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Leif Hedstrom <zw...@apache.org>.
I’m +1 too.
Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
case) instead of PP, which is how it’s spelled.
— Leif
On Sat, Feb 8, 2025 at 20:03 Brian Neradt <br...@gmail.com> wrote:
> +1
>
> My preference would be to spell out ProxyProtocol in the API instead of
> PP. But I don't feel that strongly about it though. +1 either way.
>
> On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org> wrote:
>
>> Hi,
>>
>> I'd like to propose a new TS API to access information from PROXY
>> protocol.
>>
>> ATS supports PROXY protocol, which carries connection information between
>> a client and a LB (basically the 5-tuple). And I recently added the support
>> for PROXY protocol version 2 TLV (Type-Length-Value) fields, which carry
>> additional information such as TLS parameters. However, the information
>> received is currently only available inside ATS core.
>>
>> It'd be useful to export the information so that ATS plugins can access
>> it. An example use case is the Rate Limit plugin. The plugin is currently
>> almost useless if PROXY protocol is used, because the IP address that the
>> plugin can use is always the address of a LB, and there's no way to access
>> the server name in TLS SNI extension if the LB terminates TLS.
>>
>> Here's the proposal:
>>
>> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
>> **value, int *length);
>> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
>> *value);
>>
>> enum TSVConPPInfoKey {
>> TS_PP_INFO_VERSION = 0x10000,
>> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
>> TS_PP_INFO_SRC_PORT,
>> TS_PP_INFO_DST_ADDR,
>> TS_PP_INFO_DST_PORT,
>> TS_PP_INFO_PROTOCOL,
>> TS_PP_INFO_SOCK_TYPE,
>> };
>>
>> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>>
>> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
>> integer on PROXY protocol spec. This is to have a single interface to
>> access both the 5-tuple and TLV field values. Key value less than 0x10000
>> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
>> expected to cast the returned pointer accordingly or parse the returned
>> data.
>>
>> I considered using the existing APIs with auto data source switching
>> inside the functions, but it's probably not a good idea because ATS will
>> not be able to access the information from the immediate connection. And
>> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
>> think the existing APIs should work as they are (i.e. returns information
>> from the immediate connection) so plugins can choose which one to use.
>>
>> Thoughts?
>>
>> PROXY protocol:
>> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>>
>> Rate Limit plugin:
>>
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>>
>> -- Masakazu
>>
>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Leif Hedstrom <zw...@apache.org>.
I’m +1 too.
Adding ProxyProtocol seems pretty long, maybe we can use PROXY (all upper
case) instead of PP, which is how it’s spelled.
— Leif
On Sat, Feb 8, 2025 at 20:03 Brian Neradt <br...@gmail.com> wrote:
> +1
>
> My preference would be to spell out ProxyProtocol in the API instead of
> PP. But I don't feel that strongly about it though. +1 either way.
>
> On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org> wrote:
>
>> Hi,
>>
>> I'd like to propose a new TS API to access information from PROXY
>> protocol.
>>
>> ATS supports PROXY protocol, which carries connection information between
>> a client and a LB (basically the 5-tuple). And I recently added the support
>> for PROXY protocol version 2 TLV (Type-Length-Value) fields, which carry
>> additional information such as TLS parameters. However, the information
>> received is currently only available inside ATS core.
>>
>> It'd be useful to export the information so that ATS plugins can access
>> it. An example use case is the Rate Limit plugin. The plugin is currently
>> almost useless if PROXY protocol is used, because the IP address that the
>> plugin can use is always the address of a LB, and there's no way to access
>> the server name in TLS SNI extension if the LB terminates TLS.
>>
>> Here's the proposal:
>>
>> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
>> **value, int *length);
>> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
>> *value);
>>
>> enum TSVConPPInfoKey {
>> TS_PP_INFO_VERSION = 0x10000,
>> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
>> TS_PP_INFO_SRC_PORT,
>> TS_PP_INFO_DST_ADDR,
>> TS_PP_INFO_DST_PORT,
>> TS_PP_INFO_PROTOCOL,
>> TS_PP_INFO_SOCK_TYPE,
>> };
>>
>> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>>
>> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
>> integer on PROXY protocol spec. This is to have a single interface to
>> access both the 5-tuple and TLV field values. Key value less than 0x10000
>> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
>> expected to cast the returned pointer accordingly or parse the returned
>> data.
>>
>> I considered using the existing APIs with auto data source switching
>> inside the functions, but it's probably not a good idea because ATS will
>> not be able to access the information from the immediate connection. And
>> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
>> think the existing APIs should work as they are (i.e. returns information
>> from the immediate connection) so plugins can choose which one to use.
>>
>> Thoughts?
>>
>> PROXY protocol:
>> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>>
>> Rate Limit plugin:
>>
>> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>>
>> -- Masakazu
>>
>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Brian Neradt <br...@gmail.com>.
+1
My preference would be to spell out ProxyProtocol in the API instead of PP.
But I don't feel that strongly about it though. +1 either way.
On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org> wrote:
> Hi,
>
> I'd like to propose a new TS API to access information from PROXY protocol.
>
> ATS supports PROXY protocol, which carries connection information between
> a client and a LB (basically the 5-tuple). And I recently added the support
> for PROXY protocol version 2 TLV (Type-Length-Value) fields, which carry
> additional information such as TLS parameters. However, the information
> received is currently only available inside ATS core.
>
> It'd be useful to export the information so that ATS plugins can access
> it. An example use case is the Rate Limit plugin. The plugin is currently
> almost useless if PROXY protocol is used, because the IP address that the
> plugin can use is always the address of a LB, and there's no way to access
> the server name in TLS SNI extension if the LB terminates TLS.
>
> Here's the proposal:
>
> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
> **value, int *length);
> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
> *value);
>
> enum TSVConPPInfoKey {
> TS_PP_INFO_VERSION = 0x10000,
> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
> TS_PP_INFO_SRC_PORT,
> TS_PP_INFO_DST_ADDR,
> TS_PP_INFO_DST_PORT,
> TS_PP_INFO_PROTOCOL,
> TS_PP_INFO_SOCK_TYPE,
> };
>
> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>
> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
> integer on PROXY protocol spec. This is to have a single interface to
> access both the 5-tuple and TLV field values. Key value less than 0x10000
> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
> expected to cast the returned pointer accordingly or parse the returned
> data.
>
> I considered using the existing APIs with auto data source switching
> inside the functions, but it's probably not a good idea because ATS will
> not be able to access the information from the immediate connection. And
> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
> think the existing APIs should work as they are (i.e. returns information
> from the immediate connection) so plugins can choose which one to use.
>
> Thoughts?
>
> PROXY protocol:
> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>
> Rate Limit plugin:
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>
> -- Masakazu
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
Re: [API Proposal] TSVConnPPInfoGet to access information from PROXY protocol
Posted by Brian Neradt <br...@gmail.com>.
+1
My preference would be to spell out ProxyProtocol in the API instead of PP.
But I don't feel that strongly about it though. +1 either way.
On Fri, Feb 7, 2025 at 7:21 PM Masakazu Kitajo <ma...@apache.org> wrote:
> Hi,
>
> I'd like to propose a new TS API to access information from PROXY protocol.
>
> ATS supports PROXY protocol, which carries connection information between
> a client and a LB (basically the 5-tuple). And I recently added the support
> for PROXY protocol version 2 TLV (Type-Length-Value) fields, which carry
> additional information such as TLS parameters. However, the information
> received is currently only available inside ATS core.
>
> It'd be useful to export the information so that ATS plugins can access
> it. An example use case is the Rate Limit plugin. The plugin is currently
> almost useless if PROXY protocol is used, because the IP address that the
> plugin can use is always the address of a LB, and there's no way to access
> the server name in TLS SNI extension if the LB terminates TLS.
>
> Here's the proposal:
>
> TSReturnCode TSVConnPPInfoGet(TSVConn vc, uint32_t key, const char
> **value, int *length);
> TSReturnCode TSVConnPPInfoIntGet(TSVConn vc, uint32_t key, TSMgmtInt
> *value);
>
> enum TSVConPPInfoKey {
> TS_PP_INFO_VERSION = 0x10000,
> TS_PP_INFO_SRC_ADDR, // Returns a pointer for struct sockaddr
> TS_PP_INFO_SRC_PORT,
> TS_PP_INFO_DST_ADDR,
> TS_PP_INFO_DST_PORT,
> TS_PP_INFO_PROTOCOL,
> TS_PP_INFO_SOCK_TYPE,
> };
>
> The function type signatures basiclly align with TSHttpTxnInfoIntGet.
>
> The "key" parameter is a 32 bit integer, although TLV type is a 16 bit
> integer on PROXY protocol spec. This is to have a single interface to
> access both the 5-tuple and TLV field values. Key value less than 0x10000
> (65536) will be considered as a TLV type. Users of TSVConnPPInfoGet are
> expected to cast the returned pointer accordingly or parse the returned
> data.
>
> I considered using the existing APIs with auto data source switching
> inside the functions, but it's probably not a good idea because ATS will
> not be able to access the information from the immediate connection. And
> TLV fields can have arbitrary data, thus, we need a new API anyway. So, I
> think the existing APIs should work as they are (i.e. returns information
> from the immediate connection) so plugins can choose which one to use.
>
> Thoughts?
>
> PROXY protocol:
> https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt
>
> Rate Limit plugin:
>
> https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/rate_limit.en.html
>
> -- Masakazu
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30