Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Randy Bush]

> Head on over to the Wikipedia page for SSL/TLS and then decide if you
> want rc4 to be your preference when trying to defend against a
> adversary with the resources of a nation-state.

i got hit with the clue bat on this one.

we have kinda settled on allowing rc4 for smtp as the least preferred.
if we did not it would fall back to cleartext.

otoh, for web, all browsers can do better, so we don't allow rc4

ykmv

randy

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <527459c4.5000...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
>  It is a lot simpler and a lot more practical just to
>  use shared secret between a CPE and a ISP's name server
>  for TSIG generation.
> >>>
> >>> No it isn't.  It requires a human to transfer the secret to the CPE
> >>> device or to register the secret with the ISP.
> >>
> >> Not necessarily. When the CPE is configured through DHCP (or
> >> PPP?), the ISP can send the secret.
> > 
> > Which can be seen, in many cases, by other parties
> 
> Who can see the packets sent from the local ISP to the CPE
> directly connected to the ISP?

The dhcpd traffic coming in over the cable modem and you want to
send secrets in the clear over a channel like this.

bsdi# tcpdump -n -i sis0 port bootpc
tcpdump: listening on sis0
15:05:15.637252 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc58c07ae 
flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp]
15:05:15.650590 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc58c07ae 
flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp]
15:05:34.942619 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb 
flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 
[|bootp]
15:05:36.975213 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb 
secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 
0:17:ee:4c:f3:74 [|bootp]
15:05:36.992714 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb 
secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 
0:17:ee:4c:f3:74 [|bootp]
15:05:55.931705 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 
flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:57.951400 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 secs:2 
flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:57.964049 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 secs:2 
flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:58.930921 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2af 
flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:00.054322 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2b0 
flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:00.068061 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2b0 
flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:08.933232 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 
flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 
[|bootp]
15:06:10.941233 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 
secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 
0:1a:de:6f:99:e6 [|bootp]
15:06:10.959519 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 
secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 
0:1a:de:6f:99:e6 [|bootp]
^C
10638 packets received by filter
0 packets dropped by kernel
bsdi# 

> If you mind wire tapping, you have other things to worry
> about, which needs your access line encrypted (by a manually
> configured password), which makes DHCP packets invisible.
> 
>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Jimmy Hess]

On Fri, Nov 1, 2013 at 9:19 PM, Alex Rubenstein  wrote:

> > a typical example will be the guy who run the dslam and the guy who run
> the
> > bras belong to two different companies in market which mandate open
> > access.
> ... which is very, very common.
>

It's also a troublesome situation for the ISP;  it may be  "open access" on
paper,  but  DSLAMs and  bras  break,  and then the ISP is potentially at
the mercy of  bureaucratic support walls and the  DSLAM operator,   who
would love to create as many weeks delay in repair as possible and pay lip
service to getting issues addressed;  for the end user to get frustrated,
blame the ISP, and switch service  to their own.


But yeah  sniffing/tapping can targetthe underlying link provider.

Or it can even involve  agents  tapping into  copper wires  with alligator
clips,  unbeknownst to even the DSLAM operator.


The trouble with end-to-end encryption as a solution;is the
difficulty/impossibility  of   establishing   ipsec SAs  with   arbitrary
hosts on the internet;  without manual pre-configuration  of every pair of
hosts.


-- 
-JH

RE: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[John Souvestre]

Money.  The better the encryption the more it costs to crack.  With forward
security you can even protect against your private key leaking.

In short, you can raise the stakes and make it economically unfeasible for
even the NSA.

John

    John Souvestre - New Orleans LA - (504) 454-0899


-Original Message-
From: Mike Lyon [mailto:mike.l...@gmail.com] 
Sent: Fri, November 01, 2013 9:19 pm
To: Harry Hoffman
Cc: Niels Bakker; nanog@nanog.org
Subject: Re: latest Snowden docs show NSA intercepts all Google and Yahoo
DC-to-DC traffic

So even if Goog or Yahoo encrypt their data between DCs, what stops the NSA
from decrypting that data? Or would it be done simply to make their lives a
bit more of a PiTA to get the data they want?

-Mike



> On Nov 1, 2013, at 19:08, Harry Hoffman  wrote:
>
> That's with a recommendation of using RC4.
> Head on over to the Wikipedia page for SSL/TLS and then decide if you want
rc4 to be your preference when trying to defend against a adversary with the
resources of a nation-state.
>
> Cheers,
> Harry
>
> Niels Bakker  wrote:
>
>> * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>> Its about the CPU cost of the crypto. I was once told the number of 
>>> CPUs required to do SSL on web search (which I have now forgotten) 
>>> and it was a bigger number than you'd expect -- certainly hundreds.
>>
>> False: 
>> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> "On our production frontend machines, SSL/TLS accounts for less than 
>> 1% of the CPU load, less than 10KB of memory per connection and less 
>> than 2% of network overhead. Many people believe that SSL takes a lot 
>> of CPU time and we hope the above numbers (public for the first time) 
>> will help to dispel that."
>>
>>
>>-- Niels.
>>


smime.p7s
Description: S/MIME cryptographic signature

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[joel jaeggli]

On Nov 1, 2013, at 7:06 PM, Harry Hoffman  wrote:

> That's with a recommendation of using RC4.

it’s also with 1024 bit keys in the key exchange.

> Head on over to the Wikipedia page for SSL/TLS and then decide if you want 
> rc4 to be your preference when trying to defend against a adversary with the 
> resources of a nation-state.
> 
> Cheers,
> Harry
> 
> Niels Bakker  wrote:
> 
>> * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>> Its about the CPU cost of the crypto. I was once told the number of 
>>> CPUs required to do SSL on web search (which I have now forgotten) 
>>> and it was a bigger number than you'd expect -- certainly hundreds.
>> 
>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>> 
>> "On our production frontend machines, SSL/TLS accounts for less than 
>> 1% of the CPU load, less than 10KB of memory per connection and less 
>> than 2% of network overhead. Many people believe that SSL takes a lot 
>> of CPU time and we hope the above numbers (public for the first time) 
>> will help to dispel that."
>> 
>> 
>>  -- Niels.
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Randy]

Big Brother is always watching and Big Brother has way more resources than 
network-operators in this list!
(good discussion all the same)

a) politics is the last-resort for scoundrels
b) power corrupts and absolute-power(FBI, CIA, NSA, DHS..etc,) 
corrupts-absolutely.

I speak from this-side-of-the-pond and I have no doubt that this thread is 
being monitored as well by (b) and no; I don't have my tinfoil-hat on.

To answer your question:

Not Much.
./Randy







- Original Message -
> From: Harry Hoffman 
> To: Mike Lyon 
> Cc: Niels Bakker ; nanog@nanog.org
> Sent: Friday, November 1, 2013 7:32 PM
> Subject: Re: latest Snowden docs show NSA intercepts all Google and Yahoo 
> DC-to-DC traffic
> 
> So, I'm not sure if I'm being too simple-minded in my response. Please 
> let me know if I am.
> The purpose of encrypting data is so others can't read your secrets.
> If you use a simple substitution cipher it's pretty easy to derive the set 
> of substitution rules used.
> Stronger encryption algorithms employ more "difficult" math. Figuring 
> out how to get from the ciphertext to the plaintext becomes a, 
> computationally, 
> difficult task.
> If your encryption algorithms are "good" *and* your source of random 
> data is really random then the amount of time it takes to decrypt the data is 
> so 
> far out that it makes the data useless.
> 
> Cheers,
> Harry
> 
> Mike Lyon  wrote:
> 
>> So even if Goog or Yahoo encrypt their data between DCs, what stops
>> the NSA from decrypting that data? Or would it be done simply to make
>> their lives a bit more of a PiTA to get the data they want?
>> 
>> -Mike
>> 
>> 
>> 
>>>  On Nov 1, 2013, at 19:08, Harry Hoffman 
>  wrote:
>>> 
>>>  That's with a recommendation of using RC4.
>>>  Head on over to the Wikipedia page for SSL/TLS and then decide if you 
> want rc4 to be your preference when trying to defend against a adversary with 
> the resources of a nation-state.
>>> 
>>>  Cheers,
>>>  Harry
>>> 
>>>  Niels Bakker  wrote:
>>> 
  * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>  Its about the CPU cost of the crypto. I was once told the 
> number of
>  CPUs required to do SSL on web search (which I have now 
> forgotten)
>  and it was a bigger number than you'd expect -- certainly 
> hundreds.
 
  False: 
> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
 
  "On our production frontend machines, SSL/TLS accounts for 
> less than
  1% of the CPU load, less than 10KB of memory per connection and 
> less
  than 2% of network overhead. Many people believe that SSL takes a 
> lot
  of CPU time and we hope the above numbers (public for the first 
> time)
  will help to dispel that."
 
 
     -- Niels.
 
>

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Lyndon Nerenberg]

On Nov 1, 2013, at 7:18 PM, Mike Lyon  wrote:

> So even if Goog or Yahoo encrypt their data between DCs, what stops
> the NSA from decrypting that data? Or would it be done simply to make
> their lives a bit more of a PiTA to get the data they want?

Markhov chain text generators are cheap.  Rather than amping up the crypto, why 
not bury them under heaping piles of steaming bullshit?

After all, it would be the patriotic thing to do.  Not only would you be 
helping employ your fellow network engineers (someone has to increase the size 
of the effluent pipes), you would be boosting manufacturing (disks for storage, 
high-end network gear for capture, mainframes and asics for filtering and 
analysis) and helping the much-maligned coal industry ensure its future 
prospects (that gear isn't built from electron sipping Atom CPUs, you know!).

--lyndon

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Mike Lyon]

So the latter, PITA, reason then...

-Mike



> On Nov 1, 2013, at 19:32, Harry Hoffman  wrote:
>
> So, I'm not sure if I'm being too simple-minded in my response. Please let me 
> know if I am.
> The purpose of encrypting data is so others can't read your secrets.
> If you use a simple substitution cipher it's pretty easy to derive the set of 
> substitution rules used.
> Stronger encryption algorithms employ more "difficult" math. Figuring out how 
> to get from the ciphertext to the plaintext becomes a, computationally, 
> difficult task.
> If your encryption algorithms are "good" *and* your source of random data is 
> really random then the amount of time it takes to decrypt the data is so far 
> out that it makes the data useless.
>
> Cheers,
> Harry
>
> Mike Lyon  wrote:
>
>> So even if Goog or Yahoo encrypt their data between DCs, what stops
>> the NSA from decrypting that data? Or would it be done simply to make
>> their lives a bit more of a PiTA to get the data they want?
>>
>> -Mike
>>
>>
>>
>>> On Nov 1, 2013, at 19:08, Harry Hoffman  wrote:
>>>
>>> That's with a recommendation of using RC4.
>>> Head on over to the Wikipedia page for SSL/TLS and then decide if you want 
>>> rc4 to be your preference when trying to defend against a adversary with 
>>> the resources of a nation-state.
>>>
>>> Cheers,
>>> Harry
>>>
>>> Niels Bakker  wrote:
>>>
 * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
> Its about the CPU cost of the crypto. I was once told the number of
> CPUs required to do SSL on web search (which I have now forgotten)
> and it was a bigger number than you'd expect -- certainly hundreds.

 False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

 "On our production frontend machines, SSL/TLS accounts for less than
 1% of the CPU load, less than 10KB of memory per connection and less
 than 2% of network overhead. Many people believe that SSL takes a lot
 of CPU time and we hope the above numbers (public for the first time)
 will help to dispel that."


   -- Niels.

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Harry Hoffman]

So, I'm not sure if I'm being too simple-minded in my response. Please let me 
know if I am.
The purpose of encrypting data is so others can't read your secrets.
If you use a simple substitution cipher it's pretty easy to derive the set of 
substitution rules used.
Stronger encryption algorithms employ more "difficult" math. Figuring out how 
to get from the ciphertext to the plaintext becomes a, computationally, 
difficult task.
If your encryption algorithms are "good" *and* your source of random data is 
really random then the amount of time it takes to decrypt the data is so far 
out that it makes the data useless.

Cheers,
Harry

Mike Lyon  wrote:

>So even if Goog or Yahoo encrypt their data between DCs, what stops
>the NSA from decrypting that data? Or would it be done simply to make
>their lives a bit more of a PiTA to get the data they want?
>
>-Mike
>
>
>
>> On Nov 1, 2013, at 19:08, Harry Hoffman  wrote:
>>
>> That's with a recommendation of using RC4.
>> Head on over to the Wikipedia page for SSL/TLS and then decide if you want 
>> rc4 to be your preference when trying to defend against a adversary with the 
>> resources of a nation-state.
>>
>> Cheers,
>> Harry
>>
>> Niels Bakker  wrote:
>>
>>> * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
 Its about the CPU cost of the crypto. I was once told the number of
 CPUs required to do SSL on web search (which I have now forgotten)
 and it was a bigger number than you'd expect -- certainly hundreds.
>>>
>>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>>
>>> "On our production frontend machines, SSL/TLS accounts for less than
>>> 1% of the CPU load, less than 10KB of memory per connection and less
>>> than 2% of network overhead. Many people believe that SSL takes a lot
>>> of CPU time and we hope the above numbers (public for the first time)
>>> will help to dispel that."
>>>
>>>
>>>-- Niels.
>>>

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Masataka Ohta]

George Herbert wrote:

> Anyone familiar with secure organizations will realize this as the
> internal witch hunt problem.

No hunting necessary to fire those agents who are hired at the
request of NSA/CIA.

It is also reasonable to fire those who are hired by the agents,
recursively.

Masataka Ohta

RE: Reverse DNS RFCs and Recommendations

[Alex Rubenstein]

> we cannot assume that the connection between isp and cpe is a single entity.
> 
> a typical example will be the guy who run the dslam and the guy who run the
> bras belong to two different companies in market which mandate open
> access.

... which is very, very common.

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Mike Lyon]

So even if Goog or Yahoo encrypt their data between DCs, what stops
the NSA from decrypting that data? Or would it be done simply to make
their lives a bit more of a PiTA to get the data they want?

-Mike



