NAP.

EC es una infraestructura que permite intercambiar localmente trfico de

Internet originado y terminado en el Ecuador, es decir, es una infraestructura parte
del Internet que se denomina comnmente como IXP (Internet eXchange Point) o
punto de intercambio de trfico de Internet en espaol.
Con frecuencia, el trmino "IXP" se acorta a simplemente "IX".

Presentacin e Historia
Al iniciar su actividad, AEPROVI promovo la implementacin de una infraestructura
de red que permitiese intercambiar localmente trfico de Internet originado y
terminado en el Ecuador; a esta infraestructura tecnolgica la denomin NAP
Ecuador (NAP.EC).
Oficialmente, NAP.EC fue creado y entr en operacin el 4 de julio de 2001 con aval
del CONATEL, aunque en modalidad de pruebas estuvo operando algn tiempo
antes. Fueron socios fundadores: Satnet S.A., Impsatel del Ecuador S.A.,
Ramtelecom Telecomunicaciones S.A., Megadatos S.A., Infornetsa S.A. y Prodata
S.A..

NAP.EC se soporta en un "Acuerdo" para intercambio de trfico local cuyos trminos

y condiciones los participantes se comprometen a cumplir.
AEPROVI administra NAP.EC (desde su creacin) de forma imparcial y sin fines de
lucro; entre sus funciones estn velar por el cumplimiento de los compromisos
asumidos por los participantes y brindar soporte tcnico.

Para participar de NAP.EC no es necesario ser socio de AEPROVI.

No existe una regulacin expresa del Estado Ecuatoriano para NAP.EC, sin
embargo el regulador puede solicitar en cualquier momento informacin relativa
a: estadsticas de trfico, porcentajes de ocupacin de los enlaces y
participantes. AEPROVI mantiene pblica esta informacin a travs del
portal www.nap.ec.
NAP.EC naci con el objetivo de extender sus beneficios a nivel nacional por lo cual
AEPROVI se encarga de implementar y habilitar los puntos de presencia (nodos)
que sean necesarios conforme a los requerimientos de intercambio de trfico local.
De acuerdo al documento de creacin, la interconexin entre puntos de presencia
nacionales y la conexin directa hacia la infraestructura de Internet (acceso a puntos
de intercambio de trfico de otros pases, redes de entrega de contenido,
infraestructuras de servicio DNS, etc.) pueden ser suministradas como servicios
adicionales si los respectivos estudios de demanda, viabilidad tcnica y econmica
resultaren convenientes.
Desde el 1 de diciembre de 2007 hasta el 31 de mayo de 2013, los nodos de Quito
y Guayaquil se encontraban interconectados para intercambio de trfico local entre
los proveedores conectados a ambas ciudades.
El 6 de septiembre de 2010 se habilit un nodo en la ciudad de Cuenca, el cual
estuvo interconectado con el nodo de Quito para intercambio de trfico. Este nodo
fue dado de baja oficialmente el 31 de agosto de 2012.
NAP.EC tiene habilitado el intercambio de trfico sobre IPv6 desde inicios de 2009.
Apoyados en la suscripcin de varios acuerdos, dentro de las facilidades de NAP.EC
se alojan infraestructuras de Internet que le dan valor agregado al intercambio de
trfico local, entre ellas: copias de los servidores DNS del dominio raz, servidor del
dominio .EC y nodos de redes de entrega de contenido (CDN).
El primer nodo de una CDN dentro de la infraestructura de NAP.EC empez a
funcionar oficialmente el 1 de junio de 2009. Este fue el primer nodo de una CDN
en todo el Ecuador.
Existen infraestructuras de ciertas CDN alojadas dentro de las facilidades de algn
proveedor conectado a NAP.EC. Algunas de estas CDNs se pueden alcanzar a
travs de NAP.EC gracias a acuerdos de entendimiento especiales suscritos con
los proveedores que alojan dichas infraestructuras, siendo estos proveeedores
algunas veces los propietarios de la CDN y en otras un tercero.
En septiembre de 2013, comprometidos con mejorar la seguridad en el enrutamiento
de Internet, NAP.EC implement todo el equipamiento necesario para realizar
validacin de origen en base a la informacin de RPKI y empez a realizar una
revisin del estado de los prefijos inicialmente sin aplicar ninguna poltica que
implique descartar prefijos.
Los tenedores ecuatorianos de recursos IP apoyaron el proyecto de AEPROVI y
firmaron la mayora de los prefijos IP ecuatorianos. Gracias a este escenario, desde
el 15 de marzo de 2014 en NAP.EC se realiza validacin de origen en base a RPKI
aplicando la poltica estricta de descartar los prefijos con un origen RPKI "invlido"
tanto para IPv4 como para IPv6.
NAP.EC fue la primera infraestructura alrededor del mundo en implementar
validacin de origen en base a RPKI en un ambiente en produccin. El siguiente I-
D del IETF describe el proceso de implementacin y provee ms detalles tcnicos:
https://datatracker.ietf.org/doc/draft-fmejia-opsec-origin-a-country/?include_text=1

