Re: using reserved IPv6 space
On (2012-07-19 10:25 +1000), Mark Andrews wrote: The point of the algorithm was to have something which would do a reasonable job in a CPE router without a hardware source of randomness. In that context it very much makes sense. It is a SAMPLE routinue. It is not YOU MUST DO IT THIS WAY OR ELSE. Anything that meets the requirements of RFC 4086 is fine. /dev/random on by laptop meets the requirements of RFC 4086. I Good to know, earlier in this thread, when fully 40b random (method I've been also using, which I've always thought to be superior to RFC) was suggested, it was met with cold shoulder 'does not follow RFC4086 ... do not use'. I guess I'll keep on using my 40b random instead of 'exactly RFC', and keep verifiability in wish-list. -- ++ytti
Re: using reserved IPv6 space
On (2012-07-19 15:16 +1000), Karl Auer wrote: True. But you cannot tell, from a sample of one number, whether that number was chosen randomly. You can only test it statistically within a series. A particular number may be random in one sequence, non-random in another. RFC2777 deals with this problem to a degree. If you define algorithm and define how to choose seed, then you can later verify that this particular algorithm was used to generate the number. -- ++ytti
Re: Another LTE network turns up as IPv4-only squat space + NAT
Subject: RE: Another LTE network turns up as IPv4-only squat space + NAT Date: Wed, Jul 18, 2012 at 10:36:31PM -0400 Quoting Chuck Church (chuckchu...@gmail.com): I disagree. I see it as an extra layer of security. If DOD had a network with address space 'X', obviously it's not advertised to the outside. It never interacts with public network. Having it duplicated on the outside world adds an extra layer of complexity to a hacker trying to access it. It's not a be-all/end-all, but it's a plus. A hacker who's partially in the network may try to access network 'X', but it routes to the outside world, tripping IDSs... Then DoD should go for using something like the v6 documentation prefix or similar. It both is in many peoples filters and (as referenced here recently) is being used for stuff that never (promise! or at least not until we change our minds) is going to need connectivity. I do not see DoD handing back its allocations in the name of promoting unreachability by swapping it for reusable space.. It probably values the uniqueness property of allocated space too much. And rightly so. No, reusing somebody's prefix is A Very Bad Idea. I'm having a very hard time believing the alleged ok is anything but cheap talk. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The Osmonds! You are all Osmonds!! Throwing up on a freeway at dawn!!! signature.asc Description: Digital signature
Re: Another LTE network turns up as IPv4-only squat space + NAT
On Wed, Jul 18, 2012 at 10:36:31PM -0400, Chuck Church wrote: I disagree. I see it as an extra layer of security. If DOD had a network with address space 'X', obviously it's not advertised to the outside. It never interacts with public network. Having it duplicated on the outside --- world adds an extra layer of complexity to a hacker trying to access it. It's not a be-all/end-all, but it's a plus. A hacker who's partially in the network may try to access network 'X', but it routes to the outside world, tripping IDSs... Chuck Never is a -very- long time. That said, -IF- DoD did authorize another party/contractor to utilize some DoD address blocks, its not clear if that LOA would be public. /bill
Re: using reserved IPv6 space
In message caaawwbxh1ws_9ax4fwgrqmsbjmkgj0nwhri9en53htl36vh...@mail.gmail.com , Jimmy Hess writes: On 7/18/12, Karl Auer ka...@biplane.com.au wrote: I don't understand the professed need for provable randomness. Without a number *space* to provide context, randomness is inherently non-provable. The whole point of the randomness of those 40 bits of ULA infix is that any number is as likely as any other number. Someone, When numbers are selected by choosing a random value; certain ratios of bits set to 1 are more likely to occur than other ratios of bits set to 1. A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example. Actually you can't. fdaa:: has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. The ratio of the number of bits doesn't tell you anything about whether the number was random or not. Removing the temptation by excluding the small number of choices with 90% - 95% of the bits set to 1 may eliminate future problems caused by an early accident/error in assigning the initial ULA, compared to the minor inconvenience of needing to run the ULA generator one more time to get an actual usable range. somewhere, is eventually going to get 10::, someone else will eventually get 20:: and so on. And they are just as likely to get them now as in ten years time. That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two. improbable != impossible -- -JH -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: using reserved IPv6 space
If i may summarize this thread as a method to conclude it. 1. Some people like GUA the most. 2. Smart network operators understand the facts and make decisions based on facts (ULA exist, and it meets a need in some scenarios. NAT and lack of addresses are not reasons to use ULA). 3. Most FUD around ULA comes from an over-reaction to ipv4 NAT sins, misunderstandings about how security policy works in the real world , and deficiencies in mathmatical education. CB On Jul 19, 2012 5:48 AM, Mark Andrews ma...@isc.org wrote: In message caaawwbxh1ws_9ax4fwgrqmsbjmkgj0nwhri9en53htl36vh...@mail.gmail.com , Jimmy Hess writes: On 7/18/12, Karl Auer ka...@biplane.com.au wrote: I don't understand the professed need for provable randomness. Without a number *space* to provide context, randomness is inherently non-provable. The whole point of the randomness of those 40 bits of ULA infix is that any number is as likely as any other number. Someone, When numbers are selected by choosing a random value; certain ratios of bits set to 1 are more likely to occur than other ratios of bits set to 1. A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example. Actually you can't. fdaa:: has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. The ratio of the number of bits doesn't tell you anything about whether the number was random or not. Removing the temptation by excluding the small number of choices with 90% - 95% of the bits set to 1 may eliminate future problems caused by an early accident/error in assigning the initial ULA, compared to the minor inconvenience of needing to run the ULA generator one more time to get an actual usable range. somewhere, is eventually going to get 10::, someone else will eventually get 20:: and so on. And they are just as likely to get them now as in ten years time. That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two. improbable != impossible -- -JH -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: using reserved IPv6 space
On Thu, 19 Jul 2012 07:40:31 -0700, Cameron Byrne said: 3. Most FUD around ULA comes from an over-reaction to ipv4 NAT sins, misunderstandings about how security policy works in the real world , and deficiencies in mathmatical education. I'll add on that said security policies are *themselves* often based on misunderstandings. pgpaHURDQrc98.pgp Description: PGP signature
Re: MPLS L2VPN monitoring
We also use UNI NIDs that trap interface status, log interface and COS queue statistics, and respond to y.1731 traffic. On Tue, Jul 17, 2012 at 7:56 AM, Siegel, David dave.sie...@level3.com wrote: We deploy NIDs to the customer premise. You just can't get enough alarm data be looking only at your router/switch on your side of an Ethernet NNI to give you a proper indication of whether the service is functional, and it also happens to be quite handy to have when a performance test/verification is required. There are a variety of vendors out there to choose from...we have quite a lot of Tellabs and Accedian out in the field. I had hoped that last mile vendors would have been providing NIDs smartjack style by now in a fairly ubiquitous fashion, but alas none of them have stepped up to the plate so we're still putting them out there on our own dime. Dave -Original Message- From: Peter Ehiwe [mailto:petereh...@gmail.com] Sent: Tuesday, July 17, 2012 4:14 AM To: North American Network Operators' Group Subject: MPLS L2VPN monitoring Hello , For those who provide l2vpn services to customers over MPLS , what kind of tools do you use for monitoring the circuits and what kind of values do you proactively monitor I have tools in place to monitor these circuits but i want to know based on group members experiences in order to improve my monitoring platform for this circuits. Thanks a lot!
Re: using reserved IPv6 space
On 18-Jul-12 13:07, Saku Ytti wrote: On (2012-07-18 11:39 -0500), Stephen Sprunk wrote: Those were not considered requirements for the algorithm in RFC 4193 since there is no scenario /where RFC 4193 addresses are a valid solution in the first place/ for which testability or provability of the algorithm's results are important or even useful. If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers. In my experience, pointing at RFCs is rarely how disputes are resolved in the real world. Other potential problem with RFC, if you have software to generate two, if software runs parallel, it may generate same prefixes. It is incredibly unlikely, and that is all RFC 4193 claims to offer: /statistically /unique addresses. If you want /provably/ unique addresses, use GUAs--or lobby for ULA-C, which to date has been soundly rejected for lack of usefulness. IEEE decided 2008 or 2009 to start allocation OUIs randomly, since some cheapskates were assigning themselves 'free' OUIs from end of the space, confident it'll never collide. So duplicate OUIs can happen. Also some NIC vendors ship with non-unique MAC. You'd still need two systems with duplicate MACs to run the algorithm at exactly the same timestamp, which IIRC has a resolution of 2^-32 seconds. What makes RFC method good? RFC 4193 doesn't mandate any particular algorithm; it just provides an example that was designed to be easily implemented and used. You can use another RNG if you wish. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 18-Jul-12 22:57, Karl Auer wrote: I don't understand the professed need for provable randomness. I think his concern is that if an SP generates a ULA prefix for a customer, and that prefix happens to collide with someone else's ULA prefix, the SP may wish to prove that it was a true collision rather than a result of the SP's laziness or incompetence. However, that concern does /not/ apply to those interested in ULAs in general. For the very limited community it does apply to, use a provable RNG instead of the one in RFC 4193. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On 19-Jul-12 07:47, Mark Andrews wrote: In message caaawwbxh1ws_9ax4fwgrqmsbjmkgj0nwhri9en53htl36vh...@mail.gmail.com, Jimmy Hess writes: When numbers are selected by choosing a random value; certain ratios of bits set to 1 are more likely to occur than other ratios of bits set to 1. A random generator that is operating correctly, is much more likely to emit a number with 50% of the bits set to 1, than it is to emit a number with 0% of the bits set to 1, given a sufficient number of bits. If the ratio is inconsistent by a sufficient margin, and your sample of the bits is large enough in number, you can show with high confidence that the number is not random; a 1 in 10 billion chance of the number being randomly generated, would be pretty convincing, for example. Actually you can't. fdaa:: has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. The ratio of the number of bits doesn't tell you anything about whether the number was random or not. He oversimplified the real entropy test, which covers those cases. For a sufficiently long stream of random bits, there should be twice as many runs of length 1 as runs of length 2, twice as many runs of length 2 as runs of length 3, etc. And for each length, they should be evenly divided between runs of 0s and runs of 1s. Of course, 40 bits is nowhere near sufficiently long, but you can score the entropy and set a lower bound for acceptability. The two examples above would get very low entropy scores, far below any sensible lower bound. That is extremely improbable. If you generate a million ULA IDs a day, every day, it is expected to be over 1000 years before you generate one of those two. improbable != impossible All RFC 4193 ever claimed to offer was improbability. If that's not good enough, get a GUA from your RIR. S -- Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking smime.p7s Description: S/MIME Cryptographic Signature
Re: using reserved IPv6 space
On Wed, 18 Jul 2012 21:07:35 +0300, Saku Ytti said: If collision occurs, if dispute occurs, provability that one party did not use BCP method can be useful to solve dispute and decide who renumbers. Looking at actual numbers out of RFC4193: The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 21.81*10^-12 104.54*10^-11 1004.54*10^-09 10004.54*10^-07 14.54*10^-05 OK? So even if you merge and re-merge, and go on a massive buying spree and accumulate a network where you have to interoperate 1,000 ULAs, you're *still* looking at a literally million-to-one shot. And if you only have a mess of 100 ULAs, it's a billion-to-one. Now, compare that to the chances that you'll acquire 2 companies, both of whom had an employee who didn't actually generate a proper random number, but did this sort of thing instead: http://www.spinics.net/lists/linux-driver-devel/msg26431.html A lot of people are worrying about the wrong problem. pgpljt82XfzVh.pgp Description: PGP signature
Telus Wholesale NOC NUmber
Anyone got a number to Telus Wholesale? Got an issue with an PPPoE over L2TP setup. Dennis Burgess, Mikrotik Certified Trainer Author of Learn RouterOS- Second Edition http://www.wlan1.com/product_p/mikrotik%20book-2.htm Link Technologies, Inc -- Mikrotik WISP Support Services Office: 314-735-0270 tel:314-735-0270 Website: http://www.linktechs.net http://www.linktechs.net/ - Skype: linktechs skype:linktechs?call -- Create Wireless Coverage's with www.towercoverage.com http://www.towercoverage.com/ - 900Mhz - LTE - 3G - 3.65 - TV Whitespace 5-Day Advanced RouterOS Workshop -- July 23rd 2012 - St. Louis, MO, USA http://www.wlan1.com/RouterOS_Training_p/5d-stl-training-july2012.htm 5-Day Advanced RouterOS Workshop - Oct 8th 2012 - St. Louis, MO, USA http://www.wlan1.com/RouterOS_Training_p/5d-stl-training-oct2012.htm
Re: using reserved IPv6 space
On (2012-07-19 14:29 -0400), valdis.kletni...@vt.edu wrote: OK? So even if you merge and re-merge, and go on a massive buying spree and accumulate a network where you have to interoperate 1,000 ULAs, you're *still* looking at a literally million-to-one shot. And if you only have a mess of 100 ULAs, My point was, earlier in this thread 40b random method was suggested, which was deemed non RFC compliant. And I've viewed it superior to strictly RFC. But on later post, another author pointed out that 40b random is in conformance to the RFC. To me 40b random is simpler to implement and does not have either of the risks I described (however unlikely, why should I make implementation in given domain more complex and less strong) -- ++ytti
Re: using reserved IPv6 space
On 7/19/12, Mark Andrews ma...@isc.org wrote: Actually you can't. fdaa:: has 20/20 0/1 bits but is entirely non random. fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random. [snip] The ratio of the number of bits doesn't tell you anything about whether the number was random or not. [snip] Sure it does. A ratio of 1s to 0s of a sufficient deviation, is a sufficient but not a necessarily condition, for establishing that a sequence of binary numbers shown almost certainly was not chosen randomly. As for whether fdf0:f0f0:f0f0 is a random number or not, I cannot say, not without a valid test for randomness on the sequence of bits that were chosen, and there are multiple appropriate tests available; use any reasonable test you like, they do exist, and 40 random bits is an amply large sample size. Despite that it is also definitely possible to manually construct strings that are not produced randomly, which nevertheless by design pass any specific test for randomness; intentional 'malice' cannot really be eliminated. However, there _are_ many non-random strings that exist which a 'lazy' or broken ULA ID generator might pick, that can be very easily detected as non-random with sufficient confidence, to tell the user Hey, sorry, you can't use that. Please generate a new ULA ID. improbable != impossible Improbable with a sufficiently small probability is equal to impossible intents and purposes. The probability of generating any specific decimal number you pick a priori, constructed out of 40 bits, is essentially zero, no matter what number you pick; there are _a very large number_ of possible ULA IDs you can exclude, before you have excluded enough that it actually matters.. Rejecting ULA IDs on equipment that have less than a 10^-11 chance of being a random sequence of bits;is less likely to reject a valid ID, than there is to be a collision on a ULA ID, and it would have a high probability of preventing future collisions caused by accident, misconfiguration, etc. Which means that it may be a large improvement on the honor system for picking ULA IDs with no verification. The collision doesn't happen is a better scenario than I know who to blame the guy before me who just picked zero.. and some former employee in the other company that just picked a ULA ID of zero. -- -JH
Re: using reserved IPv6 space
On Thu, 2012-07-19 at 19:30 -0500, Jimmy Hess wrote: The ratio of the number of bits doesn't tell you anything about whether the number was random or not. Sure it does. A ratio of 1s to 0s of a sufficient deviation, is a sufficient but not a necessarily condition, for establishing that a sequence of binary numbers shown almost certainly was not chosen randomly. A *sequence*, yes. A single number in isolation, no. Whether the bits within a single value are distributed randomly or not is irrelevant. You seem to be confusing the randomness of a sequence of bits (i.e., within a particular prefix) with the randomness of a sequence of prefixes. You have the entire bit sequence of a particular prefix available to inspect, so you can make a call on the randomness of the bits, but you do NOT have the entire prefix sequence, so CANNOT make a call on the randomness of the prefix. You can say, for a sufficient number of bits, whether the bits are distributed randomly. Agreed. But given a specific bit, without knowing the other bits, you cannot tell whether that specific bit was chosen randomly. If my prefix generating algorithm is to choose 39 bits completely randomly but always set bit 7, you cannot tell that bit 7 has been set non-randomly by inspecting only one prefix, because in a certain number of genuinely random prefixes, bit 7 will be set anyway. Maybe the one you happen to be looking at is such a one. The same is true of any two bits, and any three bits - and so on, all the way out to 40 bits. However, there _are_ many non-random strings that exist which a 'lazy' or broken ULA ID generator might pick, that can be very easily detected as non-random with sufficient confidence, to tell the user Hey, sorry, you can't use that. Please generate a new ULA ID. You can pick them against human criteria; you can't pick them against mathematical criteria unless you have the sequence as well as the value. All zeros is exactly as likely as insert-any-prefix-here. But: IANAS (I Am Not A Statistician :-) so I think I'll stop now. I am either flogging a dead horse or digging an embarrassing hole for myself :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 signature.asc Description: This is a digitally signed message part
Victory for Open WiFi
From the Electronic Frontier Foundation. https://www.eff.org/deeplinks/2012/07/judge-copyright-troll-cant-bully-internet-subscriber-bogus-legal-theory
Hearing Syria internet cut
Can anyone confirm?
RE: Hearing Syria internet cut
I'm likely seeing some fallout from the earlier brief outage. -Original Message- From: George Bonser [mailto:gbon...@seven.com] Sent: Thursday, July 19, 2012 10:01 PM To: nanog@nanog.org Subject: Hearing Syria internet cut Can anyone confirm?
