¿Qué significa la prueba de control para una dirección IP ?

Cuando alguien dice que “controlan” un bloque de dirección IP , ¿qué significa exactamente eso?

La respuesta es más complicada que comprobar un solo WHOIS registro.

Para los recursos del número de Internet, prueba de control es evidencia de que una persona u organización está legítimamente autorizada para realizar una acción particular con un recurso de dirección IP.

Esa acción podría ser:

• actualizar la información del registro;
• autorizar un anuncio de BGP ;
• crear o cambiar una Autorización de Origen de Ruta ( ROA );
• - Delegar el DNS inverso;
• arrendamiento o delegación operacional del espacio de dirección;
• solicitar una transferencia; o
• representando al titular de los recursos durante una disputa.

No hay ninguna prueba que responda a cada una de estas preguntas.

Un registro puede proporcionar evidencia importante.

RPKI puede proporcionar evidencia criptográfica sobre la autorización de enrutamiento.

Un contrato puede documentar una relación comercial.

BGP puede mostrar quién está anunciando un prefijo.

Los registros corporativos pueden mostrar quién está autorizado para actuar para una organización.

Estas capas pueden apoyarse entre sí, pero no deben confundirse.

Prueba de control debe responder a una pregunta específica: ¿quién está autorizado a hacer qué con este recurso número de Internet?

¿Qué significa “Control” para una dirección IP ?

Una dirección IP no se controla exactamente de la misma manera que un objeto físico.

Un prefijo IPv4 o IPv6 existe dentro de varios sistemas de superposición.

Hay un capa de registro, que registra la información de número de Internet.

Hay un capa de enrutamiento, donde las redes anuncian prefijos usando BGP .

Hay un capa de seguridad, donde mecanismos como RPKI pueden expresar la autorización de origen de ruta.

También puede haber:

• relaciones contractuales;
• arrendamientos;
• delegaciones operacionales;
• estructuras de propiedad empresarial;
• relaciones de servicio-providente;
• d) Inversión de las delegaciones del DNS ; y
• derechos o obligaciones legales aplicables.

Esto significa que el control puede tener diferentes significados dependiendo de la pregunta que se haga.

Por ejemplo:

Control de registro puede significar que se autorice a actualizar el registro oficial de recursos.

Control de rutina puede significar ser autorizado para originar o organizar la routa del prefijo.

Control operacional puede significar la gestión de la infraestructura actualmente utilizando las direcciones.

Control comercial puede implicar derechos contractuales relacionados con el arrendamiento, la transferencia o la delegación.

Estos no deben ser tratados automáticamente como idénticos.

La prueba de control no es lo mismo que la propiedad IP

Una de las distinciones más importantes es entre control y propiedad.

La condición jurídica de los recursos del número de Internet puede depender de contratos, políticas de registro, jurisdicción, estructura de transacciones y otras circunstancias.

No hay razón para suponer que un registro técnico resuelve cada posible pregunta legal.

Un registro puede proporcionar pruebas sólidas sobre el estado de registro reconocido.

No determina necesariamente todos los intereses contractuales, beneficiosos, operacionales o jurídicos que rodean el recurso.

Asimismo, controlar la infraestructura anunciando un prefijo no prueba automáticamente que la red anunciada tiene derecho a transferir el espacio de dirección.

Por ello, la prueba de control debe seguir siendo un concepto más estrecho.

En lugar de preguntar:

¿Quién posee esta dirección IP ?

a more useful operational question is often:

¿Quién ha verificado la autoridad para realizar la acción que se solicita?

Esa pregunta generalmente puede ser contestada más precisamente.

¿Por qué la prueba de los asuntos de control

Los recursos del número de Internet deben seguir siendo coordinados a nivel mundial.

A nivel mundial, IANA coordina los sistemas de dirección IP de Internet y los números de sistema autónomo, mientras que los registros regionales de Internet proporcionan capas regionales de asignación y registro.

Una vez que se utilizan los recursos, es necesario hacer cambios cuidadosamente.

Un registro no debe actualizar un bloque de direcciones simplemente porque alguien envía un email pidiendo un cambio.

Una red no debe aceptar una autorización de ruta simplemente porque alguien afirma representar al titular de los recursos.

No se debe registrar una transferencia si la parte que la solicita no puede demostrar autoridad apropiada.