Topologa
Actualmente, existe infraestructura de NAP.EC en las siguientes ciudades:

Quito, y
Guayaquil

En cada punto de presencia, los participantes se conectan a una infraestructura de

capa 2 (un medio ethernet) y a travs de esa conectividad configuran el protocolo
de enrutamiento (BGP) entre su enrutador de borde y el respectivo servidor de rutas
de NAP.EC.
La infraestructura de NAP.EC tiene sus propios nmeros de sistema autnomo
(ASN) y maneja su propio rango de direcciones IP pblicas.
A agosto de 2017, existen 20 sistemas autnomos (AS) conectados directamente a
NAP.EC, llegando a 63 la cantidad de nmeros de sistema autnomo (ASN)
diferentes presentes en la tabla de enrutamiento.
La siguiente grfica muestra la topologa lgica de NAP.EC y los participantes
actuales:

Polticas sobre el intercambio de trfico (peering policies)

El intercambio de trfico en NAP.EC se realiza bajo una de las siguientes
modalidades:

MULTILATERAL OBLIGATORIO: cualquier participante que suscriba el acuerdo

de adhesin debe intercambiar trfico de manera obligatoria con todos los
dems participantes que tambin lo hayan suscrito.

MULTILATERAL SELECTIVO: aquellos participantes que hayan suscrito

acuerdos especiales con AEPROVI para conectarse a uno de los puntos de
intercambio de trfico, solo podrn intercambiar trfico con aquellos
participantes que manifiesten a AEPROVI su conformidad con las condiciones y
por tanto su deseo expreso de intercambiar trfico con aquella infraestructura.
Polticas sobre el enrutamiento
Las siguientes polticas de enrutamiento gobiernan la operacin y administracin de
NAP.EC:

1. El protocolo de enrutamiento utilizado es Border Gateway Protocol 4, BGP-4

(RFC 4271, 4760 y sus respectivas actualizaciones).
2. Una sola sesin BGP por conexin con un servidor de rutas.
3. No se aceptan conexiones con nmeros de sistema autnomo (ASN) de uso
privado (RFC 1930, 6996, 7300) o de documentacin (RFC 5398).
4. El ASPATH de los prefijos no debe contener ASN de uso privado o de
documentacin.
5. La longitud mxima permitida para el ASPATH es de 10 ASN.
6. Se descartan rutas por defecto y rangos de direcciones IPv4 e IPv6 de uso
especial (redes privadas, de documentacin, de uso experimental o de
investigacin, rangos reservados por IANA, RFC 1918, RFC 4193, RFC 5735,
RFC 5737, RFC 6598, RFC 6890).
7. Se aceptan prefijos IPv4 con mscaras entre 12 y 24 bits.
8. Se aceptan prefijos IPv6 con mscaras entre 30 y 48 bits.
9. No se permite ebgp multi-hop.
10. Los proveedores deben anunciar los mismos prefijos sobre todas sus
conexiones a NAP.EC.
11. Se maneja un nmero mximo para la cantidad de prefijos recibidos desde los
proveedores.
12. Si el proveedor desea configurar un mximo para el nmero de prefijos recibidos
desde NAP.EC, debe consultar y coordinar el valor adecuado con la
administracin de NAP.EC.
13. A todos los prefijos recibidos en NAP.EC se les asigna un valor de cero para el
atributo MED.
14. A los prefijos recibidos se asigna una preferencia local de 100 en caso de origen
RPKI "valid" y una preferencia local de 50 en caso de origen RPKI "not-
found". Se descarta los prefijos recibidos con origen RPKI "invalid".
15. "Todos" los prefijos son anunciados desde NAP.EC con comunidad "no-export".

