August 2012 - Test - lists.nanog.org

RE: raging bulls
by Naslund, Steve 08 Aug '12

08 Aug '12

Are there not mechanisms to handle replay attacks? There is also the minor matter of fraud and regulatory concerns. You might get away with it a few times but not often enough to avoid a potential death penalty of being disconnected. Steve -----Original Message----- From: Alexandre Snarskii [mailto:snar@snar.spb.ru] Sent: Wednesday, August 08, 2012 9:46 AM To: Naslund, Steve Cc: Alexandre Snarskii Subject: Re: raging bulls On Wed, Aug 08, 2012 at 09:08:18AM -0500, Naslund, Steve wrote: > Also, we are only talking about a delay long enough to satisfy the > longest circuit so you could not push your timestamp very far back and > would have to get the fake one done pretty quickly in order for it to > be worthwhile. The real question is could you fake a cryptographic > timestamp fast enough to actually gain time on the system. Possibly > but it would be a very tall order. Looks like replay attack works here: "attacker" can easily record encrypted timestamps and reuse them some milliseconds later, claiming "I had no knowledge on how market changed during this time, it's my provider had to re-route my traffic!!" > > Steve > > -----Original Message----- > From: Chu, Yi [NTK] [mailto:Yi.Chu@sprint.com] > Sent: Wednesday, August 08, 2012 9:01 AM > To: Naslund, Steve; nanog(a)nanog.org > Subject: RE: raging bulls > > What prevents someone to fake an earlier timestamp? Money can bend > light, sure can a few msec. > > yi > > -----Original Message----- > From: Naslund, Steve [mailto:SNaslund@medline.com] > Sent: Wednesday, August 08, 2012 9:53 AM > To: nanog(a)nanog.org > Subject: RE: raging bulls > > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. > It would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then > take them in order. They could certainly use less expensive > connections and ensure that international traders get a fair shake. > > Steven Naslund > > -- In theory, there is no difference between theory and practice. But, in practice, there is.

1 0

RE: raging bulls
by Ryan Malayter 08 Aug '12

08 Aug '12

"Naslund, Steve" <SNaslund () medline com> wrote: > It seems to me that all the markets have been doing this the wrong way. > Would it now be more fair to use some kind of signed timestamp and > process all transactions in the order that they originated? Perhaps > each trade could have a signed GPS tag with the absolute time on it. It > would keep everyone's trades in order no matter how latent their > connection to the market was. All you would have to do is introduce a > couple of seconds delay to account for the longest circuit and then take > them in order. They could certainly use less expensive connections and > ensure that international traders get a fair shake. I can't see any incentive for any *influential* party involved (the big firms or the exchanges) to make the process "fair". The exchange gets more money for low-latency network access and expensive co-location. The moneyed firms with HFT capability of course do not want anyone else to have their advantage. Even governments don't want long-distance traders to have "fair" access, as that reduces the advantage of local tax-paying firms, thereby reducing tax revenue, jobs, etc. HFT is not just a US phenomenon; all major exchanges have basically the same sort of phenomenon. So UK-based trading firms with HFT setups very close to the FTSE exchanges have advantage over US-based firms that don't have HFT setups in London. -- RPM

1 0

RE: Wanted: Asia bandwidth test files
by David Wilde 07 Aug '12

07 Aug '12

Hi Micah, > From: micah anderson [mailto:micah@riseup.net] > > Thanks for the suggestion. Do you know what their bandwidth is? I can > easily pull a .iso or similar from there to do some tests. > There's some info at http://mirror.aarnet.edu.au/indexabout.html - it's connected at 10Gbps. Naturally what throughput you're able to get will depend on how you arrive on the AARNet network - there is unfortunately less bandwidth into the west of Australia from Asia is than there is into the east coast from the United States. David

1 0

Prefix Size Distribution in multiple flavors, on RIPEstat
by Vesna Manojlovic 07 Aug '12

07 Aug '12

Dear colleagues, thanks to the feedback we received after we've published the interactive widget for querying "RIR prefix size distribution" in RIPEstat, we created a follow-up: a dynamically updated web page that gives an overview of IPv4 address space prefix size distribution, per /8: https://stat.ripe.net/specials/registered-ipv4-prefix-size-distribution This page is updated once a day, and is based on statistics published by all 5 RIRs. Possible usage is general research about the distribution of address space, or prefix filtering based on minimum allocation size. If you want to query any other prefix size, and not only /8, or if you want to query for IPv6 space, here is the link to the widget: https://stat.ripe.net/widget/rir-prefix-size-distribution For the background, please find more information in RIPE Labs article about the widget: https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat Looking forward to your comments or questions, regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net