Por lo tanto, los mecanismos de control ayudan a proteger:

• exactitud del registro;
• titulares de recursos;
• Operadores de red;
• contrapartes;
• - La seguridad de la fuga;
• la integridad de la transferencia; y
• continuidad operacional.

El objetivo no es crear capas de permiso innecesarias.

Es prevenir cambios no autorizados al mismo tiempo que se verifican los cambios legítimos.

¿Qué se puede utilizar como prueba de control?

No hay una prueba universal que funcione para cada situación.

Un proceso fiable normalmente examina las pruebas apropiadas para la acción solicitada.

Pueden ser pertinentes varios tipos de pruebas.

1. Cuenta de la Secretaría y Documentos de Recursos

El registro es un punto de partida obvio.

Puede identificar:

• la organización registrada;
• contactos de recursos;
• contactos administrativos;
• contactos técnicos;
• la situación de los recursos; y
• otra información de registro.

El acceso a una cuenta de registro autenticada también puede demostrar que se ha concedido a un usuario ciertas capacidades administrativas dentro de ese sistema de registro.

Sin embargo, el acceso al registro debe interpretarse cuidadosamente.

Un empleado puede tener credenciales de ingreso sin tener autoridad corporativa para vender o transferir un recurso.

Las credenciales de un ex empleado pueden no reflejar la autoridad actual.

Una cuenta también puede ser comprometida.

Para acciones de mayor impacto, la autenticación debe combinarse con los controles de autorización adecuados.

Ser capaz de acceder a un sistema y ser autorizado para tomar una decisión en particular no siempre es lo mismo.

2. Autorización corporativa

Cuando una organización es el titular de los recursos reconocidos, la prueba de control puede requerir pruebas de que la persona que hace una solicitud puede actuar legítimamente para esa organización.

Según las circunstancias, las pruebas podrían incluir:

• información firmante autorizada;
• documentación empresarial;
• autorización de director o oficial;
• Cartas oficiales;
• registros de autorización interna; o
• otra cadena de autoridad verificable.

La documentación requerida variará.

The important principle is that control should be traceable from the resource holder to the person requesting the change.

Esto se vuelve especialmente importante durante:

• fusiones;
• adquisiciones;
• reestructuración empresarial;
• la insolvencia;
• salidas de empleados; o
• controversias entre representantes anteriores y actuales.

3. Autorización de rotación

Routing proporciona otra capa de evidencia.

Si se anuncia un prefijo a través de BGP , los operadores pueden observar qué ASN lo origina.

Pero un anuncio de BGP solo es no prueba suficiente de control legítimo.

BGP muestra la realidad descompuesta.

No prueba por sí misma la autorización.

Un prefijo puede ser:

• legítimamente anunciado por un cliente;
• anunciado por un proveedor de alojamiento;
• originada por una red aguas arriba;
• transitó temporalmente durante una migración; o
• anunciado sin autorización.

Por esta razón, un modelo útil de prueba de control debe distinguir:

¿Quién está pudrindo el prefijo?

de:

¿Quién autorizó esa fuga?

Esas son preguntas diferentes.

4. Autorización de origen RPKI y ruta

RPKI ofrece uno de los ejemplos más claros de autorización criptográfica en el sistema de recursos de número de Internet.

Bajo la arquitectura RPKI , los certificados de recursos atestiguan las tenencias del espacio de dirección IP y los números AS dentro del marco de confianza RPKI , mientras que una Autorización de Origen de Ruta permite a un titular de recursos autorizar explícitamente a un sistema autónomo a originar rutas para prefijos especificados.

Esto hace que RPKI sea una prueba valiosa para una pregunta específica:

¿Este ASN está autorizado, dentro del sistema RPKI , para originar este prefijo?

Pero incluso RPKI no debe ser estirado más allá de lo que prueba.

Un ROA válido no prueba automáticamente:

• propiedad jurídica;
• los términos de un contrato de arrendamiento;
• que opera la aplicación del cliente;
• quién pagó el recurso;
• todo interés contractual; o
• que la ruta está siendo anunciada actualmente.

Es una poderosa afirmación de seguridad.

No es un documento de título universal.

5. Cartas de autorización

Los operadores de red utilizan con frecuencia Cartas de Autorización, o LOA s, para documentar el permiso para las acciones relacionadas con el enrutamiento.

