[lacnog] Resumen de LACNOG, Vol 169, Envío 14
Gabriel Zárate
gabigon.01 en gmail.com
Mie Ene 12 19:49:11 -03 2022
Gracias Fernando.
Se trata del segundo escenario.
El mié, 12 ene 2022 a las 18:54, <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: Resumen de LACNOG, Vol 169, Envío 12 (Fernando Frediani)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 Jan 2022 18:54:00 -0300
> From: Fernando Frediani <fhfrediani en gmail.com>
> To: lacnog en lacnic.net
> Subject: Re: [lacnog] Resumen de LACNOG, Vol 169, Envío 12
> Message-ID: <7d6282fc-edaf-0360-45e3-39bdf55bfb5b en gmail.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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.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 14
> *******************************************
>
--
*Saludos!*
*Gabriel Gonzalo Zárate.*
*Administrador De Redes Informáticas, Soporte Técnico.*
*CCNA4, MTCNA, MTCRE, MTCTCE. MTCWE*
*Skype: gabigon.01*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/c4539497/attachment-0001.htm>
Más información sobre la lista de distribución LACNOG