> On Nov 1, 2013, at 19:08, Harry Hoffman  wrote:
>
> That's with a recommendation of using RC4.
> Head on over to the Wikipedia page for SSL/TLS and then decide if you want 
> rc4 to be your preference when trying to defend against a adversary with the 
> resources of a nation-state.
>
> Cheers,
> Harry
>
> Niels Bakker  wrote:
>
>> * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>> Its about the CPU cost of the crypto. I was once told the number of
>>> CPUs required to do SSL on web search (which I have now forgotten)
>>> and it was a bigger number than you'd expect -- certainly hundreds.
>>
>> False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>>
>> "On our production frontend machines, SSL/TLS accounts for less than
>> 1% of the CPU load, less than 10KB of memory per connection and less
>> than 2% of network overhead. Many people believe that SSL takes a lot
>> of CPU time and we hope the above numbers (public for the first time)
>> will help to dispel that."
>>
>>
>>-- Niels.
>>

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

(2013/11/02 10:48), Alex Rubenstein wrote:
 Not necessarily. When the CPE is configured through DHCP (or PPP?),
 the ISP can send the secret.
>>>
>>> Which can be seen, in many cases, by other parties
>>
>> Who can see the packets sent from the local ISP to the CPE directly
>> connected to the ISP?
> 
> The NSA, FBI, CIA, DHS.

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

> Or, the ISP, the ISP's employees, contractors, sub-contractors.

If you can't trust the ISP, you can't make rDNS operated
by the ISP secure.

> Or the phone company handling the PPPOE, L2TP, or whatever else.

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

> Or the WiFi sniffer on the street outside.

Does your CPE retransmit a received DHCP reply to Wifi?

Masataka Ohta

RE: Reverse DNS RFCs and Recommendations

[Beng Hui Ong]

we cannot assume that the connection between isp and cpe is a single entity. 

a typical example will be the guy who run the dslam and the guy who run the 
bras belong to two different companies in market which mandate open access.

Alex Rubenstein  wrote:

>> >> Not necessarily. When the CPE is configured through DHCP (or PPP?),
>> >> the ISP can send the secret.
>> >
>> > Which can be seen, in many cases, by other parties
>> 
>> Who can see the packets sent from the local ISP to the CPE directly
>> connected to the ISP?
>
>The NSA, FBI, CIA, DHS. Or, the ISP, the ISP's employees, contractors, 
>sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever 
>else. Or the WiFi sniffer on the street outside.
>
>
>
>

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Harry Hoffman]

That's with a recommendation of using RC4.
Head on over to the Wikipedia page for SSL/TLS and then decide if you want rc4 
to be your preference when trying to defend against a adversary with the 
resources of a nation-state.

Cheers,
Harry

Niels Bakker  wrote:

>* mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>>Its about the CPU cost of the crypto. I was once told the number of 
>>CPUs required to do SSL on web search (which I have now forgotten) 
>>and it was a bigger number than you'd expect -- certainly hundreds.
>
>False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
>
>"On our production frontend machines, SSL/TLS accounts for less than 
>1% of the CPU load, less than 10KB of memory per connection and less 
>than 2% of network overhead. Many people believe that SSL takes a lot 
>of CPU time and we hope the above numbers (public for the first time) 
>will help to dispel that."
>
>
>   -- Niels.
>

RE: Reverse DNS RFCs and Recommendations

[Alex Rubenstein]

> >> Not necessarily. When the CPE is configured through DHCP (or PPP?),
> >> the ISP can send the secret.
> >
> > Which can be seen, in many cases, by other parties
> 
> Who can see the packets sent from the local ISP to the CPE directly
> connected to the ISP?

The NSA, FBI, CIA, DHS. Or, the ISP, the ISP's employees, contractors, 
sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever 
else. Or the WiFi sniffer on the street outside.

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

Mark Andrews wrote:

 It is a lot simpler and a lot more practical just to
 use shared secret between a CPE and a ISP's name server
 for TSIG generation.
>>>
>>> No it isn't.  It requires a human to transfer the secret to the CPE
>>> device or to register the secret with the ISP.
>>
>> Not necessarily. When the CPE is configured through DHCP (or
>> PPP?), the ISP can send the secret.
> 
> Which can be seen, in many cases, by other parties

Who can see the packets sent from the local ISP to the CPE
directly connected to the ISP?

If you mind wire tapping, you have other things to worry
about, which needs your access line encrypted (by a manually
configured password), which makes DHCP packets invisible.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <20131102002035.963ba96d...@rock.dv.isc.org>, Mark Andrews writes:
> 
> In message <52743027.7050...@necom830.hpcl.titech.ac.jp>, Masataka Ohta write
> s:
> > Mark Andrews wrote:
> > 
> > >> It is a lot simpler and a lot more practical just to
> > >> use shared secret between a CPE and a ISP's name server
> > >> for TSIG generation.
> > > 
> > > No it isn't.  It requires a human to transfer the secret to the CPE
> > > device or to register the secret with the ISP.
> > 
> > Not necessarily. When the CPE is configured through DHCP (or
> > PPP?), the ISP can send the secret.
> 
> Which can be seen, in many cases, by other parties which is why I
> discounted plain TSIG key exchanges over DHCP years ago regardless
> of which side send the key material.

Now you could do a DH key exchange over DHCP then do a encrypted
TSIG key exchange.  This however also requires a encrypted key
exchange of the TSIG with the nameserver.  The DHCP server could
do this with TKEY.

Note a full DH key exhange is not strictly required.  The CPE could
just send a public key and the DHCP server could encrypt the TSIG
secret using it when replying.

> > > I'm talking about just building this into CPE devices and having it
> > > just work with no human involvement.
> > 
> > See above.
> > 
> > Involving DNSSEC here is overkill and unnecessarily introduce
> > vulnerabilities.
> 
> You do realise that you can use KEY records without DNSSEC.  The
> KEY record is in the zone to be updated so it is implictly trusted.
> 
> > Masataka Ohta
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <52743027.7050...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> >> It is a lot simpler and a lot more practical just to
> >> use shared secret between a CPE and a ISP's name server
> >> for TSIG generation.
> > 
> > No it isn't.  It requires a human to transfer the secret to the CPE
> > device or to register the secret with the ISP.
> 
> Not necessarily. When the CPE is configured through DHCP (or
> PPP?), the ISP can send the secret.

Which can be seen, in many cases, by other parties which is why I
discounted plain TSIG key exchanges over DHCP years ago regardless
of which side send the key material.

> > I'm talking about just building this into CPE devices and having it
> > just work with no human involvement.
> 
> See above.
> 
> Involving DNSSEC here is overkill and unnecessarily introduce
> vulnerabilities.

You do realise that you can use KEY records without DNSSEC.  The
KEY record is in the zone to be updated so it is implictly trusted.

>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Randy Bush]

> And zero documented proof.  I'll just go ahead and put my tinfoil hat on
> for the remainder of this thread.

http://www.antipope.org/charlie/blog-static/2013/10/spook-century.html

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Jason Biel]

--
According to Snowden, there are government agents at key
positions for managing security.
-

And zero documented proof.  I'll just go ahead and put my tinfoil hat on
for the remainder of this thread.


On Fri, Nov 1, 2013 at 6:37 PM, Randy Bush  wrote:

> > Anyone familiar with secure organizations
>
> there are such things?
>
> we should be more cautious with absolutes, usually :)
>
>


-- 
Jason

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[George Herbert]

On Fri, Nov 1, 2013 at 4:37 PM, Randy Bush  wrote:

> > Anyone familiar with secure organizations
>
> there are such things?
>
> we should be more cautious with absolutes, usually :)
>


Nothing is absolute, but there are certainly "white" organizations which
have no attempt to be secure, and much greyer ones where it's a big deal in
organizational process and ethos.

