Fwd: [lacnog] LACNOG2022 - Call for Presentations

[Carlos M. Martinez]

FYI,

Come join NANOG’s kid brother from the South ! :-)

This year’s event will be hybrid, so traveling shouldn’t be an 
issue.


Cheers!

/Carlos

Forwarded message:


From: Jorge Villa vía LACNOG 
To: Latin America and Caribbean Region Network Operators Group 


Cc: Jorge Villa 
Subject: [lacnog] LACNOG2022 - Call for Presentations
Date: Tue, 14 Jun 2022 08:52:53 -0400

LACNOG 2022 - Call for Presentations



LACNOG, the Latin American and Caribbean Network Operators Group, will 
hold its LACNOG 2022 conference together with the LACNIC 38 event from 
3 to 7 October 2022. This meeting will be held in person in the city 
of Santa Cruz, Bolivia (provided that the evolution of the 
epidemiological situation in the region allows). Otherwise, the 
conference will once again be held online.




The LACNOG 2022 Program Committee invites the Internet community to 
submit their presentation proposals for the event.




In line with the spirit of LACNOG, presentations should address topics 
geared towards regional Internet development. The following is a 
non-exhaustive list of some of the topics of interest for the LACNOG 
2022 meeting:




●Network operation and professional experiences, success 
stories


●Internet of Things

●MANRS

●Community networks

●IPv6 integration and deployment

●Experiences involving botnets, malware, spam, viruses, 
denial of service attacks, and exploit techniques


●IP network architecture, sizing, configuration, and 
administration


●Routing and switching protocols, including unicast, 
multicast, anycast, SDN, etc.


●End-user applications (e.g., e-mail, HTTP, DNS, NFVs, etc.)

●Value-added services, such as VPNs, distributed systems, 
cloud computing, etc.


●Peering, Internet traffic exchange, IXPs

●Network data security and management, attack mitigation

●Network monitoring, performance, measurements, and 
telemetry


●Network automation, evolution, and convergence

●Infrastructure and physical transport, including optical 
and wireless networks


●Legislation, regulations, and Internet governance issues

●Research and education



Possible presentation formats include:



●Lightning talk: brief, 10-minute presentation (including a 
space for Q).


●Presentation: 20-minute presentation (including a space for 
Q).


●Poster: includes a single-page PDF (A2 or smaller) with the 
basic information of the presentation and a 2- to 5-minute video with 
the presentation.




The timeline for the 2022 call for proposals will be as follows:


Reception of proposals: 31 May to 17 July 2022
Proposals will be accepted until: 17 July 2022 at 23:59 UTC-3 (Uruguay 
time)

Evaluation by the Program Committee: 18 July to 7 August 2022
Announcement of results: 10 August 2022
Reception of final presentations: 10 August to 18 September 2022 at 
23:59 UTC-3 (Uruguay time)

Event date: 3 to 7 October 2022




Applicants must submit a summary and a draft of the slides of their 
proposed presentation along with a brief biography, for which they 
must use the form available at  https://eventos.nog.lat/e/lacnog2022




If your work is selected, you authorize LACNOG and LACNIC to publish 
your name, photograph, biography, and final work in the event program.




Speakers presenting their work at the LACNOG 2022 conference will 
receive a certificate acknowledging their participation.




Guidelines for Submitting a Presentation for LACNOG including a 
description of the criteria that will be considered when evaluating 
each proposal, presentation format, and other details are available at 
https://lacnog.org/seccion/postulacion-trabajos




Communications with the Program Committee will be handled through 
p...@lacnog.org.




We thank you in advance for your attention and look forward to 
receiving your proposals for LACNOG 2022.




The Program Committee



___
LACNOG mailing list
lac...@lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

Re: DoD IP Space

[Carlos M. Martinez]

That would be true if “the Internet” was still fully comprised of 
American providers and customers. That hasn’t been the case for a 
long, long time.


On 26 Apr 2021, at 16:27, Mel Beckman wrote:


Owen,

Well, no. The Internet — meaning the ISPs and customers that 
comprise it — get substantial subsidies to this day. But that’s no 
call for the government to be obtuse with the purposes of its IP 
space.


https://www.nasdaq.com/articles/more-than-300-companies-participate-in-internet-subsidy-program-u.s.-agency-2021-04-01

 -mel



On Apr 26, 2021, at 11:05 AM, Owen DeLong  wrote:




On Apr 24, 2021, at 16:34 , Jason Biel  wrote:

The internet that is subsidized by that same Government….


Uh, s/is/was/

There’s really no subsidy any more.

Owen

Re: Gaming Consoles and IPv4

[Carlos M. Martinez]

Delay, or “lag” in gamer parlance is everything. Have too much lag 
and you are dead without realizing you are dead. Lag frustrates gamers 
enormously and is probably one of the main drivers of NOC calls.


It seems to me that a purely client/server model will inherently have 
more lag issues than a peer-to-peer game.


Not to mention cost… if you are the game publisher suddenly you’re 
faced with maintaining a global footprint of servers with all that 
implies.


/Carlos

On 28 Sep 2020, at 11:21, Tom Beecher wrote:


>

Why stray away from how PC games were 20 years ago where there was a
dedicated server and clients just spoke to servers?



