Switch tipo 3 Acceso de 48 Puertos - Solicitamos a la Convocante eliminar los requerimientos:
1. Deberá permitir la negociación de POE en LLDP-MED y Debe soportar Energy-Efficient Ethernet (EEE).
2. Debe soportar Energy-Efficient Ethernet (EEE)
Teniendo en cuenta que para el bien requerido no se están requiriendo puertos PoE, y cuyos requerimientos agregan complejidad innecesaria a la solución a ser ofertada.
Esto favorecerá a una mayor participación de potenciales oferentes.
Switch tipo 3 Acceso de 48 Puertos - Solicitamos a la Convocante eliminar los requerimientos:
1. Deberá permitir la negociación de POE en LLDP-MED y Debe soportar Energy-Efficient Ethernet (EEE).
2. Debe soportar Energy-Efficient Ethernet (EEE)
Teniendo en cuenta que para el bien requerido no se están requiriendo puertos PoE, y cuyos requerimientos agregan complejidad innecesaria a la solución a ser ofertada.
Esto favorecerá a una mayor participación de potenciales oferentes.
UPS de 6KVA – En el Pliego de Bases y Condiciones se requiere que la UPS de 6KVA tenga una capacidad de sobrecarga: Carga ≤105%, trabajo contínuo, 105%<Carga<125%, 10min luego pasa a modo bypass, 125%<Carga<150%, 1min luego pasa a modo bypass, Carga>50%, 200ms luego pasa al modo bypass.
Solicitamos puedan aceptarse UPS de 6KVA con capacidad de sobrecarga límite >150%, 200 ms y luego pase al modo bypass.
En virtud de lo anterior, solicitamos que se considere aceptar UPS de 6 kVA con capacidad de sobrecarga límite >150% por 200 ms, y luego transferencia a modo bypass. Esta modificación permitirá a los potenciales oferentes presentar ofertas correctamente dimensionadas, ajustadas a la capacidad real de los equipos, y mantener la competitividad de las propuestas.
UPS de 6KVA – En el Pliego de Bases y Condiciones se requiere que la UPS de 6KVA tenga una capacidad de sobrecarga: Carga ≤105%, trabajo contínuo, 105%<Carga<125%, 10min luego pasa a modo bypass, 125%<Carga<150%, 1min luego pasa a modo bypass, Carga>50%, 200ms luego pasa al modo bypass.
Solicitamos puedan aceptarse UPS de 6KVA con capacidad de sobrecarga límite >150%, 200 ms y luego pase al modo bypass.
En virtud de lo anterior, solicitamos que se considere aceptar UPS de 6 kVA con capacidad de sobrecarga límite >150% por 200 ms, y luego transferencia a modo bypass. Esta modificación permitirá a los potenciales oferentes presentar ofertas correctamente dimensionadas, ajustadas a la capacidad real de los equipos, y mantener la competitividad de las propuestas.
En fecha lunes, 6 de octubre, se realizo la visita técnica al sitio donde los oferentes pudieron verificar las instalaciones de manera a que puedan realizar el dimensionamiento pertinente y armar sus ofertas correspondientes.
24
Modificación del requisito “El chequeo de firmas también debe determinar si una aplicación está utilizando su puerto default o no” (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante revisar la redacción del requisito “El chequeo de firmas también debe determinar si una aplicación está utilizando su puerto default o no”, a fin de adecuarlo a la funcionalidad actual de los motores de inspección de aplicaciones (NGFW)?
Se propone la siguiente redacción alternativa, más técnica, neutral y acorde a los estándares de la industria:
“El motor de inspección de aplicaciones deberá identificar el tráfico independientemente del puerto o protocolo utilizado, mediante el uso de firmas, decodificación de protocolos y análisis de comportamiento.”
Esta modificación mantiene la finalidad del control de capa 7, evita la exclusión de equipos de última generación y garantiza la igualdad de condiciones, razonabilidad técnica y neutralidad tecnológica, conforme a los artículos 4° y 40° de la Ley 7021/22 y al Decreto N° 2264/24.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece el siguiente requisito:
“El chequeo de firmas también debe determinar si una aplicación está utilizando su puerto default o no.”
El texto, tal como está redactado, no se corresponde con el funcionamiento real de los motores de inspección de aplicaciones (App-ID o DPI) implementados por los principales fabricantes de firewalls de próxima generación (NGFW).
En estas plataformas, el motor de inspección de aplicaciones tiene por objetivo identificar el tráfico a nivel de capa 7, incluso cuando la aplicación utiliza puertos no estándar, mediante el uso de firmas, heurísticas, decodificación de protocolos y análisis de comportamiento.
Por lo tanto, exigir que el “chequeo de firmas determine si la aplicación está utilizando su puerto por defecto” no refleja un parámetro técnico válido o medible, y puede excluir equipos modernos que cumplen cabalmente con la identificación de aplicaciones, pero no dependen de la coincidencia con puertos predeterminados.
En consecuencia, esta redacción podría constituir una barrera tecnológica implícita o un direccionamiento indirecto hacia equipos antiguos o de marcas específicas que aún reportan ese tipo de validaciones.
El principio de razonabilidad (art. 4 inc. k) de la Ley 7021/22 obliga a las convocantes a ajustar las especificaciones a la funcionalidad técnica real, evitando requisitos innecesarios o inexactos que limiten la participación de oferentes y distorsionen la competencia.
10-10-2025
14-10-2025
Modificación del requisito “El chequeo de firmas también debe determinar si una aplicación está utilizando su puerto default o no” (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante revisar la redacción del requisito “El chequeo de firmas también debe determinar si una aplicación está utilizando su puerto default o no”, a fin de adecuarlo a la funcionalidad actual de los motores de inspección de aplicaciones (NGFW)?
Se propone la siguiente redacción alternativa, más técnica, neutral y acorde a los estándares de la industria:
“El motor de inspección de aplicaciones deberá identificar el tráfico independientemente del puerto o protocolo utilizado, mediante el uso de firmas, decodificación de protocolos y análisis de comportamiento.”
Esta modificación mantiene la finalidad del control de capa 7, evita la exclusión de equipos de última generación y garantiza la igualdad de condiciones, razonabilidad técnica y neutralidad tecnológica, conforme a los artículos 4° y 40° de la Ley 7021/22 y al Decreto N° 2264/24.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece el siguiente requisito:
“El chequeo de firmas también debe determinar si una aplicación está utilizando su puerto default o no.”
El texto, tal como está redactado, no se corresponde con el funcionamiento real de los motores de inspección de aplicaciones (App-ID o DPI) implementados por los principales fabricantes de firewalls de próxima generación (NGFW).
En estas plataformas, el motor de inspección de aplicaciones tiene por objetivo identificar el tráfico a nivel de capa 7, incluso cuando la aplicación utiliza puertos no estándar, mediante el uso de firmas, heurísticas, decodificación de protocolos y análisis de comportamiento.
Por lo tanto, exigir que el “chequeo de firmas determine si la aplicación está utilizando su puerto por defecto” no refleja un parámetro técnico válido o medible, y puede excluir equipos modernos que cumplen cabalmente con la identificación de aplicaciones, pero no dependen de la coincidencia con puertos predeterminados.
En consecuencia, esta redacción podría constituir una barrera tecnológica implícita o un direccionamiento indirecto hacia equipos antiguos o de marcas específicas que aún reportan ese tipo de validaciones.
El principio de razonabilidad (art. 4 inc. k) de la Ley 7021/22 obliga a las convocantes a ajustar las especificaciones a la funcionalidad técnica real, evitando requisitos innecesarios o inexactos que limiten la participación de oferentes y distorsionen la competencia.
Remitirse al PBC. Aclaramos que la funcionalidad requerida establece la identificacion de aplicaciones mediante el uso de firmas y que cuente con la capacidad de identificar si el puerto utilizado es el por defecto o no.
25
Modificación del requisito de desencripción de tráfico SSL limitado a certificados ECC (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante revisar el texto del requisito “Debe desencriptar tráfico que use certificados ECC (como ECDSA)” y sustituirlo por una redacción tecnológicamente neutral y más inclusiva, como la siguiente propuesta?
“El equipo deberá soportar la desencripción de tráfico SSL/TLS que utilice certificados RSA DCA y ECC (P-256, P-384, P-521 elliptic), u otros equivalentes reconocidos por los estándares internacionales.”
Esta modificación permitirá ampliar la participación de oferentes, garantizar la igualdad de condiciones entre fabricantes, y adecuar el pliego a los principios de razonabilidad, libre concurrencia y neutralidad tecnológica previstos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
El Ítem 3.2.1 – Firewall establece como requisito:
“Debe desencriptar tráfico que use certificados ECC (como ECDSA).”
El texto, tal como se encuentra redactado, limita la funcionalidad de desencripción SSL/TLS exclusivamente a certificados ECC (Elliptic Curve Cryptography), excluyendo otros algoritmos de cifrado y firma digital de uso común y plenamente vigente en entornos corporativos, como RSA DCA (Digital Certificate Algorithm), DSA, o EdDSA.
Esta redacción constituye una restricción tecnológica injustificada, ya que orienta la especificación hacia fabricantes que priorizan el soporte nativo de certificados ECC —en especial Fortinet—, restringiendo la participación de marcas que emplean o combinan otros esquemas criptográficos equivalentes.
La Ley 7021/22 y el Decreto 2264/24 establecen que las exigencias técnicas deben ser neutras, proporcionales y no discriminatorias, debiendo describirse en términos funcionales o de desempeño, no en función de tecnologías o algoritmos específicos que conduzcan a direccionamientos.
Además, los estándares internacionales de seguridad (TLS 1.2 / TLS 1.3, RFC 8446 y RFC 5246) no imponen la exclusividad del uso de certificados ECC, sino la interoperabilidad con diversos algoritmos de cifrado y firma. En consecuencia, admitir RSA, DSA, ECDSA, EdDSA u otros equivalentes permitiría una competencia justa y transparente entre oferentes y garantizaría la interoperabilidad con los sistemas criptográficos actualmente vigentes en la administración pública.
10-10-2025
14-10-2025
Modificación del requisito de desencripción de tráfico SSL limitado a certificados ECC (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante revisar el texto del requisito “Debe desencriptar tráfico que use certificados ECC (como ECDSA)” y sustituirlo por una redacción tecnológicamente neutral y más inclusiva, como la siguiente propuesta?
“El equipo deberá soportar la desencripción de tráfico SSL/TLS que utilice certificados RSA DCA y ECC (P-256, P-384, P-521 elliptic), u otros equivalentes reconocidos por los estándares internacionales.”
Esta modificación permitirá ampliar la participación de oferentes, garantizar la igualdad de condiciones entre fabricantes, y adecuar el pliego a los principios de razonabilidad, libre concurrencia y neutralidad tecnológica previstos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
El Ítem 3.2.1 – Firewall establece como requisito:
“Debe desencriptar tráfico que use certificados ECC (como ECDSA).”
El texto, tal como se encuentra redactado, limita la funcionalidad de desencripción SSL/TLS exclusivamente a certificados ECC (Elliptic Curve Cryptography), excluyendo otros algoritmos de cifrado y firma digital de uso común y plenamente vigente en entornos corporativos, como RSA DCA (Digital Certificate Algorithm), DSA, o EdDSA.
Esta redacción constituye una restricción tecnológica injustificada, ya que orienta la especificación hacia fabricantes que priorizan el soporte nativo de certificados ECC —en especial Fortinet—, restringiendo la participación de marcas que emplean o combinan otros esquemas criptográficos equivalentes.
La Ley 7021/22 y el Decreto 2264/24 establecen que las exigencias técnicas deben ser neutras, proporcionales y no discriminatorias, debiendo describirse en términos funcionales o de desempeño, no en función de tecnologías o algoritmos específicos que conduzcan a direccionamientos.
Además, los estándares internacionales de seguridad (TLS 1.2 / TLS 1.3, RFC 8446 y RFC 5246) no imponen la exclusividad del uso de certificados ECC, sino la interoperabilidad con diversos algoritmos de cifrado y firma. En consecuencia, admitir RSA, DSA, ECDSA, EdDSA u otros equivalentes permitiría una competencia justa y transparente entre oferentes y garantizaría la interoperabilidad con los sistemas criptográficos actualmente vigentes en la administración pública.
Remitirse al PBC. El requerimiento establece la desencripcion del trafico que use certificados ECC, sin limitar a que se acepten adicionalmente otros esquemas.
26
Revisión del requisito mínimo de interfaces RJ45 de 1 GbE (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante revisar y modificar el requisito mínimo de interfaces RJ45 de 1 GbE, reduciendo el valor a 8 (ocho) interfaces mínimas, manteniendo la compatibilidad con las interfaces SFP/SFP+ propias de equipos de categoría Enterprise?
Se propone sustituir el punto por la siguiente redacción:
“El equipo ofertado deberá contar con al menos 8 (ocho) interfaces de cobre RJ45 de 1 GbE.”
Esta modificación permite una mayor libre concurrencia de marcas, evita el direccionamiento hacia modelos específicos y mantiene plenamente el rendimiento y la seguridad requeridos por el objeto del llamado, en concordancia con los principios de razonabilidad, valor por dinero y eficiencia del artículo 4° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego exige que “los equipos ofertados deberán contar con al menos 12 interfaces de cobre RJ45 de 1 GbE”.
Este requisito resulta excesivamente restrictivo frente a la realidad tecnológica actual del mercado de equipos Enterprise y Mid-Range, donde la mayoría de los firewalls modernos integran una configuración mixta de puertos (SFP/SFP+ ópticos combinados con interfaces RJ45), optimizando rendimiento, seguridad y eficiencia energética.
Mantener la exigencia de 12 puertos RJ45 implica restringir la oferta a modelos muy específicos con una configuración de puertos poco habitual, lo que puede constituir un direccionamiento encubierto y afectar los principios de igualdad y libre competencia establecidos en los artículos 4 y 40 de la Ley 7021/22.
La reducción a 8 (ocho) interfaces RJ45 de 1 GbE responde a una medida técnicamente razonable y proporcional, manteniendo la capacidad operativa requerida para el entorno de 400 puntos de red previsto en el llamado.
Asimismo, cuando se requiere una mayor densidad de puertos de cobre, las buenas prácticas de diseño de redes recomiendan utilizar switches administrables de acceso interconectados al firewall principal, como ya se prevé en el pliego del presente procedimiento.
La modificación propuesta favorece una mayor competencia entre fabricantes, amplía la participación de equipos de última generación y se ajusta a los principios de razonabilidad, valor por dinero y eficiencia en el gasto público.
10-10-2025
14-10-2025
Revisión del requisito mínimo de interfaces RJ45 de 1 GbE (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante revisar y modificar el requisito mínimo de interfaces RJ45 de 1 GbE, reduciendo el valor a 8 (ocho) interfaces mínimas, manteniendo la compatibilidad con las interfaces SFP/SFP+ propias de equipos de categoría Enterprise?
Se propone sustituir el punto por la siguiente redacción:
“El equipo ofertado deberá contar con al menos 8 (ocho) interfaces de cobre RJ45 de 1 GbE.”
Esta modificación permite una mayor libre concurrencia de marcas, evita el direccionamiento hacia modelos específicos y mantiene plenamente el rendimiento y la seguridad requeridos por el objeto del llamado, en concordancia con los principios de razonabilidad, valor por dinero y eficiencia del artículo 4° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego exige que “los equipos ofertados deberán contar con al menos 12 interfaces de cobre RJ45 de 1 GbE”.
Este requisito resulta excesivamente restrictivo frente a la realidad tecnológica actual del mercado de equipos Enterprise y Mid-Range, donde la mayoría de los firewalls modernos integran una configuración mixta de puertos (SFP/SFP+ ópticos combinados con interfaces RJ45), optimizando rendimiento, seguridad y eficiencia energética.
Mantener la exigencia de 12 puertos RJ45 implica restringir la oferta a modelos muy específicos con una configuración de puertos poco habitual, lo que puede constituir un direccionamiento encubierto y afectar los principios de igualdad y libre competencia establecidos en los artículos 4 y 40 de la Ley 7021/22.
La reducción a 8 (ocho) interfaces RJ45 de 1 GbE responde a una medida técnicamente razonable y proporcional, manteniendo la capacidad operativa requerida para el entorno de 400 puntos de red previsto en el llamado.
Asimismo, cuando se requiere una mayor densidad de puertos de cobre, las buenas prácticas de diseño de redes recomiendan utilizar switches administrables de acceso interconectados al firewall principal, como ya se prevé en el pliego del presente procedimiento.
La modificación propuesta favorece una mayor competencia entre fabricantes, amplía la participación de equipos de última generación y se ajusta a los principios de razonabilidad, valor por dinero y eficiencia en el gasto público.
Aclaración y revisión del requisito de “Control, inspección y desencripción de tráfico SSL con capacidad mínima 130.000” (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante aclarar la unidad de medida y el método de verificación del parámetro “capacidad mínima 130.000” en el control e inspección de tráfico SSL (sesiones, conexiones o certificados)?
Asimismo, considerando que el valor coincide con las especificaciones del modelo FortiGate 100F, ¿resultaría procedente eliminar este requisito por carecer de referencia técnica verificable y reemplazarlo por un criterio de rendimiento SSL proporcional al throughput total, conforme a las prácticas internacionales (RFC 2544 / IMIX) y los principios de razonabilidad y libre concurrencia establecidos en los artículos 4° y 40° de la Ley 7021/22?
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece como requisito:
“Control, inspección y desencripción de tráfico SSL con capacidad mínima 130.000”.
El valor exigido carece de unidad de medida técnica definida (no se especifica si corresponde a sesiones SSL simultáneas, conexiones concurrentes, inspecciones por segundo o certificados analizados), lo que imposibilita la verificación objetiva de cumplimiento.
Además, la cifra 130.000 coincide casi textualmente con las hojas de datos públicas del modelo Fortinet FortiGate 100F, lo que representa un indicio directo de direccionamiento hacia una marca y modelo determinados, vulnerando los principios de igualdad, libre competencia y neutralidad tecnológica consagrados en la Ley 7021/22.
En la práctica, los fabricantes líderes de Next Generation Firewall (NGFW) no expresan la capacidad de inspección SSL mediante valores absolutos, sino como porcentaje del throughput total o como rendimiento efectivo bajo carga IMIX, conforme a las normas RFC 2544.
Por ello, mantener este parámetro sin aclaración metodológica genera inseguridad técnica y jurídica, limita la competencia y puede excluir equipos equivalentes o superiores en rendimiento y eficiencia energética.
El Decreto 2264/24 obliga a las convocantes a justificar técnicamente cada requisito y garantizar que las especificaciones sean pertinentes, objetivas y medibles, a fin de evitar direccionamientos. En este caso, el requisito no cumple dichos criterios y debe ser revisado o eliminado.
10-10-2025
14-10-2025
Aclaración y revisión del requisito de “Control, inspección y desencripción de tráfico SSL con capacidad mínima 130.000” (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante aclarar la unidad de medida y el método de verificación del parámetro “capacidad mínima 130.000” en el control e inspección de tráfico SSL (sesiones, conexiones o certificados)?
Asimismo, considerando que el valor coincide con las especificaciones del modelo FortiGate 100F, ¿resultaría procedente eliminar este requisito por carecer de referencia técnica verificable y reemplazarlo por un criterio de rendimiento SSL proporcional al throughput total, conforme a las prácticas internacionales (RFC 2544 / IMIX) y los principios de razonabilidad y libre concurrencia establecidos en los artículos 4° y 40° de la Ley 7021/22?
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece como requisito:
“Control, inspección y desencripción de tráfico SSL con capacidad mínima 130.000”.
El valor exigido carece de unidad de medida técnica definida (no se especifica si corresponde a sesiones SSL simultáneas, conexiones concurrentes, inspecciones por segundo o certificados analizados), lo que imposibilita la verificación objetiva de cumplimiento.
Además, la cifra 130.000 coincide casi textualmente con las hojas de datos públicas del modelo Fortinet FortiGate 100F, lo que representa un indicio directo de direccionamiento hacia una marca y modelo determinados, vulnerando los principios de igualdad, libre competencia y neutralidad tecnológica consagrados en la Ley 7021/22.
En la práctica, los fabricantes líderes de Next Generation Firewall (NGFW) no expresan la capacidad de inspección SSL mediante valores absolutos, sino como porcentaje del throughput total o como rendimiento efectivo bajo carga IMIX, conforme a las normas RFC 2544.
Por ello, mantener este parámetro sin aclaración metodológica genera inseguridad técnica y jurídica, limita la competencia y puede excluir equipos equivalentes o superiores en rendimiento y eficiencia energética.
El Decreto 2264/24 obliga a las convocantes a justificar técnicamente cada requisito y garantizar que las especificaciones sean pertinentes, objetivas y medibles, a fin de evitar direccionamientos. En este caso, el requisito no cumple dichos criterios y debe ser revisado o eliminado.
Remitirse al PBC. Se aclara que la capacidad mínima establecida de 130.000 se refiere expresamente a 130.000 sesiones SSL concurrentes que el equipo es capaz de inspeccionar de forma simultánea. Se ratifica que la capacidad requerida es alcanzable o superada por multiples fabricantes.
28
Modificación de la capacidad mínima de túneles Client-to-Gateway (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante justificar técnicamente la necesidad de exigir 14.000 túneles Client-to-Gateway, considerando la escala real del entorno proyectado y la capacidad operativa prevista (400 puntos de red)? Asimismo, y a fin de promover la libre competencia y razonabilidad técnica, se propone ajustar la exigencia a un mínimo de 10.000 conexiones SSL-VPN concurrentes, garantizando compatibilidad con IPSec y autenticación multiusuario, conforme a los principios de igualdad, valor por dinero y eficiencia establecidos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece la exigencia de 1.800 túneles Gateway-to-Gateway y 14.000 túneles Client-to-Gateway como parámetros mínimos.
El modo en que estos valores han sido redactados coincide casi textualmente con las hojas técnicas del modelo Fortinet FortiGate 100F, lo que podría evidenciar un direccionamiento del pliego hacia una marca y proveedor específicos, en contravención a los principios de igualdad, libre competencia y razonabilidad establecidos en el artículo 4° y el artículo 40° de la Ley 7021/22.
Este tipo de requerimiento técnico, sin justificación basada en el entorno real de uso, configura una barrera tecnológica que excluye a otras marcas de categoría Enterprise con prestaciones equivalentes o superiores en términos de rendimiento general, gestión de amenazas, escalabilidad y eficiencia energética.
De acuerdo con el Decreto 2264/24, toda especificación técnica debe ser pertinente, proporcional y necesaria para el cumplimiento del objeto contractual, no pudiendo replicar valores que identifiquen productos comerciales específicos ni inducir a la selección de una marca determinada.
En este contexto, equipos Next Generation Firewall (NGFW) de clase Enterprise que soportan hasta 6.000 túneles IPSec y 4.000 conexiones SSL-VPN concurrentes resultan plenamente adecuados para un entorno de aproximadamente 400 puntos de red, como el previsto en este llamado. Por tanto, el valor exigido de 14.000 túneles Client-to-Gateway es manifiestamente desproporcionado frente a la magnitud del proyecto y distorsiona el principio de valor por dinero.
10-10-2025
14-10-2025
Modificación de la capacidad mínima de túneles Client-to-Gateway (Ítem 3.2.1 – Firewall)
¿Podrá la Convocante justificar técnicamente la necesidad de exigir 14.000 túneles Client-to-Gateway, considerando la escala real del entorno proyectado y la capacidad operativa prevista (400 puntos de red)? Asimismo, y a fin de promover la libre competencia y razonabilidad técnica, se propone ajustar la exigencia a un mínimo de 10.000 conexiones SSL-VPN concurrentes, garantizando compatibilidad con IPSec y autenticación multiusuario, conforme a los principios de igualdad, valor por dinero y eficiencia establecidos en los artículos 4° y 40° de la Ley 7021/22.
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego establece la exigencia de 1.800 túneles Gateway-to-Gateway y 14.000 túneles Client-to-Gateway como parámetros mínimos.
El modo en que estos valores han sido redactados coincide casi textualmente con las hojas técnicas del modelo Fortinet FortiGate 100F, lo que podría evidenciar un direccionamiento del pliego hacia una marca y proveedor específicos, en contravención a los principios de igualdad, libre competencia y razonabilidad establecidos en el artículo 4° y el artículo 40° de la Ley 7021/22.
Este tipo de requerimiento técnico, sin justificación basada en el entorno real de uso, configura una barrera tecnológica que excluye a otras marcas de categoría Enterprise con prestaciones equivalentes o superiores en términos de rendimiento general, gestión de amenazas, escalabilidad y eficiencia energética.
De acuerdo con el Decreto 2264/24, toda especificación técnica debe ser pertinente, proporcional y necesaria para el cumplimiento del objeto contractual, no pudiendo replicar valores que identifiquen productos comerciales específicos ni inducir a la selección de una marca determinada.
En este contexto, equipos Next Generation Firewall (NGFW) de clase Enterprise que soportan hasta 6.000 túneles IPSec y 4.000 conexiones SSL-VPN concurrentes resultan plenamente adecuados para un entorno de aproximadamente 400 puntos de red, como el previsto en este llamado. Por tanto, el valor exigido de 14.000 túneles Client-to-Gateway es manifiestamente desproporcionado frente a la magnitud del proyecto y distorsiona el principio de valor por dinero.
Remitirse al PBC. En el pliego de bases y condiciones se especifica el soporte de conexiones SSL VPN sin delimitar cantidades, para los demás requisitos de rendimiento mencionados existen multiples fabricantes que cumplen o superan los requisitos establecidos.
29
Revisión del valor mínimo de MTBF exigido en el Ítem 3.2.1 (Firewall)
¿Podrá la Convocante justificar la pertinencia de exigir un MTBF mínimo de 180.000 horas, considerando que este parámetro excede el ciclo de vida útil de los equipos de seguridad y carece de respaldo técnico-normativo? Asimismo, ¿resultaría viable ajustar el valor exigido a un mínimo de 120.000 horas, acompañado de la garantía efectiva del fabricante, en conformidad con los principios de razonabilidad, valor por dinero y libre concurrencia establecidos en los artículos 4° y 40° de la Ley 7021/22?
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego exige un MTBF (Mean Time Between Failures) igual o superior a 180.000 horas.
Esta especificación técnica carece de proporcionalidad frente al ciclo de vida útil razonable de los equipos de seguridad de red y puede representar una barrera injustificada a la libre competencia, en contravención con los principios de razonabilidad, igualdad y valor por dinero establecidos en el artículo 4° y el artículo 40° de la Ley 7021/22.
El parámetro exigido excede las buenas prácticas de renovación tecnológica aplicadas a equipamientos críticos de seguridad perimetral, los cuales suelen ser reemplazados o actualizados entre los 3 y 5 años por motivos de ciberseguridad y compatibilidad de firmware.
Exigir un MTBF ≥ 180.000 h (más de 20 años) resulta técnicamente incongruente con dichos ciclos, ya que ningún entorno de red de nivel empresarial mantiene en operación un firewall activo durante ese periodo.
Además, la exigencia actual carece de referencia normativa o estándar internacional, dado que los fabricantes no están obligados a declarar el valor MTBF en sus fichas técnicas, sino a ofrecer garantías efectivas y SLA (Service Level Agreement) certificados. Esto restringe la participación de marcas que garantizan fiabilidad equivalente pero no presentan este valor en forma explícita, distorsionando la libre concurrencia y el principio de razonabilidad técnica.
Por tanto, establecer un valor de MTBF ≥ 120.000 h resulta suficiente y técnicamente coherente con la vida útil de los equipos y las políticas de actualización tecnológica del Estado, garantizando equilibrio entre fiabilidad, seguridad y apertura competitiva.
10-10-2025
14-10-2025
Revisión del valor mínimo de MTBF exigido en el Ítem 3.2.1 (Firewall)
¿Podrá la Convocante justificar la pertinencia de exigir un MTBF mínimo de 180.000 horas, considerando que este parámetro excede el ciclo de vida útil de los equipos de seguridad y carece de respaldo técnico-normativo? Asimismo, ¿resultaría viable ajustar el valor exigido a un mínimo de 120.000 horas, acompañado de la garantía efectiva del fabricante, en conformidad con los principios de razonabilidad, valor por dinero y libre concurrencia establecidos en los artículos 4° y 40° de la Ley 7021/22?
Análisis técnico-normativo:
En el Ítem 3.2.1 – Firewall, el pliego exige un MTBF (Mean Time Between Failures) igual o superior a 180.000 horas.
Esta especificación técnica carece de proporcionalidad frente al ciclo de vida útil razonable de los equipos de seguridad de red y puede representar una barrera injustificada a la libre competencia, en contravención con los principios de razonabilidad, igualdad y valor por dinero establecidos en el artículo 4° y el artículo 40° de la Ley 7021/22.
El parámetro exigido excede las buenas prácticas de renovación tecnológica aplicadas a equipamientos críticos de seguridad perimetral, los cuales suelen ser reemplazados o actualizados entre los 3 y 5 años por motivos de ciberseguridad y compatibilidad de firmware.
Exigir un MTBF ≥ 180.000 h (más de 20 años) resulta técnicamente incongruente con dichos ciclos, ya que ningún entorno de red de nivel empresarial mantiene en operación un firewall activo durante ese periodo.
Además, la exigencia actual carece de referencia normativa o estándar internacional, dado que los fabricantes no están obligados a declarar el valor MTBF en sus fichas técnicas, sino a ofrecer garantías efectivas y SLA (Service Level Agreement) certificados. Esto restringe la participación de marcas que garantizan fiabilidad equivalente pero no presentan este valor en forma explícita, distorsionando la libre concurrencia y el principio de razonabilidad técnica.
Por tanto, establecer un valor de MTBF ≥ 120.000 h resulta suficiente y técnicamente coherente con la vida útil de los equipos y las políticas de actualización tecnológica del Estado, garantizando equilibrio entre fiabilidad, seguridad y apertura competitiva.
Remitirse al PBC.Existen multiples fabricantes que cumplen o superan los requisitos establecidos.
30
Exigencia de contar con 8 técnicos en staff y un profesional universitario específico
¿De qué manera la Convocante justifica la proporcionalidad del requerimiento de contar con 8 técnicos en staff y un profesional universitario específico, considerando que el volumen del servicio no exige tal dotación permanente, y si resultaría procedente reducir dicha exigencia a tres (3) técnicos mínimos, a fin de asegurar la igualdad de condiciones de participación conforme al artículo 40 de la Ley 7021/22 y al principio de razonabilidad previsto en el artículo 4° inciso k) de la misma ley?
Análisis técnico-normativo:
El pliego exige que el oferente cuente con al menos ocho (8) técnicos en staff y un profesional universitario específico. Esta disposición resulta excesiva y desproporcionada frente al volumen real del servicio licitado, configurando una posible barrera de acceso que restringe la participación de oferentes plenamente competentes, especialmente micro y pequeñas empresas.
De acuerdo con la Ley 7021/22, los requerimientos de capacidad técnica deben guardar relación directa, objetiva y proporcional con la magnitud del objeto contractual, evitando criterios que generen concentración del mercado o direccionamientos indirectos.
El principio de economía y eficiencia impone a las convocantes la obligación de adoptar exigencias técnicas razonables que garanticen la ejecución del contrato sin limitar la competencia, preservando la igualdad de oportunidades y la obtención de valor por dinero para el Estado.
En este sentido, exigir ocho técnicos permanentes, además de un profesional universitario específico, no representa una garantía adicional de calidad, sino un filtro restrictivo que podría favorecer a oferentes previamente definidos, contraviniendo los principios de libre concurrencia, razonabilidad y economía procesal establecidos en la normativa vigente.
10-10-2025
14-10-2025
Exigencia de contar con 8 técnicos en staff y un profesional universitario específico
¿De qué manera la Convocante justifica la proporcionalidad del requerimiento de contar con 8 técnicos en staff y un profesional universitario específico, considerando que el volumen del servicio no exige tal dotación permanente, y si resultaría procedente reducir dicha exigencia a tres (3) técnicos mínimos, a fin de asegurar la igualdad de condiciones de participación conforme al artículo 40 de la Ley 7021/22 y al principio de razonabilidad previsto en el artículo 4° inciso k) de la misma ley?
Análisis técnico-normativo:
El pliego exige que el oferente cuente con al menos ocho (8) técnicos en staff y un profesional universitario específico. Esta disposición resulta excesiva y desproporcionada frente al volumen real del servicio licitado, configurando una posible barrera de acceso que restringe la participación de oferentes plenamente competentes, especialmente micro y pequeñas empresas.
De acuerdo con la Ley 7021/22, los requerimientos de capacidad técnica deben guardar relación directa, objetiva y proporcional con la magnitud del objeto contractual, evitando criterios que generen concentración del mercado o direccionamientos indirectos.
El principio de economía y eficiencia impone a las convocantes la obligación de adoptar exigencias técnicas razonables que garanticen la ejecución del contrato sin limitar la competencia, preservando la igualdad de oportunidades y la obtención de valor por dinero para el Estado.
En este sentido, exigir ocho técnicos permanentes, además de un profesional universitario específico, no representa una garantía adicional de calidad, sino un filtro restrictivo que podría favorecer a oferentes previamente definidos, contraviniendo los principios de libre concurrencia, razonabilidad y economía procesal establecidos en la normativa vigente.