Fwd: 2022 MANRS Ambassadors

[Arturo Servin]

I think that this message hasn't been shared here.

Regards
as


-- Forwarded message -
From: Israel Rosas 
Date: Mon, 7 Feb 2022 at 16:12
Subject: [lacnog] 2022 MANRS Ambassadors
To: LACNOG 


Dear all,

Happy Monday! I’m reaching out to you to announce that today we are opening
the call for applications for the 2022 MANRS Ambassadors program. *Ambassadors
are required to be part of a MANRS participant organization*. They'll be
responsible for guiding and mentoring a group of Fellows, as well as
work together with the MANRS team.

The call will remain open from 7-18 February. Selected Ambassadors will be
announced on March 4. All the details and the link to participate can be
found at https://www.manrs.org/ambassadors-program/

At the end of this month we will start the selection process for MANRS
Fellows. In that case, the call for applications will be open to any
interested person, not only to MANRS participants.

Cheers,

*Israel Rosas*, Senior Regional Development Manager
ro...@isoc.org | Mobile: +52 55 3550 2363 | Pronouns: he/him/his
internetsociety.org | @internetsociety

My work hours may not be your work hours. Please respond in your own time.

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

Re: someone is using my AS number

[Arturo Servin]

Proper filtering from the upstream providers.

.as

On Wed, Jun 12, 2019 at 9:25 PM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

> Unfortunately RPKI is not useful in this case.
>
> Question: What else could be done to prevent this?
>
>
> Alejandro,
>
>
>
> On 6/12/19 12:05 PM, Philip Lavine via NANOG wrote:
>
> What is the procedure to have another party to cease and desist in using
> my AS number?
>
> Thx
>
>

Re: Starting to Drop Invalids for Customers

[Arturo Servin]

Mark

Invalid according to RPKI or IRR? Or both?

Regards
as

On Tue, 10 Dec 2019, 18:22 Randy Bush,  wrote:

> mark,
>
> > Just to let this group know that we've started the process of
> > activating the dropping of Invalids for all our eBGP customers.
>
> cool.  any stats and lessons appreciated.
>
> randy
>

Re: Measuring the quality of Internet access

[Arturo Servin]

Would be M-lab (https://www.measurementlab.net/about/) what you are looking
for?

.as

On Mon, 13 Jun 2016 at 13:20 Max Tulyev  wrote:

> Thank you!
>
> I got one more reply off-list - and again it is connected to SamKnows.
>
> But I can't figure out what SamKnows uses as the destination for tests?
>
> On 13.06.16 23:04, Eric Dugas wrote:
> > CIRA (.CA) started a project one or two years ago:
> https://cira.ca/build-better-internet/cira-internet-performance-test
> >
> > CRTC (Canadian equivalent of the FCC) also conducted tests by sending
> test boxes to volunteers:
> http://www.crtc.gc.ca/eng/internet/performance.htm and
> https://www.measuringbroadbandcanada.com
> >
> > Eric
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Max Tulyev
> > Sent: June 13, 2016 3:12 PM
> > To: NANOG list 
> > Subject: Measuring the quality of Internet access
> >
> > Hi All,
> >
> > I know there are many people from many countries.
> >
> > Do you know something about mandatory measurements of Internet access
> quality from country telecom regulators? If yes, could you please share
> that information with me?
> >
> > I found ETSI EG 202 057-4 standard
> > (
> http://www.etsi.org/deliver/etsi_eg/202000_202099/20205704/01.02.01_60/eg_20205704v010201p.pdf
> ),
> > but in fact it is about measurements inside operator's network, not
> Internet access itself.
> >
> > Is it possible in general to measure the quality of Internet access? And
> if yes - how?
> >
>
>

Re: Here we go again.

[Arturo Servin]

On Sun, 13 Nov 2016 at 07:08 Dovid Bender  wrote:

> Consumers can always chose with their wallet.
>
>
As long as you have options, which is the basic problem. There isn't real
alternative options.

Re: Stalled IX requests in Google peering

[Arturo Servin]

Will

You can send me the ticket number(s) by email.

Also, if anyone else has (have) similar issues feel free to email me.

Regards
as


On Mon, 4 Mar 2024 at 15:17, Will OBrien via NANOG  wrote:

> Since google is abandoning RS routes, we worked on setting up IX peering
> across the board.
>
> All of those requests have been completed but one seems to be stalled out
> for a couple of weeks now.
>
> I put in a noc ticket and got a tone deaf response of ‘that’s another
> group and the ticket is still in process’. The response time was decent at
> least!
>
>
>
> Anyone I can ping at google to tell me what’s up?
>
>
>
>
>
> Thanks!
>

Re: Puerto Rico Internet Exchange

[Arturo Servin]

What about the PRBI project for an IXP?

I think that is working, possibly it just need a hand. If possible, I would
like to put my effort in something that is working and improve it rather
than start something else from scratch.

Regards
as

On Sat, 12 Aug 2017 at 14:15 Mike Hammett  wrote:

> Reach out to Gino Villarini at Aeronet.
>
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
>
> Midwest Internet Exchange
>
> The Brothers WISP
>
> - Original Message -
>
> From: "Mehmet Akcin" 
> To: "nanog" 
> Sent: Saturday, August 12, 2017 6:27:57 AM
> Subject: Puerto Rico Internet Exchange
>
> Hey there!
>
> ... ok this time I am not going to call it PRIX ;) well name doesn't matter
> really. Nearly 13 years ago I have attempted to start Puerto rico Internet
> exchange in San Juan. I have lived there over 5 years and i just wanted to
> really watch videos faster. The project somewhat died when i moved to LA
> but now there are few interested party to start an internet exchange in
> Puerto rico. The jsland historically had one of the slowest
> broadband/internet services which seemed to have improved in recent years
> however as of 2017 there still is not an IX in Puerto rico.
>
> We , 3-4 internet engineers (on island and remote) , want to look into
> relaunch of this IX and hopefully find a way to keep local traffic
> exchanged at high speeds and low cost. We need expertise, and people who
> want to help any way they can.
>
> We are trying to make this IX a not-for-profit one and we are looking at
> opeeating models to adapt which has worked incredibly well like Seattle IX.
>
> We are hoping the relaunch to happen sometime in 2018. Thanks in advance
> hope to share more info and traffic data sometime , soon. Watch this space!
>
> Mehmet
>
>

Peering Forum LAC: Call for Presentations

[Arturo Servin]

The Latin American and Caribbean Peering Forum LACPF-2018 will be held in
Panama City, Panama on the April 30th, 2018. The goal of the LACPF is to
promote and provide collaboration spaces in topics related to
interconnection and peering, IXPs, CDNs, transport capacity, and colo
facilities among others.

>From this edition, the LACPF will change to the more know format that other
Peering Forums have. The event will be a day long, the first half for talks
and presentations and the second half for work and negotiation sessions.

The LACPF-2018 Program Committee invites the Internet community to submit
their presentations for the event.

The topics of interest to LACNOG 2017 include, but are not limited to:


   -

   Topics related to interconnection, peering, routing, and content
   distribution networks
   -

  Best Practices
  -

  Success cases
  -

  IPv6 Deployment
  -

  Scalability
  -

  Challenges
  -

  Deployment projects
  -

  Monitoring and network management
  -

  Network operation and professional experiences, success stories
  -

   Infrastructure
   -

  Critical Systems
  -

  Disaster recovery
  -

  SDX
  -

   Services
   -

  DNS / DNSSEC / IDNs.
  -

  CDNs.
  -

   Cooperation
   -

  Synergies with operators and government
  -

  Relation between universities and network operators


Presentations must be submitted according to the following schedule::

   -

   Reception of drafts and abstracts: 23 March 2018
   -

   Evaluation by the Program Committee: By April 6th 2018
   -

   Submission of the final presentation: April 16th 2018
   -

   Event date: April 30th 2018


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.



Please send works to cp-pf-...@googlegroups.com with the following:

   -

   Title
   -

   Summary or Extended Abstract. No more than 500 words.
   -

   Name, email, organization


Program Committee

   -

   Gabriel Adonaylo
   -

   Flavio Amaral
   -

   Hernán Arcidiacono
   -

   Guillermo Cicileo
   -

   Milton Kashiwakura
   -

   Fabian Mejia
   -

   Christian O’Flaherty
   -

   Mauricio Oviedo
   -

Re: Over a decade of DDOS--any progress yet?

[Arturo Servin]

One big problem (IMHO) of DDoS is that sources (the host of botnets) 
may be completely unaware that they are part of a DDoS. I do not mean the bot 
machine, I mean the ISP connecting those.

In the other hand the target of a DDoS cannot do anything to stop to 
attack besides adding more BW or contacting one by one the whole path of 
providers to try to minimize the effect. 

I know that this has many security concerns, but would it be good a 
signalling protocol between ISPs to inform the sources of a DDoS attack in 
order to take semiautomatic actions to rate-limit the traffic as close as the 
source? Of course that this is more complex that these three or two lines, but 
I wonder if this has been considerer in the past.

Regards.
-as



On 8 Dec 2010, at 10:00, nanog-requ...@nanog.org wrote:

> Date: Wed, 8 Dec 2010 10:58:38 +
> From: bmann...@vacation.karoshi.com
> Subject: Re: Over a decade of DDOS--any progress yet?
> To: "Dobbins, Roland" 
> Cc: North American Operators' Group 
> Message-ID: <20101208105838.gd5...@vacation.karoshi.com.>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> actually, botnets are an artifact.  claiming that the tool is the problem
> might be a bit short sighted.  with the evolution of Internet technologies
> (IoT) i suspect botnet-like structures to become much more prevelent and 
> useful for things other than coordinated attacks.
> 
> just another PoV.
> 
> --bill
> 
> On Wed, Dec 08, 2010 at 04:46:13AM +, Dobbins, Roland wrote:
>> 
>> On Dec 8, 2010, at 11:26 AM, Sean Donelan wrote:
>> 
>>> Other than trying to hide your real address, what can be done to prevent 
>>> DDOS in the first place.
>> 
>> 
>> DDoS is just a symptom.  The problem is botnets.  
>> 
>> Preventing hosts from becoming bots in the first place and taking down 
>> existing botnets is the only way to actually *prevent* DDoS attacks.  Note 
>> that prevention is distinct from *defending* oneself against DDoS attacks.
>> 
>> ---
>> Roland Dobbins  // 
>> 
>> Sell your computer and buy a guitar.
>> 
>> 
>> 
>> 
>> 
> 

Re: Over a decade of DDOS--any progress yet?

[Arturo Servin]

On 8 Dec 2010, at 13:12, nanog-requ...@nanog.org wrote:

> Date: Wed, 8 Dec 2010 12:53:51 +
> From: "Dobbins, Roland" 
> Subject: Re: Over a decade of DDOS--any progress yet?
> To: North American Operators' Group 
> Message-ID: 
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> On Dec 8, 2010, at 7:28 PM, Arturo Servin wrote:
> 
>>  One big problem (IMHO) of DDoS is that sources (the host of botnets) 
>> may be completely unaware that they are part of a DDoS. I do not mean the 
>> bot machine, I mean the ISP connecting those.
> 
> The technology exists to detect and classify this attack traffic, and is 
> deployed in production networks today.

Yes, they do exist. But, is people really filtering out attacks or just 
watching the attacks going out?


> 
> And of course, the legitimate owners of the botted hosts are generally 
> unaware that their machine is being used for nefarious purposes.
> 
>>  In the other hand the target of a DDoS cannot do anything to stop to 
>> attack besides adding more BW or contacting one by one the whole path of 
>> providers to try to minimize the effect.
> 
> Actually, there're lots of things they can do.

Yes, but all of them rely on your upstreams or in mirroring your 
content. If 100 Mbps are reaching your input interface of 10Mbps there is not 
much that you can do.

> 
>>  I know that this has many security concerns, but would it be good a 
>> signalling protocol between ISPs to inform the sources of a DDoS attack in 
>> order to take semiautomatic actions to rate-limit the traffic as close as 
>> the source? Of course that this is more complex that these three or two 
>> lines, but I wonder if this has been considerer in the past.
> 
> It already exists.

If you have an URL would be good. I only found a few research papers on 
the topic and RSVP documents but nothing really concrete.

Regards,
-as

Re: Over a decade of DDOS--any progress yet?

[Arturo Servin]

And those are much more complex to detect than SYN attacks or simple 
flood attacks with ICMP.

But even for simple flood attacks, I still think that the target has 
very few defence mechanisms, and those that exists require a complex 
coordination with upstreams.

Cheers,
.as

On 8 Dec 2010, at 13:39, Jeffrey Lyon wrote:

> We have seen a recent trend of attackers "legitimately" purchasing
> servers to use for attacks. They'll setup a front company, attempt to
> make the traffic look legitimate, and then launch attacks from their
> "legitimate" botnet.
> 
> Jeff
> 
> On Wed, Dec 8, 2010 at 10:33 AM, Arturo Servin  
> wrote:
>> 
>> On 8 Dec 2010, at 13:12, nanog-requ...@nanog.org wrote:
>> 
>>> Date: Wed, 8 Dec 2010 12:53:51 +
>>> From: "Dobbins, Roland" 
>>> Subject: Re: Over a decade of DDOS--any progress yet?
>>> To: North American Operators' Group 
>>> Message-ID: 
>>> Content-Type: text/plain; charset="us-ascii"
>>> 
>>> 
>>> On Dec 8, 2010, at 7:28 PM, Arturo Servin wrote:
>>> 
>>>>  One big problem (IMHO) of DDoS is that sources (the host of botnets) 
>>>> may be completely unaware that they are part of a DDoS. I do not mean the 
>>>> bot machine, I mean the ISP connecting those.
>>> 
>>> The technology exists to detect and classify this attack traffic, and is 
>>> deployed in production networks today.
>> 
>>Yes, they do exist. But, is people really filtering out attacks or 
>> just watching the attacks going out?
>> 
>> 
>>> 
>>> And of course, the legitimate owners of the botted hosts are generally 
>>> unaware that their machine is being used for nefarious purposes.
>>> 
>>>>  In the other hand the target of a DDoS cannot do anything to stop to 
>>>> attack besides adding more BW or contacting one by one the whole path of 
>>>> providers to try to minimize the effect.
>>> 
>>> Actually, there're lots of things they can do.
>> 
>>Yes, but all of them rely on your upstreams or in mirroring your 
>> content. If 100 Mbps are reaching your input interface of 10Mbps there is 
>> not much that you can do.
>> 
>>> 
>>>>  I know that this has many security concerns, but would it be good a 
>>>> signalling protocol between ISPs to inform the sources of a DDoS attack in 
>>>> order to take semiautomatic actions to rate-limit the traffic as close as 
>>>> the source? Of course that this is more complex that these three or two 
>>>> lines, but I wonder if this has been considerer in the past.
>>> 
>>> It already exists.
>> 
>>If you have an URL would be good. I only found a few research papers 
>> on the topic and RSVP documents but nothing really concrete.
>> 
>> Regards,
>> -as
> 
> 
> 
> -- 
> Jeffrey Lyon, Leadership Team
> jeffrey.l...@blacklotus.net | http://www.blacklotus.net
> Black Lotus Communications - AS32421
> First and Leading in DDoS Protection Solutions

Re: Are you ready for RPKI in your BGP?

[Arturo Servin]

There are some pieces in the RPKI puzzle.

One is the definitions of protocols, that one is very advanced in the 
SIDR WG in the IETF. Not RFCs yet but I am sure we will se some soon.

Another piece are repositories of CA's and ROAs and Trust Anchors. RIRs 
have they implementations or you could create your own if you want to keep your 
private keys.

IMHO one piece missing (not the only one, but one important in this 
stage) is RTR (RPKI/Router Protocol) working in routers. May be is too soon to 
see it in production routers but I am only aware of one big vendor with testing 
code. Also open-source implementations (Quagga, Xorp, Bird, etc.) are not 
actively (or at all) working in RPKI, I would imagine that one first step for 
many operators is to test RPKI with these implementations.


Regards,
-as


On 9 Dec 2010, at 06:37, nanog-requ...@nanog.org wrote:

> Date: Wed, 8 Dec 2010 22:56:08 -0500
> From: Jared Mauch 
> Subject: Are you ready for RPKI in your BGP?
> To: North American Network Operators Group 
> Message-ID: <15ff52ba-388a-48e8-bdde-a151e694e...@puck.nether.net>
> Content-Type: text/plain; charset=us-ascii
> 
> Are you ready for RPKI in your network?
> 
> While there's some dubious hyperbole in the article, the work that has been 
> undertaken in SIDR wg re: RPKI is moving along.  
> 
> http://www.networkworld.com/cgi-bin/mailto/x.cgi?pagetosend=/news/2010/120710-chinese-internet-traffic-fix.html&pagename=/news/2010/120710-chinese-internet-traffic-fix.html&pageurl=http://www.networkworld.com/news/2010/120710-chinese-internet-traffic-fix.html&site=printpage&nsdr=n
> 
> For those of you preparing to assign 2011 goals to your employees, or 
> something to self-assign, this should be in the top-5 or top-10 if you 
> configure routers for BGP.
> 
> - Jared

Re: Network Simulators

[Arturo Servin]

GNS3
http://www.gns3.net/

This is another network simulator, mainly for academic research.

NS-2
http://www.isi.edu/nsnam/ns/

And you can always setup some virtual machines with DNSs, hosts and 
routers with open-source software.

regards,
-as

On 17 Jan 2011, at 11:58, James Jones wrote:

> Are there any good Network Simulators/Trainers out there that support IPv6? I 
> want play around with some IPv6 setup.
> 
> -- 
> James Jones
> +1-413-667-9199
> ja...@freedomnet.co.nz
> 

Re: [arin-announce] ARIN Resource Certification Update

[Arturo Servin]

I agree with Alex that without a hosted solution RIPE NCC wouldn't have 
so many ROAs today, for us, even with it, it has been more difficult to roll 
out RPKI among our ISPs. As many, I do not think that a hosted suits to 
everybody and it has some disadvantages but at leas it could help to lower the 
entry barrier for some.


Speaking about RPKI stats, here some ROA evolution in various TAs (the 
data from ARIN is from their beta test, the rest are production systems):

http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt

And visually:

http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/global-roa-heatmap.png

and

http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/

To see each region.

http://www.labs.lacnic.net/~rpki/rpki-heatmaps

Also, bgpmon has a nice whois interface for humans to see ROAs (not 
sure if this link was share here or in twitter, sorry if I am duplicating):

http://bgpmon.net/blog/?p=414


Best regards,
-as



On 29 Jan 2011, at 13:26, Alex Band wrote:

> John,
> 
> Thanks for the update. With regards to offering a hosted solution, as you 
> know that is the only thing the RIPE NCC currently offers. We're developing 
> support for the up/down protocol as I write this.
> 
> To give you some perspective, one month after launching the hosted RIPE NCC 
> Resource Certification service, 216 LIRs are using it in the RIPE Region and 
> created 169 ROAs covering 467 prefixes. This means 40151 /24 IPv4 prefixes 
> and 7274499 /48 IPv6 prefixes now have a valid ROA associated with them.
> 
> I realize a hosted solution is not ideal, we're very open about that. But at 
> least in our region, it seems there are quite a number of organizations who 
> understand and accept the security trade-off of not being the owner of the 
> private key for their resource certificate and trust their RIR to run a 
> properly secured and audited service. So the question is, if the RIPE NCC 
> would have required everyone to run their own certification setup using the 
> open source tool-sets Randy mentions, would there be this much certified 
> address space now? 
> 
> Looking at the depletion of IPv4 address space, it's going to be crucially 
> important to have validatable proof who is the legitimate holder of Internet 
> resources. I fear that by not offering a hosted certification solution, real 
> world adoption rates will rival those of IPv6 and DNSSEC. Can the Internet 
> community afford that?
> 
> Alex Band
> Product Manager, RIPE NCC
> 
> P.S. For those interested in which prefixes and ASs are in the RIPE NCC ROA 
> Repository, here is the latest output in CSV format:
> http://lunimon.com/valid-roas-20110129.csv
> 
> 
> 
> On 24 Jan 2011, at 21:33, John Curran wrote:
> 
>> Copy to NANOG for those who aren't on ARIN lists but may be interested in 
>> this info.
>> FYI.
>> /John
>> 
>> Begin forwarded message:
>> 
>> From: John Curran mailto:jcur...@arin.net>>
>> Date: January 24, 2011 2:58:52 PM EST
>> To: "arin-annou...@arin.net" 
>> mailto:arin-annou...@arin.net>>
>> Subject: [arin-announce] ARIN Resource Certification Update
>> 
>> ARIN continues its preparations for offering production-grade resource 
>> certification
>> services for Internet number resources in the region.  ARIN recognizes the 
>> importance
>> of Internet number resource certification in the region as a key element of 
>> further
>> securing Internet routing, and plans to rollout Resource Public Key 
>> Infrastructure (RPKI)
>> at the end of the second quarter of 2011 with support for the Up/Down 
>> protocol for those
>> ISPs who wish to certify their subdelegations via their own RPKI 
>> infrastructure.
>> 
>> ARIN continues to evaluate offering a Hosting Resource Certification service 
>> for this
>> purpose (as an alternative to organizations having to run their own RPKI 
>> infrastructure),
>> but at this time it remains under active consideration and is not committed. 
>>   We look
>> forward to discussing the need for this type of service and the organization 
>> implications
>> atour upcoming ARIN Members Meeting in April in San Juan, PR.
>> 
>> FYI,
>> /John
>> 
>> John Curran
>> President and CEO
>> ARIN
>> 
>> ___
>> ARIN-Announce
>> You are receiving this message because you are subscribed to
>> the ARIN Announce Mailing List 
>> (arin-annou...@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-announce
>> Please contact i...@arin.net if you experience any issues.
>> 
>> 
> 

Re: Level 3's IRR Database

[Arturo Servin]

I think the issue is not between valid vs invalid, but that using 
route-maps and local preference a "more specific not valid" route would be used 
over another "less specific valid" because of the routing decision process, 
right?

Perhaps this would help?

http://www.ietf.org/mail-archive/web/sidr/current/msg02117.html

So, it is my understanding that yes, with local pref the Google vs 
Pakistan Telecom wouldn't have been avoided, however Google would "only need" 
to generate more specific routes to beat the unauthorised announce and "fix" 
the issue.

Right?

.as

On 31 Jan 2011, at 14:20, Alex Band wrote:

> 
> On 31 Jan 2011, at 19:40, Dongting Yu wrote:
> 
>> On Mon, Jan 31, 2011 at 6:17 PM, Andree Toonk  wrote:
>>> 
>>> Now AS17557 start to announce a more specific: 208.65.153.0/24. Validators
>>> would classify this as Invalid (2).
>> 
>> Would it be classified as invalid or unknown? Or are both possible
>> depending on whether 208.65.153.0/24 is signed? Do these two cases
>> differ in this particular case?
> 
> No, it would classify as invalid because as Randy said earlier in the thread:
> 
>  Before issuing a ROA for a block, an operator MUST ensure that any
>  sub-allocations from that block which are announced by others (e.g.
>  customers) have ROAs in play.  Otherwise, issuing a ROA for the
>  super-block will cause the announcements of sub-allocations with no
>  ROAs to be Invalid.
> 
> In a ROA you can specify a maximum length, authorising the AS to deaggregate 
> the prefix to the point you specify. If no max length is specified, the AS is 
> only allowed to announce the prefix as indicated.
> 
> So if the ROA for AS36561 with prefix 208.65.152.0/22 was created with no 
> 'max length' specified, the /24 that AS17557 announces would be invalid 
> because  it's the wrong prefix length *and* because it's the wrong origin AS. 
> If a max length of /24 was specified in the ROA, it would be invalid only 
> because of the latter.
> 
> There could be another ROA for 208.65.153.0/24 specifically, but obviously 
> not for AS17557, so again invalid because of the wrong origin AS. Pakistan 
> Telecom also can't create a valid ROA, because they are not the holder of the 
> address space.
> 
> -Alex

Re: ipv4's last graph

[Arturo Servin]

We have been doing it for a few months.

http://www.lacnic.net/en/registro/espacio-disponible-ipv4.html

We are working in a new model to forecast the available space over time 
and in providing the data so anybody can do their own graphs.

Also APNIC has some very useful data:

http://www.apnic.net/community/ipv4-exhaustion/graphical-information

Regards,
-as

On 1 Feb 2011, at 11:18, Tony Hain wrote:

> The individual RIR graphs won't be around long enough to be worth the
> effort... ;) 
> 
> FWIW: the Jan. 2011 global burn rate (outbound from the RIRs) for
> /24-equivlents was 18.97 seconds. At the Jan. rate, APnic won't last to June
> and Ripe might make to the end of August, then chaos ensues. Is there really
> any value in trying to distribute graphs that will all be flat before the
> end of the year?
> 
> Tony
> 
> 
>> -Original Message-
>> From: Randy Bush [mailto:ra...@psg.com]
>> Sent: Tuesday, February 01, 2011 12:02 AM
>> To: Geoff Huston
>> Cc: NANOG Operators' Group
>> Subject: ipv4's last graph
>> 
>> with the iana free pool run-out, i guess we won't be getting those nice
>> graphs any more.  might we have one last one for the turnstiles?  :-)/2
>> 
>> and would you mind doing the curves now for each of the five rirs?
>> gotta give us all something to repeat endlessly on lists and in presos.
>> 
>> randy
> 

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

[Arturo Servin]

Is it really a better alternative? Do we want to pay the cost of a 
fully distributed RPKI architecture?

Or do we just abandon the idea of protecting the routing infrastructure?

There is no free-lunch, we just need to select the price that we want 
to pay.

-as

On 1 Feb 2011, at 16:29, Benson Schliesser wrote:

> 
> On Feb 1, 2011, at 11:14 AM, Christopher Morrow wrote:
> 
>> On Sun, Jan 30, 2011 at 2:55 PM, Martin Millnert  wrote:
>>> Here be dragons,
>> 
>>> 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?
> 
> In theory at least, entities closer to the RPKI root (RIRs, IANA) could 
> invalidate routes for any sort of policy reasons.  This might provide 
> leverage to certain governments, perhaps even offering the ability to control 
> routing beyond their jurisdiction.
> 
> As an example, it's imaginable that the US government could require IANA or 
> ARIN to delegate authority to the NSA for a Canadian ISP's routes.  Feel free 
> to replace the RIR/LIR and country names, to suit your own example.
> 
> Cheers,
> -Benson
> 
> 

Re: BCP38.info

[Arturo Servin]

Not working in the Internet access business but as Internet citizen
this sounds interesting.

You would need some motivations to make ISPs register and perhaps some
kind of validation in the future. But as initial step it sounds cool.

.as


On Wed, Jan 29, 2014 at 10:16 AM, Andrei Robachevsky
 wrote:
> Hi,
>
> Jared Mauch wrote on 1/28/14 9:03 PM:
>> I'd rather share some data and how others can observe this to determine how 
>> we can approach a fix.  Someone spoofing your IP address out some other 
>> carrier is something you may be interested to know about, even if you have a 
>> non-spoofing network.
>
> At the Internet Society we are flashing out an idea of an anti-spoofing
> "movement", where ISPs can list themselves as not spoofing-capable on
> our website. The requirement is that they can demonstrate that they
> block spoofed packets, for instance by successfully running the Spoofer
> test. I think your, Jared, test can add to this picture.
>
> Sort of a positive spin on the name and shame technique.
>
> It is not ideal, as one test is not a real proof of such capability, but
> might help raising awareness, at least. Does this sound as something
> that can be useful and fly?

Re: ISP inbound failover without BGP

[Arturo Servin]

On Mon, Mar 3, 2014 at 7:20 PM, Randy Carpenter wrote:

> Is there some technical reason that BGP is not an option? You could allow
> them to announce their AT&T space via you as a secondary.


unless it is a /26, /25 or something shorter.

Even with a /24 things may get messy.

IPv4 is coming to an end, but it is not possible for the customer to get
their own space and use BGP?

Regards,
as

Re: pay.gov and IPv6

[Arturo Servin]

No Happy Eyeballs?

Perhaps also time to ditch XP and IE for something new as well.

-as




On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman wrote:

> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail
> when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of
> client computers that should be dual-stacked are now relegated to IPv4-only
> until someone remembers to turn it back on for each of them... sigh.
>
> Matthew Kaufman
>
>

Re: pay.gov and IPv6

[Arturo Servin]

HE should work then, perhaps another problem + IPv6.

-as


On Mon, Mar 17, 2014 at 11:55 AM, Matthew Kaufman wrote:

>  Windows 8 running Google Chrome as the browser.
>
> Matthew Kaufman
>
>
> On 3/17/2014 11:46 AM, Arturo Servin wrote:
>
>
> No Happy Eyeballs?
>
>  Perhaps also time to ditch XP and IE for something new as well.
>
>  -as
>
>
>
>
> On Mon, Mar 17, 2014 at 11:43 AM, Matthew Kaufman wrote:
>
>> Random IPv6 complaint of the day: redirects from FCC.gov to pay.gov fail
>> when clients have IPv6 enabled. Work fine if IPv6 is off. One more set of
>> client computers that should be dual-stacked are now relegated to IPv4-only
>> until someone remembers to turn it back on for each of them... sigh.
>>
>> Matthew Kaufman
>>
>>
>
>

Re: IPv6 and DNS

[Arturo Servin]

On 12 Jun 2011, at 09:38, Fabio Mendes wrote:

> 2011/6/11 Matthew Palmer 
> 
>> 
>> The router isn't assigning an address, it's merely telling everyone on the
>> segment what the local prefix and default route is.  As such, there's no
>> reason why the router should try to register a DNS entry.
>> 
>> On the other hand, the host could (and should) register it's address with
>> whatever DNS server handles it's name.  The protocol for such is already
>> standardised and should be independent of IPv4/IPv6.
>> 
>> - Matt
>> 
> 
> Thanks Matt.
> 
> I was thinking about something like this, it looks the natural way to go,
> but isn't too dangerous allow hosts to update entries (even if it's their
> own)  in an DNS server ?
> 
> I preferred to believe that a router would do this because routers are
> considered to be more reliable than a hosts. In the other hand, I also
> recognize that this could put a lot of weight in routers' CPU processing.


Routers route packets, otherwise they would be called registrars or 
something like that.

-as

Re: Errant Advertisement - 128.1/16

[Arturo Servin]

They also made Interface Message Processors, like the grandpas of 
routers.


.as

On 8 Aug 2011, at 12:29, Peter Stockli wrote:

> Wow, BBN, the reason we use the @ sign, second .com Domain, former AS1.
> 
> Lots of history ;)
> 
> On Mon, Aug 8, 2011 at 2:07 PM, Rick Altmann  wrote:
> 
>> This issue has been cleared up.  Thanks to everyone for their help.
>> 
>> -Rick
>> 
>> On Aug 4, 2011, at 12:07 PM, Rick Altmann wrote:
>> 
>>> Is there anyone from AT&T on the list that could help with a likely
>> misconfiguration?  I have not received any response yet to my complaint (see
>> below) submitted to the abuse address on July 26.  We have since started
>> advertising this space and would like to resolve the MOAS condition we have
>> created.
>>> 
>>> 
>>> 
>>> The 128.1.0.0/16 address block is registered to BBN Technologies
>> (AS11488) but is currently unused on any BBN networks.  BBN would like to
>> begin using this address space however AS7018 is currently originating
>> public BGP routes for this address block.  We believe this to be a
>> configuration error.  Please help us resolve this.
>>> 
>>> A traceroute to 128.1.0.1 shows the following routers as the last 4
>> responding hops:
>>> 
>>> cr1.n54ny.ip.att.net (12.122.81.106)
>>> cr81.nw2nj.ip.att.net (12.122.105.30)
>>> gar18.n54ny.ip.att.net (12.122.105.101)
>>> 12.89.231.190
>>> 
>>> 
>>> 
>>> Thanks,
>>> Rick
>> 
>> 
>> 

Re: Prefix hijacking by Michael Lindsay via Internap

[Arturo Servin]

What's the prefix you claim is hijacked?

/as

On 20 Aug 2011, at 22:05, Denis Spirin wrote:

> Hello All,
> 
> I was hired by the Russian ISP company to get it back to the business. Due
> to impact of the financial crisis, the company was almost bankrupt, but then
> found the investor and have a big wish to life again.
> 
> When I tried to announce it's networks, upstreams rejected to accept it
> because of Spamhaus listings. But our employer sworn there is not and was
> not any spamming from the company. The Spamhaus lists all our networks as
> spamming Zombies. And it IS announced and used now!!! The announce is from
> American based company Internap (AS12182). I wrote the abuse report them,
> but instead of stop unauthorized announces of our networks, I was contacted
> by a person named 'Michael Lindsay' - he tell me he buy our networks from
> some other people and demand we get back our abuse reports. Of course, we
> don't. After a short googling, I found this is well-known cyber crime
> person: http://www.spamhaus.org/rokso/listing.lasso?file=818&skip=0, and he
> did IP hijacking with the fake letter of authorization before:
> http://www.spamhaus.org/rokso/evidence.lasso?rokso_id=ROK8686 so our company
> is not a first victim of him. Yes, our company "help" him with the mistake
> of loosing old domain link-telecom.biz he was also squatted. This domain was
> listed as contact at RIPE Database.
> 
> It is a good topic why these easy-to-forge LOAs is still in use, as
> RADB/RIPE DB/other routing database with the password access is a common
> thing. But this is not the main thing. The main thing is why Internap helps
> to commit a crime to the well-known felony person, and completely ignores
> our requests? Is there any way to push them to stop doing that immediately?
> If anybody can - please help...

Re: Prefix hijacking by Michael Lindsay via Internap

[Arturo Servin]

These prefix are originated by AS31733 which seems to be assigned to 
the same organisation than the ASN, which in turn seems to be you.

I can see AS12182 in the path but not originating the route. So I do 
not understand what are your claiming.

.as


On 20 Aug 2011, at 23:05, Denis Spirin wrote:

> Right now there are:
> 46.96.0.0/16
> 83.223.224.0/19
> 94.250.128.0/19
> 94.250.160.0/19
> 188.164.0.0/24

Re: Prefix hijacking by Michael Lindsay via Internap

[Arturo Servin]

On 21 Aug 2011, at 00:28, Denis Spirin wrote:

> Yes, they are using our ASN 31733 to originate networks. All the visible
> paths are through AS12182. Internap was contacted about a week ago, but did
> nothing.

Which seems to be the right decision because the whois data backed it 
on.


> No, I'm not a venture capitalist, but IT specialist.
> 
> I am too sleepy, so replied to Adrian directly while wanted to post in the
> list.

If you are claiming right over these prefixes I suggest you to contact 
RIPE NCC.

/as

> 
> 2011/8/21 Arturo Servin 
> 
>> 
>> These prefix are originated by AS31733 which seems to be assigned to the
>> same organisation than the ASN, which in turn seems to be you.
>> 
>> I can see AS12182 in the path but not originating the route. So I do not
>> understand what are your claiming.
>> 
>> .as
>> 
>> 
>> On 20 Aug 2011, at 23:05, Denis Spirin wrote:
>> 
>> Right now there are:
>> 46.96.0.0/16
>> 83.223.224.0/19
>> 94.250.128.0/19
>> 94.250.160.0/19
>> 188.164.0.0/24
>> 
>> 
>> 

Re: Prefix hijacking by Michael Lindsay via Internap

[Arturo Servin]

What I understand is that he is clamming that the registration of this 
prefix was hijacked from him.

But honestly I do not what the problem is. Any how, it won't be solved 
here.

Regards,
/as



On 21 Aug 2011, at 02:25, David Conrad wrote:

> On Aug 20, 2011, at 6:01 PM, Arturo Servin wrote:
>>  If you are claiming right over these prefixes I suggest you to contact 
>> RIPE NCC.
> 
> And that will do what exactly?
> 
> Back when I worked at an RIR, a prefix was "misplaced".  When I contacted the 
> (country monopoly PTT) ISP and told them the prefix had been removed from 
> APNIC's database and should not be routed.  Their response was "We have a 
> contract with the customer for connectivity.  We do not have a contract with 
> you." and I was encouraged to get the customer to voluntarily withdraw the 
> prefix.
> 
> If BGPSEC+RPKI were deployed, there might be something active the RIRs could 
> do.  However, this has its own implications regarding centralized control of 
> the routing system (as discussed, ironically enough, in the RIPE region).  
> And this is going to get much more 'interesting' as the IPv4 free pool 
> exhausts and the market moves from black to grey or white.  Fun times ahead.
> 
> Regards,
> -drc
> 

Re: NAT444 or ?

[Arturo Servin]

NAT444 alone is not enough.

You will need to deploy it along with 6rd or DS-lite.

Whilst you still have global v4, use it. The best is to deploy 
dual-stack, but that won't last for too long.

Regards,
as-



On 1 Sep 2011, at 15:36, Serge Vautour wrote:

> Hello,
> 
> Things I understand: IPv6 is the long term solution to IPv4 exhaustion. For 
> IPv6 to work correctly, most of the IPv4 content has to be on IPv6. That's 
> not there yet. IPv6 deployment to end users is not trivial (end user support, 
> CPE support, etc...). Translation techniques are generally evil. IPv6->IPv4 
> still requires 1 IPv4 IP per end user or else you're doing NAT. IPv4->IPv6 
> (1-1) doesn't solve our main problem of giving users access to the IPv4 
> Internet.
> 
> 
> I expect like most companies we're faced with having to extend the life of 
> IPv4 since our users will continue to want access to the IPv4 content. Doing 
> that by giving them an IPv6 address is not very feasible yet for many 
> reasons. NAT444 seems like the only solution available while we slowly 
> transition over to IPv6 over the next 20 years. Based on the this RFC, NAT444 
> breaks a lot of applications!
> 
> http://tools.ietf.org/html/draft-donley-nat444-impacts-01
> 
> Has anyone deployed NAT444? Can folks share their experiences? Does it really 
> break this many apps? What other options do we have? 
> 
> 
> Thanks,
> Serge

Re: Botnets buying up IPv4 address space

[Arturo Servin]

What do you mean with "purchasing or renting IPv4".

Last time that I check it was not possible in the RIR world.

If you mean "hijacking" unused IPv4 space, that's another history.

.as

On 7 Oct 2011, at 15:11, Joly MacFie wrote:

> I'd welcome comments as to solutions to this. Or is it just scaremongering?
> 
> j
> 
> -- Forwarded message --
> From: Lauren Weinstein 
> Date: Fri, Oct 7, 2011 at 1:31 PM
> 
> Botnets buying up IPv4 address space
> 
> http://j.mp/nMJ5Lr  (Threat Post)
> 
>   "Now, in one effort to get around these systems, some attackers are
>taking advantage of the lack of IPV4 space by either purchasing or
>renting blocks of IP space with good reputations that have been built
>up over the course of several years. A number of legitimate trading
>and auction sites have appeared as the IPV4 space became scarcer, and
>the attackers have gotten involved as well, getting their hands on
>known good IP blocks and using them for C&C or hosting malware."
> 
> - - -
> 
> --Lauren--
> NNSquad Moderator
> 
> 
> 
> -- 
> ---
> Joly MacFie  218 565 9365 Skype:punkcast
> WWWhatsup NYC - http://wwwhatsup.com
> http://pinstand.com - http://punkcast.com
> VP (Admin) - ISOC-NY - http://isoc-ny.org
> --
> -

Re: Botnets buying up IPv4 address space

[Arturo Servin]

Yes, I forgot that one.

ARIN and APNIC allows it, LACNIC will when it reaches the last /12 (so 
now is not possible). RIPE NCC and Afrinic do not have a policy yet AFAIK.


-as 

On 7 Oct 2011, at 15:35, David Conrad wrote:

> On Oct 7, 2011, at 11:31 AM, Arturo Servin wrote:
>>  What do you mean with "purchasing or renting IPv4".
>> 
>>  Last time that I check it was not possible in the RIR world.
> 
> Seriously?
> 
> http://www.networkworld.com/community/blog/microsoft-pays-nortel-75-million-ipv4-address
> 
> The next phases are anger, bargaining, depression, and finally acceptance.
> 
> Regards,
> -drc
> 

Re: Botnets buying up IPv4 address space

[Arturo Servin]

I agree with Benson.

In fact, for this "problem" I find irrelevant that IPv4 is running out. 
They are just looking for good reputation IP nodes.

-as

On 7 Oct 2011, at 16:03, Benson Schliesser wrote:

> I don't see anything new in the article, and would classify parts of it as 
> scaremongering. (e.g. the criticism of IPv6)

Re: Botnets buying up IPv4 address space

[Arturo Servin]

Thanks, I didn't know that one.

I followed the link to "IPv4 Address Allocation and Assignment Policies 
for the RIPE NCC Service Region" and seems a good and simple approach.

Regards,
.as

On 9 Oct 2011, at 10:16, Martin Millnert wrote:

> Arturo,
> 
> On Fri, Oct 7, 2011 at 8:59 PM, Arturo Servin  wrote:
>>ARIN and APNIC allows it, LACNIC will when it reaches the last /12 
>> (so now is not possible). RIPE NCC and Afrinic do not have a policy yet 
>> AFAIK.
> 
> RIPE's LIR IPv4 listing service has 1x /20 listed, *right now*.
> https://www.ripe.net/lir-services/resource-management/listing
> 
> Regards,
> Martin

Re: DPI deployment use case

[Arturo Servin]

I imagine that those proposals are not from users …

I would add "tyrannical" telcos cracking down on their own customers.

-as

On 7 Oct 2011, at 14:20, Claudio Lapidus wrote:

> Hello,
> 
> On Thu, Oct 6, 2011 at 8:00 PM, Martin Millnert  wrote:
> 
>> I've seen tyrannical governments use Bluecoat's to crack down on their
>> own population(*).
>> Was this the sort of use-case you were looking for? :)
>> 
> Ummm, not really... :)
> 
> Actually, we've been faced with proposals to build services based on traffic
> classification, like e.g. "access our own webmail and all social networking
> sites, but not skype and video" or the capability to do exact metering based
> on net traffic time or volume, as well as being able to redirect the
> customer to various captive portals using HTTP redirect directly from the
> DPI box, and such.

Re: using IPv6 address block across multiple locations

[Arturo Servin]

Same from LACNIC. This would have justify a /44 or separate /48s for 
each site.


/as

On 31 Oct 2011, at 12:45, Justin M. Streiner wrote:

> On Mon, 31 Oct 2011, Owen DeLong wrote:
> 
>> Ideally, you should put a /48 at each location.
> 
> Speaking from my experience with getting v6 space from ARIN earlier this 
> year, as long as your documentation is in pretty good order, a /48 per site 
> is pretty easy to get.
> 
> I don't know if the experience is different with other RIRs.
> 
> jms

Re: IPV6 6to4 and 6In4 Lab

[Arturo Servin]

Why don't you use just a tunnelbroker?

I would take just a few minutes to setup a tunnel. From there, you can 
do a lot of stuff inside your network.

My 2 cents
/as

On 1 Nov 2011, at 18:36, Meftah Tayeb wrote:

> Hello folks,
> i'm posting this Message to both nanog and afnog lists
> preferably if i can get one from afnog to work with me a bit for routing IPV6 
> prefixs over him using at least static or OSPFv3 or BGP (at you like)
> i want to anounce my /48 optained from a friend as number) and 2002::/16 
> (6to4 prefixs=) at least for 10min to see real IPV6 traffic.
> if someone want to help me, please contact me
> thank you
>Meftah Tayeb
> IT Consulting
> http://www.tmvoip.com/ 
> phone: +21321656139
> Mobile: +213660347746
> 
> 
> __ Information from ESET NOD32 Antivirus, version of virus signature 
> database 6596 (2002) __
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com

Re: Minimum Allocation Size by RIRs (IPv4)

[Arturo Servin]

/24 as minimal allocation is only for end-users and critical 
infrastructure.

For ISPs (LIRs) the minimal allocation is /22.

/as


On 16 Nov 2011, at 00:30, Rubens Kuhl wrote:

> LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html

Re: First real-world SCADA attack in US

[Arturo Servin]

I wonder if they are using private IP addresses.

-as

On 21 Nov 2011, at 13:32, Jay Ashworth wrote:

> On an Illinois water utility:
> 
> http://www.msnbc.msn.com/id/45359594/ns/technology_and_science-security
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Dynamic (changing) IPv6 prefix delegation

[Arturo Servin]

On 22 Nov 2011, at 13:38, Joel Maslak wrote:

> 1) Not having IPv6 at all.  I expect to get it on my DSL in about 10 years or 
> so when the equipment my line on is old enough to be replaced under a 15 or 
> 20 year replacement cycle.
> 
> 2) Bandwidth caps probably affect people a lot more than changing IPs.  I 
> don't have one on my landline, but I expect to get it when the DSL 
> aggregation devices are replaced (I suspect I don't have it now because the 
> equipment doesn't do it well).


Add to your list:

1.5) Instead of getting IPv6, getting private IPv4 and CGN service.

-as

Re: Network Latency Measurements

[Arturo Servin]

It is in beta and in spanish, though:

http://simon.labs.lacnic.net/simon/api
http://simon.labs.lacnic.net/simon
http://simon.labs.lacnic.net/simon/participate/

If you found it useful we could create an english version.

Regards
as

On 04/12/2012 19:05, Tal Mizrahi wrote:
> Hi,
> 
> We are looking for publicly available statistics of network latency 
> measurements taken in large networks.
> For example, there is FCC's measurements 
> (http://www.fcc.gov/measuring-broadband-america/2012/july).
> However, we are looking for something more detailed that can show a large 
> number of latency measurements taken periodically (preferably with as small a 
> period as possible).
> 
> Any help will be appreciated.
> 
> Thanks,
> Tal Mizrahi.
> 

Re: /. ITU Approves Deep Packet Inspection

[Arturo Servin]

Perhaps because you are addressing to a bunch of Internet engineers
that (we) are used to create standards in open forums where everybody
have a say.

For the new Internet world "available to all participants in the ITU-T,
on exactly the same terms as drafts of other Recommendations" is not
longer valid.

Regards,
as

On 05/12/2012 17:01, Tom Taylor wrote:
> I'm seriously not clear why Y.2770 is characterized as "negotiated
> behind closed doors". Any drafts were available to all participants in
> the ITU-T, on exactly the same terms as drafts of other Recommendations.
> As an example, the draft coming out of the October, 2011 meeting can be
> seen at http://www.itu.int/md/T09-SG13-111010-TD-WP4-0201/en. (I have
> access delegated by a vendor to whom I have been consulting, by virtue
> of their membership in the ITU-T.)
> 
> I should mention that the "Next Generation Network" within the context
> of which this draft was developed is more likely to be implemented by
> old-line operators than by pure internet operations.
> 
> Tom Taylor
> 
> On 05/12/2012 4:34 AM, Eugen Leitl wrote:
>>
>> http://yro.slashdot.org/story/12/12/05/0115214/itu-approves-deep-packet-inspection
>>
>>
>> ITU Approves Deep Packet Inspection
>>
>> Posted by Soulskill on Tuesday December 04, @08:19PM
>>
>> from the inspect-my-encryption-all-you'd-like dept.
>>
>> dsinc sends this quote from Techdirt about the International
>> Telecommunications Union's ongoing conference in Dubai that will have an
>> effect on the internet everywhere: "One of the concerns is that decisions
>> taken there may make the Internet less a medium that can be used to
>> enhance
>> personal freedom than a tool for state surveillance and oppression.
>> The new
>> Y.2770 standard is entitled 'Requirements for deep packet inspection
>> in Next
>> Generation Networks', and seeks to define an international standard
>> for deep
>> packet inspection (DPI). As the Center for Democracy & Technology
>> points out,
>> it is thoroughgoing in its desire to specify technologies that can be
>> used to
>> spy on people. One of the big issues surrounding WCIT and the ITU has
>> been
>> the lack of transparency — or even understanding what real
>> transparency might
>> be. So it will comes as no surprise that the new DPI standard was
>> negotiated
>> behind closed doors, with no drafts being made available."
>>
>>
>>

Re: www.eftps.gov contact

[Arturo Servin]

It works for me (http)