Much cheaper to just let all the game clients talk peer to peer than 
it is

to maintain regional dedicated server infrastructure.

On Mon, Sep 28, 2020 at 8:35 AM Mike Hammett  wrote:


Why stray away from how PC games were 20 years ago where there was a
dedicated server and clients just spoke to servers?



-
Mike Hammett
Intelligent Computing Solutions 




Midwest Internet Exchange 



The Brothers WISP 


--
*From: *"Justin Wilson (Lists)" 
*To: *"North American Network Operators' Group" 
*Sent: *Monday, September 28, 2020 7:22:28 AM
*Subject: *Re: Gaming Consoles and IPv4

There are many things going on with gaming that makes natted IPv4 an 
issue
when it comes to consoles and gaming in general.   When you break it 
down

it makes sense.

-You have voice chat
-You are receiving data from servers about other people in the game
-You are sending data to servers about yourself
-If you are using certain features where you are “the host” then 
you are
serving content from your gaming console.  This is not much different 
than
a customer running a web server.  You can’t have more than one 
customer

running a port 80 web-server behind nat.
-Streaming to services like Twitch or YouTube

All of these take up standard, agreed upon ports. It’s really only
prevalent on gaming consoles because they are doing many functions.  
Look

at it another way.  You have a customer doing the following.

-Making a VOIP call
-Streaming a movie
-Running a web server
-Running bittorrent on a single port
-Having a camera folks need to access from the outside world

This is why platforms like Xbox developed things like Teredo.

Justin Wilson
j...@mtin.net

—
https://j2sw.com - All things jsw (AS209109)
https://blog.j2sw.com - Podcast and Blog

On Sep 27, 2020, at 9:33 PM, Daniel Sterling 


wrote:

Matt Hoppes raises an interesting question,

At the risk of this being off-topic, in the latest call of duty games 
I've
played, their UDP-NAT-breaking algorithm seems to work rather well 
and
should function fine even behind CGNAT. Ironically turning on upnp 
makes
this *worse*, because when their algorithm probes to see what ports 
to use,
upnp sends all traffic from the "magical xbox port" to one box 
instead of

letting NAT control the ports. This does cause problems when multiple
xboxes are behind one NAT doing upnp. If upnp is on and both xboxes 
are
fully powered off and then turned on one at a time, things do work. 
But

when upnp is off everything works w/o having to do that.

There are many other games and many CPE NAT boxes that may do 
horrible
things, but CGNAT by itself shouldn't cause problems for any recent 
device

/ gaming system.

It is true that I've yet to see any FPS game use ipv6. I assume 
that's cuz
they can't count on users having v6, so they have to support v4, and 
it
wouldn't be worth their while to have their gaming host support 
dual-stack.

just a guess there

-- Dan



On Sun, Sep 27, 2020 at 7:29 PM Mike Hammett  
wrote:



Actually, uPNP is the only way to get two devices to work behind one
public IP, at least with XBox 360s. I haven't kept up in that realm.



-
Mike Hammett
Intelligent Computing Solutions 




Midwest Internet Exchange 



The Brothers WISP 


--
*From: *"Matt Hoppes" 
*To: *"Darin Steffl" 
*Cc: *"North 

Fwd: [lacnog] LACNOG 2020 - Call for Presentations

[Carlos M. Martinez]

Hi all,

LACNOG (the Latin American and Caribbean Network Operators Group) will 
be a virtual meeting this year.


Looking forward to great talks from our big brother NANOG members :-)

/Carlos
LACNOG PC

Forwarded message:


From: Jorge Villa 
To: Latin America and Caribbean Region Network Operators Group 


Subject: [lacnog] LACNOG 2020 - Call for Presentations
Date: Mon, 08 Jun 2020 11:49:02 -0400

LACNOG 2020 - Call for Presentations



https://www.lacnog.org/eventos/



LACNOG, the Latin American and Caribbean Network Operators Group, will 
hold its LACNOG 2020 conference in the city of Santa Cruz de la 
Sierra, Bolivia, from 5 to 9 October 2020, which will be co-located 
with the LACNIC 34 event.




The LACNOG 2020 Program Committee invites the Internet community to 
submit their proposals for the event.




In line with the spirit of LACNOG, proposed topics must be geared 
towards Internet development in the region. The following is a 
non-exhaustive list of some of the topics of interest for the LACNOG 
2020 meeting:



Network operation and professional experiences, success stories
Internet of Things
MANRS
Community networks
IPv6 integration and deployment
Experiences involving botnets, malware, spam, viruses, denial of 
service attacks and exploit techniques

IP network architecture, sizing, configuration and administration
Routing and switching protocols, including unicast, multicast, 
anycast, SDN, etc.

End-user applications (e.g. e-mail, HTTP, DNS, NFVs, etc.)
Value-added services such as VPNs, distributed systems, cloud 
computing, etc.

Peering, Internet traffic exchange, IXPs
Network data security and management, attack mitigation
Network monitoring, performance, measurements and telemetry
Network automation, evolution and convergence
Infrastructure and physical transport, including optical and wireless 
networks

Legislation, regulations and Internet governance issues
Research and education


Possible presentation formats include:


Lightning talk: brief, 8-minute presentation plus 4 additional minutes 
for questions.
Presentation: 20-minute presentation plus 5 additional minutes for 
questions.



