Modelos de Referencia de Seguridad de la Información

RFC Equipo Alpha

Rafael Alfaro Tapia
Carla Cortés Leyva
Octavio Domínguez Salgado
Nayely Morales Perales
Ricardo Uriel Osorno Ortiz
Stephanie Torres Juan

1
 En 1969 Stephen Crocker (pionero en la comunicación entre ordenadores
y experto en seguridad computacional) inventó un sistema eficaz de
hacer llegar las propuestas técnicas a todo un grupo de trabajo,
denominado RFC.

El RFC es básicamente una recopilación de la documentación estándar

RFC sobre internet. En esta serie de documentos se detalla todo lo
relacionado con la tecnología de la que se sirve Internet, protocolos,
recomendaciones y comunicaciones.

En la actualidad, se cuenta con más de 9,000 RFC’s.

2
El Request for Comments (RFC) es un documento numérico en el que se describen y
definen protocolos, conceptos, métodos y programas de Internet.

La gestión de los RFC se realiza a través de IETF (Internet Engineering Task Force).

Request for
El RFC 1 fue elaborado en Abril de 1969. Comments
(RFC)
Algunos RFC básicos han sido aprobados oficialmente como estándares, sin
embargo, a pesar de que la mayoría de los RFC no logra alcanzar dicho estatus, son
utilizados como tales en todo el mundo.

Los grupos o personas que colaboran en los RFC, invierten su tiempo principalmente
en mejorar los protocolos y no en estandarizarlos.

3
 La configuración de un RFC requiere de un formalismo bastante
estricto.

En el RFC 2223 se describe cómo hay que escribir un RFC.

Elaboración de El RFC 2119 estipula qué significado se le asigna a cada término como
un RFC «Must» o «Must not». De este modo se evitan malentendidos.

La composición de las cadenas de caracteres también está

estrictamente definida.

Si un RFC es publicado nunca podrá corregirse, sólamente puede ser

relevado por un RFC nuevo.

4
Cada RFC tiene un título y número asignado que no puede repetirse ni
eliminarse a pesar de que el documento quede obsoleto.

Los RFC están redactados en inglés y en formato de texto ASCII.

Categorías de los RFC: Propuestas de estándares nuevos, informativo o

histórico. Características

La descarga y consulta de los RFC es gratuita.

La numeración de un RFC puede cambiar cuando surge un documento nuevo

con modificaciones o suplementos sustanciales o cuando supone una
recopilación de varios precursores.

5
RFC - Estándar

A aquellos RFCs, que

documentan estándares de
Internet, se les asigna una
etiqueta adicional "STDxxx",
conservando su propio número
RFC.

RFC 2026 - The Internet Standards Process -- Revision 3 6

RFC – BCP

A aquellos RFCs, que

documentan las mejores
prácticas, se les asigna una
etiqueta adicional "BCPxxx",
conservando su propio número
RFC.

RFC 2026 - The Internet Standards Process -- Revision 3 7

Categorías de  Technical Specification (TS)
los estándares  Aplicability Statement (AS)
de Internet

RFC 2026 - The Internet Standards Process -- Revision 3 8

 Un TS debe aplicar uno de los siguientes niveles de cumplimiento a
cada uno de los TS a los que hace referencia:
 Requerido: Es de cumplimiento obligado. Por ejemplo, el RFC del
protocolo IP.
 Recomendado: Aquellas que, si no son cumplidas, no impiden la
conexión a Internet, pero afectan de manera importante a la
prestación y acceso a los servicios. Por ejemplo, el RFC de TCP.
Niveles de cumplimiento  Electivo: Son necesarias para un servicio en concreto. Por
aplicables a un TS
ejemplo, SMTP para acceder al correo electrónico
 Uso limitado: Se utiliza en determinadas circunstancias. Esto
puede ser debido a su estado experimental, naturaleza específica,
funcionalidad limitada o estado histórico.
 No recomendado: Aquellas que no se recomiendan para uso
general. Esto puede ser debido a su funcionalidad limitada,
naturaleza específica o estado experimental o histórico.

RFC 2026 - The Internet Standards Process -- Revision 3 9

 Un AS debe aplicar uno de los siguientes niveles de cumplimiento a
cada uno de los TS a los que hace referencia:
 Requerido: Es de cumplimiento obligado. Por ejemplo, el RFC del
protocolo IP.
 Recomendado: Aquellas que, si no son cumplidas, no impiden la
conexión a Internet, pero afectan de manera importante a la
prestación y acceso a los servicios. Por ejemplo, el RFC de TCP.
Niveles de cumplimiento  Electivo: Son necesarias para un servicio en concreto. Por
aplicables a un TS
ejemplo, SMTP para acceder al correo electrónico
 Uso limitado: Se utiliza en determinadas circunstancias. Esto