Cannot ping, so maybe they filtered the whole ICMPv6 and you have a MTU
problem. But that is only a guessing.

as

On 18/12/2012 13:36, Christopher Morrow wrote:
> On Tue, Dec 18, 2012 at 10:35 AM, Christopher Morrow
>  wrote:
>> On Tue, Dec 18, 2012 at 10:33 AM, Christopher Morrow
>>  wrote:
>>> if only some us-gov folks read this mailing list...
>>> maybe someone form NIST could aim the right question to the right
>>> eftps.gov people?
>>> you'd think helping the taxman would be appreciated.
>>>
>>
>> it's probably also fair to point out that ... it seems to be working.
>> ( and A)
> 
> and traceroute/traceroute6 seems to work to the prem...
> 
>  6  cr1.attga.ip.att.net (12.122.1.173)  79.126 ms  71.722 ms  74.646 ms
>  7  cr2.dlstx.ip.att.net (12.122.28.174)  74.001 ms  74.127 ms  74.198 ms
>  8  cr1.dlstx.ip.att.net (12.122.1.209)  75.261 ms  75.305 ms  75.405 ms
>  9  cr1.phmaz.ip.att.net (12.122.28.182)  73.070 ms  73.381 ms  73.408 ms
> 10  12.123.206.173 (12.123.206.173)  71.586 ms  70.289 ms  70.048 ms
> 11  12.87.83.6 (12.87.83.6)  71.226 ms  71.290 ms  71.526 ms
> 12  * * *
> 
>  6  2600:803:95f::d (2600:803:95f::d)  4.618 ms  4.951 ms *
>  7  2600:805:51f::12 (2600:805:51f::12)  49.616 ms  49.726 ms  49.672 ms
>  8  2600:805:51f::12 (2600:805:51f::12)  48.548 ms  48.561 ms  48.75 ms
>  9  2620:10f:400e:1::6 (2620:10f:400e:1::6)  50 ms  53.366 ms  50.704 ms
> 10  * * *
> 
> so, what's broken?
> 
>>> On Tue, Dec 18, 2012 at 10:26 AM, Dennis Burgess
>>>  wrote:
 I tried to this a month ago, no luck :( i.e. nothing back from them, just 
 goes into no answer e-mail space!

 Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- 
 Second Edition"
  Link Technologies, Inc -- Mikrotik & WISP Support Services
  Office: 314-735-0270 Website: http://www.linktechs.net - Skype: linktechs
  -- Create Wireless Coverage's with www.towercoverage.com - 900Mhz - LTE - 
 3G - 3.65 - TV Whitespace



 -Original Message-
 From: Darren Pilgrim [mailto:na...@bitfreak.org]
 Sent: Tuesday, December 18, 2012 9:09 AM
 To: nanog@nanog.org
 Subject: www.eftps.gov contact

 The hostname www.eftps.gov has both A and  records, but the site is 
 only reachable via IPv4.  Worse, the IPv6 connectivity is broken in such a 
 way that Firefox and Internet Explorer do not fall back to IPv4.
 Tracing is broken for both protocols.  The 10-net addresss in the IPv4 
 path were cute.

 Calling their technical support was an exercise in futility.  Supposedly 
 they forwarded messages on to the right people; but the site is still 
 broken after over a week's wait.  If someone knows the admins behind the 
 EFTPS website and can forward this to them, the accounting firm for which 
 I work would appreciate it.

 Thanks,

Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?

[Arturo Servin]

On 7 Mar 2013, at 02:50, Dobbins, Roland wrote:

> 
> On Mar 7, 2013, at 11:36 AM, Jared Mauch wrote:
> 
>> I would pitch it as follows: We need to at least have IPv6 access to 
>> troubleshoot/understand customers that have dual-stack technology.
> 
> That's a great point, but my guess is that the suits will say that since none 
> of their customers are using IPv6, there's no urgency (yes, I know, it's 
> better to be prepared ahead of time; but foresight doesn't generally carry 
> much weight in quarterly-driven enterprises).
> 

Yes, but this is an argument to deploy the whole IPv6 thing, not 
against a strategy to first deploy in-house and then to customers, isn't it?

In my experience, it is always best to try IPv6 in-house (at least a 
small office, a group, etc.) and then move to customers, YMMV.

/as

Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?

[Arturo Servin]

Pretty much the same process that I have seen in many ISPs and 
enterprises.

Regards.
as

On 07/03/2013 11:32, John Curran wrote:
> On Mar 7, 2013, at 5:42 AM, Arturo Servin  wrote:
> 
>>  Yes, but this is an argument to deploy the whole IPv6 thing, not 
>> against a strategy to first deploy in-house and then to customers, isn't it?
>>  In my experience, it is always best to try IPv6 in-house (at least a 
>> small office, a group, etc.) and then move to customers, YMMV.
> 
> Presuming a medium/small service provider, the most typical sequence 
> that I've been hearing runs something like this:
> 
> 1. Engineers internally experiment with IPv6 on an individual basis
>(lab, tunnels, virtual servers, etc.)   Doesn't always happen,
>but the ones that don't are making their own gamble regarding 
>their skills and career trajectory.
> 
> 2. Some formal recognition by the network team of need to gain IPv6 
>experience; this can be equipment for a "real" lab, formal training,
>minor investment in external firewalls to bring up to spec, etc.
> 
> 3. The network folks start arranging for real IPv6 connectivity from
>the outside, this could be transit or peering, and begin working
>on plans for the "network backbone" to be fully dual-stack.
> 
> 4. The "talk" with IT regarding IPv6, and acceptance of the concept
>that it would be nice if the web site had some minimal support
>(yes, maybe not the customer ticketing/feedback system, or every
>page, but at least the major content sections.)   This leads to 
>the idea that IT will test new web rollouts with IPv6, and the 
>need therefore to get IPv6 to some of the integration/QA folks.
> 
> 5. IT/internal network team realization that they have to get IPv6 
>internally to some of the Internet network team, some of the 
>developers, and that means that the "corporate" network really
>does need to support IPv6, and that means those firewalls, and
>management and training for the internal corporate network team.
> 
> 6. Several meetings with marketing and sales trying to explain that
>other organizations (i.e. customers are doing the same thing, and 
>a general mismatch in expectations since the vast majority of 
>customers have never uttered "IPv6" to anyone in sales/marketing.
> 
> 7. Slow but steady internal progress on IPv6 deployment in the company, 
>all while waiting for sales/marketing to recognize the need for IPv6
>services for customers.
> 
> 8. One key event (often a customer RFP requirement, or a sale lost due
>to lack of IPv6 support) occurs, which then brings the lack of IPv6 
>into focus as a competitive issue, and subsequent discussions about 
>budget/investment for adding IPv6 support to the service catalog.
> 
> YMMV, and every organization is a little different, but the common theme 
> is that the more awareness that we can generate in CIO/IT industry about 
> the IPv4 constraints facing the Internet network industry, the faster 
> that IPv6 will happen...
> 
> /John
> 
> 
> 
> 

Re: [c-nsp] DNS amplification

[Arturo Servin]

Yes, BCP38 is the solution.

Now, how widely is deployed?

Someone said in the IEPG session during the IETF86 that 80% of the
service providers had done it?

This raises two questions for me. One, is it really 80%, how to measure 
it?

Second, if it were 80%, how come the 20% makes so much trouble and how
to encourage it to deploy BCP38?

(well, actually 4 questions :)

Regards,
as

On 3/16/13 7:24 PM, Jon Lewis wrote:
> On Sat, 16 Mar 2013, Robert Joosten wrote:
> 
>> Hi,
>>
 Can anyone provide insight into how to defeat DNS amplification
 attacks?
>>> Restrict resolvers to your customer networks.
>>
>> And deploy RPF
> 
> uRPF / BCP38 is really the only solution.  Even if we did close all the
> open recursion DNS servers (which is a good idea), the attackers would
> just shift to another protocol/service that provides amplification of
> traffic and can be aimed via spoofed source address packets.  Going
> after DNS is playing whack-a-mole.  DNS is the hip one right now.  It's
> not the only one available.

Re: [c-nsp] DNS amplification

[Arturo Servin]

They should publish the spoofable AS. Not for public shame but at least
to show the netadmins that they are doing something wrong, or if they
are trying to do the good think is not working.

Or at least a tool to check for your ASN or netblock.

/as

On 3/17/13 1:35 PM, Christopher Morrow wrote:
> On Sun, Mar 17, 2013 at 11:33 AM, Arturo Servin  
> wrote:
>>
>> Yes, BCP38 is the solution.
>>
>> Now, how widely is deployed?
>>
>> Someone said in the IEPG session during the IETF86 that 80% of the
>> service providers had done it?
> 
> right... sure.
> 
>> This raises two questions for me. One, is it really 80%, how to 
>> measure it?
>>
> 
> csail had a project for a while... spoofer project?
>   <http://spoofer.csail.mit.edu/>
> 
> I think the last I looked they reported ONLY 35% or so coverage of
> proper filtering. Looking at:
>   <http://spoofer.csail.mit.edu/summary.php>
> 
> though they report 86% non-spoofable, that seems very high to me.
> 
>> Second, if it were 80%, how come the 20% makes so much trouble and 
>> how
>> to encourage it to deploy BCP38?
> 
> some of the 20% seems to be very highspeed connected end hosts and at
> a 70:1 amplification ratio you don't need much bandwidth to fill a 1g
> pipe, eh?
> 
> -chris
> 
>> (well, actually 4 questions :)
>>
>> Regards,
>> as
>>
>> On 3/16/13 7:24 PM, Jon Lewis wrote:
>>> On Sat, 16 Mar 2013, Robert Joosten wrote:
>>>
>>>> Hi,
>>>>
>>>>>> Can anyone provide insight into how to defeat DNS amplification
>>>>>> attacks?
>>>>> Restrict resolvers to your customer networks.
>>>>
>>>> And deploy RPF
>>>
>>> uRPF / BCP38 is really the only solution.  Even if we did close all the
>>> open recursion DNS servers (which is a good idea), the attackers would
>>> just shift to another protocol/service that provides amplification of
>>> traffic and can be aimed via spoofed source address packets.  Going
>>> after DNS is playing whack-a-mole.  DNS is the hip one right now.  It's
>>> not the only one available.
>>

Re: [c-nsp] DNS amplification

[Arturo Servin]

I think BCP it is a solution. Perhaps not complete but hardy any single
solution would be suitable for a complex problem as this one.

If you are the end-user organization with a multihomed topology you
apply BCP38 within your own scope. This will help to have less spoofed
traffic. Not solving all the problems but it would help not seeing your
spoofed packets all over the Internet.

And about the routing table size, it is not multihomed sites the
offenders, it is large ISPs fragmenting because of traffic engineering
or because lack of BGP knowledge.

.as

On 3/18/13 2:47 AM, Masataka Ohta wrote:
> Mark Andrews wrote:
> 
Yes, BCP38 is the solution.
>>>
>>> It is not a solution at all, because it, instead, will promote
>>> multihomed sites bloats the global routing table.
>>
>> How does enforcing that source address entering your net from
>> customers sites match thoses that have been allocated to them
>> bloat the routing table?
> 
> First of all, multihomed sites with its own global routing
> table entries bloats the global routing table, which is the
> major cause of global routing table bloat and is not acceptable.
> 
> Then, the only solution is to let the multihomed sites have
> multiple prefixes, each of which is aggregated by each
> provider.
> 
> But, then, all the end systems are required to choose the proper
> source addresses corresponding to destination addresses, which
> requires IGPs carry such information.
> 
> See draft-ohta-e2e-multihoming-05 for details.
> 
>> Now if you only accept address you have allocated to them by you
>> then that could bloat the routing table but BCP 38 does NOT say to
>> do that.  Simlarly URP checking is not BCP 38.
> 
> That BCP 38 is narrowly scoped is not my problem.
> 
>> With SIDR each multi-homed customer could provide CERTs which proves
>> they have been allocated a address range which could be feed into
>> the acl generators as exceptions to the default rules.  This is in
>> theory automatible.
> 
> The problem is not in individual ISPs but in the global routing
> table size.
> 
>> How does that solve the problem?
> 
> In the end to end fashion.
> 
> See draft-ohta-e2e-multihoming-05 for details.
> 
>   Masataka Ohta
> 
> 

Re: [c-nsp] DNS amplification

[Arturo Servin]

Masataka,

Do you have data to support your claim?

I would said that poor BCP38 deployment it is because a lack of
economical incentive. I have only empirical data to support my claim
though (which is private conversations with ISPs not doing it and saying
that they do not see a cost effective advantage).

Regards,
as

On 3/18/13 12:02 PM, Masataka Ohta wrote:
> Current poor support for multihomed sites is a reason why
> BCP38 is not operational.

Re: [c-nsp] DNS amplification

[Arturo Servin]

It does if I am not the sender.

.as

On 3/18/13 12:10 PM, Masataka Ohta wrote:
> Arturo Servin wrote:
> 
>> >If you are the end-user organization with a multihomed topology you
>> > apply BCP38 within your own scope. This will help to have less spoofed
>> > traffic. Not solving all the problems but it would help not seeing your
>> > spoofed packets all over the Internet.
> It does not help not seeing a spoofed packets with source addresses
> of yours.
> 

Re: [c-nsp] DNS amplification

[Arturo Servin]

The last presentations that I saw about it said that we are going to be
fine:

http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf

http://www.iepg.org/2011-11-ietf82/iepg-20.pdf

Regards,
as

On 20/03/2013 02:53, Randy Bush wrote:
> i am not saying bgp and forwarding can deal with growth forever, but
> 
>   o over my career, the death of spinning oxide has always been two
> years away.  yet the hardwhere jocks have continued to pull the
> rabbit out of the hat.  perhaps, many decades later, ssds have
> finally caught up and physical limits are finally approaching.
> 
>   o a dozen or so years ago, i shared an nsf grant with lixia, dan, and
> others called "better bgp," based on the assumption that bgp was not
> gonna scale.  i took the contrary position, we actually had no clear
> measurement showing it was not going to scale.  out of this came
> beacons, 'happy packets', etc.
> 
> so i think we need some measurements of the sky before we can judge the
> rate of its descent.
> 
> randy
> 

Re: [c-nsp] DNS amplification

[Arturo Servin]

On 20/03/2013 09:07, Aled Morris wrote:
> On 20 March 2013 11:44, Arturo Servin  <mailto:arturo.ser...@gmail.com>> wrote:
> 
> 
> The last presentations that I saw about it said that we are
> going to be
> fine:
> 
> http://www.iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf
> http://www.iepg.org/2011-11-ietf82/iepg-20.pdf
> 
> 
> 
> It isn't just about "imminient death of the net predicted" though - our
> reliance on the current BGP model for route adverisement is restricting
> the deployment of better connectivity paradigms.

Agree with that. But as today I do not think LISP would be the solution.

> 
> For example I know there are enterprises that would  like to multihome
> but they find the current mechanism a barrier to this - for a start they
> can't justify the size of PI space that would guarantee them entry to
> the global routing table.

Which is good. If they cannot justify PI space may be they should not
get into the global routing table. It is a problem for them, yes. Do we
have a solution? Not yet.

> 
> ISPs differentiate between "regular" and "BGP-capable" connections - is
> this desirable for the evolution of the Internet?  or is it the reason
> that BGP appears to be able to cope, because ISPs are throttling the
> potential growth?

It is an operational practice. Maintaining BGP sessions have a cost.
Also, at least in the cases that I know those connections also have
different SLAs which is the real cost, not just the BGP.

> 
> LISP is about seperating the role of the ISP (as routing provider) from
> the end user or content provider/consumer.

Yes, but as mentioned before the cost is in the edge, the benefit in
the core. The economic equation is all wrong. There is not economic
incentive for the edge to deploy LISP. We are facing the same problem
that we have with IPv6.

Now, if with LISP as an edge site I can have multihome, high
availability, not to renumber my network, or any other combination of
benefits and it does cost less than PI+BGP or PA+
then it may work.

> 
> Aled
> 

Regards,
as

Re: [c-nsp] DNS amplification

[Arturo Servin]

On 3/20/13 12:26 PM, David Conrad wrote:
> Arturo,
> 
> On Mar 20, 2013, at 5:32 AM, Arturo Servin  wrote:
>>> For example I know there are enterprises that would  like to multihome
>>> but they find the current mechanism a barrier to this - for a start they
>>> can't justify the size of PI space that would guarantee them entry to
>>> the global routing table.
>>
>>  Which is good. If they cannot justify PI space may be they should not
>> get into the global routing table.
> 
> The implication of this statement is that if you cannot afford the RIR fees, 
> the routers, the technical expertise to run those routers, the additional 
> opex associated with "BGP-capable" Internet connectivity, etc., the 
> services/content you provide don't deserve resiliency/redundancy/etc.
> 

You deserve it, but can you afford it? (at least with the technology
that we have today).

> I have trouble seeing how this can be called "good".  A "necessary evil given 
> broken technology" perhaps, but not "good".
> 
May be not my best choice of words. What I meant was that if you cannot
justify PI, probably you do not have the means to run multihome today.

It is not really good, in fact it sucks but this is the reality.


>>> LISP is about seperating the role of the ISP (as routing provider) from
>>> the end user or content provider/consumer.
>>
>>  Yes, but as mentioned before the cost is in the edge, the benefit in
>> the core.
> 
> Being able to effectively multi-home without BGP, removing the need to ever 
> renumber, etc., all sound like benefits to the edge to me.
> 
>> The economic equation is all wrong. 

Is LISP able to provide all those benefits?

> 
> People keep saying this.
> 
> For core providers, the equation doesn't change.  Well, OK, they may lose the 
> additional fees they get for "BGP-capable" connections and they won't have 
> the 'benefit' of the cost of renumbering to reduce customer thrash, however 
> they continue to get paid for providing connectivity services. They might 
> even save some money in the long run as they won't need to replace their 
> hamsters with guinea pigs quite as frequently.
> 
> For edges, the addition of a network element gives them freedom and 
> resiliency at the cost of additional complexity and a bit of additional 
> latency/reduced bandwidth.  However, it is the edges that would pay the cost 
> to get the benefit. I have trouble seeing how this economic equation is wrong.
> 
>> There is not economic incentive for the edge to deploy LISP. We are facing 
>> the same problem
>> that we have with IPv6.
> 
> Not really. 

Not in the details, but in the macro it is. A technology that has to be
lead by somebody that may not have the incentive to do it.

>For example, you (or somebody) have to edit/recompile code to use IPv6.
>You do not have to recompile code to use LISP.
> 

But as edge site I have to have a capable router, have engineers to
deploy LISP (or pay for it), etc. Without a clear benefit I do not
seeing any one doing it.

But I've already said it in my previous emal:

"Now, if with LISP as an edge site I can have multihome, high
availability, not to renumber my network, or any other combination of
benefits and it does cost less than PI+BGP or PA+
then it may work."


> Regards,
> -drc
> 

Regards,
as

Re: Why are there no GeoDNS solutions anywhere in sight?

[Arturo Servin]

On 21/03/2013 04:23, Constantine A. Murenin wrote:
> Are you suggesting that geolocation is inaccurate enough to misplace
> Europe with Asia?

Yes, sometimes very inaccurate.

Just go to an IETF meeting and you will be placed all around the globe.
It is a corner case, but it shows some deficiencies in the current approach.

.as

Re: BCP38 needs advertising

[Arturo Servin]

And do not forget 

http://tools.ietf.org/html/bcp38

:)