The deadlines for the 2020 call for proposals will be as follows:


Reception of proposals: 8 June - 7 July 2020
Proposals will be accepted until: 7 July 2020 at 23:59 UTC-3 (Uruguay 
time)

Evaluation by the Program Committee: 8-19 July 2020
Announcement of results: 20 July 2020
Deadline for submitting the final presentation: 1 August - 18 
September 2020
Final presentations will be accepted until: 21 September 2020 at 23:59 
UTC-3 (Uruguay time)

Event date: 5-9 October 2020


Applicants must submit a summary and a draft of the slides of their 
proposed presentation along with a brief biography and photograph 
using the form available at https://vulcano.lacnog.org/e/lacnog2020




If your work is selected, you authorize LACNOG and LACNIC to publish 
your name, photograph, biography, and final work in the event program.




Regardless of the chosen format, all works must presented in person at 
the event venue.




Given the current pandemic caused by the coronavirus (covid-19) 
outbreak, there is the possibility that the event may be held in 
virtual format, in which case speakers will be notified in advance and 
the necessary adjustments will be coordinated based on the schedule 
determined by the Program Committee.




Applicants whose proposals are accepted will be exempted from paying 
their in-person event registration fee but will not automatically 
receive financial assistance for their travel and/or accommodation 
expenses. However, LACNIC offers a fellowship program for attending 
the LACNIC 34 event which will be held jointly with LACNOG 2020 to 
which speakers can apply independently. When submitting your draft to 
the LACNOG Program Committee, please specify whether you are applying 
(or planning to apply) for a LACNIC fellowship.




Speakers presenting their work at the LACNOG 2020 conference will 
receive a certificate acknowledging their participation.




Guidelines for Submitting a Presentation for LACNOG have been prepared 
containing a description of the criteria that will be considered when 
evaluating each proposal, presentation format details and other data. 
These Guidelines are available at 
https://www.lacnog.org/guiapresentaciones/.




Communications with the Program Committee will be handled through 
p...@lacnog.org.




We thank you in advance for your attention and look forward to your 
proposals for LACNOG 2020.




Program Committee




___
LACNOG mailing list
lac...@lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

Re: No IPv6 by design to increase reliability...

[Carlos M. Martinez]

It is an interesting question to ponder. It is true that IPv6 tends to 
be somewhat more problematic than IPv4, but these days the incidents 
where IPv6 becomes unavailable or has issues are rare.


BTW I have had recently an issue where I had IPv4 reachability problems 
while IPv6 worked perfectly.


regards,

-Carlos

On 17 Jan 2019, at 16:45, John Von Essen wrote:

I was having a debate with someone on this. Take a critical web site, 
say one where you want 100% global uptime, no potential issues with 
end users having connectivity or routing issues getting to your IP. 
Would it be advantageous to purposely not support a  record in DNS 
and disable IPv6, only exist on IPv4?


My argument against this was "Broken IPv6 Connectivity" doesn't really 
occur anymore, also, almost all browsers and OS IP stacks implement 
Happy Eyeballs algorithm where both v4 and v6 are attempted, so if v6 
dies it will try v4. I would also argue that lack of IPv6 technically 
makes the site unreachable from native IPv6 clients, and in the event 
of an IPv4 outage, connectivity might still remain on IPv6 if the site 
had an IPv6 address (I've experienced scenarios with a bad IPv4 BGP 
session, but the IPv6 session remained up and transiting traffic...)


Thoughts?


-John

Contact at SpeedTest.net

[Carlos M. Martinez]

Hi all,

If anyone has a contact at SpeedTest it would be greatly appreciated.

Thanks!

/Carlos

Contacting AS6589 - "Beneficial Technologies"

[Carlos M. Martinez]

Hello all,

I’m trying to reach anyone at AS 6589, “Beneficial Technologies”. 
They are announcing large chunk of LACNIC unallocated space, as can be 
seen here: https://bgp.he.net/AS6589


Although I usually give people the benefit of doubt, in this case we are 
talking about 5 /16 prefixes. Talk about fat fingers.


Private email is ok.

Thanks

Carlos
LACNIC CTO

Fwd: [lacnog] Call for Presentations – LACNOG 2017

[Carlos M. Martinez]

FYI, apologies for duplicates.

Forwarded message:


From: Tomas Lynch 
To: lac...@lacnog.org 
Subject: [lacnog] Call for Presentations – LACNOG 2017
Date: Thu, 15 Jun 2017 08:55:17 -0400

LACNOG, the Latin American and Caribbean Network Operators Group, will 
be
holding its annual conference – LACNOG 2017 – in the city of 
Montevideo,
Uruguay, on 18-22 September 2017. This event will be co-located with 
the

LACNIC 28 meeting.

The 2017 LACNOG Program Committee invites the Internet community to 
submit

their presentations for the event.



Possible formats are as follows:

   -

   Lightning talk: short, 10-minute presentation with an additional 5
   minutes for questions.
   -

   Presentation: 20-minute presentation with an additional 10 minutes 
for

   questions.
   -

   Tutorial: 45-minute presentation with an additional 15 minutes for
   questions.

In the spirit of LACNOG, the topics to be covered by the presentations
should be geared towards regional Internet development. The topics of
interest to LACNOG 2017 include, but are not limited to:

   -

   Network operation and professional experiences, success stories
   -

   IP network architecture, sizing, configuration and administration
   -

   Routing and switching protocols, including unicast, multicast, 
anycast,

   and others
   -

   End-user applications (e.g. E-mail, HTTP, DNS, etc.)
   -

   Value-added services such as VPNs, distributed systems, cloud 
computing,

   etc.
   -

   Peering, regional traffic exchange, IXPs
   -

   Transition to IPv6 and IPv6 Deployment
   -

   Network security and data management, attack mitigation
   -

   Network monitoring, performance, measurements and telemetry
   -

   Network automation, evolution and convergence
   -

   Infrastructure and physical transport including optical and 
wireless

   networks
   -

   Internet governance issues, legislation and regulations
   -

   Research and education



All submissions must meet the following requirements:

   -

   Proposals must be submitted in English, Portuguese or Spanish.
   -

   Accepted formats: Microsoft Powerpoint (PPT, PPTX), Apache 
OpenOffice
   Presentation (ODP), LibreOffice Impress (ODP), or Portable Document 
Format

   (PDF).
   -

   The number of slides must be appropriate for the time assigned for 
the

   presentation. As a rule of thumb, estimate 1-2 minutes per slide.
   -

   We recommend following the Guidelines for Submitting a Presentation
   .



Presentations must be submitted according to the following schedule:

   -

   Reception of drafts and abstracts: 12 June to 17 July
   -

   Evaluation by the Program Committee: 17 to 31 July
   -

   Submission of the final presentation: 31 July to 28 August
   -

   Event date: 18-22 September



Anyone wishing to participate must submit a short biography, picture 
and
abstract to 
http://www.lacnog.org/en/call-for-presentations-lacnog-2017/




Presenters at the LACNOG 2017 conference will receive a certificate
attesting their participation.



Program Committee




___
LACNOG mailing list
lac...@lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

Re: BGP IP prefix hijacking

[Carlos M. Martinez]

We use a mix of BGPMon and RPKI+RIPE Validator.

On 30 Jan 2017, at 4:41, Nagarjun Govindraj via NANOG wrote:

> Hi All,
>
> I am planning to write a tool to detect real time BGP IP prefix hijacking.
> I am glad to know some of the open problems faced by
> providers/companies/community.
> I would like to know how the community is currently dealing and mitigating
> with such problems.
> It will be very helpful to know some of the adopted strategies by the
> community to detect bgp IP prefix hijacking and problems that are yet to be
> solved.
> Also I would like to know some of the very well industry standard open
> source tools used in the area of BGP which makes life easier.
>
> Regards,
> Nagarjun

Re: GeoIP database issues and the real world consequences

[Carlos M. Martinez]

Or (90S,0), so they get a bit of fresh air and have some time think
during the voyage :-)

On 4/11/16 2:14 PM, Josh Luthman wrote:
> Or 0,0, send the FBI to Africa on a boating trip.  that would probably be
> easier than "unknown" or "null".
> 
> 
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> On Mon, Apr 11, 2016 at 1:11 PM, Hugo Slabbert  wrote:
> 
>>
>> On Mon 2016-Apr-11 13:02:14 -0400, Ken Chase  wrote:
>>
>> TL;DR: GeoIP put unknown IP location mappings to the 'center of the
>>> country'
>>> but then rounded off the lat long so it points at this farm.
>>>
>>> Cant believe law enforcement is using this kind of info to execute
>>> searches.
>>> Wouldnt that undermine the credibility of any evidence brought up in
>>> trials
>>> for any geoip locates?
>>>
>>> Seems to me locating unknowns somewhere in the middle of a big lake or
>>> park in
>>> the center of the country might be a better idea.
>>>
>>
>> ...how about actually marking an unknown as...oh, I dunno: "unknown"?  Is
>> there no analogue in the GeoIP lookups for a 404?
>>
>>
>>> /kc
>>>
>>
>> --
>> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
>> pgp key: B178313E   | also on Signal
>>
>>
>>
>>> On Mon, Apr 11, 2016 at 11:55:11AM -0500, Chris Boyd said:
>>>  >
>>>  >Interesting article.
>>>  >
>>>  >http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/
>>>  >
>>>  >An hour???s drive from Wichita, Kansas, in a little town called Potwin,
>>>  >there is a 360-acre piece of land with a very big problem.
>>>  >
>>>  >The plot has been owned by the Vogelman family for more than a hundred
>>>  >years, though the current owner, Joyce Taylor n??e Vogelman, 82, now
>>>  >rents it out. The acreage is quiet and remote: a farm, a pasture, an old
>>>  >orchard, two barns, some hog shacks and a two-story house. It???s the
>>> kind
>>>  >of place you move to if you want to get away from it all. The nearest
>>>  >neighbor is a mile away, and the closest big town has just 13,000
>>>  >people. It is real, rural America; in fact, it???s a two-hour drive from
>>>  >the exact geographical center of the United States.
>>>  >
>>>  >But instead of being a place of respite, the people who live on Joyce
>>>  >Taylor???s land find themselves in a technological horror story.
>>>  >
>>>  >
>>>  >For the last decade, Taylor and her renters have been visited by all
>>>  >kinds of mysterious trouble. They???ve been accused of being identity
>>>  >thieves, spammers, scammers and fraudsters. They???ve gotten visited by
>>>  >FBI agents, federal marshals, IRS collectors, ambulances searching for
>>>  >suicidal veterans, and police officers searching for runaway children.
>>>  >They???ve found people scrounging around in their barn. The renters have
>>>  >been doxxed, their names and addresses posted on the internet by
>>>  >vigilantes. Once, someone left a broken toilet in the driveway as a
>>>  >strange, indefinite threat.
>>>  >
>>>  >--Chris
>>>  >
>>>
>>

Re: ARIN's RPKI Relying agreement

[Carlos M. Martinez]

Hello,

On 12/4/2014 2:33 PM, Andrew Gallo wrote:
 
 On 12/4/2014 11:22 AM, William Herrin wrote:
 Understood and good point.  I've heard rumblings of setting up a
 non-ARIN TAL, though I wonder what the value is in separating RPKI from
 the registry.  Wouldn't this put us in the same position we're in with
 routing registries (with respect to data quality)?

Exactly the same. RPKI without the tie-in to the registration database
is just another random database, like the dozens that are out there,
bound to suffer from exactly the same problems current IRRs suffer.

Disclaimer: I work for LACNIC, but in this case, if I was a beggar
playing music at subway stations my opinion would be exactly the same.

Cheers!

Carlos

Re: ARIN's RPKI Relying agreement

[Carlos M. Martinez]

Hello,

On 12/4/2014 2:33 PM, Andrew Gallo wrote:
 
 On 12/4/2014 11:22 AM, William Herrin wrote:
 Understood and good point.  I've heard rumblings of setting up a
 non-ARIN TAL, though I wonder what the value is in separating RPKI from
 the registry.  Wouldn't this put us in the same position we're in with
 routing registries (with respect to data quality)?

Exactly the same. RPKI without the tie-in to the registration database
is just another random database, like the dozens that are out there,
bound to suffer from exactly the same problems current IRRs suffer.

Disclaimer: I work for LACNIC, but in this case, if I was a beggar
playing music at subway stations my opinion would be exactly the same.

Cheers!

Carlos

Re: Network diagnostics for the end user

[Carlos M. Martinez]

May sound silly, but in another life I faced a similar problem and by
hosting local SpeedTest.net servers in our network we could fend off
many of these calls.

But I guess it will depend on your customers, whether they take it or not.

cheers,

~Carlos

On 6/20/13 9:45 PM, Jeffrey Ollie wrote:
 Are there any tools out there that we could give to our end users to help
 diagnose network problems? We get a lot of the Internet is slow support
 calls and it would be helpful if we had something that would run on the end
 user's computer and help characterize the problem. We have central
 monitoring system of course but that doesn't always give a complete
 picture, as the problem could always be on the end user's computer - slow
 hard drive, not enough memory, wrong name servers, etc.
 

RPKI Support on the Juniper SRX line

[Carlos M. martinez]

Hello all,

I'm working with a Juniper partner in Colombia on a possible RPKI
deployment.

As far as I understand Juniper's website, only the T, M and MX lines
support RPKI, yet the partner insists that Junos 12.3 / 13.1 supports
RPKI on the SRX line.

I cannot find any document or reference confirming this.

Any comments would be appreciated.

regards,

~Carlos

Symantec contact

[Carlos M. Martinez]

Hello all,

I'm looking for a PoC in Symantec who could help me with an issue in
this report:

http://www.symantec.com/threatreport/topic.jsp?id=namaid=nam_malicious_activity_by_geo

I've already tried to contact the emails listed on the website, multiple
times, to no avail.

Contact me on private.

regards,

~Carlos

Re: Notice: Fradulent RIPE ASNs

[Carlos M. Martinez]

Please, please someone go to http://meemsy.com/videos/add/24 and create
'Hitler reacts to the fraudulent Romanian ASNs'

After that we can move on.

:=)

~C.

On 1/16/13 2:01 PM, Matthew Petach wrote:
 I'll bet Hitler would have used his real name on the whois entries.
 
 There.  Now I think we're done.
 
 Matt
  On Jan 16, 2013 7:09 AM, Todd Underwood toddun...@gmail.com wrote:
 
 I do not understand why you're so adamant about sending this information
 to an organization primarily distinguished by its incompetence and
 negligence.  If they were actually DOING THEIR JOBS in even minimally
 diligent fashion, then Ron wouldn't needed to write that note or do
 the research behind it, because this wouldn't be happening.

 this kind of mostly unfounded vitriole is silly and damages your
 credibility.

 no one seriously believes that the RIPE NCC (which is managed by all
 of its members) is primarily distinguished by their incompetence and
 negligence.

 i believe this conversation has now gotten to the plonk stage.  can
 someone compare them to hitler so that we can move on?

 cheers,

 t

Akamai Network Contact

[Carlos M. Martinez]

Hello!

I'm looking for a contact in Akamai, preferably someone dwelling in the
dark realm of layer 3.

I've been contacted by a LACNIC member from Suriname who is having
reachability issues specifically with sites hosted in Akamai.

Thank you!

~Carlos

Re: Adding GPS location to IPv6 header

[Carlos M. Martinez]

Just for redundancy's sake: No, L3 is **not** the place for this kind of
information. L3 is supposed to be simple, easy to implement, fast to
switch. In Spanish we have a very strong adjective for this kind of
ideas: pésimo. I couldn't find a similar one in English without using
foul words :-)

In any case, and as it already has been pointed out, I can imagine an
upper layer protocol, similar to NTP that reports GPS coordinates. Come
to think of it, if NTP could be extended this would fit in nicely as
there are already lots of NTP nodes which already have GPS sensors.

Additionally, unless the proponents of this idea are expecting every
router manufacturer to build GPS chips into their gear and us datacentre
operators to drill holes on our roofs for the antennas, I don't see any
real useful role for this extension header.

cheers!

~Carlos

On 11/26/12 9:20 AM, Mohacsi Janos wrote:
 
 
 
 On Sun, 25 Nov 2012, Ammar Salih wrote:
 
 Thank you everyone, I appreciate your feedback and will try to
 summarize few
 points in one email to avoid duplication .. apologies if I missed any.





 This is not data that should be sent on every packet. It becomes
 redundant.



 1- It does not have to be in every IPv6 header, only when there is
 location
 update.
 
 It should not be in any IPv6 packet. It has to be in an upper layer
 protocol.
 
 

 2- the host should have the option of not sending location updates.
 
 In worst case. Host should have an option to sending location update -
 probably not in IP headers, but upper layer protocol.
 

 3- I am suggesting an *extension header*, which means that operators will
 have the option of not using it in case they don't want to.
 
 
 I suggest an upper layer protocol. Something like HTTP, TCP or UDP
 option. The server can initiate a carry, and a client can decide to
 answer with location information.
 
 



 





 A good alternative would be to create application layer protocols that
 could request and send GPS positions.

 1- there are already several application-layer mechanisms which have been
 created for this purpose, none of them has been considered by major
 service
 providers, google for example is still using RIR info for determining
 location-based settings like language.


 2- Layer 7 will not be detected by layer 3 devices (routers) .. so
 location-based service on layer-3 will not be possible.


 3- Currently, many applications do not share same mechanisms to obtain
 location or location-related data, GEOPRIV WG [1] works on http location
 mechanism, but *for the sake of example* VoIP soft-switches may not
 support
 http protocol, so a new mechanism needs to be developed- which has
 been done
 [2] .. W3c has also specified another API that provides scripted
 access to
 geographical location information [3] which has not been considered by
 others ..

 that's why I am suggesting a unified lower layer *optional* mechanism
 which
 is capable of supporting all other applications.

 
 I prefer application and at most the transport layer protocol extension.
 
 
 


 [1]  https://datatracker.ietf.org/wg/geopriv/charter/

 [2]   http://tools.ietf.org/html/rfc6442

 [3]   http://dev.w3.org/geo/api/spec-source.html



 

 --





  I see major privacy issues with this.  Why introduce more intelligence
 which WILL eventually be used for more intrusion into the private
 lives of
 all of us?



 1-  The host should have the option of not sending location updates.

 2-   It's extension header, means it's up to the service provider
 to use
 the feature or not.

 3-  Users are being routed through ISPs, if we don't trust the ISP then I
 can assure you that ISP can get much more information than physical
 location, any un-encrypted traffic -which is the majority- can be
 analyzed
 at the ISP level (up to layer-7).



 Anythink you write on facebook for example *if you don't use https*
 can be
 detected, including location tags, relationships, activities, wall posts,
 friends ... and much more, all your http traffic, including documents you
 read, messages, usernames, passwords, bank accounts ...etc.



 Other than ISP, sniffers can be connected to the same layer-2/layer-3
 device
 as mine, in this case I would worry about
 usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not
 location as the sniffer in this case is mostly sitting at the same
 physical
 location as mine.



 4- our locations currently are being sent anyways through RIR info,
 without
 our awareness or control, I am suggesting to have the end user control
 the
 feature, still his/her option though not to send location updates.



 ---





 Thank you everyone for your time and professional feedback, I highly
 appreciate it!



 Please be informed that this is only a draft, and I am requesting
 comments,
 I 

Re: Big day for IPv6 - 1% native penetration

[Carlos M. Martinez]

We have numbers to share.

We have performed two experiments at two different events LACNIC held
this year:

- June in Port-Au-Prince (~110 attendees)
- October in Montevideo (~400 attendees)

The question was: What is the relation between IPv4 and IPv6 traffic in
a fully dual-stacked network?. The answers were remarkably consistent.
We got ~30% IPv6 in PAP and around 33% in MVD (actually in MVD we got
over 40% in total byte counts, but we corrected for the IPv6 video feed
that added a constant 1 Mbps/sec)

This percentage is calculated as:

100*(bytes sent and received over IPv6) / (total bytes sent and received)

In PAP we measured this using iftop and a couple of pcap filters on the
Linux server we were using as 'router' (Owen was there and was of great
help setting the whole thing up).

In MVD we had a dual 7201s as routers and we measured traffic with Netflow.

Warm regards,

~Carlos