A Snowden once a decade or so is not a bad record.  Unfortunately, we ...
hoped ... they were the good guys, not the bad guys.


-- 
-george william herbert
george.herb...@gmail.com

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Randy Bush]

> Anyone familiar with secure organizations

there are such things?

we should be more cautious with absolutes, usually :)

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[George Herbert]

On Fri, Nov 1, 2013 at 4:01 PM, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Anthony Junk wrote:
>
> > It seems as if both Yahoo and Google assumed that since they were
> > private circuits that they didn't have to encrypt.
>
> According to Snowden, there are government agents at key
> positions for managing security.
>
> When they declare the private circuits are secure, no one
> else in the companies can argue against.
>
> Unless they are fired and all the backdoors installed by
> them are removed, neither Yahoo and Google are secure.
>

This is probably not entirely true, however...

There is certainly enough in the Snowden docs to render this a valid
question, and there is enough to assume some truth to the statement.

Anyone familiar with secure organizations will realize this as the internal
witch hunt problem.  You now have serious reason to believe that you have
been compromised.  If security needs to be absolute, then the degree of
response needed to succeed at attaining that will require very serious
vetting of all the staff, of the nature of what national security
organizations do (background checks, polygraphs, detailed personal
histories, intrusive random monitoring of employee actions in and outside
the office, etc).

Most of "us" will not put up with that.  However, most of "us" also desire
reasonably secure services (both those of us who work for those services,
and those of us who use them).

The prior default setting was to assume there was nobody trying hard enough
to penetrate those services that the internal witch hunt degree of internal
security was necessary.  It was "reasonable" to hope that someone with
nation-state / superpower level resources was not actively Trying To Get
In.  Now that's not a safe assumption.

The NSA has just put the entire profession in a horrible bind.  By going
beyond the foggy-but-legally-documented FISA warrant activities into active
hostile actions against US providers we have to wonder about what degree of
paranoia is necessary.

Do we now just stick our heads back in the sand?  Identify key security
groups with override authority within our organizations, vet them and
monitor them like the CIA and NSA vet and monitor their employees?  Try to
establish that level of review of all our staffs?

Bruce Schneier has tiptoed around this some, but the thread from his blog
last week of "How do we know we can trust Bruce" is terrifying when we have
to consider applying that question to everyone on this list (and who should
be on this list).


-- 
-george william herbert
george.herb...@gmail.com

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Masataka Ohta]

Anthony Junk wrote:

> It seems as if both Yahoo and Google assumed that since they were
> private circuits that they didn't have to encrypt.

According to Snowden, there are government agents at key
positions for managing security.

When they declare the private circuits are secure, no one
else in the companies can argue against.

Unless they are fired and all the backdoors installed by
them are removed, neither Yahoo and Google are secure.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

Mark Andrews wrote:

>> It is a lot simpler and a lot more practical just to
>> use shared secret between a CPE and a ISP's name server
>> for TSIG generation.
> 
> No it isn't.  It requires a human to transfer the secret to the CPE
> device or to register the secret with the ISP.

Not necessarily. When the CPE is configured through DHCP (or
PPP?), the ISP can send the secret.

> I'm talking about just building this into CPE devices and having it
> just work with no human involvement.

See above.

Involving DNSSEC here is overkill and unnecessarily introduce
vulnerabilities.

Masataka Ohta

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[George Herbert]

On Fri, Nov 1, 2013 at 3:26 PM, Niels Bakker  wrote:

> * mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
>
>  Its about the CPU cost of the crypto. I was once told the number of CPUs
>> required to do SSL on web search (which I have now forgotten) and it was a
>> bigger number than you'd expect -- certainly hundreds.
>>
>
> False: 
> https://www.imperialviolet.**org/2010/06/25/overclocking-**ssl.html
>
> "On our production frontend machines, SSL/TLS accounts for less than 1% of
> the CPU load, less than 10KB of memory per connection and less than 2% of
> network overhead. Many people believe that SSL takes a lot of CPU time and
> we hope the above numbers (public for the first time) will help to dispel
> that."


That was *front end* SSL/TLS - not internal / back end SSL/TLS.

One could assert that the per-activity SSL/TLS overhead might be the same
for internal services accessed to answer a front-end request, but that's
not necessarily true.  The code/request ratios and external/internal
SSL/TLS startup costs are going to vary wildly from service to service.


-- 
-george william herbert
george.herb...@gmail.com

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Niels Bakker]

* mi...@stillhq.com (Michael Still) [Fri 01 Nov 2013, 05:27 CET]:
Its about the CPU cost of the crypto. I was once told the number of 
CPUs required to do SSL on web search (which I have now forgotten) 
and it was a bigger number than you'd expect -- certainly hundreds.


False: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

"On our production frontend machines, SSL/TLS accounts for less than 
1% of the CPU load, less than 10KB of memory per connection and less 
than 2% of network overhead. Many people believe that SSL takes a lot 
of CPU time and we hope the above numbers (public for the first time) 
will help to dispel that."



-- Niels.

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

 valdis.kletni...@vt.edu wrote:

>> It is a lot simpler and a lot more practical just to
>> use shared secret between a CPE and a ISP's name server
>> for TSIG generation.
> 
> Hmm.. Shared secret between a CPE you don't necessarily control
> and your own DNS server?

Of course. That is the very basic requirement for any security
between two parties.

Masataka Ohta

BGP Update Report

[cidr-report]

BGP Update Report
Interval: 24-Oct-13 -to- 31-Oct-13 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS30693  118832  4.7% 242.0 -- 
EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 2 - AS640753437  2.1%1113.3 -- PRIMUS-AS6407 - Primus 
Telecommunications Canada Inc.
 3 - AS982942413  1.7%  30.7 -- BSNL-NIB National Internet 
Backbone
 4 - AS840231837  1.3%  18.8 -- CORBINA-AS OJSC "Vimpelcom"
 5 - AS28573   31108  1.2%   8.6 -- NET Serviços de Comunicação S.A.
 6 - AS605723257  0.9%  57.4 -- Administracion Nacional de 
Telecomunicaciones
 7 - AS36998   22882  0.9%  12.3 -- SDN-MOBITEL
 8 - AS10620   21791  0.9%   8.3 -- Telmex Colombia S.A.
 9 - AS13118   21652  0.9% 470.7 -- ASN-YARTELECOM OJSC Rostelecom
10 - AS29990   21546  0.9%1134.0 -- ASN-APPNEXUS - AppNexus, Inc
11 - AS755220464  0.8%  17.2 -- VIETEL-AS-AP Vietel Corporation
12 - AS35873   19784  0.8%1798.5 -- MOVE-NETWORKS - Move Networks, 
inc.
13 - AS684917484  0.7%  19.6 -- UKRTELNET JSC UKRTELECOM,
14 - AS42334   17101  0.7%1005.9 -- BBP-AS Broadband Plus s.a.l.
15 - AS477516743  0.7% 128.8 -- GLOBE-TELECOM-AS Globe Telecoms
16 - AS18403   14353  0.6%  24.9 -- FPT-AS-AP The Corporation for 
Financing & Promoting Technology
17 - AS815112915  0.5%  10.7 -- Uninet S.A. de C.V.
18 - AS929911499  0.5%  23.3 -- IPG-AS-AP Philippine Long 
Distance Telephone Company
19 - AS35819   11426  0.5%  22.2 -- MOBILY-AS Etihad Etisalat 
Company (Mobily)
20 - AS29049   11263  0.5%  33.4 -- DELTA-TELECOM-AS Delta Telecom 
LTD.


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASNUpds %  Upds/PfxAS-Name
 1 - AS6174 6731  0.3%3365.5 -- SPRINTLINK8 - Sprint
 2 - AS561314957  0.2%2478.5 -- UXCCONNECT-AS-AP UXC Connect 