16. Adicional a la comunidad no-export, los prefijos son anunciandos con una de las
siguientes comunidades en funcin de la validacin de origen en base a RPKI:
Quito Guayaquil
52482:21 --> sin validacin de origen 52483:21 --> sin validacin de origen
52482:22 --> origen RPKI valid 52483:22 --> origen RPKI valid
52482:23 --> origen RPKI not-found 52483:23 --> origen RPKI not-found
52482:24 --> origen RPKI invalid 52483:24 --> origen RPKI invalid
17. En NAP.EC no se filtran aplicaciones, ni prefijos "pblicos vlidos, esto debe
cumplirse tambin en el lado del proveedor.
Trfico
A continuacin se muestra un resumen general del trfico cursado a travs de
NAP.EC:

Caractersticas de los grficos:

Las estadsticas se actualizan cada 5 minutos.
Tasas de transferencia de datos promediadas cada 5 minutos (en grficos diarios).
VERDE ### Trfico entrante al NAP en bits por segundo

AZUL ### Trfico saliente desde el NAP en bits por segundo

TOTAL QUITO

TOTAL GUAYAQUIL

Cargos
Los cargos que se aplican en NAP.EC permiten cubrir los costos del equipamiento
utilizado, as como tambin los costos de operacin, mantenimiento y
administracin, bajo el lineamiento de que el administrador (AEPROVI) es una
organizacin privada y sin fines de lucro.
Los cargos son establecidos y pueden ser revisados por AEPROVI quien informa
de este particular con 30 das de antelacin a su puesta en prctica. Actualmente
existen los siguientes tipos de cargos:

1. Cargo por puesta en marcha del servicio (a cancelar por una sola vez y depende
de la capacidad de la interfaz).
2. Cargo por cambio de interfaz (aplicable solo en caso de ampliacin/upgrade de
la conexin).
3. Cargo mensual (tiene dos componentes, se explica ms adelante).

El cargo mensual por el servicio de intercambio de trfico local aplicado a un

determinado participante tiene dos componentes: un componente fijo y un
componente variable.

El componente fijo depende de la cantidad y capacidad de las interfaces que el

participante utilice para conectarse a los diferentes puntos de presencia de
NAP.EC.
El componente variable depende del trfico cursado a travs de NAP.EC durante
el mes calendario en cuestin y de los costos operativos de NAP.EC.

Como referencia, en la siguiente grfica se muestra un historial del costo promedio

mensual calculado para 1Mbps considerando todos los componentes:
Cmo participar en NAP.EC?
Los potenciales participantes de NAP.EC son organizaciones que cumplen alguno
de los siguientes roles: proveedores de acceso o trnsito a Internet, redes de
entrega de contenido, redes de investigacin o educativas, redes de servicio DNS
(raz, ccTLD o gTLD), otros puntos de intercambio de trfico, etc.. En cualquier caso,
existen requisitos mnimos y procedimientos obligatorios a seguir, los cuales se
describen a continuacin.

Previo a conectarse por primera vez a cualquiera de los puntos de presencia, toda
organizacin debe suscribir un acuerdo con la administracin del punto de
intercambio de trfico. Existen dos opciones para este acuerdo:

1. Acuerdo de adhesin, tambin denominado "Acuerdo multilateral para

intercambio de trfico a travs de NAP.EC", cuyos trminos establecen una
poltica de intercambio de trfico multilateral obligatorio entre suscriptores de
este acuerdo, adems de definir parmetros de calidad mnima para los enlaces
de conexin, costos y otros detalles relacionados con la operacin.
2. Acuerdo especial cuyos trminos estn sujetos a evaluacin y aprobacin de la
administracin del punto de intercambio de trfico. Entre los parmetros que
sern evaluados estn: pertinencia, personera jurdica de la organizacin en
Ecuador y/o a nivel internacional, contribucin a la estabilidad / resistencia a
fallas / seguridad del Internet ecuatoriano, cantidad de trfico y ahorro de costos
para los usuarios de Internet en Ecuador.
Para que una organizacin pueda suscribir el acuerdo de ahesin debe cumplir los
siguientes requisitos mnimos:

1. Estar autorizado para la explotacin de servicios de Internet conforme a la

legislacin ecuatoriana vigente.
2. Tener legalmente asignados y utilizar recursos "propios" en cuanto a nmero de
sistema autnomo pblico y direcciones IP pblicas.