On 11/21/12 12:51 AM, Patrick W. Gilmore wrote:
 On Nov 20, 2012, at 14:44 , Tony Hain alh-i...@tndh.net wrote:
 
 If you assume that Youtube/Facebook/Netflix are 50% of the overall traffic, 
 why wouldn't a dual stacked end point have half of its traffic as IPv6 after 
 June???
 
 If you assume  Kinda says it all right there.
 
 But more importantly, those three combined are not 50% of overall traffic.  
 It _might_ be true in the US, for some times of the day, but certainly not 
 world-wide overall traffic.  If for no better reason than you cannot get NF 
 in all countries.
 

LACNIC RPKI RTA key rollover

[Carlos M. Martinez]

Folks,

On Thursday, November 29, 2012 LACNIC will be performing a system
migration to a new release of the RPKI system. We will take the
opportunity to also perform a key rollover of LACNIC's RPKI trust
anchor. The new TAL (trust anchor locator) file can be downloaded from
[1]. Also a ready-to-use configuration file for RIPE-NCC's Validation
Application is available at [2].

Both the certificate and repository this TAL points to are already
active, but the main repository material (resource CAs and ROAs) will be
migrated on the same date at 14.00 UTC. All relying-party operators are
encouraged to download the TAL file and add it to their validation tool
configuration before that time in order to maintain continuity of
validation.

[1] https://rpki.lacnic.net/tal/lacnic-201212.tal
[2] https://rpki.lacnic.net/tal/lacnic-ripeval-201212.tal

If you have any questions please do not hesitate to contact us at
rpki-ad...@lacnic.net

Warm regards,

Carlos

Re: IPv6 only streaming video

[Carlos M. martinez]

Hello,

Due to popular demand ( :=)) ), we are currently offering the streaming
of the LACNIC / LACNOG event over an IP6-only channel.

Take a look at http://www2.lacnic.net/sp/eventos/lacnicxviii/stream6.html

The webpage will load over IPv4 but the video is IPv6-only

regards

~Carlos

On 7/25/12 2:11 PM, Tina TSOU wrote:
 http://video.v6.labs.lacnic.net/jw/
 Server can not be found since yesterday. Has the URL been changed?
 
 Tina
 408-859-4996
 

Re: quietly....

[Carlos M. Martinez]

I think the ship has sailed for the class E /8s. Using them will require
significant effort and that effort, both time and money, is better spent
on deploying IPv6.

regards

Carlos

On 2/1/11 9:45 AM, Owen DeLong wrote:
 On Jan 31, 2011, at 10:43 PM, George Bonser wrote:

 3. Busting out 16 more /8s only delays the IPv4 endgame by about a
 year.

 jms
 If used for general assignment, sure.  But if used for what people have
 been begging for NAT444 middle-4 space.  Well, that might work.  Code
 update on the CPE is all it would take.  The systems involved would
 never see it.


 If they could do code updates on the CPE, then, they could use RFC-1918.

 The problem is that code-updating that much CPE is, well, impractical to
 say the least.

 Owen

