<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hola Gabriel<br>
Que bueno que hayas enviado más detalles del escenario para que
podamos ser más asertivos en las manifestaciones.<br>
<br>
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 .<br>
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 ?<br>
<br>
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.</p>
<p>Saludos<br>
Fernando<br>
</p>
<div class="moz-cite-prefix">On 12/01/2022 17:47, Gabriel Zárate
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMWk8=HzMY5aPTrvhQUHq_vSmpjeF83zmy9UBxRFFx6+qBghKQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">nantoniello@gmail.com</a>><br>
To: Latin America and Caribbean Region Network Operators Group<br>
<<a href="mailto:lacnog@lacnic.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">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 <a class="moz-txt-link-abbreviated" href="mailto:listLACNOG@lacnic.nethttps://">listLACNOG@lacnic.nethttps://</a><a
href="http://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true">mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/options/lacnog</a><br>
><br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
> <a
href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">nantoniello@gmail.com</a>><br>
To: Latin America and Caribbean Region Network Operators Group<br>
<<a href="mailto:lacnog@lacnog.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">https://72.schedule.icann.org/meetings/M24SJN375N2rcupnS</a>,<br>
<a
href="https://72.schedule.icann.org/meetings/NQMcvSwdLbpdGPaz6"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://72.schedule.icann.org/meetings/NQMcvSwdLbpdGPaz6</a>,
and<br>
<a
href="https://72.schedule.icann.org/meetings/9g4P3ceRA8FGS34Ei"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">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>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>