Re: Hearing Syria internet cut

[Andree Toonk]

.-- My secret spy satellite informs me that at 12-07-19 10:00 PM  George
Bonser wrote:
> Can anyone confirm? 

Yes confirmed, about 90% of the Syrian prefixes disappeared from the BGP
tables between 13:32 and 14:13 (UTC) earlier today (2012-07-19).

Cheers,
 Andree

RE: Hearing Syria internet cut

[George Bonser]

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?
> 
> 

Hearing Syria internet cut

[George Bonser]

Can anyone confirm? 

Victory for Open WiFi

[Michael Painter]

From the Electronic Frontier Foundation.

https://www.eff.org/deeplinks/2012/07/judge-copyright-troll-cant-bully-internet-subscriber-bogus-legal-theory

Re: using "reserved" IPv6 space

[Karl Auer]

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

Re: using "reserved" IPv6 space

[Jimmy Hess]

On 7/19/12, Mark Andrews  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

[Saku Ytti]

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

Telus Wholesale NOC NUmber

[Dennis Burgess]

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  "

 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  
5-Day Advanced RouterOS Workshop -- July 23rd 2012 - St. Louis, MO, USA
 
5-Day Advanced RouterOS Workshop - Oct 8th 2012 - St. Louis, MO, USA
 



 

Re: using "reserved" IPv6 space

[valdis . kletnieks]

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

Re: using "reserved" IPv6 space

[Stephen Sprunk]

On 19-Jul-12 07:47, Mark Andrews wrote:
> In message 
> , 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

[Stephen Sprunk]

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

[Stephen Sprunk]

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: MPLS L2VPN monitoring

[Jason Iannone]

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  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

[valdis . kletnieks]

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: using "reserved" IPv6 space

[Cameron Byrne]

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"  wrote:

>
> In message <
> caaawwbxh1ws_9ax4fwgrqmsbjmkgj0nwhri9en53htl36vh...@mail.gmail.com>
> , Jimmy Hess writes:
> > On 7/18/12, Karl Auer  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

[Mark Andrews]

In message 
, Jimmy Hess writes:
> On 7/18/12, Karl Auer  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: Another LTE network turns up as IPv4-only squat space + NAT

[bmanning]

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: Another LTE network turns up as IPv4-only squat space + NAT

[Måns Nilsson]

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: using "reserved" IPv6 space

[Saku Ytti]

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: using "reserved" IPv6 space

[Saku Ytti]

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