1 0

IPv6 Toolkit v1.2.2 released
by Fernando Gont 07 Aug '12

07 Aug '12

Folks, We've released IPv6 toolkit version 1.2.2. It is available at: <http://www.si6networks.com/tools> (tarball and git repository). This version is meant to be fully-portable to Mac OS (the list of supported systems now including, at the very least, FreeBSD, NetBSD, OpenBSD, Linux, and Mac OS), and also incorporates a number of patches send by the community. Any feedback on the tools will be welcome (either unicast to me, or on the ipv6hackers mailing-list <http://lists.si6networks.com/listinfo/ipv6hackers/>). P.S.: If you've sent patches and your patches have not yet been applied, most likely it just means that I'm catching-up with them (feel free to resend!). Thanks! Best regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0

Cisco 7200 PCI Limitations
by shthead 07 Aug '12

07 Aug '12

Hi all, I have a 7200 series router (7204) here and I am trying to figure out something with it. Currently the router has a NPE-G1 card in it, giving it 3 gig interfaces but I need an extra gig interface on it to make 4. Having a look around the available options are either get a PA-GE card that fits into one of the slots on the router or to get a C7200-I/O-GE+E (I/O controller with a gbit port on it). The PA-GE wouldn't be suitable as looking at the Cisco site the PCI bus will limit it to 300mbit full duplex (and it goes on further to say it will be limited to approx 200mbit in best case scenario due to the design of the card) [1]. The other option left is the I/O controller. I found that you can get a port adaptor jacket card [2] for the 7200's that let you stick a normal interface card into the I/O controller slot (instead of the I/O controller itself). My main concern is if the jacket card uses its own PCI bus I am assuming the C7200-I/O-GE+E also connects via PCI which means it would be subject to the same limitations as the PA-GE. Does anyone have any idea if that would be correct and the only option for another gbit port would be to get another device? Thanks for the help [1] http://www.cisco.com/en/US/products/hw/routers/ps341/products_tech_note0918… [2] http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd80…

6 6

Wanted: Asia bandwidth test files
by Micah Anderson 07 Aug '12

07 Aug '12

Hi, I'm sitting on what is advertised as a 100mbit/sec connection in Cambodia. I have been trying to verify that, because I do not believe it is valid. I did iperf tests from a number of network locations, and at one point I did get 71mbit/sec (most of the results were around 20-25mbit/sec or less). But I dont think 30 second iperf tests are particularly revealing when the bandwith rate might change drastically over the day. I considered doing a 3 day iperf test, but somehow this seems not how the tool was designed. Someone suggested I find test files from various Asian locations to download via wget. I found a bunch of 100mb test files for various providers in N. America and Europe on webhostingtalk, which were interesting, but I never got more than around 5mbit/sec with them. Does anyone have any machines in Japan, S. Korea, or other asian locations with good bandwidth. where they can host a 100mbit file so I can attempt to download it to test this? Other suggestions for reliable tests would also be welcome! Please, dont suggest some flash garbage :) thanks! micah --

7 6

Re: Verizon FiOS - is BGP an option?
by William Herrin 06 Aug '12

06 Aug '12