Para suscribir un acuerdo especial, la organizacin debe cumplir los siguientes

requisitos mnimos:

1. Tener legalmente asignados y utilizar recursos "propios" en cuanto a nmero de

sistema autnomo pblico y direcciones IP pblicas.

Cualquier organizacin interesada en participar del intercambio de trfico a travs

de NAP.EC deber cumplir el siguiente procedimiento para consultas:

1. Lectura. Es indispensable que los interesados den una lectura y comprendan la

informacin disponible en www.nap.ec, en especial lo correspondiente a los
requisitos y las polticas que rigen NAP.EC.
2. Contacto informal. Para aclarar alguna duda, los interesados que reunan los
requisitos podrn contactarse con la administracin de NAP.EC a travs de
llenar y enviar ESTE FORMULARIO.

Las organizaciones interesadas en suscribir el acuerdo de adhesin debern

cumplir el siguiente proceso a fin de participar del intercambio de trfico a travs de
NAP.EC (por cada nodo):

1. Factibilidad enlace de acceso. El potencial participante deber coordinar con

AEPROVI una inspeccin a las instalaciones de NAP.EC para determinar la
factibilidad de instalar su enlace de acceso. Debe tomar en cuenta que existen
requerimientos de disponibilidad y capacidad mnimos exigidos por NAP.EC.
2. Envo de la solicitud. Luego de aclarada cualquier duda y de haber verificado
que existe factibilidad para instalar un enlace de acceso, el interesado deber
enviar una solicitud formal de conexin a NAP.EC. Para esto deber enviar la
siguiente documentacin a la oficina administrativa de AEPROVI:
o Solicitud de conexin remitida por el representante legal.
 o Acuerdo multilateral para intercambio de trfico a travs de NAP.EC firmado
por el representante legal (en caso de no haberlo firmado antes).
o Formulario para solicitar conexin a NAP.EC firmado por el representate
legal.
o Copia del nombramiento de representante legal.
o Copia de la cdula del representante legal.
o Copia del registro nico de contribuyentes RUC.
o Copia del permiso para la provisin del servicio de valor agregado - Internet.
3. Revisin. AEPROVI revisar la documentacin recibida para garantizar que
todos los temas administrativos y tcnicos sean cumplidos correctamente. Si
todos los requisitos son cumplidos se continuar con el proceso, caso contrario
se informar de los reparos al solicitante, quien deber dar una solucin y
reiniciar el proceso.
4. Pago cargos iniciales. Si la documentacin est completa y todos los
requerimientos son cumplidos, AEPROVI emitir una factura correspondiente a
los cargos por puesta en marcha del servicio, la cual debe ser cancelada antes
de continuar con el proceso.
5. Instalacin enlace de acceso:
o El proveedor proceder a la instalacin y pruebas de su enlace de acceso
(existen requerimientos de disponibilidad y capacidad exigidos por NAP.EC).
o AEPROVI asignar los recursos necesarios en el equipamiento de NAP.EC.
o AEPROVI en coordinacin con el responsable tcnico del proveedor
proceder a configurar la sesin BGP (existen polticas de enrutamiento de
cumplimiento obligatorio).
o Si no se cumplen las condiciones de disponibilidad o capacidad del enlace,
as como las polticas de enrutamiento y peering, AEPROVI podr suspender
el proceso hasta que se solucionen los inconvenientes.
6. Si todo funciona correctamente, se proceder a suscribir la respectiva
"Notificacin de entrega del servicio".
7. Los servicios sern facturados a partir de la fecha de suscripcin de la
"Notificacin de entrega del servicio".

NBAR
Introduciendo el uso de NBAR

Network-Based Application Recorgnition (NBAR) es