Un LOA puede indicar que una red particular o ASN está autorizado para anunciar un prefijo.

Esto puede ser útil cuando:

• la creación de BGP ;
• moviéndose entre los proveedores;
• configuración de redes de aguas arriba;
• utilizando el espacio IPv4 alquilado; o
• cambiando ambientes de alojamiento.

Una LOA proporciona evidencia de autorización, pero su confiabilidad depende de si la parte emisora estaba autorizada a hacerlo.

La importante cuestión sigue siendo la cadena de control.

Un documento es tan útil como la autoridad detrás de él.

6. Contracts and Operational Delegation Records

Un titular de recursos de IP puede permitir que otra organización utilice el espacio de dirección sin transferir la relación de registro subyacente.

Esto es común en el arrendamiento y otros arreglos operacionales.

Un contrato puede establecer:

• que prefijo se utiliza;
• quien puede recorrerlo;
• que la ASN puede originar;
• cuánto dura la delegación;
• que administra RPKI ;
• quién controla el DNS inverso;
• que maneja informes de abuso; y
• lo que sucede cuando la relación termina.

En esta situación, el titular de los recursos y el usuario operacional son partes diferentes.

Eso no crea necesariamente una contradicción.

Crea una necesidad de registros más claros.

El titular debe permanecer identificable.

La delegación operacional debe ser comprensible.

La autorización de enrutamiento debe coincidir con la red prevista.

Y el fin de la delegación debe tener un proceso operativo claro.

Esta es una razón The Policy Mirror Sostiene un modelo de registro capaz de reconocer a la delegación operacional manteniendo la capa común de coordinación centrada en la singularidad, la exactitud y la continuidad.

7. Control DNS inverso

La capacidad de cambiar el DNS inverso puede demostrar autoridad operacional en otra parte del entorno de recursos de la IP .

Pero de nuevo, sólo demuestra una capacidad específica.

Si una organización puede actualizar los registros de PTR , eso no significa automáticamente que pueda:

• transferir el prefijo;
• cambiar el titular registrado;
• crear un ROA ; o
• autorizar una red totalmente diferente para originarla.

DNS inverso es una capa.

No debe confundirse con la prueba de cada otra capa.

8. Registros históricos y de auditoría

La prueba se vuelve mucho más fácil cuando los cambios de recursos dejan una pista de auditoría.

Los registros útiles pueden mostrar:

• que hizo un cambio;
• cuando se hizo;
• lo que era el estado anterior;
• qué pruebas apoyaron el cambio;
• qué organización lo autorizó; y
• si los registros relacionados de seguridad o de enrutamiento cambiaron al mismo tiempo.

Esto se vuelve particularmente importante durante las controversias.

Supongamos que dos partes reclaman autoridad sobre un prefijo.

Un sistema sin antecedentes significativos puede contener sólo la entrada actual de la base de datos.

En cambio, un sistema auditable puede reconstruir cómo el recurso pasó de un estado a otro.

Esto permite que la pregunta se convierta en:

¿La transición era válida?

en lugar de simplemente:

“¿Qué dice la base de datos hoy?”

Esta distinción importa porque un buen registro debe mantener un estado preciso y hacer que los cambios estatales legítimos sean explicables.

Qué prueba de control no prueba

Un error común es tomar una prueba válida y tratarla como prueba de todo.

Eso debería evitarse.

Es por eso que la prueba de control se entiende mejor como marco de pruebas más que un solo documento.

Prueba de control durante una transferencia de direcciones IP

Las transferencias son una de las situaciones donde la prueba de control se vuelve más importante.

Antes de que un registro cambie de un titular a otro, el proceso debe ser capaz de establecer al mínimo:

1. ¿Qué recurso está involucrado?
2. ¿Quién es el transferor reconocido?
3. ¿La persona que solicita la transferencia tiene autoridad para actuar para esa parte?
4. ¿Hay una reclamación contradictoria, preocupación por el fraude o retención pertinente?
5. ¿Quién es el cesionario previsto?
6. ¿Se puede registrar con precisión la nueva información del registro?
7. ¿Puede la transición de la información operacional asociada sin interrupciones innecesarias?

El papel del registro aquí debe ser significativo pero centrado.

Debe verificar la integridad de la transición del registro.

Eso no significa necesariamente decidir cada pregunta comercial que rodea la transacción.

