[lacnog] Resumen de LACNOG, Vol 169, Envío 12
Fernando Frediani
fhfrediani en gmail.com
Mie Ene 12 18:54:00 -03 2022
Hola Gabriel
Que bueno que hayas enviado más detalles del escenario para que podamos
ser más asertivos en las manifestaciones.
En este caso, que está citando por lo que entiendo, la razón por la cual
el bloque /24 está siendo sub-asignado de ISP1 a ISP2 es porque ISP2 (la
suya) se quedó sin direcciones disponibles .
Entonces, las direcciones de este bloque /24 bajo responsabilidad del
ISP1 que anunciará el ISP2 también se usarán para atender a otros
clientes de ISP2 además del ISP1, que entiendo es uno de sus clientes ?
Si esto es cierto, es el escenario que estaba citando en mis
publicaciones anteriores. Si un día el RIR le pide al ISP1 que
justifique lo que se está haciendo con ese bloque /24, no puede
simplemente decir que cedió al ISP2 para que pueda usarlo para servir a
sus otros clientes ya que no sería un uso para el que se justificaba ese
bloque. Ahora bien, si por alguna otra razón el ISP2 está originando
estos anuncios (por ejemplo, porque el ISP1 no quiere administrar su
propio BGP), pero estas direcciones son utilizadas al final por completo
por el ISP1, no veo ningún problema.
Saludos
Fernando
On 12/01/2022 17:47, Gabriel Zárate wrote:
> Gracias a todos por las respuestas, muy agradecido.
> Creo que ya le daremos fin a esto, veo algunos criterios diferentes y
> cada uno parece tener razón, nuestro caso es bastante simple y tenemos
> la necesidad de sumar un nuevo bloque porque lo que teníamos ya nos
> quedó chico.
> Aclaro que si tenemos ASN y bloques propios.
> El escenario de interconexión es el siguiente:
> ISP1-----ISP2----ISPmayorista.
> Yo sería ISP2, tengo escasez de direcciones y necesito otro bloque,
> luego ISP1 sub-asigna un bloque /24 a ISP2, entonces debo poder
> publicar ese bloque con mi ASN hacia arriba(ISPmayorista), ya que ISP2
> es quien va a ser el responsable del uso de ese bloque, ISPmayorista
> era quien decia que ISP2 debía publicar el bloque con el ASN de ISP1.
> Ya me quedó claro que está permitido hacerlo siempre y cuando estén
> realizadas formalmente las sub-asignaciones en la plataforma de LACNIC
> y tengamos justificaciones reales de esto, si alguien las solicita las
> daremos con gusto.
> Hasta luego!!!.
>
> El mié, 12 ene 2022 a las 13:10, <lacnog-request en lacnic.net> escribió:
>
> Envíe los mensajes para la lista LACNOG a
> lacnog en lacnic.net
>
> Para subscribirse o anular su subscripción a través de la WEB
> https://mail.lacnic.net/mailman/listinfo/lacnog
>
> O por correo electrónico, enviando un mensaje con el texto "help" en
> el asunto (subject) o en el cuerpo a:
> lacnog-request en lacnic.net
>
> Puede contactar con el responsable de la lista escribiendo a:
> lacnog-owner en lacnic.net
>
> Si responde a algún contenido de este mensaje, por favor, edite la
> linea del asunto (subject) para que el texto sea mas especifico que:
> "Re: Contents of LACNOG digest...". Además, por favor, incluya en la
> respuesta sólo aquellas partes del mensaje a las que está
> respondiendo.
>
>
> Asuntos del día:
>
> 1. Re: Consulta peer BGP con bloque sub-asignado
> (Nicolas Antoniello)
> 2. Fwd: Call for Participation -- ICANN DNSSEC and Security
> Workshop for ICANN73 Community Forum (Nicolas Antoniello)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 Jan 2022 12:58:29 -0300
> From: Nicolas Antoniello <nantoniello en gmail.com>
> To: Latin America and Caribbean Region Network Operators Group
> <lacnog en lacnic.net>
> Subject: Re: [lacnog] Consulta peer BGP con bloque sub-asignado
> Message-ID:
>
> <CADHEbK-g=e2R_ZtYQDuc6P1sF00v5d0EYWGsGBw0NsXQCSGT1Q en mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Fernando,
>
> Si lees nuevamente lo que escribí notarás que indiqué:
>
> "entiendo que las sub-asignaciones de bloques IP (IPv4 e IPv6),
> siempre que
> mantengan alguna relación más allá de la mera sub-asignación (por
> ejemplo
> ser cliente BGP) son totalmente válidas"
>
> Allí claramente expongo el motivo de la sub-asignación, que es el de
> brindar un servicio de conectividad a internet (usando BGP) por
> parte del
> proveedor (ISP en este caso) al cliente... no veo ningún problema ni
> técnico ni de violación de políticas, a priori, en esto.
> No se está solamente cediendo bloques sino que se está presentando un
> servicio de conectividad (ese es el motivo, no la asignación de
> IPs). No me
> gustaría que por "supuestas intenciones" se confunda la comunidad
> técnica
> sobre que cosas se pueden y cuales no hacer.
>
> No constituye un "regalo" en esos casos como tu dices sino que
> claramente
> (al menos para mi) es un servicio de conectividad (lo de los
> bloques IP es
> anecdótico y es la forma de implementarlo)... ya se indicaron
> varios casos
> más de esos usos entre los que yo mencioné y los que otros han
> mencionado.
>
> Saludos,
> Nico
>
>
>
> El mié, 12 ene 2022 a la(s) 12:40, Fernando Frediani
> (fhfrediani en gmail.com)
> escribió:
>
> > Em 12/01/2022 12:22, Nicolas Antoniello escreveu:
> >
> > <clip>
> > Entonces, entiendo que las sub-asignaciones de bloques IP (IPv4
> e IPv6),
> > siempre que mantengan alguna relación más allá de la mera
> sub-asignación
> > (por ejemplo ser cliente BGP) son totalmente válidas. Y claro,
> eso también
> > permitiría al cliente publicar esos bloques por otros proveedores de
> > transporte (es parte de la idea detrás de usar BGP para el
> servicio).
> >
> > Aquí empieza el problema.
> > Si la organización propietaria del bloque lo regala para que lo
> use un
> > cliente, no debería poder usarlo de esta manera como si fuera
> una cesión
> > de bloque hecha directamente por el RIR , de lo contrario,
> comienza a
> > parecerse más a un préstamo en bloque que a un titular de bloque
> que lo
> > subasigna para que lo use el cliente en la forma que se justificó
> > inicialmente.
> >
> > Los motivos por los que el cliente hace esto pueden ser varios y
> son un
> > tema de cada cliente... Algunos incluso ni manejan su BGP sino
> que lo
> > administra el mismo proveedor de transporte (porque no quieren
> > hacerlo; porque no tienen la gente para eso; o por cualquier
> otro motivo).
> > Claro que para esto, es necesario que quien provee la
> sub-asignación la
> > registre adecuadamente en el sistema del RIR (o delegue la misma al
> > cliente)... para que quede claro quien es el que administra y
> "posee" los
> > derechos de publicación y gestión del bloque de IPs. Y también
> que el
> > cliente tenga un ASN en el caso en que la/las sesiones BGP sean
> con un ASN
> > público.
> >
> > Lo que técnicamente no se debería hacer, pues si puede generar
> problemas,
> > es por un lado mantener bloques de un proveedor de transporte
> con quien no
> > tengo sesión BGP y al mismo tiempo publicar esos bloques por BGP
> a un
> > proveedor diferente (porque en ese caso el registro de los
> bloques en los
> > sistemas de información no va a figurar con el origen correcto).
> Es decir,
> > si quiero multihoming-multiproveedor, lo correcto sería hablar
> BGP con
> > ambos desde mi propio ASN público (pero entiendo que los bloques
> de IPs
> > pueden ser sub-asignados por cualquiera de esos proveedores) o
> ser propios
> > es decir asignados directamente al cliente por el RIR.
> >
> > Como dato anecdótico histórico, muchos de los IPS de la región
> de LAC,
> > antes de la creación de LACNIC, publicaban con su propio ASN bloques
> > sub-asignados por proveedores de transporte de la región de ARIN en
> > exactamente la misma modalidad que describí anteriormente (con
> el añadido
> > de que entonces, esos si que eran ISP que tenían a su vez sus
> propios
> > clientes). Y no había ningún problema en tanto todo estuviese
> correctamente
> > registrado en el Whois y en los IRR (en ese entonces no teníamos
> RPKI). Y
> > de hecho, los ASN públicos eran asignados por ARIN... que fueron
> > transferidos a LACNIC luego de su creación si mal no recuerdo.
> >
> > Como otro ejemplo de independencia del titular el ASN con el de los
> > bloques de IPs, están los proveedores de CDNs en los que muchos
> de ellos
> > publican bloques de IPs propios, desde el ASN que los aloja, o
> viceversa
> > (lo que importa es que todo esté correctamente registrado).
> >
> > Para satisfacer alguna necesidad, la organización titular de
> recursos del
> > bloque.
> >
> >
> > Saludos,
> > Nico
> >
> > En resumen: *El punto principal no es qué ASN origina el
> anuncio* mas,
> > ¿cuál es la justificación para que ese bloque se use de esa manera?
> > Independientemente del ASN que originará el anuncio.
> > No siempre se puede suponer que debido a que una organización tiene
> > derechos sobre ese bloque, puede hacer lo que quiera. El uso del
> bloque, ya
> > sea por la propia organización o por sus clientes, debe seguir
> siendo
> > válido de acuerdo con lo que se justificó cuando se solicitó
> originalmente
> > al RIR. Y los casos que aun configurando involuntariamente un
> préstamo o
> > leasing en bloque no pueden considerarse válidos solo porque se
> emitió una
> > LOA o algo por el estilo.
> >
> > Fernando
> >
> >
> >
> > _______________________________________________
> > LACNOG mailing
> listLACNOG en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/lacnog
> <http://mail.lacnic.net/mailman/listinfo/lacnog>
> > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> >
> > _______________________________________________
> > LACNOG mailing list
> > LACNOG en lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/lacnog
> > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
> >
> ------------ próxima parte ------------
> Se ha borrado un adjunto en formato HTML...
> URL:
> <https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/183282d6/attachment-0001.htm>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 12 Jan 2022 13:10:32 -0300
> From: Nicolas Antoniello <nantoniello en gmail.com>
> To: Latin America and Caribbean Region Network Operators Group
> <lacnog en lacnog.net>
> Subject: [lacnog] Fwd: Call for Participation -- ICANN DNSSEC and
> Security Workshop for ICANN73 Community Forum
> Message-ID:
>
> <CADHEbK9QKjs_8fEjp39FSefUzce-ohg=iO3my6_6p56RTwiiFA en mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> En caso que alguien desee presentar algo...
>
> ---------- Forwarded message ---------
>
>
>
> *Call for Participation -- ICANN DNSSEC and Security Workshop for
> ICANN73
> Community Forum*
>
>
>
> In cooperation with the ICANN Security and Stability Advisory
> Committee
> (SSAC), we are planning a DNSSEC and Security Workshop for the ICANN73
> Community Forum being held virtually from 05-10 March 2022 in the
> Atlantic
> Standard Time Zone (UTC -4). This workshop date will be
> determined once
> ICANN creates a block schedule for us to follow; then we will be
> able to
> request a day and time. The DNSSEC and Security Workshop has been
> a part of
> ICANN meetings for several years and has provided a forum for both
> experienced and new people to meet, present and discuss current
> and future
> DNSSEC deployments. For reference, the most recent session was
> held at the
> ICANN72 Annual General Meeting on Wednesday 27 October 2021. The
> presentations and transcripts are available at
> https://72.schedule.icann.org/meetings/M24SJN375N2rcupnS,
> https://72.schedule.icann.org/meetings/NQMcvSwdLbpdGPaz6, and
> https://72.schedule.icann.org/meetings/9g4P3ceRA8FGS34Ei.
>
>
>
> The DNSSEC Workshop Program Committee is developing a program.
> Proposals
> will be considered for the following topic areas and included if space
> permits. In addition, we welcome suggestions for additional
> topics either
> for inclusion in the ICANN72 workshop, or for consideration for future
> workshops.
>
>
>
> *1. **Global DNSSEC Activities Panel*
>
> For this panel, we are seeking participation from those who have been
> involved in DNSSEC deployment as well as from those who have not
> deployed
> DNSSEC but who have a keen interest in the challenges and benefits of
> deployment, including Root Key Signing Key (KSK) Rollover
> activities and
> plans.
>
>
>
> *2. DNSSEC Best Practice*
>
> Now that DNSSEC has become an operational norm for many registries,
> registrars, and ISPs, what have we learned about how we manage DNSSEC?
>
>
>
> - Do you still submit/accept DS records with Digest Type 1?
> - What is the best practice around key roll-overs?
> - What about Algorithm roll-overs?
> - Do you use and support DNSKEY Algorithms 13-16?
> - How often do you review your disaster recovery procedures?
> - Is there operational familiarity within your customer support
> teams?
> - What operational statistics have we gathered about DNSSEC?
> - Are there experiences being documented in the form of best
> practices,
> or something similar, for transfer of signed zones?
>
>
>
> Activities and issues related to DNSSEC in the DNS Root Zone are also
> desired.
>
>
>
> *3. DNSSEC Deployment Challenges*
>
> The program committee is seeking input from those that are
> interested in
> implementation of DNSSEC but have general or particular concerns with
> DNSSEC. In particular, we are seeking input from individuals that
> would be
> willing to participate in a panel that would discuss questions of the
> following nature:
>
>
>
> - Are there any policies directly or indirectly impeding your
> DNSSEC
> deployment? (RRR model, CDS/CDNSKEY automation)
> - What are your most significant concerns with DNSSEC, e.g.,
> complexity,
> training, implementation, operation or something else?
> - What do you expect DNSSEC to do for you and what doesn't it do?
> - What do you see as the most important trade-offs with respect
> to doing
> or not doing DNSSEC?
>
>
>
> *4. Security Panel*
>
> The program committee is looking for presentations on DNS, DNSSEC and
> Routing topics that could impact the security and/or stability of the
> internet.
>
>
>
> We are looking for presentations that cover implementation issues,
> challenges, opportunities and best practices for:
>
>
>
> - Emerging threats that could impact the security and/or
> stability of
> the internet
> - DoH and DoT
> - RPKI (Resource Public Key Infrastructure)
> - BGP routing & secure implementations
> - MANRS ( Mutually Agreed Norms for Routing Security)
> - Browser security ? DNS, DNSSEC, DoH
> - EMAIL & DNS related security ? DMARC, DKIM, TLSA, etc?
>
>
>
> If you are interested in participating, please send a brief (1-2
> sentence)
> description of your proposed presentation to
> dnssec-security-workshop en icann.org *by COB Friday, January 21 2022*
>
>
>
> Thank you,
>
>
>
> Kathy and Andrew
>
> On behalf of the DNSSEC Workshop Program Committee:
>
> Steve Crocker, Shinkuro
>
> Mark Elkins, DNS/ZACR
>
> Jacques Latour, .CA
>
> Russ Mundy, Parsons
>
> Ondrej Filip, CZ.NIC
>
> Yoshiro Yoneya, JPRS
>
> Fred Baker, ISC
>
> Dan York, Internet Society
> ------------ próxima parte ------------
> Se ha borrado un adjunto en formato HTML...
> URL:
> <https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/f2ebeb30/attachment.htm>
>
> ------------------------------
>
> Subject: Pié de página del digest
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: lacnog-unsubscribe en lacnic.net
>
>
> ------------------------------
>
> Fin de Resumen de LACNOG, Vol 169, Envío 12
> *******************************************
>
>
>
> --
> /Saludos!/
> /Gabriel Gonzalo Zárate./
> /Administrador De Redes Informáticas, Soporte Técnico./
> /CCNA4, MTCNA, MTCRE, MTCTCE. MTCWE/
> /Skype: gabigon.01/
>
>
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion:https://mail.lacnic.net/mailman/options/lacnog
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/798ec0bd/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG