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