From juan.navarro at gmx.es Thu Dec 5 15:21:15 2019 From: juan.navarro at gmx.es (Juan Navarro) Date: Thu, 5 Dec 2019 16:21:15 +0100 Subject: [libnice] New method proposal: nice_agent_set_port_exclusions() Message-ID: <65be3d23-ecf6-da09-39fd-8e02505a3541@gmx.es> Hi, I've been experimenting with the idea of adding a new method to NiceAgent: a function similar to nice_agent_set_port_range() but with a complimentary purpose. While set_port_range() is able to define, well, a port range that should be used for local candidates during the gathering process, a method such as nice_agent_set_port_exclusions() would be able to define a set of ports that should be _avoided_. The method would have a signature such as this: nice_agent_set_port_exclusions (     NiceAgent *agent,     guint stream_id,     guint component_id,     gchar* ports); And 'ports' would be a string such as this: "1234,5678,2000-4000" Meaning: * Don't use port 1234 * Don't use port 5678 * Don't use any port between 2000 and 4000 (inclusive) The rationale for such feature is that it adapts better to the needs that are common in typical cloud deployments, where a specific set of control ports should not be made accessible from the outside, with no reason whatsoever to prevent such access from all other ports in between. For a concrete example: A quick glance at one test Kubernetes deployment shows that these ports are sensitive and shouldn't be opened up to the public: 22/tcp 25/tcp 67/udp 68/udp 111/tcp 111/udp 123/udp 137/udp 138/udp 139/tcp 139/udp 179/tcp 445/tcp 445/udp 1214/udp 1900/udp 4662/tcp 6346/tcp 6346/udp 6699/tcp These include control ports for Kubernetes itself. Instead of finding what is the biggest range that can be opened without touching any of those ports, it would be just easier (and easier to maintain for the Devops guys) to just specify a blacklist that includes all these ports, and pass it to libnice: nice_agent_set_port_exclusions("22,25,67,68,111,123,137-139,179,445,1214,1900,4662,6346,6699") I already have code that implements this, and having it in upstream is always nicer than maintaining it downstream. Would this feature be interesting for libnice? If so, I'd open a Merge Request for discussion and code review. Regards, Juan -- Juan Navarro Kurento maintainer & developer j1elo @ Twitter / GitHub -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.crete at collabora.com Thu Dec 5 16:13:32 2019 From: olivier.crete at collabora.com (=?ISO-8859-1?Q?Olivier_Cr=EAte?=) Date: Thu, 05 Dec 2019 11:13:32 -0500 Subject: [libnice] New method proposal: nice_agent_set_port_exclusions() In-Reply-To: <65be3d23-ecf6-da09-39fd-8e02505a3541@gmx.es> References: <65be3d23-ecf6-da09-39fd-8e02505a3541@gmx.es> Message-ID: <8637C77C-B5F7-4848-90F4-4CFA3BCE72A2@collabora.com> Hi, Yes do open a MR, it sounds like a good feature to have. Olivier On December 5, 2019 10:21:15 a.m. EST, Juan Navarro wrote: >Hi, > >I've been experimenting with the idea of adding a new method to >NiceAgent: a function similar to nice_agent_set_port_range() but with a >complimentary purpose. While set_port_range() is able to define, well, >a >port range that should be used for local candidates during the >gathering >process, a method such as nice_agent_set_port_exclusions() would be >able >to define a set of ports that should be _avoided_. > >The method would have a signature such as this: > >nice_agent_set_port_exclusions ( >     NiceAgent *agent, >     guint stream_id, >     guint component_id, >     gchar* ports); > >And 'ports' would be a string such as this: > >"1234,5678,2000-4000" > >Meaning: >* Don't use port 1234 >* Don't use port 5678 >* Don't use any port between 2000 and 4000 (inclusive) > >The rationale for such feature is that it adapts better to the needs >that are common in typical cloud deployments, where a specific set of >control ports should not be made accessible from the outside, with no >reason whatsoever to prevent such access from all other ports in >between. > >For a concrete example: A quick glance at one test Kubernetes >deployment >shows that these ports are sensitive and shouldn't be opened up to the >public: > >22/tcp >25/tcp >67/udp >68/udp >111/tcp >111/udp >123/udp >137/udp >138/udp >139/tcp >139/udp >179/tcp >445/tcp >445/udp >1214/udp >1900/udp >4662/tcp >6346/tcp >6346/udp >6699/tcp > >These include control ports for Kubernetes itself. > >Instead of finding what is the biggest range that can be opened without >touching any of those ports, it would be just easier (and easier to >maintain for the Devops guys) to just specify a blacklist that includes >all these ports, and pass it to libnice: > >nice_agent_set_port_exclusions("22,25,67,68,111,123,137-139,179,445,1214,1900,4662,6346,6699") > > >I already have code that implements this, and having it in upstream is >always nicer than maintaining it downstream. Would this feature be >interesting for libnice? If so, I'd open a Merge Request for discussion >and code review. > >Regards, >Juan > > >-- >Juan Navarro >Kurento maintainer & developer >j1elo @ Twitter / GitHub > -- Olivier Crête olivier.crete at collabora.com From juan.navarro at gmx.es Thu Dec 5 17:11:17 2019 From: juan.navarro at gmx.es (Juan Navarro) Date: Thu, 5 Dec 2019 18:11:17 +0100 Subject: [libnice] New method proposal: nice_agent_set_port_exclusions() In-Reply-To: <8637C77C-B5F7-4848-90F4-4CFA3BCE72A2@collabora.com> References: <65be3d23-ecf6-da09-39fd-8e02505a3541@gmx.es> <8637C77C-B5F7-4848-90F4-4CFA3BCE72A2@collabora.com> Message-ID: <92869d21-2691-3334-110c-d5f22bd47b09@gmx.es> Done; we can track it here: https://gitlab.freedesktop.org/libnice/libnice/merge_requests/82 On 5/12/19 17:13, Olivier Crête wrote: > Hi, > > Yes do open a MR, it sounds like a good feature to have. > > Olivier > > On December 5, 2019 10:21:15 a.m. EST, Juan Navarro wrote: >> Hi, >> >> I've been experimenting with the idea of adding a new method to >> NiceAgent: a function similar to nice_agent_set_port_range() but with a >> complimentary purpose. While set_port_range() is able to define, well, >> a >> port range that should be used for local candidates during the >> gathering >> process, a method such as nice_agent_set_port_exclusions() would be >> able >> to define a set of ports that should be _avoided_. >> >> The method would have a signature such as this: >> >> nice_agent_set_port_exclusions ( >>     NiceAgent *agent, >>     guint stream_id, >>     guint component_id, >>     gchar* ports); >> >> And 'ports' would be a string such as this: >> >> "1234,5678,2000-4000" >> >> Meaning: >> * Don't use port 1234 >> * Don't use port 5678 >> * Don't use any port between 2000 and 4000 (inclusive) >> >> The rationale for such feature is that it adapts better to the needs >> that are common in typical cloud deployments, where a specific set of >> control ports should not be made accessible from the outside, with no >> reason whatsoever to prevent such access from all other ports in >> between. >> >> For a concrete example: A quick glance at one test Kubernetes >> deployment >> shows that these ports are sensitive and shouldn't be opened up to the >> public: >> >> 22/tcp >> 25/tcp >> 67/udp >> 68/udp >> 111/tcp >> 111/udp >> 123/udp >> 137/udp >> 138/udp >> 139/tcp >> 139/udp >> 179/tcp >> 445/tcp >> 445/udp >> 1214/udp >> 1900/udp >> 4662/tcp >> 6346/tcp >> 6346/udp >> 6699/tcp >> >> These include control ports for Kubernetes itself. >> >> Instead of finding what is the biggest range that can be opened without >> touching any of those ports, it would be just easier (and easier to >> maintain for the Devops guys) to just specify a blacklist that includes >> all these ports, and pass it to libnice: >> >> nice_agent_set_port_exclusions("22,25,67,68,111,123,137-139,179,445,1214,1900,4662,6346,6699") >> >> >> I already have code that implements this, and having it in upstream is >> always nicer than maintaining it downstream. Would this feature be >> interesting for libnice? If so, I'd open a Merge Request for discussion >> and code review. >> >> Regards, >> Juan >> >> >> -- >> Juan Navarro >> Kurento maintainer & developer >> j1elo @ Twitter / GitHub >>