un feature incluido en Cisco IOS a partir de su versin 12.0, que agrega
habilidades de clasificacin de trfico a la insfraestructura de la red.
Es un motor de clasificacin de trfico que reconoce una amplia variedad de
aplicaciones, incluyendo aquellas que utilizan asignacin dinmica de puertos TCP
o UDP. Esto permite aplicar servicios especficos a las aplicaciones que se
reconocen. Es como tener un analizador de trfico incorporado en nuestra imagen
de Cisco IOS. De esta manera nuestos dispositivos ya no slo pueden operar
sobre informacin de los encabezados de capa 3 y 4, sino que ahora pueden
extender su poder de anlisis hasta capa 7.
A partir de IOS 12.3, las habilidades de clasificacin de trfico de NBAR merced a
la posibilidad de utilizar PDLM (Packet Description Language Module) para
extender estas prestaciones. Cisco regularmente lanza nuevos mdulos PDLM
para nuevas aplicaciones. La lista de PDLM puede ser consultada en la pgina
web de Cisco.
Cmo se utiliza NBAR?
NBAR ha sido diseado como una aplicacin para el reconocimiento de trfico en
la red con el propsito de implementar QoS, sin embargo, es posible darle un
sinnmero de aplicaciones adicionale con el propsito de controlar el trfico con
objetivos de seguridad o solamente remover el trfico indeseable en un
determinado enlace.
En este sentido una de las prestaciones ms interesantes de NBAR es la
posibilidad de identificar campos especficos en un paquete http, tales como una
URL especfica o ciertos clientes web.
En general, se puede utilizar NBAR para identificar cualquier trfico decapa de
aplicacin para el que NBAR tenga una definicin en sus mdulos. La tabla de
protocolos soportados por NBAR puede ser consultada aqu.
Hay algunas limitaciones para la implementacin de NBAR: No se puede aplicar
en tneles o interfaces encriptadas, tampoco puede operar con flujos de trfico
asimtricos o analizar trfico https. Para su operacin requiere habilitar
previamente CEF.
Cmo se configura NBAR?
NBAR es simplemente una aplicacin para identificacin y marcado de trfico.
Para mostrar su implementacin desarrollar un ejemplo en el que se utiliza NBAR
para filtrar trfico http a una URL especfica utilizando ACL, sin embargo, con las
debidas variantes, este mismo procedimiento se puede aplicar a partir del paso 5
para implementar otro tipo de polticas:
Asegrese de que en el dispositivo se encuentra habilitado CEF.

Router(config)#ip cef
Cree una clase para identificar el trfico que se desea clasificar y marcas.
En este caso y a fines de ejemplo definir una clase llamada "descarte" que
clasifica toda URL de http que contenga un programa nombrado "readme.exe".

Router(config)#class-map descarte
Router(config-cmap)#match protocol http url "*readme.exe*"

Los asteriscos indican que se desea detectar cualquier URL que contenga el texto
"readme.exe" sin importar lo que lo precede o siga.
Genere una poltica para marcar el trfico que se ha clasificado en el paso
anterior. Para esto lo marcaremos con un valor de DSCP igual a 1:

Router(config)#policy-map trafico_indeseable
Router(config-pmap)#class descarte
Router(config-pmap)#set ip dscp 1
Configure NBAR de modo que inicie el proceso de descubrimiento de trfico
para todos los protocolos conocidos en una interfaz en particular. En el caso del
ejemplo, esta tarea se debe realizar en la interfaz a travs de la cual ingresa al
dispositivo el trfico que se desea clasificar y marcar para luego filtrarlo.

Router(config)#interface serial 0/0/0

Router(config-if)#ip nbar protocol-discovery

Si se desea realizar una tarea semejante sobre trfico que ingresa a travs de otra
interfaz, NBAR deber ser activado en esa interfaz.
 Ahora es necesario aplicar la poltica que hemos definido antes, a la interfaz
en la que ingresa el trfico que se desea marcar.

Router(config-if)#service-policy input trafico_indeseable

De este modo se ha definido un procedimiento de monitoreo y marcacin de

trfico indeseable. Este tipo de trfico ser marcado con un valor de DSCP igual a
1. Ahora procederemos a filtrarlo sobre el enlace que deseamos preservar,
utilizando una ACL.
Cree una lista de control de acceso que deniegue el trfico marcado:

Router(config)#access-list 110 deny ip any any dscp 1

Router(config)#access-list 110 permit ip any any
A continuacin slo resta aplicar esa lista de acceso a la interfaz elegida
para filtrar el trfico:

Router(config)#interface fastethernet 0/0

Router(config-if)#ip access-group 110 out
NBAR es una potente herramienta de monitoreo de trfico que ya viene instalada
en nuestros routers Cisco IOS desde la versin 12.0. Slo es necesario
familiarizarnos con ella y comenzar a implementarla para aprovechar todo su
potencial.
Tengamos en cuenta que con procedimientos como este, al filtrado tradicional de
ACLs utilizando criterios de capa 3 y 4, podemos ahora agregar la posibilidad de
filtrar trfico en funcin de informacin de capa 7.