Resumen

  • RFC 791 asignó al tipo 130 un formato fijo de once octetos con seguridad, compartimentos, restricciones de manejo y código de control de transmisión; las revisiones conservaron el número, pero no esa estructura.
  • RFC 1108 convirtió la clasificación y las autoridades de protección en datos que cada interfaz comparaba con su política, y admitió tanto etiquetas explícitas como etiquetas implícitas de redes dedicadas.
  • Aunque RFC 1108 pasó a Historic y el tipo 130 no debería verse normalmente en Internet público, RFC 7126 desaconsejó que un dispositivo genérico lo quitara o descartara por defecto: en una red MLS cerrada, hacerlo podía reclasificar los datos por accidente.

Una ausencia también puede tener un nivel

El detalle que cambia toda la historia aparece en RFC 7126. Cuando un intermediario quita el Basic Security Option, el destino puede rechazar un paquete que debía llevar etiqueta. Pero también puede admitirlo bajo una etiqueta implícita asociada a la interfaz. Así, borrar un campo no siempre elimina una decisión; a veces activa otra decisión que estaba esperando precisamente la ausencia.

El resultado puede elevar información ordinaria a un dominio más restringido o rebajar información sensible a un dominio menos protegido. En el primer caso se bloquean usos legítimos y se contaminan sistemas de mayor nivel. En el segundo se abre una vía de exposición. El cortafuegos no ha neutralizado una prueba de identidad: ha cambiado una entrada de política sin conocer la regla de sustitución del receptor.

La opción no cifra el contenido, no autentica al remitente y no acredita una habilitación. Es una etiqueta destinada a sistemas de confianza. Solo adquiere fuerza cuando la asignación, los extremos, los encaminadores y la configuración de interfaces forman una cadena protegida.

El primer tipo 130 combinaba cuatro ejes

RFC 791 definió Security como una opción de once octetos. Después de tipo y longitud colocó dieciséis bits de Security, dieciséis de Compartments, dieciséis de Handling Restrictions y veinticuatro de Transmission Control Code.

Security elegía un nivel denominado. Compartments separaba categorías controladas. Handling Restrictions representaba marcas de control y difusión. TCC identificaba comunidades de interés. Por tanto, el encabezado no contenía solo una escala lineal: intentaba transportar varias dimensiones de un régimen externo de manejo de información.

La opción tenía activado el bit de copia. Cada fragmento debía conservarla y solo podía aparecer una vez por datagrama. Fragmentar el paquete no debía separar su contenido del contexto bajo el que podía circular.

RFC 791 también decía que usar una opción en un datagrama concreto era opcional, pero implementarla en los módulos IP no lo era. Algunos entornos podían exigir Security en todos los datagramas. El protocolo común reservaba así capacidad para una obligación que dependía totalmente del dominio conectado.

Copiar esos campos no demostraba su verdad. Sin integridad criptográfica, fuentes confiables y controles sobre el trayecto, una etiqueta bien formada seguía siendo solo una afirmación.

La continuidad del número ocultó la sustitución del cuerpo

RFC 1038 revisó en 1988 el tipo 130 como Basic Security Option de longitud variable. La antigua secuencia de compartimentos, manejo y TCC desapareció. En su lugar quedaron un nivel de clasificación e indicadores de autoridad de protección.

Para analizar una captura, el número 130 no basta. La longitud y el RFC aplicable deciden cómo se dividen los octetos. Un registro puede mantener estable el identificador mientras la gramática que este introduce cambia de forma incompatible.

RFC 1038 esperaba que componentes confiables usaran la etiqueta para comprobar que la fuente podía transmitir la información, que el trayecto y el destino disponían de protección suficiente y que distintos modelos de control compartieran una representación. Ninguna de esas propiedades nacía del encabezado por sí solo: dependían de sistemas acreditados y encaminamiento consciente de la seguridad.

RFC 1108 volvió a revisar el mecanismo, dejó obsoleto RFC 1038 y definió Basic y Extended Security Options. El Basic conservó el tipo 130, pero incluso su mínimo cambió: podía ocupar tres octetos cuando no había Protection Authority. La estabilidad del código fue administrativa; el formato atravesó dos transiciones.

Los valores no debían compararse como números

RFC 1108 destinó un octeto al Classification Level. Sus códigos válidos eran patrones dispersos que representaban Top Secret, Secret, Confidential o Unclassified; otros patrones de la tabla permanecían reservados. El orden numérico no coincidía con el orden de sensibilidad.

Por ello, un programa no podía aplicar una comparación aritmética y aceptar todo byte entre dos valores. Ese intervalo incluiría patrones sin asignar. Primero debía reconocer exactamente el código y luego consultar el orden definido por la tabla.

Los patrones se eligieron con una distancia de Hamming mínima de cuatro entre valores válidos. Unas pocas inversiones accidentales de bits tenían menos probabilidad de convertir directamente una clasificación válida en otra. Esa separación detecta errores; no aporta cifrado, autenticidad ni resistencia frente a quien escriba deliberadamente otro código válido.

El diseño expresa una separación importante: la política ordena símbolos, no magnitudes. El software necesita el vocabulario administrado; no puede deducir qué domina a qué observando el tamaño del byte.

Las autoridades eran selectores de reglas

Tras el nivel, RFC 1108 permitía un campo Protection Authority variable. Los siete bits superiores de cada octeto eran indicadores y el bit inferior avisaba de otro octeto. Un datagrama podía invocar reglas de varias autoridades, y una implementación mínima debía procesar al menos dos octetos de indicadores.

La especificación advertía que estas no eran autoridades de acreditación. Los bits identificaban programas cuyas reglas de protección se aplicaban a la información; no certificaban un host ni concedían autorización a una persona.

La codificación debía ser mínima. No se permitían octetos finales de continuación con todos los indicadores a cero, y la longitud indicada debía coincidir con la opción. Una extensión mal formada era un error de protocolo, no una lista inocua de nombres desconocidos.

Además, las asignaciones tenían que gobernarse fuera del paquete. El campo seleccionaba valores de un espacio administrado, pero no podía publicar las reglas ni demostrar que un componente las hubiera cumplido.

La frontera real era cada interfaz

RFC 1108 especificó parámetros generales y parámetros por «port». En este contexto port significa interfaz o conexión de red, no puerto TCP o UDP. Una interfaz podía exigir BSO al enviar, al recibir, en ambos sentidos o en ninguno.

Los sistemas que manejaban datos clasificados normalmente debían emitir la opción. Había una excepción para una red dedicada o system-high: si todos los datos compartían el mismo contexto, la interfaz podía proporcionar una etiqueta implícita. Un paquete sin etiqueta explícita adoptaba entonces el nivel configurado localmente.

Por eso no existe un significado universal para la ausencia. En una interfaz puede equivaler a tráfico ordinario; en otra, a información de un nivel protegido concreto. Quitar el campo explícito no deja una casilla vacía: desplaza la fuente de autoridad hacia la configuración de entrada.

Al recibir, el sistema comprobaba que la clasificación estuviera asignada, que no superara el máximo de la interfaz y que sus autoridades estuvieran permitidas. Al transmitir, el nivel debía quedar entre el mínimo y el máximo de salida y los indicadores debían pertenecer al conjunto autorizado.

El paquete proponía un nivel y la interfaz imponía el intervalo admisible. Una captura que no incluya esa configuración solo conserva una mitad de la decisión.

Responder o callar formaba parte de la política

Si una interfaz exigía BSO y recibía un datagrama sin la opción, RFC 1108 indicaba ICMP Parameter Problem con Code 1 para una opción obligatoria ausente. Una estructura defectuosa usaba la forma ordinaria de parameter problem y ciertos rechazos podían comunicarse como administratively prohibited.

Esas eran las acciones menos restrictivas permitidas. La política local podía exigir registro, avisar a un responsable o prohibir cualquier respuesta. Incluso un diagnóstico saliente debía ser compatible con la clasificación de la interfaz por la que se enviaba.

No se desprende de aquí una regla general para toda opción IPv4 faltante. El caso muestra un sistema donde silencio, error y etiqueta de la respuesta son actos de seguridad. El interés principal no es el código ICMP, sino que la opción era una condición de admisión real.

Los hosts descartaron formatos antiguos; los routers conservaron la revisión

RFC 1122 llamó obsoletas a las opciones descritas por RFC 791 y RFC 1038. Para aplicaciones DoD dirigió a los fabricantes hacia la revisión posterior. «Obsoleto» calificaba esos formatos, no declaraba la desaparición de todas las redes con etiquetas.

RFC 1812 mantuvo la distinción. Repitió que las variantes anteriores eran obsoletas, pero dijo que los routers debían implementar la opción revisada de RFC 1108. Los routers destinados a varios niveles de seguridad debían filtrar etiquetas IPSO.