Pty Ltd
 3 - AS544658794  0.3%2198.5 -- QPM-AS-1 - QuickPlay Media Inc.
 4 - AS35873   19784  0.8%1798.5 -- MOVE-NETWORKS - Move Networks, 
inc.
 5 - AS373671569  0.1%1569.0 -- CALLKEY
 6 - AS6629 9342  0.4%1557.0 -- NOAA-AS - NOAA
 7 - AS284931549  0.1%1549.0 -- Universidad Pedagogica Nacional
 8 - AS5323 1326  0.1%1326.0 -- DNIC-ASBLK-05120-05376 - DoD 
Network Information Center
 9 - AS7202 8884  0.3%1269.1 -- FAMU - Florida A & M University
10 - AS29990   21546  0.9%1134.0 -- ASN-APPNEXUS - AppNexus, Inc
11 - AS640753437  2.1%1113.3 -- PRIMUS-AS6407 - Primus 
Telecommunications Canada Inc.
12 - AS225925150  0.2%1030.0 -- HBP - HBP, Inc.
13 - AS42334   17101  0.7%1005.9 -- BBP-AS Broadband Plus s.a.l.
14 - AS503371912  0.1% 956.0 -- TETTAS-AS TETTAS SRL
15 - AS571301858  0.1% 929.0 -- SECPRAL-AS Secpral COM SRL
16 - AS519732656  0.1% 885.3 -- KOLT-AS Koltushsky Internet Ltd
17 - AS45808 882  0.0% 882.0 -- UTP-MY Bandar Seri Iskandar
18 - AS6775 5205  0.2% 867.5 -- BACKBONE_EHF_EUROPE Backbone ehf
19 - AS5487 4880  0.2% 697.1 -- Elisa Oyj
20 - AS62431 680  0.0% 680.0 -- NCSC-IE-AS National Cyber 
Security Centre


TOP 20 Unstable Prefixes
Rank Prefix Upds % Origin AS -- AS Name
 1 - 109.161.64.0/20   21588  0.8%   AS13118 -- ASN-YARTELECOM OJSC Rostelecom
 2 - 103.243.220.0/22  21525  0.8%   AS29990 -- ASN-APPNEXUS - AppNexus, Inc
 3 - 23.90.5.0/24  21020  0.8%   AS30693 -- 
EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 4 - 23.90.6.0/24  21013  0.8%   AS30693 -- 
EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 5 - 8.20.2.0/24   19774  0.8%   AS35873 -- MOVE-NETWORKS - Move Networks, 
inc.
 6 - 62.84.76.0/24 17081  0.7%   AS42334 -- BBP-AS Broadband Plus s.a.l.
 7 - 23.90.21.0/24 13254  0.5%   AS30693 -- 
EONIX-CORPORATION-AS-WWW-EONIX-NET - Eonix Corporation
 8 - 192.58.232.0/249337  0.3%   AS6629  -- NOAA-AS - NOAA
 9 - 206.152.15.0/248791  0.3%   AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
10 - 202.154.17.0/248682  0.3%   AS4434  -- ERX-RADNET1-AS PT Rahajasa 
Media Internet
11 - 120.28.62.0/24 8278  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
12 - 222.127.0.0/24 8028  0.3%   AS4775  -- GLOBE-TELECOM-AS Globe Telecoms
13 - 121.52.144.0/247887  0.3%   AS17557 -- PKTELECOM-AS-PK Pakistan 
Telecommunication Company Limited
 AS45773 -- HECPERN-AS-PK PERN AS Content 
Servie Provider, Islamabad, Pakistan
14 - 67.210.190.0/235851  0.2%   AS11976 -- FIDN - Fidelity Communication 
International Inc.
15 - 67.210.188.0/2352

The Cidr Report

[cidr-report]

This report has been generated at Fri Nov  1 21:13:38 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
Date  PrefixesCIDR Agg
25-10-13481005  273685
26-10-13480922  272864
27-10-13480241  273108
28-10-13480622  271494
29-10-13480919  271909
30-10-13481209  272234
31-10-13481352  272350
01-11-13481734  272532


AS Summary
 45515  Number of ASes in routing system
 18684  Number of ASes announcing only one prefix
  4185  Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
  118856704  Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 01Nov13 ---
ASnumNetsNow NetsAggr  NetGain   % Gain   Description

Table 481879   272481   20939843.5%   All ASes

AS6389  3056   59 299798.1%   BELLSOUTH-NET-BLK -
   BellSouth.net Inc.
AS28573 3432  461 297186.6%   NET Serviços de Comunicação
   S.A.
AS17974 2710  135 257595.0%   TELKOMNET-AS2-AP PT
   Telekomunikasi Indonesia
AS7029  4185 1872 231355.3%   WINDSTREAM - Windstream
   Communications Inc
AS22773 2191  147 204493.3%   ASN-CXA-ALL-CCI-22773-RDC -
   Cox Communications Inc.
AS4766  2937  951 198667.6%   KIXS-AS-KR Korea Telecom
AS10620 2641 1051 159060.2%   Telmex Colombia S.A.
AS18566 2057  567 149072.4%   MEGAPATH5-US - MegaPath
   Corporation
AS4323  2960 1538 142248.0%   TWTC - tw telecom holdings,
   inc.
AS18881 1523  105 141893.1%   Global Village Telecom
AS36998 1854  457 139775.4%   SDN-MOBITEL
AS7303  1724  466 125873.0%   Telecom Argentina S.A.
AS1785  2036  818 121859.8%   AS-PAETEC-NET - PaeTec
   Communications, Inc.
AS4755  1787  583 120467.4%   TATACOMM-AS TATA
   Communications formerly VSNL
   is Leading ISP
AS7552  1191  138 105388.4%   VIETEL-AS-AP Vietel
   Corporation
AS22561 1245  219 102682.4%   DIGITAL-TELEPORT - Digital
   Teleport Inc.
AS35908  911   89  82290.2%   VPLSNET - Krypt Technologies
AS7545  2102 1282  82039.0%   TPG-INTERNET-AP TPG Telecom
   Limited
AS18101  980  180  80081.6%   RELIANCE-COMMUNICATIONS-IN
   Reliance Communications
   Ltd.DAKC MUMBAI
AS4808  1158  404  75465.1%   CHINA169-BJ CNCGROUP IP
   network China169 Beijing
   Province Network
AS24560 1092  367  72566.4%   AIRTELBROADBAND-AS-AP Bharti
   Airtel Ltd., Telemedia
   Services
AS701   1508  785  72347.9%   UUNET - MCI Communications
   Services, Inc. d/b/a Verizon
   Business
AS8151  1355  637  71853.0%   Uninet S.A. de C.V.
AS6983  1293  584  70954.8%   ITCDELTA - ITC^Deltacom
AS13977  852  143  70983.2%   CTELCO - FAIRPOINT
   COMMUNICATIONS, INC.
AS6147   792  108  68486.4%   Telefonica del Peru S.A.A.
AS4788   844  171  67379.7%   TMNET-AS-AP TM Net, Internet
   Service Provider
AS855726   55  67192.4%   CANET-ASN-4 - Bell Aliant
   Regional Communications, Inc.
AS4780  1000  335  66566.5%   SEEDNET Digital United Inc.
AS7738 

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

In message <5273525c.5060...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
> 
> > That said it is possible to completely automate the secure assignment
> > of PTR records.  It is also possible to completely automate the
> > secure delegation of the reverse name space.  See
> > http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
> 
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.

No it isn't.  It requires a human to transfer the secret to the CPE
device or to register the secret with the ISP.

I'm talking about just building this into CPE devices and having it
just work with no human involvement.

> As the secret can be directly shared end to end, it is more
> secure than DNSSEC involving untrustworthy third parties.
> 
>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Integra Telecom BGP contact

[Ken McIntyre]

Sent you an email off list.
Ken-

On Nov 1, 2013, at 12:21 PM, Joseph Jackson  wrote:

> Anyone from Integra Telecom who knows their BGP routing on list?  I
> have an open ticket but can't get past the noc techs and the issue is
> a weird one.
> 
> Thanks!
> 

Integra Telecom BGP contact

[Joseph Jackson]

Anyone from Integra Telecom who knows their BGP routing on list?  I
have an open ticket but can't get past the noc techs and the issue is
a weird one.

Thanks!

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Phil Bedard]

On 11/1/13, 1:08 PM, "Gary Buhrmaster"  wrote:

>On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk 
>wrote:
>...
>> It seems as if both Yahoo and Google assumed that since they were
>>private
>> circuits that they didn't have to encrypt.
>
>I actually cannot see them assuming that.  Google
>and Yahoo engineers are smart, and taping fibres
>has been well known for, well, "forever".  I can
>see them making a business decision that the
>costs would be excessive to mitigate against
>taping(*) that would be allowed under the laws
>in any event.
>
>Gary

While smart, most providers make an assumption at least with a piece of
dark fiber the only people with access to it are themselves and any
providers of the fiber.  I don't think that's an unrealistic
expectation... Providers who have trenched their own fiber certainly do
not encrypt traffic across the network, but their fiber is probably no
less susceptible to tapping at certain locations.  There have been a
number of articles in recent years about how vulnerable the fiber
infrastructure is to attacks, tapping, etc.  Vaults, manhole locations,
etc. are pretty much wide open.


Phil 

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Mark Foster]

On Sat, November 2, 2013 6:44 am, David Miller wrote:
> On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
>> On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk 
>> wrote:
>> ...
>>> It seems as if both Yahoo and Google assumed that since they were
>>> private
>>> circuits that they didn't have to encrypt.
>>
>> I actually cannot see them assuming that.  Google
>> and Yahoo engineers are smart, and taping fibres
>> has been well known for, well, "forever".  I can
>> see them making a business decision that the
>> costs would be excessive to mitigate against
>> taping(*) that would be allowed under the laws
>> in any event.
>>
>> Gary
>>
>> (*) "A" mitigation  was run the fibre through your
>> own pressured pipe which you monitored for loss
>> of pressure, so that even a "hot tap" on the pipe
>> itself would possibly be detected (and there are
>> countermeasures to countermeasures
>> to countermeasures of the various methods).
>> And even then, you had to have a someone walk
>> the path from time to time to verify its integrity.
>> And I am pretty sure there is even an NSA/DOD
>> doc on the requirements/implementation to do
>> those mitigations.
>>
>
> Given what we now know about the breadth of the NSA operations, and the
> likelihood that this is still only the tip of the iceberg - would anyone
> still point to NSA guidance on avoiding monitoring with any sort of
> confidence?
>
> There has always been cognitive dissonance in the dual roles of the NSA:
> 1. The NSA monitors.
> 2. The NSA provides guidance on how to avoid being monitored.
>
> Conflict?
>

I don't think so. The folks who actually do it, are the ones who are going
to best know how to avoid it.  Plenty of TV shows bear this out. :-)

I think that failure to encrypt inter-DC traffic that is on dark fibre is
simply on the presumption that corporations are seeking to protect their
links from the actions of 'unauthorised' people.  The telco theyre
contracting presumably have some sort of privacy agreement with them. 
No-one else is supposed to be able to get on the wire.  A risk assessment
pre-Snowdon probably didn't make the performance hits, costs, etc of
high-speed rateable encryption, worthwhile - but the paradigm has shifted.
The government is using 'authorisation' to get access to that dark fibre
link (presumably) and that authority is at the heart of the problem.

When reviewing your risk assessment around the presence (or not) of
encryption on your inter-site links, also consider whether the methods of
encryption available to the private sector havn't also been cracked by the
NSA etc. They had the 'golden standard' for crypto, but one has to wonder
whether that standard includes an undocumented backdoor...

Mark.

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[berry]

> On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:

[...]

>
> Given what we now know about the breadth of the NSA operations, and the
> likelihood that this is still only the tip of the iceberg - would anyone
> still point to NSA guidance on avoiding monitoring with any sort of
> confidence?
>
> There has always been cognitive dissonance in the dual roles of the NSA:
> 1. The NSA monitors.
> 2. The NSA provides guidance on how to avoid being monitored.
>
> Conflict?
>
> -DMM
>
As a local 'barbecue baron' said about his brother's competing
restaurants: "I taught him everything he knows about barbecue. I just
didn't teach him everything _I_ know about barbecue."

Re: large scale ipsec

[Scott Weeks]

--- morrowc.li...@gmail.com wrote:
From: Christopher Morrow 

One good reason to not do link encryption is: "the problem is that
whackadoodle box you put outside the router!" :( most often those
boxes can't do light-level monitoring, loopbacks, etc... all the stuff
your NOC wants to do when 'link flapped,doh!' happens.
-


Yes!  It is really hard to work with those things for the reasons
you mention and they tend to be the culprit quite often.  Also,
a lot of times it adds more finger pointing as there tends to be
a different group taking care of just the bulk encryptors.  Last,
I have seen some strange behaviors, such as not passing BPDUs.
That makes VLANing *phun*.  Not!

scott

Re: large scale ipsec

[Christopher Morrow]

On Fri, Nov 1, 2013 at 1:06 PM, Jan Schaumann  wrote:
> Christopher Morrow  wrote:
>
>> One might look at MS's documentation about deploying end-to-end ipsec
>> in their enterprise for one example of peer-to-peer ubiquitous ipsec.
>
> This is interesting and kind of what I'm looking for.  Do you have a
> pointer to this documentation?

sadly I can't find what I once read :( damned webcrawler search!!!

> My apologies for not having defined "large scale" in my original mail.
> What I had in mind was, basically, environments ranging with multiple
> datacenters (possibly across the globe) pushing tens of gb/s or more.

that's probably a different problem to solve, unless you wanted to
push the crypto down to the server/workstation level, which seems like
a more reasonable answer, for a number of reasons, provided you can do
key management and fault isolation.

One good reason to not do link encryption is: "the problem is that
whackadoodle box you put outside the router!" :( most often those
boxes can't do light-level monitoring, loopbacks, etc... all the stuff
your NOC wants to do when 'link flapped,doh!' happens.

-chris

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Jorge Amodio]

I still have some one time pads if you are good writing fast ...

-J


On Fri, Nov 1, 2013 at 11:26 AM, Randy Bush  wrote:

> > For encryption of traffic between datacenters;There should be very
> > little session setup and teardown  (very few public key operations);
> > almost all the crypto load would be symmetric cryptography.
>
> trivial at 9600 baud between google datacenters
>
>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 02 Nov, 2013

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  470880
Prefixes after maximum aggregation:  189231
Deaggregation factor:  2.49
Unique aggregates announced to Internet: 233598
Total ASes present in the Internet Routing Table: 45368
Prefixes per ASN: 10.38
Origin-only ASes present in the Internet Routing Table:   35324
Origin ASes announcing only one prefix:   16267
Transit ASes present in the Internet Routing Table:5954
Transit-only ASes present in the Internet Routing Table:161
Average AS path length visible in the Internet Routing Table:   4.6
Max AS path length visible:  35
Max AS path prepend of ASN ( 55644)  31
Prefixes from unregistered ASNs in the Routing Table:   720
Unregistered ASNs in the Routing Table: 194
Number of 32-bit ASNs allocated by the RIRs:   5284
Number of 32-bit ASNs visible in the Routing Table:4090
Prefixes from 32-bit ASNs in the Routing Table:   12675
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:889
Number of addresses announced to Internet:   2653744084
Equivalent to 158 /8s, 44 /16s and 235 /24s
Percentage of available address space announced:   71.7
Percentage of allocated address space announced:   71.7
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   95.1
Total number of prefixes smaller than registry allocations:  164648

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   111522
Total APNIC prefixes after maximum aggregation:   33881
APNIC Deaggregation factor:3.29
Prefixes being announced from the APNIC address blocks:  113638
Unique aggregates announced from the APNIC address blocks:47281
APNIC Region origin ASes present in the Internet Routing Table:4884
APNIC Prefixes per ASN:   23.27
APNIC Region origin ASes announcing only one prefix:   1214
APNIC Region transit ASes present in the Internet Routing Table:836
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 35
Number of APNIC region 32-bit ASNs visible in the Routing Table:721
Number of APNIC addresses announced to Internet:  729894080
Equivalent to 43 /8s, 129 /16s and 76 /24s
Percentage of available APNIC address space announced: 85.3

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-63999, 131072-133631
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:162649
Total ARIN prefixes after maximum aggregation:81501
ARIN Deaggregation factor: 2.00
Prefixes being announced from the ARIN address blocks:   163562
Unique aggregates announced from the ARIN address blocks: 75922
ARIN Region origin ASes present in the Internet Routing Table:15916
ARIN Prefixes per ASN:10.28
ARIN Region origin ASes anno

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[David Miller]

On 11/01/2013 01:08 PM, Gary Buhrmaster wrote:
> On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk  wrote:
> ...
>> It seems as if both Yahoo and Google assumed that since they were private
>> circuits that they didn't have to encrypt.
> 
> I actually cannot see them assuming that.  Google
> and Yahoo engineers are smart, and taping fibres
> has been well known for, well, "forever".  I can
> see them making a business decision that the
> costs would be excessive to mitigate against
> taping(*) that would be allowed under the laws
> in any event.
> 
> Gary
> 
> (*) "A" mitigation  was run the fibre through your
> own pressured pipe which you monitored for loss
> of pressure, so that even a "hot tap" on the pipe
> itself would possibly be detected (and there are
> countermeasures to countermeasures
> to countermeasures of the various methods).
> And even then, you had to have a someone walk
> the path from time to time to verify its integrity.
> And I am pretty sure there is even an NSA/DOD
> doc on the requirements/implementation to do
> those mitigations.
> 

Given what we now know about the breadth of the NSA operations, and the
likelihood that this is still only the tip of the iceberg - would anyone
still point to NSA guidance on avoiding monitoring with any sort of
confidence?

There has always been cognitive dissonance in the dual roles of the NSA:
1. The NSA monitors.
2. The NSA provides guidance on how to avoid being monitored.

Conflict?

-DMM



signature.asc
Description: OpenPGP digital signature

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Gary Buhrmaster]

On Fri, Nov 1, 2013 at 4:43 AM, Anthony Junk  wrote:
...
> It seems as if both Yahoo and Google assumed that since they were private
> circuits that they didn't have to encrypt.

I actually cannot see them assuming that.  Google
and Yahoo engineers are smart, and taping fibres
has been well known for, well, "forever".  I can
see them making a business decision that the
costs would be excessive to mitigate against
taping(*) that would be allowed under the laws
in any event.

Gary

(*) "A" mitigation  was run the fibre through your
own pressured pipe which you monitored for loss
of pressure, so that even a "hot tap" on the pipe
itself would possibly be detected (and there are
countermeasures to countermeasures
to countermeasures of the various methods).
And even then, you had to have a someone walk
the path from time to time to verify its integrity.
And I am pretty sure there is even an NSA/DOD
doc on the requirements/implementation to do
those mitigations.

Re: large scale ipsec

[Jan Schaumann]

Christopher Morrow  wrote:
 
> One might look at MS's documentation about deploying end-to-end ipsec
> in their enterprise for one example of peer-to-peer ubiquitous ipsec.

This is interesting and kind of what I'm looking for.  Do you have a
pointer to this documentation?

My apologies for not having defined "large scale" in my original mail.
What I had in mind was, basically, environments ranging with multiple
datacenters (possibly across the globe) pushing tens of gb/s or more.

Though I suppose I'd also be interested in any other scale, both larger
and smaller.  I'd be glad to collect any information you may want to
send me off-list and report back with a summary, if that's preferred.

-Jan


pgpoXg6mnTxQB.pgp
Description: PGP signature

Re: Reverse DNS RFCs and Recommendations

[William Herrin]

On Fri, Nov 1, 2013 at 3:03 AM, Masataka Ohta
 wrote:
> Mark Andrews wrote:
>> That said it is possible to completely automate the secure assignment
>> of PTR records.  It is also possible to completely automate the
>> secure delegation of the reverse name space.  See
>> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.

Howdy,

I hope you don't mean to suggest that a user should be able to use his
normal ISP username and password to set those DNS records which the
ISP has determined that he's allowed to set. That's just crazy talk!

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Randy Bush]

> For encryption of traffic between datacenters;There should be very
> little session setup and teardown  (very few public key operations);
> almost all the crypto load would be symmetric cryptography.

trivial at 9600 baud between google datacenters

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Randy Bush]

>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=1494884
> They must be hiding their content,  for fear that flaws be pointed
> out.

it's the ieee.  what they're hiding is a last century business model.

randy

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Anthony Junk]

Hey expanoit,

There was a small part that jumped out at me when I read the article
earlier:

"In recent years, both of them are said to have bought
or leased thousands of miles of fiber-optic cables for their own exclusive
use. They had reason to think, insiders said, that their private, internal
networks were safe from prying eyes."

It seems as if both Yahoo and Google assumed that since they were private
circuits that they didn't have to encrypt. This would've added cost in
engineering, hardware, and in the end, overall throughput; I would assume
they saw it as a low possibility that anyone would (a) have knowledge of
the their traffic inter-site and (b) would have the ability to not only
accomplish the task but not get caught as well.

This is just my take on the situation and I'm sure there are others more
experienced that could offer a more detailed perspective with much less
speculation. Thanks.


Sincerely,

Anthony R Junk
Network Engineer
(410) 929-1838
anthonyrj...@gmail.com



On Thu, Oct 31, 2013 at 10:48 PM, explanoit
wrote:

> As a top-posting IT generalist pleb, can someone explain why Google/Yahoo
> did not already encrypt their data between DCs?
> Why is my data encrypted over the internet from my computer to theirs, but
> they don't encrypt the data when it goes outside their building and all the
> fancy access controls they like to talk about?
>
> Thank you for your feedback,
> explanoit
>
> On 2013-10-30 13:46, Jacque O'Lantern wrote:
>
>> http://www.washingtonpost.com/**world/national-security/nsa-**
>> infiltrates-links-to-yahoo-**google-data-centers-worldwide-**
>> snowden-documents-say/2013/10/**30/e51d661e-4166-11e3-8b74-**
>> d89d714ca4dd_story.html
>>
>
>

Re: large scale ipsec

[Christopher Morrow]

On Fri, Nov 1, 2013 at 10:30 AM, David Barak  wrote:
> Hi Jan,
>
> Please define "large scale".  Is that by number of endpoints, throughput, or 
> some other metric?  How big is big?
>

it's fair to believe that there are 'lots' of ipsec deployments where
there are ~1000 or so endpoints (network endpoints) connected in a
'vpn'. There are also certainly large volume ipsec deployments (I
recall an ipsec vpn problem at a former company for a single 400mbps
'flow' between endpoints, maybe david remembers this as well).

One might look at MS's documentation about deploying end-to-end ipsec
in their enterprise for one example of peer-to-peer ubiquitous ipsec.

it'd sure be helpful to have some dimensions to the OP's question though.

-chris

Re: large scale ipsec

[David Barak]

Hi Jan,

Please define "large scale".  Is that by number of endpoints, 
throughput, or some other metric?  How big is big?

David Barak

Re: large scale ipsec

[Paul Stewart]

Can you give us an idea of “large scale” in your mind?  Also, site to site
deployments or remote access or both?

Paul


On 11/1/2013, 9:38 AM, "Jan Schaumann"  wrote:

>Hello,
>
>Who here on this list has deployed IPSec or other comparable lower layer
>encryption in a large scale environment, or attempted to do so?
>
>I've repeatedly heard claims that doing so is not feasible (either
>operationally or financially), but I have not seen any specific studies,
>reports, numbers or anything else to support this.  Of course I haven't
>seen anything proving the opposite, either, which is why I'm reaching
>out here on this list.
>
>What was your experience, and what alternatives have you considered?  If
>your findings were made longer than, say, 5 years ago, what might have
>changed to change the results?
>
>-Jan

Re: Reverse DNS RFCs and Recommendations

[Valdis . Kletnieks]

On Fri, 01 Nov 2013 16:03:56 +0900, Masataka Ohta said:
> It is a lot simpler and a lot more practical just to
> use shared secret between a CPE and a ISP's name server
> for TSIG generation.

Hmm.. Shared secret between a CPE you don't necessarily control
and your own DNS server?  This *will* get you a dartboard with
your picture on it at the ISP's help desk.


pgp9_mr_OWSEw.pgp
Description: PGP signature

large scale ipsec

[Jan Schaumann]

Hello,

Who here on this list has deployed IPSec or other comparable lower layer
encryption in a large scale environment, or attempted to do so?

I've repeatedly heard claims that doing so is not feasible (either
operationally or financially), but I have not seen any specific studies,
reports, numbers or anything else to support this.  Of course I haven't
seen anything proving the opposite, either, which is why I'm reaching
out here on this list.

What was your experience, and what alternatives have you considered?  If
your findings were made longer than, say, 5 years ago, what might have
changed to change the results?

-Jan


pgpqk7gg1JECs.pgp
Description: PGP signature

RE: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Lorell Hathcock]

Until you've heard an ex-NSA guy explain to you how this is done, with a
device the size of a brief-case, it can seem a little unbelievable.  I had
that conversation in the late '90s.

-Original Message-
From: Matthew Petach [mailto:mpet...@netflight.com] 
Sent: Thursday, October 31, 2013 8:27 PM
To: Jimmy Hess
Cc: NANOG
Subject: Re: latest Snowden docs show NSA intercepts all Google and Yahoo
DC-to-DC traffic

On Thu, Oct 31, 2013 at 5:53 PM, Jimmy Hess  wrote:

> On Thu, Oct 31, 2013 at 7:24 PM, Matthew Petach
wrote:
>
>> On Thu, Oct 31, 2013 at 7:02 AM, Ray Soucy  wrote:
>> > Was the unplanned L3 DF maintenance that took place on Tuesday a 
>> > frantic removal of taps? :-)
>>
> No need for intrusive techniques such as direct taps:
>>
>> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumbe
>> r=1494884
>>
>
> For shame you've  sent in a link to some article behind a paywall, 
> with some insane download fee.
> Which is an equivalent of hand-waving.
>
> They must be hiding their content,  for fear that flaws be pointed out.
>

Oy...OK, let me find a document that spells it out a bit more clearly for
you.


>
>
> "Of all the techniques, the bent fiber tap is the most easily deployed 
> with
>> minimal risk of damage or detection. The paper quantifies the bend 
>> loss required to tap a signal propagating in a single mode fiber"
>>
>
> There will be some wavelengths of light, that may be on the cable, that
> bending won't get a useful signal from.
>
> Bending the cable sufficiently to  break  the total internal reflection
>  property,  and allow light to leak --  will generate power losses in the
> cable,  that can be identified  on an OTDR.
>

This patent covers a technique developed to do
non-intrusive optical tapping with a 0.5" microbend,
with only 0.5dB signal loss:

http://www.google.com/patents/CA2576969C

Most people aren't going to be able to tell a
0.5dB loss from a microbend tap from a splice
job.

Matt



>
>
>
>> Matt
>>
> --
> -JH
>

Re: latest Snowden docs show NSA intercepts all Google and Yahoo DC-to-DC traffic

[Jimmy Hess]

On Thu, Oct 31, 2013 at 11:26 PM, Michael Still  wrote:

> [snip]
>


> Its about the CPU cost of the crypto. I was once told the number of
> CPUs required to do SSL on web search (which I have now forgotten) and
> it was a bigger number than you'd expect -- certainly hundreds.
>
So, crypto costs money at scale basically.
>

SSL Cryptography for web search is a different problem than, say
 Site-to-Site VPN encryption.

Every time a new browser connects, you have a new SSL session setup.
New SSL session setup requires  public cryptography operations which impose
a significant delay, and the public key operations have an enormous CPU
cost.

So much so,  that the key generation and signing operations involved in CPU
session setup are a big bottleneck, and therefore, a potential DoS risk.

For encryption of traffic between datacenters;There should be very
little session setup and teardown  (very few public key operations);
 almost all the crypto load would be symmetric cryptography.


No doubt, there still  must be some cost in terms of crypto processors
required to achieve encryption of all the traffic on 100-gigabit links
 between datacenters;  it's always something, after all.






>
> Cheers,
> Michael
>
>


-- 
-JH

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

Mark Andrews wrote:

> That said it is possible to completely automate the secure assignment
> of PTR records.  It is also possible to completely automate the
> secure delegation of the reverse name space.  See
> http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00

It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.

As the secret can be directly shared end to end, it is more
secure than DNSSEC involving untrustworthy third parties.

Masataka Ohta