Re: A top-down RPKI model a threat to human freedom? (was Re: Level 3's IRR Database)

[Carlos M. Martinez]

Although I support Rpki as a technology, there are legitimate concerns that it 
could be abused. I now believe that Rpki needs work in this area at IETF level 
so the concerns are adressed.

I imagine some form of secret sharing among different parties or sme form of 
key escrow. I am sure that it is not an easy problem, but maybe some progress 
can be made in this direction.

Regards

Carlos

On Feb 1, 2011, at 7:33 PM, Michael Hallgren m.hallg...@free.fr wrote:

 Le mardi 01 février 2011 à 12:14 -0500, Christopher Morrow a écrit : 
 On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert milln...@gmail.com wrote:
 Here be dragons,
 snip
 It should be fairly obvious, by most recently what's going on in
 Egypt, why allowing a government to control the Internet is a Really
 Bad Idea.
 
 
 how is the egypt thing related to rPKI?
 How is the propsed rPKI work related to gov't control?
 
 architecturally/technologically *impossible* for a entity from country
 A to via-the-hierarchical-trust-model block a prefix assigned to some
 entity in country B, that is assigned by B's RIR and in full
 accordance with the RIR policies and in no breach of any contract.
 
 countries do not have RIR's, countries have NIR's... regions have RIR's.
 
 In this context, at least, perhaps the NIR should be considered
 superfluous or redundant? What is the operational rationale behind the
 NIR level? Wouldn't a flatter RIR-LIR structure do just fine?
 
 mh
 
 
 
 

Re: Level 3's IRR Database

[Carlos M. Martinez]

Hey Martin,

I see your point and I believe it is a concern that should be addressed.

tks

Carlos

On 1/31/11 3:59 AM, Martin Millnert wrote:
 Carlos,

 On Sun, Jan 30, 2011 at 9:22 PM, Carlos Martinez-Cagnazzo
 carlosm3...@gmail.com wrote:
 Hi,

 this is the second mention I see of RPKI and Egypt in the same
 context. I sincerely fail to see the connection between both
 situations.

 It is quite simple actually.

 1. Governments (eventually) want to take pieces of the Internet
 offline, and Egypt is only the latest abundantly clear proof of this
 desire.
 2. RPKI might make this easier to accomplish than before, effectively
 leading to more censorship than without it.

 My fear is that of the big red DELETE-FROM-THE-INTERNET-button:

 If the system becomes widely deployed, it is an even shorter step to
 make for various lawmakers in various countries to legislate how RPKI
 is to be used.
 There are obviously other ways for your local autocrat to cut the
 Internet down, but this would undoubtedly add a potential fine-grained
 mechanism on top of it that I fail to see how it will not be abused.
   Eg, it'd be possible to, with the right hand, require that all ISPs
 treats RPKI in a certain way (abstract away the censorship to all
 ISPs, even those in other countries(!), own routers, once the
 technology is in place), and with the left hand cherry pick what can
 be on and what can be off, at a much, much lower cost than unplugging
 everything (Egypt), or buying lots of cool hardware (China). (This is
 a bad thing, btw.)

 I'd happily see an explanation of RPKI that clears these fears from my
 mind, and I'm fairly sure that I am not crazy for having them...
 (Meanwhile I will read all of Randy's recommended reading.)
 And yes there are a myriad of other ways to shut things down from the
 Internet, but none of them are as integrated with the Internet as RPKI
 would be, right? Plus, I don't really see adding another way to shut
 things down as a positive thing, because of the apparent abuse-vector
 it represents.

 Regards,
 Martin

 (With tiny, tiny steps, nobody will understand how we ended up where
 we end up, and by then it's hard to retract.)

 On Sun, Jan 30, 2011 at 7:53 PM, Brandon Butterworth
 bran...@rd.bbc.co.uk wrote:
 I think it is too early in the deployment process to start dropping
 routes based on RPKI alone. We'll get there at some point, I guess.
 Do we really *want* to get to that point?
 I thought that was the point and the goal of securing the routing
 infrastructure is laudable. But the voices in my head say don't trust
 them with control of your routes, see what happened in Egypt.

 brandon




 --
 --
 =
 Carlos M. Martinez-Cagnazzo
 http://www.labs.lacnic.net
 =

Re: quietly....

[Carlos M. Martinez]

They are effectively gone, will be allocated in coming days or weeks, 1
per RIR. This is per global IANA policy.

regards

Carlos

On 1/31/11 10:20 PM, Patrick Greene wrote:
 I thought there are still 5 /8's left in IANA.

 -Original Message-
 From: Carlos Martinez-Cagnazzo [mailto:carlosm3...@gmail.com] 
 Sent: Monday, January 31, 2011 4:36 PM
 To: NANOG
 Subject: Re: quietly

 That was it :-) so long IPv4! It's been a great ride!

 As good old Frank said, And now, the end is near, we face the final 
 curtain...

 cheers!

 Carlos

 On Mon, Jan 31, 2011 at 9:28 PM, Randy Bush ra...@psg.com wrote:
 039/8 APNIC 2011-01 whois.apnic.net ALLOCATED
 106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
 it's been on most of the lists.  sunny will probably post to nanog 
 shortly.  the announcement is really well phrased, but i will not 
 steal sunny's thunder.

 randy




 --
 --
 =
 Carlos M. Martinez-Cagnazzo
 http://www.labs.lacnic.net
 =

Re: [arin-announce] ARIN Resource Certification Update

[Carlos M. Martinez]

Hey!
 Steinar Haug, Nethelp consulting, sth...@nethelp.no
 Because they publish data you have signed. They don't have the ability
 to modify the data and then sign that modification as if they were you if
 they aren't holding the private key. If they are holding the private key,
 then, you have, in essence, given them power of attorney to administer
 your network.

 If you're OK with that, more power to you. It's not the trust model I would
 prefer.

I think that is the whole point. Hosted is fine with some, top-down will
be preferred by others. Will top-down be intrinsically more secure than
hosted? I am tempted to say yes, but I have some doubts on that too.

What top-down certainly does is getting you out of the lawyers' sights.
Mostly anyways.

 Owen
Carlos

Re: Level 3's IRR Database

[Carlos M. Martinez]

I think we just don't know (yet) how people are going to apply RPKI. If
I were operating a large network today, I would try to run RPKI in a
sort of warning-only mode, i.e. getting some sort of alert if an invalid
route was detected.

While this wouldn't have prevented YouTube's incident, it would probably
have shortened the recovery period.

I think it is too early in the deployment process to start dropping
routes based on RPKI alone. We'll get there at some point, I guess.

cheers

Carlos

On 1/30/11 6:47 PM, Nick Hilliard wrote:
 On 30/01/2011 17:39, Carlos Martinez-Cagnazzo wrote:
 The solution to this problem (theoretical at least) already exist in
 the form of RPKI.

 So, what are peoples' routing policies on RPKI going to be?  Are
 people going to drop prefixes with no RPKI record?  Or drop prefixes
 with an incorrect RPKI record?  Or drop prefixes with a revoked status?

 I'm concerned that if we're trying to avoid another Youtube affair,
 the RPKI policy acceptability criteria will have to be so strict that
 this may have a serious effect on overall reachability via the internet.

 Nick

Re: Monitoring Tools

[Carlos M. Martinez]

On 8/19/2010 5:36 PM, Curtis Maurand wrote:


 But the configuration learning curve for SNMP is very steep indeed.
 
 --Curtis
 
 

For some esoteric topics (dynamic tables, AgentX) this might be true,
however, you can get 80% of the benefit of SNMP with 20% of the whole thing.

It's a query/response protocol with a tree-based data model. That's it.

warm regards

Carlos