[lacnog] Resumen de LACNOG, Vol 169, Envío 12

Mie Ene 12 17:47:05 -03 2022

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
> > 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*
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/e29c609a/attachment-0001.htm>