puede ser debido a su estado experimental, naturaleza específica,
funcionalidad limitada o estado histórico.
 No recomendado: Aquellas que no se recomiendan para uso
general. Esto puede ser debido a su funcionalidad limitada,
naturaleza específica o estado experimental o histórico.

RFC 2026 - The Internet Standards Process -- Revision 3 10

 Documento RFC considerado estándar
 Estándar: Se caracteriza por tener un alto grado de madurez
técnico, el protocolo o servicio proporciona un beneficio significante a la
comunidad de Internet.
 Estándar borrador: Se considera como un posible protocolo estándar.
 Estándar propuesto: Es una propuesta que debe considerar el IAB para su
estandarización en el futuro.
Niveles de madurez de
los RFC.
Documento RFC no considerado estándar
 Experimental: Es una especificación experimental que
no debería implementarse a no ser que esté participando en el experimento
y ha coordinado su uso del protocolo con el desarrollador del protocolo.
 Informativo: Protocolos desarrollados por otras organizaciones o que están
fuera del alcance del IAB, deben publicarse como RFCs por conveniencia de la
comunidad de Internet como protocolos informativos.
 Histórico: Es poco probable que pasen a ser estándares en Internet porque
los han reemplazado los desarrolladores más tarde o por falta de interés.

RFC 2026 - The Internet Standards Process -- Revision 3 11

 Cada RFC se presenta
¿Dónde
como texto plano ASCII y podemos
Fuente oficial » RFC Editor se publica en esa forma,
([Link]) pero también pueden estar consultar los
disponibles en otros
formatos. RFC?

12
 El proceso de publicación de RFC incluye las siguientes etapas:
 Proceso de envío de RFC
Proceso de  Proceso de edición de RFC
publicación de  Revisión final de los autores
un RFC  Publicación
 Aviso de derechos de autor y leyenda

13
  RFC del IAB
El RFC 4845 describe como el IAB procesa sus documentos.
 RFC del IETF
Todos los RFC en una categoría de Standards Track o Best
Current Practice (BCP), así como algunos RFC informativos y
Proceso de experimentales, se originan dentro del proceso IETF y llegan al editor de
RFC a través del IESG. Los miembros del IESG incluyen a los directores del
envío de RFC área (AD) del IETF, que son responsables de conjuntos de grupos de
trabajo relacionados. Estos grupos de trabajo desarrollan documentos
que pueden ser aprobados para su publicación como RFC por los AD con
la concurrencia de IESG.
 RFC de la IRTF
El RFC 5743 describe como el IRTF procesa sus documentos.

14
  Envíos independientes
Cualquiera puede escribir un borrador de internet y enviarlo de
forma independiente al editor de envíos independientes (ISE) para su
posible publicación como un RFC (solo en las categorías Informativo,
Proceso de Experimental e Histórico). Se revisará su competencia técnica,
relevancia y redacción adecuada. También será revisado por el ISE y por el
envío de RFC IESG por posibles conflictos con el proceso IETF. Si se selecciona para su
publicación, el envío ingresará a la cola de publicación del editor de RFC.
Una presentación independiente debe publicarse primero como borrador
de internet.

15
  El editor RFC mantiene una lista de documentos en el proceso editorial.
Los documentos se procesan en orden FIFO, esta lista se denomina
cola de publicación.
 Cada documento en la cola se asigna a un estado que realiza un
Proceso de seguimiento de su proceso. El diagrama de estado muestra el proceso
de publicación general.
edición de RFC  Cada vez que un documento ingresa a la cola editorial, cambia su estado
en la cola o sale de la cola, se envía a los autores un mensaje de correo
electrónico automático que resume el cambio de estado. Este mensaje
es solo para información; no reemplaza los mensajes existentes para los
autores, como los mensajes AUTH48.

16
 Una vez que se ha editado un RFC y está listo para su publicación,
los autores tienes “48 horas” (en la práctica, esto a menudo se
extiende durante semanas) para revisar su documento en busca de
Proceso de errores, editoriales y de otro tipo. NO SE REALIZAN CAMBIOS EN
LOS RFC UNA VEZ QUE SE HAN PUBLICADO. Tras la aprobación
Revisión final de todos los autores, se publica el RFC.
de los autores El mensaje de notificación AUTH48 enviado a los autores solicita
que revisen todo el documento, prestando especial atención a:
(estado  Actualizaciones de las consideraciones de la IANA (si
AUTH48) corresponde)
 Información de contacto
 Referencias

17
 Cuando se publica un RFC, se envía un anuncio a las listas de correo
ietf-announce y rfc-dist. La URL de la página de información de un
RFC tiene el formato:
Publicación
[Link]/info/rfcXXXX

18
 La página de información sobre la licencia del administrador del
IETF resume las reglas actuales que rigen los derechos de autor de
Aviso de RFC y las exenciones de responsabilidad sobre los derechos de
derechos de patente (“Propiedad intelectual”) al 10 de noviembre de 2008.

autor y
[Link]
leyenda

19
Definiciones de estado:
EDIT = En espera de edición o siendo editado
RFC-EDITOR = En proceso de revisión interna final antes de AUTH48
AUTH48 = En espera de la aprobación final del autor
AUTH48-DONE = Las aprobaciones finales están completas
AUTH = En espera de la acción del autor
IESG = En espera de acción de IESG
IANA = El documento se ha editado, pero está pendiente de finalización
de las acciones de la IANA
TI = problema de herramientas. La publicación del documento está en
suspenso a la espera de la resolución de un problema con las
herramientas de software utilizadas para crear los archivos.
REF = El documento ha sido editado, pero está en espera de una
referencia normativa que está en la cola.
MISSREF = En espera de una referencia normativa faltante (es decir, la
referencia NO SE RECIBE) o hubo una solicitud específica del IESG o de
los autores para la publicación simultánea con otro documento.
Consulte a continuación los números de generación de MISSREF.

20
  Cualquier persona puede enviar memorandums propuestos para
ser RFCs.
 Reglas de formato: ASCII y PostScript.
 Indica los lineamientos para los encabezados y pie de página

RFC 2223 -Instructions

to RFC Authors

21
  Status Section: Debe incluir la sección "Status of this Memo", que
incluye el tipo de RFC y el distribution statement.

RFC 2223 -Instructions

to RFC Authors

22
 De acuerdo con el RFC 2223, se debe indicar una de las
siguientes categorías en el documento:
 Standards Track: Especifica un protocolo de seguimiento de
estándares de internet.
 Best Current Practice
RFC 2223 -Instructions  Experimental: Está pensado para experimentar o representar el
to RFC Authors posible inicio de un futuro estándar
 Informational: Cuando contiene simplemente una nota o
idea para la comunidad.
Nota: Buscar ejemplos de RFC de cada tipo*

23
 Otros puntos que deben incluirse en un RFC son los siguientes:

 Copyright Notice
 Introduction Section
 References Section
RFC 2223 -Instructions
to RFC Authors  Security Considerations Section
 Author's Address Section
 Copyright Section
 Relation to other RFCs
 Protocol Standards Process
 Contact

24
 Ejemplos - RFC 791
 INTRODUCCION
• Motivación
• Ámbito
• Interfaces
• Operación
PANORAMA GENERAL
• Relación con Otros Protocolos
• Modelo de Operación
• Descripción de Funciones
• Pasarelas ("Gateways")
ESPECIFICACION
 Formato de Cabecera Internet
• Discusión
• Interfaces
APENDICE A: Ejemplos y Escenarios
APENDICE B: Orden de Transmisión de Datos
GLOSARIO
REFERENCIAS

25
 Ejemplos - RFC HTTP
2.0
1. Introducción

2. Resumen de protocolo HTTP/2

3. Inicio de HTTP/2

4. Frames de HTTP

5. Flujos y multiplexaje

6. Definición de frames

7. Código de error

8. Intercambios de mensajes HTTP

9. Requerimientos/Consideraciones adicionales

10. Consideraciones de seguridad

11. Consideraciones de IANA

12. Referencias

13. Apendice A. Lista negra de suites de cifrado TLS 1.2

26
 Ejemplos - RFC
DHCP
 Introducción

 Resumen de protocolo

 Protocolo Cliente/Servidor

 Frames de HTTP

 Especificación del protocolo cliente servidor

DHCP
 Agradecimiento

 Referencias

 Consideraciones de seguridad

 Dirección del autor

 Parámetros de configuración del host

27
 Ejemplos - RFC TLS 1.3

 Introducción

 Resumen de protocolo TLS 1.3

 Lenguaje de presentación

 Protocolo Handshake

 Protocolo de registro

 Protocolo de alerta

 Cálculos criptográfica

 Anti replay

 Requerimientos de cumplimiento

 Consideraciones de seguridad

 Consideraciones de IANA

 Referencias

Apéndice A. Estado de la máquina

Apéndice B. Estructuras de datos de protocolo y valores constantes
Apéndice C. Notas de implementación
Apéndice D. Compatibilidad con versiones anteriores
Apéndice E. Resumen de propiedades de seguridad

28
  RFC Editor: [Link]

Referencias  RFCs: IETF | RFCs

 Request for comments: [Link] ([Link])

29