Su modelo asignaba a cada interfaz un límite inferior y otro superior de sensibilidad. Un paquete fuera del intervalo debía descartarse en silencio y aumentar un contador. No era source routing ni una lista de pasos: cada interfaz aplicaba una prueba local.

La historia normativa no es un interruptor. Un formato se retira, un sucesor queda como función condicional, ese RFC acaba en Historic y aun así persiste la necesidad dentro de un nicho operativo.

Historic no quería decir «sin despliegues»

RFC 7126 afirma que estas opciones no deberían aparecer normalmente en Internet público global. A la vez, documenta que redes privadas multinivel usaban Basic y Extended Security Options sobre productos comerciales y sistemas abiertos. Consideraba posible que el despliegue MLS, y con él IPSO, hubiera crecido desde la retirada del Standards Track.

Una técnica puede desaparecer de la corriente pública y sobrevivir en espacios cerrados donde cumple una función difícil de sustituir. Historic es el estado de un documento; no es una medición actual, ni una prueba de cero paquetes, ni una orden para borrar el registro.

El mismo equipo comercial puede instalarse en ambos lugares. Antes de ser configurado, no sabe si el tipo 130 es ruido en un enlace público o un requisito dentro de un dominio MLS. Esa incertidumbre convierte la conservación en un mejor valor inicial.

Conservar no equivale a reconocer autoridad

La recomendación de RFC 7126 está acotada. Como quitar o bloquear BSO puede romper redes que lo necesitan y transportarlo no produce un daño específico nuevo donde no se utiliza, un dispositivo genérico no debería eliminarlo ni descartar el paquete solo por su presencia.

Un administrador que sabe que su entorno no usa IPSO puede configurar el descarte. El equipo debería contar paquetes BSO por interfaz y permitir filtros tanto por presencia como por valores. No se pide al Internet abierto que interprete etiquetas clasificadas; se pide que la configuración, no una limpieza silenciosa, decida qué hacer.

Un intermediario puede preservar bytes sin confiar en ellos. La interpretación y la aceptación pertenecen a los puntos que poseen política MLS. Esa separación evita confundir interoperabilidad con autorización.

El TCP contemporáneo todavía tuvo que delimitar la excepción

RFC 9293 conserva la huella de antiguas reglas TCP que trataban la seguridad y los compartimentos IP durante el procesamiento de conexiones. Para entonces RFC 1108 era Historic, pero RFC 791 no había sido actualizado para retirar Security.

El texto moderno coloca la cuestión en notas de implementación. La información puede seguir siendo relevante para implementadores MLS y puede ignorarse fuera de ese ámbito. Expresar la bifurcación es más seguro que fingir una única conducta válida para todos.

También recuerda que reiniciar conexiones cuando no coinciden compartimentos o precedence se reconoció como posible vector de ataque. Una etiqueta útil dentro de su confianza puede convertirse en palanca de interrupción si una antigua reacción entre capas se conserva mecánicamente.

Las pruebas que el tipo 130 no contiene

En una captura, el tipo 130 prueba que existen bytes en una posición históricamente asignada. La longitud y el diseño aparente ayudan a determinar qué RFC parece seguir. Un código válido y una cadena de autoridades bien formada muestran conformidad sintáctica.

No prueban que el emisor tenga habilitación, que el nivel sea verdadero, que el contenido esté cifrado, que el trayecto sea seguro ni que la próxima interfaz lo vaya a aceptar. Para afirmarlo harían falta evidencias de los sistemas, las asignaciones y la configuración reales.

Tampoco la ausencia demuestra Unclassified. Si la interfaz emplea etiquetas implícitas, el nivel puede estar fuera del paquete. El analista que separa la captura de su punto de entrada pierde la regla que completaba el significado.

El legado del tipo 130 no es una invitación a colocar seguridad en todos los encabezados. Es una advertencia: borrar metadatos que alimentan control de acceso obligatorio es una operación semántica. Un campo desconocido puede ser más seguro intacto que convertido en una ausencia engañosa.

Fuentes y límites de la evidencia

El conjunto cerrado es RFC 791, RFC 1038, RFC 1108, RFC 1122, RFC 1812, RFC 7126 y RFC 9293. Establecen formatos, procesamiento, historia normativa y consejo de filtrado. No revelan despliegues clasificados, no miden tráfico vigente, no verifican productos y no garantizan que una etiqueta observada sea verdadera.