Esto refleja el principio expresado en The Bill of Rights of Uniqueness Coordination: la capa común debe proteger la singularidad, la prueba de control, la exactitud del registro, las afirmaciones de seguridad, los registros de transferencia, la auditabilidad y la continuidad.

Prueba de control durante la dirección IP Leasing

El plomo crea una situación diferente.

El titular de los recursos registrados puede seguir siendo el mismo.

Otra organización puede convertirse en el usuario operacional.

Un tercero puede proporcionar la red a través de la cual se anuncia el prefijo.

Por lo tanto, la prueba de control debe responder a varias preguntas más estrechas:

¿Quién es el titular?

¿Quién es el usuario autorizado?

¿Quién puede anunciar el prefijo?

¿Qué ASN debería originarlo?

¿Quién maneja RPKI ?

¿Quién controla DNS revertido?

¿Cuándo comienza y termina la delegación?

Intentar derrumbar todos estos roles en una sola palabra —“propista”, “accionista” o “usuario”— puede crear más confusión que claridad.

Un mejor sistema registra las relaciones que realmente importan.

¿Qué sucede cuando diferentes pruebas de conflicto?

Los casos más difíciles ocurren cuando diferentes sistemas cuentan historias diferentes.

Imagina eso:

• el registro identifica a la Organización A;
• el prefijo es anunciado por la Organización B;
• un contrato dice que la Organización C está utilizando las direcciones;
• un viejo ROA todavía autoriza ASN X;
• la red actual está utilizando ASN Y; y
• dos partes discrepan sobre quién puede solicitar la siguiente actualización del registro.

Simplemente elegir una base de datos e ignorar el resto puede no resolver el problema subyacente.

Una mejor investigación pregunta:

• ¿Cuál fue el último estado de registro verificado?
• ¿Qué cambió después de eso?
• ¿Quién autorizó el cambio?
• ¿Qué evidencia apoya cada reclamación?
• ¿Qué partes de la red están actualmente en funcionamiento?
• ¿Hay evidencia de fraude o de una transición estatal no autorizada?
• ¿Qué información se puede actualizar sin perturbar innecesariamente la operación legítima de red?

Un estado en disputa debe ser tratado como un problema para investigar, no como una excusa para pretender que la realidad operacional no existe.

¿Por qué “Último Estado Verificado”

Cuando el control es incierto, manteniendo una auditoría último estado verificado puede ayudar a evitar que la incertidumbre se convierta en cambio arbitrario.

La idea es directa.

Antes de cambiar un registro controvertido, el sistema debe saber:

• cuál era el último estado verificado;
• qué pruebas la respaldaban;
• qué nueva evidencia ha aparecido;
• si la transición propuesta es válida; y
• si una controversia sigue sin resolverse.

Esto no significa preservar un registro incorrecto para siempre.

Significa hacer cambios rastreables.

Un registro debe poder decir no sólo:

“Este es el estado actual”.

pero también:

“Así es como el recurso pasó del estado verificado anterior al estado actual”.

Eso es lo que la auditabilidad añade a la prueba de control.

Prueba de control debe ser portátil

Hay otra pregunta importante de diseño.

¿Qué pasa si la prueba de control existe sólo dentro de la base de datos privada de una institución?

Entonces la capacidad del titular de los recursos para demostrar el control puede depender del acceso continuo a esa institución.

Un modelo de coordinación más resistente debería aportar pruebas importantes:

• verificable;
• auditables;
• transferible cuando proceda;
• comprensible por contrapartes; y
• recuperable durante el fracaso institucional.

Esto no significa que cada credencial debe estar expuesto públicamente.

Significa que la validez no debe depender innecesariamente del bloqueo institucional.

Un titular de recursos debe poder demostrar una cadena legítima de control incluso cuando los proveedores, empleados, infraestructura o sistemas administrativos cambien.

Una lista práctica de verificación de control

Antes de hacer un cambio significativo que implica un recurso IP , pregunte:

Identidad en los recursos

• ¿Qué prefijo IPv4 o IPv6 está involucrado?
• ¿Está identificado el recurso?

Estado del registro

• ¿Qué organización está registrada actualmente?
• ¿Están los registros pertinentes actualizados?
• ¿Hay una disputa o conflicto activo?

Autoridad orgánica

• ¿Quién solicita el cambio?
• ¿Puede esa persona actuar legítimamente para la organización?