-as


On 3/27/13 2:17 PM, Paul Ferguson wrote:
> Please reference:
> 
> http://openresolverproject.org/
> http://spoofer.csail.mit.edu/
> http://blog.cloudflare.com/deep-inside-a-dns-amplification-ddos-attack
> 
> ...and anything else to raise the awareness level.
> 
> Thanks,
> 
> - ferg (co-perpetrator of BCP38)  :-)
> 
> On Wed, Mar 27, 2013 at 9:48 AM, Alain Hebert  wrote:
> 
>> bcp38.org coming soon =D
>>
>> -
>> Alain Hebertaheb...@pubnix.net
>> PubNIX Inc.
>> 50 boul. St-Charles
>> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
>> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>>
>> On 03/27/13 11:20, Jack Bates wrote:
>>> Outside of needing more details and examples, BCP38 could use more
>>> advertising.
>>>
>>> The best option, if they would accept it, is to have all RIRs mention
>>> BCP38 as well as require that mention of BCP38 be included in all IP
>>> justification requests to customers (so that those who receive
>>> netblocks from their ISPs are also aware of it).
>>>
>>> For ARIN, at least, having it mentioned in the attestation process
>>> wouldn't be a bad idea. At least someone of management would be aware
>>> of it.
>>>
>>> The only issue is see concerning the RIRs is that they may object to
>>> it being out of scope to their duties. However, informing people of
>>> something is not requiring implementation of something. On the other
>>> hand, we know that there are a great number of networks that don't
>>> participate with the community at large and may have no idea about
>>> BCP38 and why it is important.
>>>
>>>
>>> Jack
>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 

Re: BCP38 - Internet Death Penalty

[Arturo Servin]

I am afraid you are right.

It is going to cost us money and time, but unfortunately I do not see
another way out.

/as

On 3/27/13 6:19 PM, Paul Ferguson wrote:
> As I mentioned on another list earlier today, let's face it -- this is
> going to require a large-scale, very public, and probably multi-year
> education & awareness effort (as if 13+ years isn't enough already!).

Re: Verizon DSL moving to CGN

[Arturo Servin]

On 4/8/13 9:41 AM, Owen DeLong wrote:
> On Apr 7, 2013, at 23:27 , Tore Anderson  wrote:
> 
>> > * Owen DeLong
>> > 
>>> >> The need for CGN is not divorced from the failure to deploy IPv6, it
>>> >> is caused by it.
>> > 
>> > In a historical context, this is true enough. If we had accomplished
>> > ubiquitous IPv6 deployment ten years ago, there would be no IPv4
>> > depletion, and there would be no CGN. However, that ship has sailed long
>> > ago. You're using present tense where you should have used past.
>> > 
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.
> 


I though that they have done it last year around June 8th.  ;-)

In fact, the need for CGN has been reduced if you count that 30-40% of
your traffic would go to those places. Although CGN is going to be a
necessary evil, deploying CGN without IPv6 would be a mistake IMHO.

/as

Re: "It's the end of the world as we know it" -- REM

[Arturo Servin]

Yes.

We figured this out and we are starting a program (or a set of
activities) to promote the deployment of IPv6 in what we call "End-users
organizations" (basically enterprises, universities). We are seeing much
lower adoption numbers than our ISP's categories.

One basic problem that we have found when talking with enterprises is
that the perceived value of deploy v6 is near to zero as they have v4
addresses (universities) or NAT.

Regards,
as

On 4/24/13 6:26 PM, Fred Baker (fred) wrote:
> If we really want to help the cause, I suspect that focusing attention on 
> enterprise, and finding ways to convince them that address shortages are also 
> their problem, will help the most.

Re: GMail IPv6 IMAP Issue, or is it Just Me?

[Arturo Servin]

It works to me, a different one by the way:

telnet -6 imap.gmail.com 993
Trying 2607:f8b0:400c:c01::6c...
Connected to gmail-imap.l.google.com.
Escape character is '^]'.
]
^]
telnet> q
Connection closed.

The same one, works too:

telnet 2607:f8b0:400d:c00::6c 993
Trying 2607:f8b0:400d:c00::6c...
Connected to qa-in-x6c.1e100.net.
Escape character is '^]'.
^]
telnet> q
Connection closed.


Regards,
as


On 6/1/13 2:53 PM, Stevens, Brant I. wrote:
> Is anyone else having issues reaching GMail on IPv6 via IMAP, or is it just
> me?
> 
> Here's some of what I'm seeing:
> 
> It responds to ping...
> 
> imac01:~ branto$ ping6 imap.gmail.com
> PING6(56=40+8+8 bytes) 2001:470:8d30:b00c::bb0e --> 2607:f8b0:400d:c00::6c
> 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=0 hlim=55 time=31.299 ms
> 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=1 hlim=55 time=41.528 ms
> 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=2 hlim=55 time=30.092 ms
> 16 bytes from 2607:f8b0:400d:c00::6c, icmp_seq=3 hlim=55 time=35.450 ms
> ^C
> --- gmail-imap.l.google.com ping6 statistics ---
> 4 packets transmitted, 4 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 30.092/34.592/41.528/4.470 ms
> 
> 
> TCP Sessions on v6 seem to time-out:
> 
> imac01:~ branto$ telnet -6 imap.gmail.com 993
> Trying 2607:f8b0:400d:c01::6c...
> telnet: connect to address 2607:f8b0:400d:c01::6c: Operation timed out
> telnet: Unable to connect to remote host
> 
> IPv4 Connects:
> 
> imac01:~ branto$ telnet -4 imap.gmail.com 993
> Trying 173.194.76.108...
> Connected to gmail-imap.l.google.com.
> Escape character is '^]'.
> 
> ^]
> telnet> close
> Connection closed.
> 
> and other connectivity via IPv6 works:
> 
> imac01:~ branto$ telnet -6 www.google.com 80
> Trying 2607:f8b0:400c:c04::68...
> Connected to www.google.com.
> Escape character is '^]'.
> 
> GET /
> HTTP/1.0 200 OK
> Date: Sat, 01 Jun 2013 17:08:58 GMT
> 
> 
> 
> Connection closed by foreign host.
> 
> I've tried flushing my dnscache to make sure I'm not holding on to
> something that's not valid, but no dice.
> 
> -Brant
> 

Re: shell access to BGP router, CALEA tips??

[Arturo Servin]

Not sure if this is what you are looking for:

http://www.traceroute.org/#Route%20Servers

/as

On 8 Jan 2012, at 22:31, David Prall wrote:

> Both AT&T and Hurricane Electric have access for this.
> 
> A quick list of them.
> http://www.netdigix.com/servers.html
> 
> Majority of these are telnet:// links.
> 
> David
> 
> --
> http://dcp.dcptech.com
> 
> 
> 
> -Original Message-
> From: N Rauhauser [mailto:neal.rauhau...@gmail.com] 
> Sent: Sunday, January 08, 2012 12:13 PM
> To: nanog@nanog.org
> Subject: shell access to BGP router, CALEA tips??
> 
>  Ladies & Gentlemen,
> 
>  I wanted to check something on an IP address block this morning and,
> much to my surprise, I don't have access to a single router that has a full
> table in it - first time since 1999 this is the case. I see route views is
> still happily serving up shells, but I'm curious to know if there are any
> other viewpoints available. I am probably going to script something for
> this particular problem, so I want boxes that have shell access, not
> graphical looking glass type stuff.
> 
> 
> I am also plunged into the world of lawful intercept after a long
> absence. Other than providing muddled responses ten minutes before the
> deadline on obvious MPAA/RIAA trolls I haven't had to do a subpoena
> response since 2005 and I've not installed anything that needed to meet
> requirements since 2009. Is there a good write up somewhere on the current
> state of affairs?
> 
> 
> 
> 
> 
> Neal Rauhauser
> 

Re: ANNOUNCE: bgptables.merit.edu - understanding visibility of your prefix/AS

[Arturo Servin]

Manish,

Nice tool.

Is it possible to see the "history" of a prefix?


Regards,
.as



On 13 Jan 2012, at 18:19, Manish Karir wrote:

> 
> All,
> 
> We would like to announce the availability of the bgpTables Project at Merit 
> at: http://bgptables.merit.edu
> bgpTables allows users to easily navigate global routing table data collected 
> via routviews.org.  bgptables
> essentially processes the data collected at routeviews and makes is available 
> in a somewhat easier
> to use interface. The goal of bgpTables is to represent global prefix and AS 
> visibility information from the
> vantage point of the various bgp table views as seen at routeviews. 
> The data is currently updated nightly (EST) but we hope to improve this over 
> time. 
> Please see the FAQ (http://bgptables.merit.edu/faq.php) for some simple 
> examples of how you can use bgpTables.
> 
> Some examples:
> - You can query for a specific ASN by entering the text 'as' followed by the 
> AS number into the search box. For example to query for information about AS 
> 237 you would enter 'as237' [without quotation marks] into the search box and 
> then click 'search'. You can then use the view navigator map to switch to 
> different routing table views for this ASN
> 
> - You can query for a specific prefix by directly entering the prefix into 
> the search box. For example to query for information about prefix 12.0.0.0/8 
> you would simply enter '12.0.0.0/8' [without quotation marks] into the search 
> box and then click 'search'. You can then use the view navigator map to 
> switch to different routing table views for the prefix.
> 
> - You can find a particular prefix that you might be interested in by running 
> a 'contained within' query via the search box. For example to quickly browse 
> a list of prefixes contained within 1.0.0.0/8 to find the particular prefix 
> you might be interested in, you can enter the text 'cw1.0.0.0/8' [without 
> quotation marks] into the search box and click 'search'. You can then browse 
> the resulting table to select the particular prefix you might be interested 
> in.
> 
> - You can simply enter the text 'as' followed by the company name into the 
> search box then click search to view a list of possible matches for that 
> text. For example, to view all matching google ASNs you can simply enter 
> 'asgoogle' into the search box and click search. A list of possible matching 
> ASNs that reference Google by name will be returned from which you an then 
> select the particular ASN that is of interest to you.
> 
> 
> Comments, corrections, and suggestions are very welcome.  Please send them to 
> mka...@merit.edu.  Hopefully folks will find this useful.
> 
> Thanks.
> -The Merit Network Research and Development Team
> 

Re: ANNOUNCE: bgptables.merit.edu - understanding visibility of your prefix/AS

[Arturo Servin]

For example for any given prefix to get which ASNs have originated that 
prefix over time and when.

I think that could be interesting for discovering if a prefix has been 
hijacked in the past.

RIS from RIPE NCC provides something like this:

http://www.ripe.net/data-tools/stats/ris/routing-information-service

We have used it to verify some "suspicious" announcements of prefixes. 

Regards,
as

On 17 Jan 2012, at 19:52, Manish Karir wrote:

> 
> Hi Arturo,
> 
> We could easily archive older copies of the database when we update the data, 
> but I think our issue right now
> is that we dont fully understand how to add the notion of time to the user 
> interface and we dont understand how
> folks might want to use it.  Do you have a simple use case description of an 
> example which might help us
> figure out how the notion of time can help answer a question.?  What would be 
> an example of a query 
> that uses time?
> 
> Thanks.
> -manish
> 
> 
> On Jan 16, 2012, at 12:53 PM, Arturo Servin wrote:
> 
>> Manish,
>> 
>>  Nice tool.
>> 
>>  Is it possible to see the "history" of a prefix?
>> 
>> 
>> Regards,
>> .as
>> 
>>  
>>  
>> On 13 Jan 2012, at 18:19, Manish Karir wrote:
>> 
>>> 
>>> All,
>>> 
>>> We would like to announce the availability of the bgpTables Project at 
>>> Merit at: http://bgptables.merit.edu
>>> bgpTables allows users to easily navigate global routing table data 
>>> collected via routviews.org.  bgptables
>>> essentially processes the data collected at routeviews and makes is 
>>> available in a somewhat easier
>>> to use interface. The goal of bgpTables is to represent global prefix and 
>>> AS visibility information from the
>>> vantage point of the various bgp table views as seen at routeviews. 
>>> The data is currently updated nightly (EST) but we hope to improve this 
>>> over time. 
>>> Please see the FAQ (http://bgptables.merit.edu/faq.php) for some simple 
>>> examples of how you can use bgpTables.
>>> 
>>> Some examples:
>>> - You can query for a specific ASN by entering the text 'as' followed by 
>>> the AS number into the search box. For example to query for information 
>>> about AS 237 you would enter 'as237' [without quotation marks] into the 
>>> search box and then click 'search'. You can then use the view navigator map 
>>> to switch to different routing table views for this ASN
>>> 
>>> - You can query for a specific prefix by directly entering the prefix into 
>>> the search box. For example to query for information about prefix 
>>> 12.0.0.0/8 you would simply enter '12.0.0.0/8' [without quotation marks] 
>>> into the search box and then click 'search'. You can then use the view 
>>> navigator map to switch to different routing table views for the prefix.
>>> 
>>> - You can find a particular prefix that you might be interested in by 
>>> running a 'contained within' query via the search box. For example to 
>>> quickly browse a list of prefixes contained within 1.0.0.0/8 to find the 
>>> particular prefix you might be interested in, you can enter the text 
>>> 'cw1.0.0.0/8' [without quotation marks] into the search box and click 
>>> 'search'. You can then browse the resulting table to select the particular 
>>> prefix you might be interested in.
>>> 
>>> - You can simply enter the text 'as' followed by the company name into the 
>>> search box then click search to view a list of possible matches for that 
>>> text. For example, to view all matching google ASNs you can simply enter 
>>> 'asgoogle' into the search box and click search. A list of possible 
>>> matching ASNs that reference Google by name will be returned from which you 
>>> an then select the particular ASN that is of interest to you.
>>> 
>>> 
>>> Comments, corrections, and suggestions are very welcome.  Please send them 
>>> to mka...@merit.edu.  Hopefully folks will find this useful.
>>> 
>>> Thanks.
>>> -The Merit Network Research and Development Team
>>> 
>> 
> 

Why not to use RPKI (Was Re: Argus: a hijacking alarm system)

[Arturo Servin]

You could use RPKI and origin validation as well.

We have an application that does that. 

http://www.labs.lacnic.net/rpkitools/looking_glass/

For example you can periodically check if your prefix is valid:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/valid/cidr/200.7.84.0/23/

If it were invalid for a possible hijack it would look like:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/200.31.18.0/24/

Or you can just query for any state:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0/22/



Regards,
as

On 20 Jan 2012, at 07:47, Yang Xiang wrote:

> Hi,
> 
> I build a system ‘Argus’ to real-timely alert prefix hijackings.
> Argus monitors the Internet and discovers anomaly BGP updates which caused
> by prefix hijacking.
> When Argus discovers a potential prefix hijacking, it will advertise it in
> a very short time,
> both in our website (http://argus.csnet1.cs.tsinghua.edu.cn) and the
> mailing list (ar...@csnet1.cs.tsinghua.edu.cn).
> 
> Argus has been running in the Internet for more than eight months,
> it usually can discover potential prefix hijackings in ten seconds after
> the first anomaly BGP update announced.
> Several hijacking alarms have been confirmed by network operators.
> For example: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/61544/ has
> been confirmed by the network operators of AS23910 and AS4538,
> it was a prefix hijacking caused by a mis-configuration of route filter.
> 
> If you are interest in BGP security, welcome to visit our website and
> subscribe the mailing list.
> If you are interest in the system itself, you can find our paper which
> published in ICNP 2011 (FIST workshop)
> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6089080.
> 
> Hope Argus will be useful for you.
> _
> Yang Xiang . about.me/xiangyang
> Ph.D candidate. Tsinghua University
> Argus: argus.csnet1.cs.tsinghua.edu.cn

Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)

[Arturo Servin]

On 20 Jan 2012, at 10:38, Yang Xiang wrote:

> RPKI is great.
> 
> But, firstly, ROA doesn't cover all the prefixes now,
> we need an alternative service to alert hijackings.

Or to sign your prefixes.

> 
> secondly, ROA can only secure the 'Origin AS' of a prefix,

That's true.

> while Argus can discover potential hijackings caused by anomalous AS path.

Can you explain how?

> 
> After ROA and BGPsec deployed in the entire Internet (or, in all of your 
> network),
> Argus will stop the service :)

I was just suggesting to add a more deterministic way to detecting 
hijacks.


Regards,
as

> 
> 2012/1/20 Arturo Servin 
> 
>You could use RPKI and origin validation as well.
> 
>We have an application that does that.
> 
>http://www.labs.lacnic.net/rpkitools/looking_glass/
> 
>For example you can periodically check if your prefix is valid:
> 
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/valid/cidr/200.7.84.0/23/
> 
>If it were invalid for a possible hijack it would look like:
> 
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/200.31.18.0/24/
> 
>Or you can just query for any state:
> 
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0/22/
> 
> 
> 
> Regards,
> as
> 
> 
> 
> 
> 
> -- 
> _
> Yang Xiang. Ph.D candidate. Tsinghua University
> Argus: argus.csnet1.cs.tsinghua.edu.cn
> 

Re: Thanks & Let's Prevent this in the Future.

[Arturo Servin]

One option is to use RPKI and origin validation. But it won't help much 
unless prefix holders create their certificates and ROAs and networks operators 
use those to validate origins. It won't solve all the issues but at least some 
fat fingers/un-expierience errors.

We are running an experiment to detect route-hijacks/missconf using 
RPKI. So far, not many routes are "signed" but at least we can periodically 
check our own prefix (or any other with ROAs) to detect some inconsistencies:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/

http://www.labs.lacnic.net/rpkitools/looking_glass/


Regards,
-as


On 1 Feb 2012, at 06:58, Kelvin Williams wrote:

> First off, I'd like to thank everyone on this list who have reached out
> today and offered us help with our hijacked network space.  It's so
> refreshing to see that there are still so many who refuse to leave a
> man/woman down.
> 
> I'm not going to place any blame, its useless.  There were lies, there were
> incompetencies, and there was negligence but that is now water under the
> bridge.
> 
> However, I think that we as network operators have a duty to each other to
> make sure we don't allow a downstream customer wreck the operations of
> another entity who has been rightfully allocated resources.
> 
> A few months ago, when establishing a new peering relationship I was
> encouraged (actually required) to utilize one of the IRRs.  I took the time
> to register all of my routes, ASNs, etc.  However, as I learned today, this
> was probably done in vain.  Too many people won't spend the extra
> 30-seconds to verify the information listed there or in ARINs WHOIS.
> 
> I don't care what a customer tells me, too many times I've found they
> aren't 100% honest either for malicious/fraudulent reasons or they are
> unknowing.  So, for our networks or the networks we manage, we want to
> verify what a customer is saying to prevent what happened to us today.
> 
> I'd like to get a conversation going and possibly some support of an
> initiative to spend that extra 30-seconds to verify ownership and
> authorization of network space to be advertised.  Additionally, if someone
> rings your NOC's line an industry-standard process of verifying "ownership"
> and immediately responding by filtering out announcements. There's no sense
> in allowing a service provider to be impaired because a spammer doesn't
> want to give up clean IP space.  Do you protect a bad customer or the
> Internet as a whole?  I pick the Internet as a whole.
> 
> How can we prevent anyone else from ever enduring this again?  While we may
> never stop it from ever happening, spammers (that's what we got hit by
> today) are a dime a dozen and will do everything possible to hit an Inbox,
> so how can we establish a protocol to immediate mitigate the effects of an
> traffic-stopping advertisement?
> 
> I thought registering with IRRs and up-to-date information in ARINs WHOIS
> was sufficient, apparently I was wrong.  Not everyone respects them, but
> then again, they aren't very well managed (I've got several networks with
> antiquated information I've been unable to remove, it doesn't impair us
> normally, but its still there).
> 
> What can we do?  Better yet, how do we as a whole respond when we encounter
> upstream providers who refuse to look at the facts and allow another to
> stay down?
> 
> kw
> 
> -- 
> Kelvin Williams
> Sr. Service Delivery Engineer
> Broadband & Carrier Services
> Altus Communications Group, Inc.
> 
> 
> "If you only have a hammer, you tend to see every problem as a nail." --
> Abraham Maslow

Re: filtering /48 is going to be necessary

[Arturo Servin]

On 11 Mar 2012, at 09:48, Iljitsch van Beijnum  wrote:

> On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote:
> 
>> The way we are headed right now, it is likely that the IPv6 address
>> space being issued today will look like "the swamp" in a few short
>> years, and we will regret repeating this obvious mistake.
> 
>> We had this discussion on the list exactly a year ago.  At that time,
>> the average IPv6 origin ASN was announcing 1.43 routes.  That figure
>> today is 1.57 routes per origin ASN.
> 
> The IETF and IRTF have looked at the routing scalability issue for a long 
> time. The IETF came up with shim6, which allows multihoming without BGP. 
> Unfortunately, ARIN started to allow IPv6 PI just in time so nobody bothered 
> to adopt shim6. I haven't followed the IRTF RRG results for a while, but at 
> some point LISP came out of this, where we basically tunnel the entire 
> internet so the core routers don't have to see the real routing table.
> 
> But back to the topic at hand: filtering long prefixes. There are two reasons 
> you want to do this:
> 
> 1. Attackers could flood BGP with bogus prefixes to make tables overflow
> 
> 2. Legitimate prefixes may be deaggregated so tables overflow
> 
> It won't be quick or easy, but the RPKI stuff should solve 1.
> 
> 

Unless the attacker uses the same origin AS that is in the ROA. Probably it 
won't hijack the traffic but it may create a DoS or any other kind of problem.

Regards,
as

Re: SNMP monitoring of routing tables

[Arturo Servin]

Try RIS from RIPE NCC or routeviews.

regards,
as

Sent from my mobile device
(please excuse typoss and brevit.)


On 13 Mar 2012, at 11:54, Walter Keen  wrote:

> 
> Trying to work on an interesting project, where it would be nice to monitor 
> the routing table of a collection of routers, store it, and look at it later, 
> as a snapshot of what the routing table for a particular router looked at a 
> particular time. All the information I'm wanting (route entry, nexthop, etc) 
> is available via snmp on the ip-route mib I believe, and needs to stay fairly 
> generic, or equipment-agnostic.
> 
> 
> Does anyone know of an existing project to do this before I start trying to 
> make one?
> 
> Walter Keen 

Re: Quad-A records in Network Solutions ?

[Arturo Servin]

Another reason to not use them.