On Sat, Aug 4, 2012 at 6:50 PM, Andy Koch <gawul00(a)gmail.com> wrote: > On Aug 4, 2012, at 11:56, William Herrin <bill(a)herrin.us> wrote: >> 100 miles isn't a serious logistics problem with 500 gallons of fuel >> tank in the bed of a pickup truck. That buys you 8-12 hours for 100 >> fiber huts with $500 gasoline generators before you send the next crew >> for more. > > Your expectations are way off here. With a 100 mile drive, even > if that is round trip mileage, you can expect that trip to exceed > 5 hours not including waiting in line to fuel up. Then when you > return, distribution can take well over 3 hours, meaning that > some locations will not get refueled before they run out. Then one group is on the gas run, fetching 500 gallons to a staging location while another group is on genset runs, topping the tanks of with the fetched gas. Or hey, if you're prepared then you have a contract in place with an oil company to divert one of the 9,000 gallon tank trucks from the non-functional local gas stations to your local distribution site. Then base your genset fueling runs from there. Few thousand bucks ahead of time to set up a box at the edge of one of your parking lots that can connect to the tanker's standard hose and pump gas. >> Hell, local Verizon couldn't even keep the 911 center online. Both it >> and its backup collapsed. > >So, rather than focus on repairing 911, you want these technicians >to drive for hours and distribute gasoline to keep your home data >service running? The E911 facility was supposed to be five nines. You don't get five nines with a focus on repair, you get it with prevention. This year Verizon'll achieve two nines. That's shameful. Shameful! I don't expect five nines from my residential Internet service. But I think two nines on the last mile cable and three nines on the aggregation system is a reasonable expectation for a primary first-world suburban communications service. It wasn't achieved. > Does the spider web of cables include power distribution? > If not, why the exception? If so, why not ostracize them > for failing to keep power to the "critical infrastructure" > in your neighborhood? Dominion can't seem to keep my local substation powered. Not my house per se, but the substation serving 611 power customers. They've missed 3 nines for at least 6 of the last 10 years without a single tree over the lines between me and the substation. And that's the last I'm going to say about it here because this isn't a forum for discussing the power companies' operational failures. It is, however, a forum for discussing network providers' operational failures. On Sat, Aug 4, 2012 at 10:26 PM, Nathan Eisenberg <nathan(a)atlasnetworks.us> wrote: >> Residences aren't critical infrastructure, no matter how angry the owners get. > > 911 access isn't a critical service? Fire and security panels aren't critical services? > If basic life safety and property protection aren't critical services, I'm not sure what is. Whether each individual's residence contains critical infrastructure is a decision best left up to that individual. By necessity that makes the upstream aggregation components critical infrastructure. No different than it was for POTS 20 years ago. The Internet isn't just a toy any more. It's the primary communications channel in to many folks homes and well on its way to becoming the primary channel period. Regards, Bill Herrin -- William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

4 6

IETF contacts? - Fwd: Reference to historic or obsolated RFCs
by Livio Zanol Puppim 06 Aug '12

06 Aug '12

Hello guys, I've sent the e-mail below to IETF, but I couldn't find a contact e-mail to address this kind of subject in IETF site. Does anybody knows which e-mail to send this? The contact page from IETF website: http://www.ietf.org/contact-the-ietf.html ---------- Forwarded message ---------- From: Livio Zanol Puppim <livio.zanol.puppim(a)gmail.com> Date: 2012/8/6 Subject: Reference to historic or obsolated RFCs To: ietf-info(a)ietf.org, ietf-action(a)ietf.org Hello, I don't know which contact to send this e-mail, so I'm copying the INFO and ACTION e-mail... If these are the wrong contact, can you please point me the correct e-mail? Reading the *RFC 5375* I've found references to some RFCs that are considered Historic, or have been updated. In some cases, this can lead to a misunderstand of a a section in a RFC. For example: The* RFC 5375* in section *B.2.2* states that we should avoid using /127 IPv6 prefix, but* RFC 6164* clearly says that we can use /127 prefix for Inter-Router links. In fact, the *RFC 6547*, moves the *RFC 3627*(referenced by the * RFC 5375* in the above section) to Historic status. If my point of view is indeed correct, I think that everytime a new RFC is published that proposes an *Update* to another RFC, or *Obsoletes* another RFC or moves a RFC to *Historic *status, the team responsible for it's creation needs to read every reference to that RFC and request changes in order to avoid this kind of misunderstanding. This is very important to guys like me, that only reads the RFCs. the section from RFC 5375 http://tools.ietf.org/html/rfc5375#appendix-B.2.2 " B.2.2 <http://tools.ietf.org/html/rfc5375#appendix-B.2.2>. /127 Addresses The usage of the /127 addresses, the equivalent of IPv4's RFC 3021 <http://tools.ietf.org/html/rfc3021> [RFC3021 <http://tools.ietf.org/html/rfc3021>], is not valid and should be strongly discouraged as documented in RFC 3627 <http://tools.ietf.org/html/rfc3627> [RFC3627 <http://tools.ietf.org/html/rfc3627>]. " -- []'s Lívio Zanol Puppim -- []'s Lívio Zanol Puppim

3 3

IPv6 End User Fee
by Otis L. Surratt, Jr. 06 Aug '12

06 Aug '12

Anyone charging end users for IPv6 space yet? :p Just wondering, with so many IPv6 resources in a single allocation it would seem difficult to charge anything at all. 1. How are you making up loss of revenue on IPv4 assignments? 2. Are you charging anything? 3. Is the cost built into the service? 4. Do you assign IPv6 space to end user and charge admin fee? Take care, Otis

15 27