Routing

• ¿Qué ASN origina actualmente el prefijo?
• ¿Qué ASN tiene la intención de originarlo después del cambio?
• ¿Quién autorizó ese acuerdo?

RPKI

• ¿Hay un ROA relevante?
• ¿Concuerda con el estado de enrutamiento previsto?
• ¿Quién puede hacer cambios RPKI necesarios?

Delegación operacional

• ¿Está utilizando el recurso otra organización?
• ¿Está documentada esa delegación?
• ¿Cuándo empieza o termina?

DNS inversa

• ¿Quién controla la delegación DNS inversa?
• ¿Esa responsabilidad tiene que cambiar?

Auditoría

• ¿Qué evidencia apoya la transición estatal solicitada?
• ¿El estado anterior seguirá siendo rastreable?

Continuidad

• ¿Se puede completar el cambio sin interrumpir innecesariamente una red de funcionamiento?

Esta es una prueba mucho más útil que preguntar si alguien puede producir un documento etiquetado “prueba de control”.

Thin Coordination requiere una prueba fuerte, no control amplio

Un registro delgado no significa un registro con poca seguridad.

De muchas maneras, lo contrario es cierto.

Si una capa de coordinación se centra en un conjunto más pequeño de funciones esenciales, esas funciones deben hacerse bien.

Esto significa mecanismos sólidos para:

• singularidad;
• identidad;
• prueba de control;
• exactitud del registro;
• prevención del fraude;
• de seguridad;
• c) Registros de transferencia;
• auditabilidad;
• situación de conflicto; y
• continuidad operacional.

Lo que no pertenece necesariamente en la misma capa común son decisiones más amplias acerca de:

• fijación de precios;
• geografía del cliente;
• modelos comerciales ordinarios;
• estrategia empresarial o
• que legítimo proveedor de infraestructura un operador elige.

La prueba de control debe proteger la integridad del registro.

No debe convertirse en una justificación vaga para controlar cada decisión que implica un recurso número de Internet.

Proof of Control and Running Networks

En última instancia, la prueba de los asuntos de control porque las direcciones IP son usadas por redes de ejecución.

Una vez desplegado un prefijo, puede apoyar:

• servidores;
• sitios web;
• API ;
• ambientes de nubes;
• servicios al cliente;
• cortafuegos;
• VPN s;
• DNS ;
• sistemas de correo electrónico;
• políticas de seguridad; y
• Controles de acceso a la red.

Por consiguiente, un cambio no autorizado puede tener consecuencias mucho más allá de una base de datos del registro.

Al mismo tiempo, no se debe permitir automáticamente que una cuestión administrativa no resuelta produzca perturbaciones innecesarias para una red de funcionamiento válida.

Este equilibrio es central en Primacía del departamento.

El registro necesita pruebas sólidas.

La capa de seguridad necesita autorización válida.

El registro debe permanecer exacto.

Pero estos mecanismos existen para apoyar las redes interoperables.

No deben perder de vista ese propósito.

Conclusión

La prueba de control de una dirección IP no debe reducirse a un campo de base de datos, un anuncio de BGP o un documento.

Los recursos del número de Internet existen en varias capas.

El registro registra una parte de la realidad.

BGP describe el enrutamiento.

RPKI describe la autorización de origen de ruta.

Los contratos pueden describir la delegación comercial o operacional.

Los registros corporativos pueden establecer autoridad para actuar.

La historia de la auditoría muestra cómo el recurso se movió entre los estados.

Cada capa responde a una pregunta diferente.

El objetivo no es hacer la prueba más complicada de lo necesario.

Es para hacerlo preciso.

¿Quién controla el recurso?

a menudo es demasiado amplio.

Una mejor pregunta es:

¿Quién está autorizado para realizar esta acción específica, qué evidencia apoya esa autoridad, y puede el estado resultante ser comprendido y verificado independientemente?

Eso es lo que la prueba de control debe proporcionar.

Un sistema fuerte de registro debe facilitar el control legítimo, los cambios no autorizados difíciles de realizar, las controversias más fáciles de auditar y las redes de funcionamiento más fáciles de proteger.

El registro debe registrar el control con precisión.

Las pruebas deben hacer verificable el control.

Y la prueba debe servir a la red, no convertirse en un sustituto de ella.