Seriusly, if they cannot expend some thousands of dollars (because it 
shouldn't be more than that) in "touching code, (hopefully) testing that code, 
deploying it, training customer support staff to answer questions, updating 
documentation, etc." I cannot take them as a serious provider for my names.

Regards,
.as

On 28 Mar 2012, at 21:16, John T. Yocum wrote:

> 
> 
> On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote:
>> I'm not convinced. What you mention is real, but the code they need is
>> little more than a regular expression that can be found on Google and a
>> 20-line script for testing lames. And a couple of weeks of testing, and
>> I think I'm exaggerating.
>> 
>> If they don't want to offer support for it, they can just put up some
>> disclaimer.
>> 
>> regards,
>> 
>> Carlos
>> 
>> 
>> On 3/28/12 3:55 PM, David Conrad wrote:
>>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote:
 I'm not a fan of conspiracy theories, but, c'mon. For a provisioning
 system, an  record is just a fragging string, just like any other
 DNS record. How difficult to support can it be ?
>>> 
>>> Of course it is more than a string. It requires touching code, (hopefully) 
>>> testing that code, deploying it, training customer support staff to answer 
>>> questions, updating documentation, etc. Presumably Netsol did the 
>>> cost/benefit analysis and decided the potential increase in revenue 
>>> generated by the vast hordes of people demanding IPv6 (or the potential 
>>> lost in revenue as the vast hordes transfer away) didn't justify the 
>>> expense. Simple business decision.
>>> 
>>> Regards,
>>> -drc
>>> 
>>> 
>> 
> 
> That's assuming their system is sanely or logically designed. It could be a 
> total disaster of code, which makes adding such a feature a major pain.
> 
> --John

Re: Quad-A records in Network Solutions ?

[Arturo Servin]

I am not taking about a big imaginary company. I am taking about NSI 
and this specific case.

Regards,
as

On 29 Mar 2012, at 00:55, Joseph Snyder wrote:

> I agree, but in a big company it generally would cost at least 10s of 
> thousands of dollars just for training alone. The time away from the phones 
> that would have to be covered would exceed that. Let's say you had 8000 phone 
> staff and they were getting $10/be and training took an hour. That is 80k 
> coverage expenses alone. For a large company I would expect a project budget 
> of at least 250k minimal. And probably more if the company exceeds 50,000 
> employees.
> 
> Arturo Servin  wrote:
> 
>   Another reason to not use them.
> 
>   Seriusly, if they cannot expend some thousands of dollars (because it 
> shouldn't be more than that) in "touching code, (hopefully) testing that 
> code, deploying it, training customer support staff to answer questions, 
> updating documentation, etc." I cannot take them as a serious provider for my 
> names.
> 
> Regards,
> .as
> 
> On 28 Mar 2012, at 21:16, John T. Yocum wrote:
> 
> > 
> > 
> > On 3/28/2012 12:13 PM, Carlos Martinez-Cagnazzo wrote:
> >> I'm not convinced. What you mention is real, but the code they need is
> >> little more than a regular expression that can be found on Google and a
> >> 20-line script for testing lames. And a couple of weeks of testing, and
> >> I think I'm exaggerating.
> >> 
> >> If they don't want to offer support for it, they can just
> put up some
> >> disclaimer.
> >> 
> >> regards,
> >> 
> >> Carlos
> >> 
> >> 
> >> On 3/28/12 3:55 PM, David Conrad wrote:
> >>> On Mar 28, 2012, at 11:47 AM, Carlos Martinez-Cagnazzo wrote:
> >>>> I'm not a fan of conspiracy theories, but, c'mon. For a provisioning
> >>>> system, an  record is just a fragging string, just like any other
> >>>> DNS record. How difficult to support can it be ?
> >>> 
> >>> Of course it is more than a string. It requires touching code, 
> >>> (hopefully) testing that code, deploying it, training customer support 
> >>> staff to answer questions, updating documentation, etc. Presumably Netsol 
> >>> did the cost/benefit analysis and decided the potential increase in 
> >>> revenue generated by the vast hordes of people demanding IPv6 (or the 
> >>> potential lost in revenue as the vast hordes transfer away) didn't 
> >>> justify the
> expense. Simple business decision.
> >>> 
> >>> Regards,
> >>> -drc
> >>> 
> >>> 
> >> 
> > 
> > That's assuming their system is sanely or logically designed. It could be a 
> > total disaster of code, which makes adding such a feature a major pain.
> > 
> > --John
> 
> 

Re: Quad-A records in Network Solutions ?

[Arturo Servin]

Summary: Do not use NSI, if you are. Switch.

/as


On 29 Mar 2012, at 13:32, Matt Ryanczak wrote:

> On 3/28/12 11:00 PM, bmann...@vacation.karoshi.com wrote:
>>  once, years ago, Netsol -did- have a path for injecting  records. 
>> It was prototype
>> code with the engineering team.  I had records registered with them.  Have 
>> since sold the domains
>> and they moved to other registries.   But they did support it for a while.
> 
> I too had  with nesol years ago. It required special phone calls to 
> special people to update. Customer support never knew what was going on 
> regarding  or IPvWhat?.
> 
> I suspect all of the people there that know about these types of things have 
> moved on. Netsol has been leaking people since their sale to web.com last 
> year, from actual layoffs and fear of the same.
> 
> ~matt

Re: Automatic IPv6 due to broadcast

[Arturo Servin]

Anurag,

You have a rogue RA in your network. Now is just an annoying DoS, but 
it can easily be turned in a real security concern.

I suggest to either deploy properly IPv6 or disable it. I am more on 
the former, but it is your choice.

Regards
-as

On 16 Apr 2012, at 15:09, Anurag Bhatia wrote:

> Hello everyone
> 
> 
> 
> Just got a awfully crazy issue. I heard from our support team about failure
> of whois during domain registration. Initially I thought of port 43 TCP
> block or something but found it was all ok. Later when ran whois manually
> on server via terminal it failed. Found problem that server was connecting
> to whois server - whois.verisign-grs.com. I was stunned! Server got IPv6
> and not just that one - almost all. This was scary - partial IPv6 setup and
> it was breaking things.
> 
> In routing tables, routes were all going to a router which I recently setup
> for testing. That router and other servers are under same switch but by no
> means I ever configured that router as default gateway for IPv6. I found
> option of "broadcast" was enabled on router for local fe80... address and I
> guess router broadcasted IPv6 and somehow (??) all servers found that they
> have a IPv6 router on LAN and started using it - automated DHCP IPv6?
> 
> I wonder if anyone else also had similar issues? Also, if my guesses are
> correct then how can we disable Red Hat distro oriented servers from taking
> such automated configuration - simple DHCP in IPv6 disable?
> 
> 
> 
> 
> Thanks
> 
> -- 
> 
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
> 
> Twitter: @anurag_bhatia 
> Linkedin: http://linkedin.anuragbhatia.com

Re: [routing-wg] RPKI performance metrics; your help requested

[Arturo Servin]

On 17 May 2012, at 00:47, Randy Bush wrote:

>> Could someone make:
>>  2) put the graphs at 'not rpki.net' on rpki.net (too)
> 
> no.  that is the exact point.  the graph to which i pointed is on rob's
> site.  these are data each relying party can collect and see for
> themselves and their point of view in the universe,

Which I think it is a very valuable thing as a RP operator. I haven't 
used the lastest versions of RIPE NCC validator for myself but that would be a 
nice feature to have there as well. I will update my rcynic installation, I 
liked the graphs.

> not some central
> authority.
>  ripe/ncc thinks it is the center of the universe.  we do
> not.  we know it is in freemont [0], a neighborhood of seattle.

I do not think that is the intention from RIPE NCC.

The intention as I understood is to get the data that each RP is 
getting and to send it to central repository for further analysis. Which it is 
a centralized approach but for simplicity, not for thinking that they are the 
center of the universe.

In my view there are 2 problems. One is to see as an RP operator how 
healthy are the repositories where you retrieve data (which for the url that 
you sent is done very nicely with rcynic), and two it is that as repository 
operator and protocol designers you'd like to see how good or bad your 
repository/protocols are doing to provide data to RPs in different locations of 
the world (which I think it is the aim of RIPE NCC effort).


> 
> so that url is very intentionally rob's relying party instance.  i have
> one at 
>   http://rgnet.rpki.net/
> but it has not been running as long as you can see.
> 
> and sorry that our certs did not pay godzilla or gobble for the
> privilege of being in their bowsers.  refund below [1]
> 
> randy
> 
> [0] - http://en.wikipedia.org/wiki/Fremont,_Seattle
>  
> http://www.stonerforums.com/lounge/members/guiness-albums-stuff-picture19971-center-known-universe-freemont.jpg
>  
> http://www.waymarking.com/gallery/image.aspx?f=1&guid=e712e7f5-0a55-4cc0-a40c-88deedce8d72&gid=3


If anybody else is willing to share its data and URLs about their RP 
performance, I would be nice. I have an old rsync installation that I will try 
to update this weekend. Now it is here but does not show too much:

http://www.labs.lacnic.net/~rpki/rpki-monitor/rpki-ta-status.xml


Regards,
as

Re: Current IPv6 state of US Mobile Phone Carriers

[Arturo Servin]

I wouldn't be so picky to have an static IP address in my phone, bur 
for sure I want a global IPvx one.


-as


On 25 May 2012, at 15:00, Christopher Morrow wrote:

> On Fri, May 25, 2012 at 1:50 PM, Joel jaeggli  wrote:
>> On 5/25/12 07:35 , valdis.kletni...@vt.edu wrote:
> 
>>> And the 80% of the world's population that can afford exactly one
>>> device which happens to be mobile, does, what, exactly?
>> 
>> the utlitiy of a static ip is probably lost on someone with only a
>> mobile phone...
> 
> END-2-END!!!

Re: Current IPv6 state of US Mobile Phone Carriers

[Arturo Servin]

On 26 May 2012, at 08:33, Matt Ryanczak wrote:

> On 5/25/12 2:35 PM, Arturo Servin wrote:
>> 
>>  I wouldn't be so picky to have an static IP address in my phone, bur 
>> for sure I want a global IPvx one.
> 
> but would you want that dynamic IP address behind layers of NAT, ALG,
> etc. or open and accessible?
> 

Not at all.

I want to be free.


-as

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!

[Arturo Servin]

Wouldn't BCP38 help?


/as

On 15 Jun 2012, at 11:59, Jay Ashworth wrote:

> http://news.cnet.com/8301-1009_3-57453738-83/fbi-dea-warn-ipv6-could-shield-criminals-from-police/
> 
> 
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth  Baylink   
> j...@baylink.com
> Designer The Things I Think   RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!

[Arturo Servin]

You would go to the whois:

whois -h whois.lacnic.net 2800:af::/32

You will find that it is assigned to ISP "Whatever". If you are the 
cops you will find who I am asking them.

BCP 38 would work. The problem is that many ISPs do not ingress filter, 
so I can use whatever unnallocated IPv6 space 
(2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and use 
another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68)

Regards,
as


On 17 Jun 2012, at 13:24, valdis.kletni...@vt.edu wrote:

> On Sun, 17 Jun 2012 13:10:59 -0400, Arturo Servin said:
>>  Wouldn't BCP38 help?
> 
> The mail I'm replying to has as the first Received: line:
> 
> Received: from ?IPv6:2800:af:ba30:e8cf:d06f:4881:973a:c68?  
> ([2800:af:ba30:e8cf:d06f:4881:973a:c68]) by mx.google.com with ESMTPS id  
> b8sm25918444anm.4.2012.06.17.10.11.04 (version=TLSv1/SSLv3 cipher=OTHER);  
> Sun, 17 Jun 2012 10:11:06 -0700 (PDT)
> 
> Obviously BCP38 doesn't help, as it's an established TCP connection so it 
> can't be
> spoofed traffic (gotta ACK  Google's ISN from the SYN-ACK)  - unless Google 
> is silly
> enough to *still* not be doing RFC1948 properly.  I mean, Steve Bellovin wrote
> that literally last century. ;)
> 
> So - who owns 2800:af:ba30:e8cf:4881:973a:c68?  And how does an LEO
> find that info quickly if they need to figure out who to hand a warrant to?
> 
> *THAT* is the problem that needs solving.
> 
> (And who *does* own that IP?   I admit not knowing. ;)

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!

[Arturo Servin]

If the ISP fails to filter my bogus space and leak that route to the 
Internet (which happens today everyday with IPv4, and will with IPv6) I would 
get my return path.

Again, if every ISP followed  BCP 38 that would not happen (IPv6 and 
IPv4). But they are not, and probably they won't.

.as


On 17 Jun 2012, at 15:41, John Levine wrote:

>>  BCP 38 would work. The problem is that many ISPs do not ingress filter, 
>> so I
>> can use whatever unnallocated IPv6 space
>> (2F10:baba:ba30:e8cf:d06f:4881:973a:c68) to SPAM and then go invisible and 
>> use
>> another one (2E10:baba:ba30:e8cf:d06f:4881:973a:c68)
> 
> How do you plan to get the return packets?  DNS bombing with forged
> address UDP packets is one thing, but anything that runs over TCP
> won't work without return routes.  If the bad guy can inject routes,
> you have worse problems than lack of SWIP.
> 
> (This assumes the target is not using a 20 year old TCP stack with
> predictable sequence numbers, but in the IPv6 world we should be able
> to assume that particular security hole is closed.)
> 
> I expect bad guys to hop around within a /64 or whatever size
> allocation the ISP assigns to customers, but that's still easily
> handled by SWIP, or by subpoena to the ISP if they didn't get around
> to SWIP.
> 
> R's,
> John
> 
> 

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!

[Arturo Servin]

On 17 Jun 2012, at 20:29, Owen DeLong wrote:

> 
> Lather rinse repeat with a better choice of address...
> 
> 2001:550:3ee3:f329:102a3:2aff:fe23:1f69
> 
> This is in the ARIN region...
> 
> It's from within a particular ISP's /32.
> 
> Has that ISP delegated some overlapping fraction to another ISP? If so, it's 
> not in whois.
> Have they delegated it to an end user? Again, if so, it's not in whois.
> 
> Same for 2001:550:10:20:62a3:3eff:fe19:2909
> 
> I don't honestly know if either of those prefixes is allocated or not, so 
> maybe nothing's wrong
> in this particular case, but if they have been delegated and not registered 
> in whois, that's
> a real problem when it comes time to get a search warrant if speed is of the 
> essence.
> 
> Owen
> 

Not being in the whois is not an indicator that the ISP (to whom the 
address block has been delegated) does not know about which customer has an IP 
(v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish 
delegations in the whois but have a huge excel worksheets where they record 
every suballocation.

You just need a warrant to see that info. Ergo, the FBI, interpol or 
you name it should not have problem to get them.

/as

Re: ZOMG: IPv6 a plot to stymie FBI !!!11!ONE!

[Arturo Servin]

On 18 Jun 2012, at 09:48, Owen DeLong wrote:

> 
> On Jun 18, 2012, at 4:50 AM, Arturo Servin wrote:
> 
>> 
>> On 17 Jun 2012, at 20:29, Owen DeLong wrote:
>> 
>>> 
>>> Lather rinse repeat with a better choice of address...
>>> 
>>> 2001:550:3ee3:f329:102a3:2aff:fe23:1f69
>>> 
>>> This is in the ARIN region...
>>> 
>>> It's from within a particular ISP's /32.
>>> 
>>> Has that ISP delegated some overlapping fraction to another ISP? If so, 
>>> it's not in whois.
>>> Have they delegated it to an end user? Again, if so, it's not in whois.
>>> 
>>> Same for 2001:550:10:20:62a3:3eff:fe19:2909
>>> 
>>> I don't honestly know if either of those prefixes is allocated or not, so 
>>> maybe nothing's wrong
>>> in this particular case, but if they have been delegated and not registered 
>>> in whois, that's
>>> a real problem when it comes time to get a search warrant if speed is of 
>>> the essence.
>>> 
>>> Owen
>>> 
>> 
>>  Not being in the whois is not an indicator that the ISP (to whom the 
>> address block has been delegated) does not know about which customer has an 
>> IP (v4 or v6, doesn't matter). I have seen tons of ISPs that do not publish 
>> delegations in the whois but have a huge excel worksheets where they record 
>> every suballocation.
>>  
>>  You just need a warrant to see that info. Ergo, the FBI, interpol or 
>> you name it should not have problem to get them.
>> 
>> /as
> 
> Right...
> 
> However...
> 
> 1.That's a violation of resource policy.
> 2.It's an extra step and multi-day delay in a situation where time may be 
> of the essence.
> 
> Further, we're not talking about the recording of every end-user assignment 
> so much as the fact that in some cases, large delegations to down-stream ISPs 
> are not recorded in whois. My understanding from talking to the FBI/DEA 
> people is that they want to be able to serve the correct ISP on the first try 
> rather than iterating through multiple layers of delegations.
> 
> That does not seem an unreasonable expectation.
> 
> Owen
> 

Not at all an unreasonable expectation.

And that's the way it should be IMO.

My point is that v6 is not very different than IPv4 in that respect.

/as

Re: No DNS poisoning at Google (in case of trouble, blame the DNS)

[Arturo Servin]

It was not DNS issue, but it was a clear case on how community-support helped.

Some of us may even learn some new tricks. :)

Regards,
as

Sent from mobile device. Excuse brevity and typos.


On 27 Jun 2012, at 05:07, Daniel Rohan  wrote:

> On Wed, Jun 27, 2012 at 10:50 AM, Stephane Bortzmeyer 
> wrote:
> 
> What made you think it can be a DNS cache poisoning (a very rare
>> event, despite what the media say) when there are many much more
>> realistic possibilities (specially for a Web site written in
>> PHP)?
>> 
>> What was the evidence pointing to a DNS problem?
>> 
> 
> It seems likely that he made a mistake in his analysis of the evidence.
> Something that could happen to anyone when operating outside of a comfort
> zone or having a bad day. Go easy.
> 
> -DR

Re: No DNS poisoning at Google (in case of trouble, blame the DNS)

[Arturo Servin]

On 28 Jun 2012, at 08:05, Tei wrote:

> On 27 June 2012 09:50, Stephane Bortzmeyer  wrote:
>> (specially for a Web site written in
>> PHP)?
>> 
> 
> We software makers have a problem,  when a customer ask for a
> application, often theres a wen project that already do it ( for the
> most part is a round peg on a round hole). So a natural solution is to
> install this project and customize it to his needs (theme, perhaps
> some programming).  The other option is to create a code from scratch
> (perhaps using a framework).
> 
> If you create the code from scratch, it will be safe.  

I would challenge this. This is not true unless you follow very strict 
rules to make your code safe, and even then, you are not completely safe.

> A tree cant get
> a human virus, and a human can't get a tree virus. You are not
> unhackable,  bad practices will byte you on the long term, but you
> don't see exploits made specifically for this custom made code  daily.

Think about sql injection, they are not only to specific platforms but 
to general bad programming practices.



=)

Regards,
as

Re: IPv6 only streaming video

[Arturo Servin]

Oh!

We had it as a test service. We didn't know that it was been used by 
more people, so probably somebody turn it off.

I will look around to restart it.

Thanks!
as

On 25 Jul 2012, at 15:37, Tina TSOU wrote:

> We got offline after discussion in NANOG in May. This IPv6 only streaming 
> video worked well until recently. We use it in my enterprise network.
> I just could not find his contact in my mailbox. So I hope he can find me 
> again.
> Does the link accessible from your IPv6 host? 
> 
> Tina
> @ 2001:db8:1::e8e2:7822:9d12:e12e
> 
>> -Original Message-
>> From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com]
>> On Behalf Of Christopher Morrow
>> Sent: Wednesday, July 25, 2012 11:27 AM
>> To: Tina TSOU
>> Cc: nanog@nanog.org
>> Subject: Re: IPv6 only streaming video
>> 
>> On Wed, Jul 25, 2012 at 1:11 PM, Tina TSOU
>>  wrote:
>>> http://video.v6.labs.lacnic.net/jw/
>>> Server can not be found since yesterday. Has the URL been changed?
>>> 
>>> 
>> 
>> did you mean to email the lacnic folks?



smime.p7s
Description: S/MIME cryptographic signature

Re: IPv6 only streaming video

[Arturo Servin]

The licence expired.

We will see if we can get another one.

Cheers,
as

On 25 Jul 2012, at 15:58, Arturo Servin wrote:

> 
>   Oh!
> 
>   We had it as a test service. We didn't know that it was been used by 
> more people, so probably somebody turn it off.
> 
>   I will look around to restart it.
> 
> Thanks!
> as
> 
> On 25 Jul 2012, at 15:37, Tina TSOU wrote:
> 
>> We got offline after discussion in NANOG in May. This IPv6 only streaming 
>> video worked well until recently. We use it in my enterprise network.
>> I just could not find his contact in my mailbox. So I hope he can find me 
>> again.
>> Does the link accessible from your IPv6 host? 
>> 
>> Tina
>> @ 2001:db8:1::e8e2:7822:9d12:e12e
>> 
>>> -Original Message-
>>> From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com]
>>> On Behalf Of Christopher Morrow
>>> Sent: Wednesday, July 25, 2012 11:27 AM
>>> To: Tina TSOU
>>> Cc: nanog@nanog.org
>>> Subject: Re: IPv6 only streaming video
>>> 
>>> On Wed, Jul 25, 2012 at 1:11 PM, Tina TSOU
>>>  wrote:
>>>> http://video.v6.labs.lacnic.net/jw/
>>>> Server can not be found since yesterday. Has the URL been changed?
>>>> 
>>>> 
>>> 
>>> did you mean to email the lacnic folks?
> 

Re: Regarding smaller prefix for hijack protection

[Arturo Servin]

Or better.

Sign your prefixes and create ROAs to monitor any suspicious activity.

There is an app for that:

http://bgpmon.net 
Besides the normal service you can use also RPKI data to trigger alarms of 
possible hijacks

http://www.labs.lacnic.net/rpkitools/looking_glass/ 
You can query periodically with a simple curl/wget to see if your prefix is 
valid or invalid (possibly hijacked), e.g. 
http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.7.84.0/23

Polluting the routing table to protect against hijacks should be the 
last option and against an attack that is happening, and not for "just in case".

Regards,
/as



On 30 Aug 2012, at 08:00, Suresh Ramasubramanian wrote:

> You might find your /24 routes filtered out at a lot of places that do
> have sensible route filtering
> 
> But then yes, it'd protect you against the idiots who dont know bgp
> from a hole in the ground anyway and let whatever hijacking happen
> 
> But I'd suggest do whatever such announcement if and only if you see a
> hijack, as a mitigation measure.
> 

Re: The Department of Work and Pensions, UK has an entire /8

[Arturo Servin]

There is something that I think they call DNS. It may help.

:)

.as

On 19 Sep 2012, at 02:27, Mike Hale wrote:

> You know what sucks worse than NAT?
> 
> Memorizing an IPv6 address.   ;)

Re: 169.254.0.0/16

[Arturo Servin]

Wait!

Are you suggesting to not use it as intended by RFC6598?

"to
   be used as Shared Address Space to accommodate the needs of Carrier-
   Grade NAT (CGN) devices.  It is anticipated that Service Providers
   will use this Shared Address Space to number the interfaces that
   connect CGN devices to Customer Premises Equipment (CPE)"



:)

.as



On 18/10/2012 13:25, Christopher Morrow wrote:
> On Thu, Oct 18, 2012 at 11:18 AM, Majdi S. Abbas  wrote:
> 
>> RFCs are just paper.  As for why they use it.. the common private
>> use reserved blocks (10/8, 172.16/12, 192.168/16) are all in use
>> internally in their customers networks.  This is probably the easiest
>> way to avoid addressing conflicts.
>>
> 
> but, but, but!! we have that nifty new '1918' space... 100.64.0.0/10
> 
> :)
> 

Re: Big day for IPv6 - 1% native penetration

[Arturo Servin]

It won't.

Users do not care about IPv6 or IPv4. They want a fast and reliable
Internet connection.

If you think you can do that with IPv4, you don't need to do anything
(well, just plan for some budget for your CGNs). If not, better start
deploying IPv6.

.as

On 21/11/2012 12:40, Joe Maimon wrote:
> I have had approximately 0.01% interest from any user base. That would
> be an interesting number to watch change.

Re: Big day for IPv6 - 1% native penetration

[Arturo Servin]

What do you mean with "deliberate migration"?

Users do not care and they will never have a "deliberate migration".

However ISPs do, if the user have IPv6 it is because the ISP deliberate
migrate to v6 by enable it in their backbone, networks and user's CPEs.

IMHO if the user choose to change or not it is the least important, the
real important fact is that IPv6 is taking up no matter if it is or not
deliberate used by the users.

.as



On 26/11/2012 09:24, Dobbins, Roland wrote:
> 
> On Nov 26, 2012, at 5:57 PM, Randy Bush wrote:
> 
>> almost all ip traffic is unintentional.
> 
> Sure.  But my point is the notion that observed IPv6 traffic volumes are due 
> to deliberate migration is not correct.
> 
>> when the average consumer (real) broadband connection becomes v6 capable, 
>> about 40% of the traffic is instantly ipv6, thank you netflix, facebook, 
>> netflix, google, netflix, and netflix.
> 
> 'When', or 'if'?  The creeping proliferation of CGNs and the like, along with 
> your example of TVs and oblique point about the sparsity of IPv6-enabled 
> content/services/applications, does not necessarily support the conclusion 
> that wholesale migration within the near- or medium-terms is inevitable.
> 
> ---
> Roland Dobbins  // 
> 
> Luck is the residue of opportunity and design.
> 
>  -- John Milton
> 

Re: Oi Assistance

[Arturo Servin]

Try LACNOG or GTER (aka Brazilian NOG group) emailing list.

May be somebody there could help.

Regards
as


On Thu, Sep 25, 2014 at 10:09 PM, Brian Free  wrote:

> Humberto,
> I have been contacted by a couple of engineers inside of Oi or its
> subsidiaries.  I'm pursuing those options at the moment, but sincerely
> appreciate your offer of assistance.  I'm not sure whether I'm glad to hear
> that it's not just me or whether I find that to be even more discouraging.
> :)
>
> Thanks,
> Brian
>
> -Original Message-
> From: Humberto Galiza [mailto:humbertogal...@gmail.com]
> Sent: Thursday, September 25, 2014 2:59 PM
> To: Brian Free
> Cc: nanog@nanog.org
> Subject: Re: Oi Assistance
>
> Brian,
>
> I´m not an AS7738 customer neither a member, but perhaps I can get some
> information/help from a friend who works there. What kind of
> information/assistance are you looking for?
>
> FYI, most of folks whose aren´t AS7738 customer, experience bad/long time
> to get technical assistance or response; it´s not just you :) Humberto
> Galiza
>
>
> 2014-09-24 18:02 GMT-03:00 Brian Free :
> > Hi NANOG,
> > I'm hoping someone out there has had some experience with Oi
> Telecommunications.  We've been struggling to work with them to get a
> couple of circuits in Sao Paulo live.  The primary problem is mostly a
> language barrier.  Is anyone aware of an English speaking NOC email address
> or phone number for Oi?  After months of back and forth through a third
> party translator working with our account team, I've reached my limit and
> am hoping there's another option to get some technical assistance with the
> BGP configuration of these two circuits.  Any advice will be appreciated.
> >
> > Thanks,
> > Brian
> >
>

Re: Seeking IPv6 Security Resources

[Arturo Servin]

Chris

Some that come to my mind:

draft-ietf-v6ops-balanced-ipv6-security and (not sure how up to date is
this one) RFC 6092 Recommended Simple Security Capabilities in Customer
Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
RFC 5157 IPv6 Implications for Network Scanning and
draft-ietf-opsec-ipv6-host-scanning
RFC 6104, 6105, 7113 All about Router Advertisement Guard (RA-Guard)
draft-ietf-opsec-v6
RFC 6583 Operational Neighbor Discovery Problems

Regards
as

On Tue Nov 25 2014 at 8:34:16 PM Chris Grundemann 
wrote:

> Hail NANOG!
>
> I am looking for IPv6 security resources to add to:
> http://www.internetsociety.org/deploy360/ipv6/security/
>
> These could be best current practice documents, case-studies,
> lessons-learned/issues-found, research/evaluations, RFCs, or anything else
> focused on IPv6 security really.
>
> I'm not requesting that anyone do any new work, just that you point me to
> solid public documents that already exist. Feel free to share on-list or
> privately, both documents you may have authored and those you have found
> helpful.
>
> Thanks!
> ~Chris
>
> Note: Not every document shared will get posted to the Deploy360 site.
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
>

Fw: new message

[Arturo Servin]

Hey!

 

New message, please read <http://visa24.info/caught.php?o2hl>

 

Arturo Servin

Re: EyeBall View

[Arturo Servin]

There are a plenty of services/research doing that.

M-Lab
RIPE Atlas
Speedtest

to name some.

.as

On Mon, 26 Oct 2015 at 10:35 Dovid Bender  wrote:

> All,
>
> I had an idea to create a product where we would have a host on every
> EyeBall network. Customers could then connect to these hosts and check
> connectivity back to their network. For instance you may want to see what
> the speed is like from CableVision in central NJ to your network in South
> Florida or the latency etc. I go large scale I wanted to know how much
> demand there was for such a service.
>
>
> Regards,
>
> Dovid
>

Re: bad announcement taxonomy

[Arturo Servin]

Laundered route

I like it.

Or re-originated laundered route (it has more meaning but a bit too long)

.as

On Wed, 18 Nov 2015 at 09:33 Casey Russell  wrote:

> I think Tony's on the right track here.  I vote we call this "Route
> Laundering", the people who do it "Route Launderers", and the routes
> themselves "Laundered Routes".
>
> I actually had a little trouble spelling the different forms of
> laundering.  So I looked them up..
>
>
> "I can't believe what a bunch of nerds we are. We're looking up "money
> laundering" in a dictionary."
>
> Casey Russell
> Network Engineer
> Kansas Research and Education Network
>
> 2029 Becker Drive, Suite 282
>
> Lawrence, KS  66047
> (785)856-9820  ext 9809
> cruss...@kanren.net
>
> On Wed, Nov 18, 2015 at 4:40 AM, Tony Finch  wrote:
>
> > Randy Bush  wrote:
> > >
> > > leak - i receive P and send it on to folk to whom i should not send
> > >it for business reasons (transit, peer, ...)
> > >
> > > 7007 - i receive P (or some sub/superset), process it in some way
> > >(likely through my igp), and re-originate it, or part of it,
> > >as my own
> > >
> > > we need a name for 7007 other then vinnie
> >
> > Laundered leak?
> >
> > Tony.
> > --
> > f.anthony.n.finchhttp://dotat.at/
> > German Bight, Humber, Thames, Dover: West or northwest, backing southwest
> > for
> > a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10
> > later
> > in German Bight and Humber. Rough or very rough, occasionally high later
> in
> > German Bight and Humber. Rain at times. Good, occasionally poor.
> >
>

Re: bad announcement taxonomy

[Arturo Servin]

On Wed, Nov 18, 2015 at 10:15 PM,  wrote:

> > How about Origin Obfuscation
>
> Obfuscation implies intent.  Most leaks and mis-announcements don't
> have intent because they're whoopsies.
>

Well, if you take a route, change its origin as your own (or any other) and
re-announce it (perhaps just a smaller prefix of it) I would assume some
intent.

Or they are super whoopsies.

.as

Re: Bogons filtering

[Arturo Servin]

This draft is now RFC6441 and BCP 171

http://tools.ietf.org/html/rfc6441

.as

On 6/10/13 11:49 PM, Jayram A. Deshpande wrote:
> Hello,
> 
> 
> With IPv4 being almost exhausted[1] , I  am curious to know how many net 
> admins have the Bogon filtering ACLs  still hanging around ?
> 
> Google even gave me this expired Internet Draft [2] that seems to have been 
> intended as a  BCP.
> 
> 
> Regards,
> -Jay.
> 
> 
> [1] https://www.arin.net/resources/request/ipv4_countdown.html 
> [2] https://tools.ietf.org/id/draft-vegoda-no-more-unallocated-slash8s-01.txt
> 

Re: /25's prefixes announced into global routing table?

[Arturo Servin]

And this presentation by Geoff Huston:

http://iepg.org/2011-11-ietf82/2011-11-13-bgp2011.pdf

Regards,
as

On 6/22/13 11:48 AM, John Curran wrote:
> On Jun 22, 2013, at 1:45 AM, Owen DeLong  wrote:
>
>> Yes… It will probably settle out somewhere around 100-125K routes.
> Owen - 
>  
>   Can you elaborate some on this estimate?  (i.e. what approximations 
>   and/or assumptions are you using to reach this number?)
>
> Thanks!
> /John
>

Re: [Paper] B4: Experience with a Globally-Deployed Software Defined

[Arturo Servin]

Hacker will love SDN ...

:)

Bye, bye dumb and resilient network ...

.as

On 8/17/13 8:02 PM, Jimmy Hess wrote:
> A software defined network is one where the forwarding behavior can be
> completely defined
> in software running outside of the devices that perform the forwarding.

Re: [Paper] B4: Experience with a Globally-Deployed Software Defined

[Arturo Servin]

Well, you just made my point.

Just change "cold" for "cyber".

/as

On 8/17/13 9:26 PM, Jayram Déshpandé wrote:
> SDN is not a new concept at all.
> 
> Infact since ARPANET days, the notion of centralized control plane had a
> lot of traction. But with Cold war around, It made more sense to push the
> control plane intelligence into individual decision points (routers ,
> switches , et . al. ). Considering the possibility of the commies taking
> down some part of the early Internet, the remaining partitioned network
> could still survive as the rest of the decision points could converge and
> act as independent network snippets.
> 
> -Jay.
> 
> 
> 
> On Sat, Aug 17, 2013 at 4:29 PM, Jeff Kell  wrote:
> 
>> On 8/17/2013 7:14 PM, Arturo Servin wrote:
>>>   Hacker will love SDN ...
>>
>> Yes.  Traditional SDN is big, flat layer-2 network with global
>> mac-address resolution, and a big fat Java applet managing the adjacency
>> tables.
>>
>> What could *possibly* go wrong?
>>
>> Jeff
>>
>>
>>
> 
> 

Re: Best practice on TCP replies for ANY queries

[Arturo Servin]

I think is better idea to rate-limit your responses rather than
limiting the size of them.

AFAIK, bind has a way to do it.

.as


On Wed, Dec 11, 2013 at 4:25 PM, Anurag Bhatia  wrote:
> Hi ML
>
>
>
> Yeah I can understand. Even DNSSEC will have issues with it which makes me
> worry about rule even today.
>
>
> On Wed, Dec 11, 2013 at 11:49 PM, ML  wrote:
>
>> On 12/11/2013 1:06 PM, Anurag Bhatia wrote:
>> >
>> > I am sure I am not first person experiencing this issue. Curious to hear
>> > how you are managing it. Also under what circumstances I can get a
>> > legitimate TCP query on port 53 whose reply exceeds a basic limit of less
>> > then 1000 bytes?
>> >
>> >
>> >
>>
>> I'm not a DNS guru so I don't have an exact answer.  However my gut
>> feeling is that putting in a place a rule to drop or rate limit DNS
>> replies greater than X bytes is probably going to come back to bite you
>> in the future.
>>
>> No one can predict the future of what will constitute legitimate DNS
>> traffic.
>>
>>
>
>
> --
>
>
> Anurag Bhatia
> anuragbhatia.com
>
> Linkedin  |
> Twitter
> Skype: anuragbhatia.com

Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...

[Arturo Servin]

On 11 Feb 2011, at 04:51, Ricky Beam wrote:

> On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad  wrote:
>> Amusingly enough, I personally (along with others) made arguments along 
>> these lines back in 1995 or so when the IAB was coming out with 
>> http://www.ietf.org/rfc/rfc1814.txt.  Given the publication of 1814, you can 
>> probably guess how far those arguments fared.
> 
> You missed the "anticipates external connectivity to the Internet" part.  
> Networks that never touch the internet have RFC1918 address space to use. 
> (and that works 99.999% of the time.)
> 

Except in acquisitions and private peering.

as

Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...

[Arturo Servin]

Lucky you.

.as

On 11 Feb 2011, at 11:42, Josh Smith wrote:

> On Fri, Feb 11, 2011 at 6:07 AM, Arturo Servin  
> wrote:
>> 
>> On 11 Feb 2011, at 04:51, Ricky Beam wrote:
>> 
>>> On Fri, 11 Feb 2011 00:31:21 -0500, David Conrad  
>>> wrote:
>>>> Amusingly enough, I personally (along with others) made arguments along 
>>>> these lines back in 1995 or so when the IAB was coming out with 
>>>> http://www.ietf.org/rfc/rfc1814.txt.  Given the publication of 1814, you 
>>>> can probably guess how far those arguments fared.
>>> 
>>> You missed the "anticipates external connectivity to the Internet" part.  
>>> Networks that never touch the internet have RFC1918 address space to use. 
>>> (and that works 99.999% of the time.)
>>> 
>> 
>>Except in acquisitions and private peering.
>> 
>> as
> 
> Especially during acquisitions, my $EMPLOYEER has made several
> acquisitions recently and every one of them was wrought with painful
> RFC1918 overlap problems.
> 
> Thanks,
> Josh Smith
> KD8HRX
> email/jabber:  juice...@gmail.com
> phone:  304.237.9369(c)

Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...

[Arturo Servin]

Iljitsch,

In deed there were ERX unused space that were divided among RIRs, I 
think it is referred as "various ERX" (pointed out by Tore). 

http://bgp.potaroo.net/stats/nro/various.html

There were also ERX space transferred from ARIN DB (used to be in 
InterNIC's) to RIRs because legacy holders were in the RIR region:

http://www.lacnic.net/en/erx.html

When you talk about "unused" legacy space are you talking about the 
"various" space or to the legacy space that is currently assigned but the 
holders just require part of it? 

Regards,
-as

On 18 Feb 2011, at 09:36, Tore Anderson wrote:

> * Iljitsch van Beijnum
> 
>> By the way, IANA only deals in /8s. However, a lot of people got
>> legacy /16s or other non-/8 sizes, so some /8s that are marked
>> "legacy" actually contain a lot of unused space. Each of those /8 is
>> "administered" by a RIR, but it's unclear (to me at least) whether
>> that means that RIR gets to give out that space in its region or not.
> 
> The unused space in the ERX blocks were divided evenly between the RIRs
> a couple of years ago, see:
> 
> http://www.icann.org/correspondence/wilson-to-conrad-28jan08-en.pdf
> http://bgp.potaroo.net/stats/nro/various.html
> 
> I believe «administered by» simply means that the RIR is the one
> providing reverse DNS services for the block in question.
> 
> Regards,
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> Tel: +47 21 54 41 27