Re: Pointer for documentation on actually delivering IPv6

[Truman Boyes]

On 6 Dec 2010, at 11:07 PM, Owen DeLong wrote:

> 
> On Dec 6, 2010, at 6:55 AM, Jared Mauch wrote:
> 
>> 
>> On Dec 6, 2010, at 8:35 AM, Jeff Johnstone wrote:
>> 
>>> Speaking of IPV6 security, is there any movement towards any open source
>>> IPV6 firewall solutions for the consumer / small business?
>>> 
>>> Almost all the info I've managed to find to date indicates no support, nor
>>> any planned support in upcoming releases.
>>> 
>>> Any info would be helpful.
>> 
>> Honestly (and I'm sure some IPv6 folks will want me injured as a result) 
>> there should be some '1918-like' space allocated for the corporate guys who 
>> "don't get it", so they can nat everyone through a single /128.  It would 
>> make life easier for them and quite possibly be a large item in pushing ipv6 
>> deployment in the enterprise.
>> 
> Yes... Those of us who would like to see sanity return to the internet would 
> prefer to have you lynched for such heresy. ;-)
> 
> Seriously, though, you're welcome to use fd00::/8 for exactly that purpose. 
> The problem is that you (and hopefully it stays this way)
> won't have much luck finding a vendor that will provide the NAT for you to do 
> it with.

You can of course use Unique Local IPv6 Unicast Addresses internally. (RFC 
4193). And if you wanted you could NAT66. But, this is not an ideal way to 
design a network. The benefit of RFC1918 addresses is that you can easily know 
the perimeter of your global reachability. You can achieve the same with public 
IPv6 by *knowing* your security policy. Public addresses on internal 
infrastructure are quite normal. 


>> I don't see our corporate IT guys that number stuff in 1918 space wanting to 
>> put hosts on 'real' ips.  The chances for unintended routing are enough to 
>> make them say that v6 is actually a security risk vs security enabler is my 
>> suspicion.
>> 
> There are multiple easy ways to solve this problem that don't require the use 
> of NAT or the damage that comes with it.
> 
> First, let's clarify things a bit. I don't think unintended routing is what 
> concerns your IT guys. Afterall, even with the NAT
> box today, there's routing from the outside to the inside. It's just 
> controlled by stateful inspection.
> 
> It's trivial to implement an IPv6 default-deny-inbound stateful inspection 
> policy that provides exactly the same security
> model as is afforded by the current NAT box in IPv4 without mangling the 
> packet headers. The rest is superstition.
> Admittedly, superstition is powerful among IT professionals, especially in 
> the enterprise world. So strong that people
> on this very list who I generally respect and consider to be good competent 
> professionals tell me that I'm flat out
> wrong about it.
> 
> However, not one of them has been able to produce an argument that actually 
> stands up to scrutiny. The closest they
> can come is what happens when someone misconfigures something. However, I've 
> always been able to show that
> it's equally easy to make fatal misconfigurations on the NAT box with just as 
> dire consequences.
> 
> Owen


I agree with Owen. You could NAT66, but seriously, why bother with all that 
headache in implementing v6 on your hosts and then putting all sessions through 
NAT. IPv6 security policy would be more explicit security than a NAT perimeter. 

Truman

Re: ARIN space not accepted

[Jeroen van Aart]

From: valdis.kletni...@vt.edu

From: valdis.kletni...@vt.edu

Date: Fri, 03 Dec 2010 20:00:15 -0500



224/3

Oh. And don't forget to do *bidirectional* filtering of these addresses. ;)

Ahh, not quite. Blocking 224/3 bi-directionally might cause a few issues
if you accept multicast traffic from anyone.


240/4 appears to be reserved for "Future use"...

"[15] Reserved for future use (formerly "Class E") [RFC1112]"

--
http://goldmark.org/jeff/stupid-disclaimers/
http://linuxmafia.com/~rick/faq/plural-of-virus.html

Re: ipfix/netflow/sflow generator for Linux

[Eric S. Johnson]

>fprobe doesn't work properly because it has the input and output interface
>IDs as both 0.

fprobe-ulog fixes this. From the http://fprobe.sourceforge.net/ front page:

fprobe-ulog - libipulog-based fork of fprobe. It obtains packets
through linux netfilter code (iptables ULOG target). The main
advantages of this version are native input/output interface
SNMP-index support and significant performance benefit. Of course,
this version work on linux only.

We have used it here for a few years and have been quite happy with it.

E

Re: ipfix/netflow/sflow generator for Linux

[Yiming Gong]

Try PMACCT, it is pretty handy.

Yiming

On 12/06/2010 01:15 PM, Thomas York wrote:

At my current place of work, we use all Linux routers. I need to do some IP
accounting/reporting and am currently trying to use Scrutinizer. Scrutinizer
can use netstream, jstream, ipfix, netflow, and sflow data without qualms.
My only issue is that I can't seem to find any good software for Linux that
works with multiple interfaces to generate the flow information. I've tried
ndsad, nprobe, softflowd, host sflow, and ipcad without much luck. Most of
the software only works on one interface (which is useless as I need to do
accounting for numerous interfaces).



I've had the best luck with ipcad. The only thing that seems to not work
with it is that it doesn't correctly give the interface number in the flow
information. It refers to all interfaces as interface 65535. I've tried the
config option for ipcad to map an interface directly to an SNMP interface
ID, but that option of the config file seems to be ignored.



Ntop functionally does exactly what I need, but it's extremely buggy. It
segfaults after a few minutes, regardless of Linux distro or Ntop version.
So..any ideas on what I can do to get good flow information from our Linux
routers?

Re: ipfix/netflow/sflow generator for Linux

[Dobbins, Roland]

On Dec 7, 2010, at 4:24 AM, Thomas York wrote:

> It can, but then you are setting the input/output IDs statically. That would
> work fine if your router only had 2 interfaces. 

With a probe of this type, northbound/southbound tagging is generally 
sufficient, in my experience (i.e., let's not make the perfect the enemy of the 
merely good).

;>

---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

RE: ipfix/netflow/sflow generator for Linux

[Thomas York]

It can, but then you are setting the input/output IDs statically. That would
work fine if your router only had 2 interfaces. We currently have routers
with a single (or few) WAN interfaces and multiple internal interfaces and
there isn't any way to statically categorize the data.

-Original Message-
From: Dobbins, Roland [mailto:rdobb...@arbor.net] 
Sent: Monday, December 06, 2010 4:20 PM
To: North American Network Operators Group
Subject: Re: ipfix/netflow/sflow generator for Linux


On Dec 7, 2010, at 3:44 AM, Thomas York wrote:

> fprobe doesn't work properly because it has the input and output interface
IDs as both 0.


IIRC, this can be altered via a config change.

---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

Re: ipfix/netflow/sflow generator for Linux

[Dobbins, Roland]

On Dec 7, 2010, at 3:44 AM, Thomas York wrote:

> fprobe doesn't work properly because it has the input and output interface 
> IDs as both 0.


IIRC, this can be altered via a config change.

---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

RE: ipfix/netflow/sflow generator for Linux

[Thomas York]

Never heard of it. I'll give it a shot. Another project that uses argus also
looks interesting.. http://nautilus.oshean.org/wiki/Periscope

-Original Message-
From: Ken A [mailto:k...@pacific.net] 
Sent: Monday, December 06, 2010 4:04 PM
To: nanog@nanog.org
Subject: Re: ipfix/netflow/sflow generator for Linux

Have you considered argus?
It can deliver "argus flows" from multiple interfaces.
 From http://www.qosient.com/argus/ :

> Argus can be considered an implementation of the architecture 
> described in the IETF IPFIX Working Group. Argus pre-dates IPFIX, and 
> the project has actively contributed to the IPFIX effort, however, 
> Argus technology should be considered a superset of the IPFIX 
> architecture, providing "proof of concept" implementations for most 
> aspects of the IPFIX applicability statement. Argus technology can 
> read and process Cisco Netflow data, and many sites develop audits 
> using a mixture of Argus and Netflow records.

Ken


On 12/6/2010 2:44 PM, Thomas York wrote:
> fprobe doesn't work properly because it has the input and output 
> interface IDs as both 0. In Scrutinizer, this makes the flow look like 
> all the data came in the interface and immediately left via the same 
> interface. Also, this causes problems when running multiple instances 
> of fprobe.
>
> This seems to be the issue with most of the flow software I've tried.
>
> -Original Message- From: Samuel Petreski 
> [mailto:sp...@georgetown.edu] Sent: Monday, December 06, 2010 3:38 PM 
> To: 'Thomas York'; nanog@nanog.org Subject: RE:
> ipfix/netflow/sflow generator for Linux
>
> I've used fprobe with great success. You can run multiple instances of 
> fprobe for the different interfaces.
>
> --Samuel
>
> fprobe: a NetFlow probe - libpcap-based tool that collects network 
> traffic data and emit it as NetFlow flows towards the specified 
> collector.
>
> WWW: http://sourceforge.net/projects/fprobe
>
> -- Samuel Petreski Sr. Security Analyst Georgetown University
>
>> -Original Message- From: Thomas York 
>> [mailto:strate...@fuhell.com] Sent: Monday, December 06, 2010 2:15 PM 
>> To: nanog@nanog.org Subject: ipfix/netflow/sflow generator for Linux
>>
>> At my current place of work, we use all Linux routers. I need to do 
>> some
> IP
>> accounting/reporting and am currently trying to use Scrutinizer.
> Scrutinizer
>> can use netstream, jstream, ipfix, netflow, and sflow data without 
>> qualms. My only issue is that I can't seem to find any good software 
>> for Linux
> that
>> works with multiple interfaces to generate the flow information.
>> I've
> tried
>> ndsad, nprobe, softflowd, host sflow, and ipcad without much luck.
>> Most of the software only works on one interface (which is useless as 
>> I need to do accounting for numerous interfaces).
>>
>>
>>
>> I've had the best luck with ipcad. The only thing that seems to not 
>> work
> with
>> it is that it doesn't correctly give the interface number in the flow 
>> information. It refers to all interfaces as interface 65535.
>> I've tried
> the config
>> option for ipcad to map an interface directly to an SNMP interface 
>> ID, but that option of the config file seems to be ignored.
>>
>>
>>
>> Ntop functionally does exactly what I need, but it's extremely buggy. 
>> It segfaults after a few minutes, regardless of Linux distro or Ntop
> version.
>> So..any ideas on what I can do to get good flow information from our 
>> Linux routers?
>
>
>
>
>

--
Ken Anderson
Pacific Internet - http://www.pacific.net

Re: ipfix/netflow/sflow generator for Linux

[Ken A]

Have you considered argus?
It can deliver "argus flows" from multiple interfaces.
From http://www.qosient.com/argus/ :


Argus can be considered an implementation of the architecture
described in the IETF IPFIX Working Group. Argus pre-dates IPFIX, and
the project has actively contributed to the IPFIX effort, however,
Argus technology should be considered a superset of the IPFIX
architecture, providing "proof of concept" implementations for most
aspects of the IPFIX applicability statement. Argus technology can
read and process Cisco Netflow data, and many sites develop audits
using a mixture of Argus and Netflow records.


Ken


On 12/6/2010 2:44 PM, Thomas York wrote:

fprobe doesn't work properly because it has the input and output
interface IDs as both 0. In Scrutinizer, this makes the flow look
like all the data came in the interface and immediately left via the
same interface. Also, this causes problems when running multiple
instances of fprobe.

This seems to be the issue with most of the flow software I've
tried.

-Original Message- From: Samuel Petreski
[mailto:sp...@georgetown.edu] Sent: Monday, December 06, 2010 3:38
PM To: 'Thomas York'; nanog@nanog.org Subject: RE:
ipfix/netflow/sflow generator for Linux

I've used fprobe with great success. You can run multiple instances
of fprobe for the different interfaces.

--Samuel

fprobe: a NetFlow probe - libpcap-based tool that collects network
traffic data and emit it as NetFlow flows towards the specified
collector.

WWW: http://sourceforge.net/projects/fprobe

-- Samuel Petreski Sr. Security Analyst Georgetown University


-Original Message- From: Thomas York
[mailto:strate...@fuhell.com] Sent: Monday, December 06, 2010 2:15
PM To: nanog@nanog.org Subject: ipfix/netflow/sflow generator for
Linux

At my current place of work, we use all Linux routers. I need to
do some

IP

accounting/reporting and am currently trying to use Scrutinizer.

Scrutinizer

can use netstream, jstream, ipfix, netflow, and sflow data without
qualms. My only issue is that I can't seem to find any good
software for Linux

that

works with multiple interfaces to generate the flow information.
I've

tried

ndsad, nprobe, softflowd, host sflow, and ipcad without much luck.
Most of the software only works on one interface (which is useless
as I need to do accounting for numerous interfaces).



I've had the best luck with ipcad. The only thing that seems to
not work

with

it is that it doesn't correctly give the interface number in the
flow information. It refers to all interfaces as interface 65535.
I've tried

the config

option for ipcad to map an interface directly to an SNMP interface
ID, but that option of the config file seems to be ignored.



Ntop functionally does exactly what I need, but it's extremely
buggy. It segfaults after a few minutes, regardless of Linux distro
or Ntop

version.

So..any ideas on what I can do to get good flow information from
our Linux routers?








--
Ken Anderson
Pacific Internet - http://www.pacific.net

RE: ipfix/netflow/sflow generator for Linux

[Thomas York]

fprobe doesn't work properly because it has the input and output interface
IDs as both 0. In Scrutinizer, this makes the flow look like all the data
came in the interface and immediately left via the same interface. Also,
this causes problems when running multiple instances of fprobe. 

This seems to be the issue with most of the flow software I've tried.

-Original Message-
From: Samuel Petreski [mailto:sp...@georgetown.edu] 
Sent: Monday, December 06, 2010 3:38 PM
To: 'Thomas York'; nanog@nanog.org
Subject: RE: ipfix/netflow/sflow generator for Linux

I've used fprobe with great success. You can run multiple instances of
fprobe for the different interfaces.  

--Samuel

fprobe: a NetFlow probe - libpcap-based tool that collects network traffic
data and emit it as NetFlow flows towards the specified collector.

WWW: http://sourceforge.net/projects/fprobe

--
Samuel Petreski
Sr. Security Analyst
Georgetown University

> -Original Message-
> From: Thomas York [mailto:strate...@fuhell.com]
> Sent: Monday, December 06, 2010 2:15 PM
> To: nanog@nanog.org
> Subject: ipfix/netflow/sflow generator for Linux
> 
> At my current place of work, we use all Linux routers. I need to do 
> some
IP
> accounting/reporting and am currently trying to use Scrutinizer.
Scrutinizer
> can use netstream, jstream, ipfix, netflow, and sflow data without qualms.
> My only issue is that I can't seem to find any good software for Linux
that
> works with multiple interfaces to generate the flow information. I've
tried
> ndsad, nprobe, softflowd, host sflow, and ipcad without much luck. 
> Most of the software only works on one interface (which is useless as 
> I need to do accounting for numerous interfaces).
> 
> 
> 
> I've had the best luck with ipcad. The only thing that seems to not 
> work
with
> it is that it doesn't correctly give the interface number in the flow 
> information. It refers to all interfaces as interface 65535. I've 
> tried
the config
> option for ipcad to map an interface directly to an SNMP interface ID, 
> but that option of the config file seems to be ignored.
> 
> 
> 
> Ntop functionally does exactly what I need, but it's extremely buggy. 
> It segfaults after a few minutes, regardless of Linux distro or Ntop
version.
> So..any ideas on what I can do to get good flow information from our 
> Linux routers?

RE: ipfix/netflow/sflow generator for Linux

[Samuel Petreski]

I've used fprobe with great success. You can run multiple instances of
fprobe for the different interfaces.  

--Samuel

fprobe: a NetFlow probe - libpcap-based tool that collects
network traffic data and emit it as NetFlow flows towards the
specified collector.

WWW: http://sourceforge.net/projects/fprobe

--
Samuel Petreski
Sr. Security Analyst
Georgetown University

> -Original Message-
> From: Thomas York [mailto:strate...@fuhell.com]
> Sent: Monday, December 06, 2010 2:15 PM
> To: nanog@nanog.org
> Subject: ipfix/netflow/sflow generator for Linux
> 
> At my current place of work, we use all Linux routers. I need to do some
IP
> accounting/reporting and am currently trying to use Scrutinizer.
Scrutinizer
> can use netstream, jstream, ipfix, netflow, and sflow data without qualms.
> My only issue is that I can't seem to find any good software for Linux
that
> works with multiple interfaces to generate the flow information. I've
tried
> ndsad, nprobe, softflowd, host sflow, and ipcad without much luck. Most of
> the software only works on one interface (which is useless as I need to do
> accounting for numerous interfaces).
> 
> 
> 
> I've had the best luck with ipcad. The only thing that seems to not work
with
> it is that it doesn't correctly give the interface number in the flow
> information. It refers to all interfaces as interface 65535. I've tried
the config
> option for ipcad to map an interface directly to an SNMP interface ID, but
> that option of the config file seems to be ignored.
> 
> 
> 
> Ntop functionally does exactly what I need, but it's extremely buggy. It
> segfaults after a few minutes, regardless of Linux distro or Ntop version.
> So..any ideas on what I can do to get good flow information from our Linux
> routers?

Re: ipfix/netflow/sflow generator for Linux

[Matthew Palmer]

On Mon, Dec 06, 2010 at 02:15:10PM -0500, Thomas York wrote:
> I've had the best luck with ipcad. The only thing that seems to not work
> with it is that it doesn't correctly give the interface number in the flow
> information. It refers to all interfaces as interface 65535. I've tried the
> config option for ipcad to map an interface directly to an SNMP interface
> ID, but that option of the config file seems to be ignored.
> 
> Ntop functionally does exactly what I need, but it's extremely buggy. It
> segfaults after a few minutes, regardless of Linux distro or Ntop version.
> So..any ideas on what I can do to get good flow information from our Linux
> routers?

Fix ipcad to send the interface number.

- Matt

-- 
Just because we work at a University doesn't mean we're surrounded by smart
people.
-- Brian Kantor, in the monastery

Re: ipfix/netflow/sflow generator for Linux

[Jack Carrozzo]

IPtraf can be setup to look at flows per-block, per interface, per vlan, etc
and export the data every minute / 5 minutes. Back in the day I had it
scripted to dump data into rrdtool and give pretty graphs. See the man page,
it's well written.

Cheers,

-Jack Carrozzo

On Mon, Dec 6, 2010 at 2:15 PM, Thomas York  wrote:

> At my current place of work, we use all Linux routers. I need to do some IP
> accounting/reporting and am currently trying to use Scrutinizer.
> Scrutinizer
> can use netstream, jstream, ipfix, netflow, and sflow data without qualms.
> My only issue is that I can't seem to find any good software for Linux that
> works with multiple interfaces to generate the flow information. I've tried
> ndsad, nprobe, softflowd, host sflow, and ipcad without much luck. Most of
> the software only works on one interface (which is useless as I need to do
> accounting for numerous interfaces).
>
>
>
> I've had the best luck with ipcad. The only thing that seems to not work
> with it is that it doesn't correctly give the interface number in the flow
> information. It refers to all interfaces as interface 65535. I've tried the
> config option for ipcad to map an interface directly to an SNMP interface
> ID, but that option of the config file seems to be ignored.
>
>
>
> Ntop functionally does exactly what I need, but it's extremely buggy. It
> segfaults after a few minutes, regardless of Linux distro or Ntop version.
> So..any ideas on what I can do to get good flow information from our Linux
> routers?
>
>

ipfix/netflow/sflow generator for Linux

[Thomas York]

At my current place of work, we use all Linux routers. I need to do some IP
accounting/reporting and am currently trying to use Scrutinizer. Scrutinizer
can use netstream, jstream, ipfix, netflow, and sflow data without qualms.
My only issue is that I can't seem to find any good software for Linux that
works with multiple interfaces to generate the flow information. I've tried
ndsad, nprobe, softflowd, host sflow, and ipcad without much luck. Most of
the software only works on one interface (which is useless as I need to do
accounting for numerous interfaces). 

 

I've had the best luck with ipcad. The only thing that seems to not work
with it is that it doesn't correctly give the interface number in the flow
information. It refers to all interfaces as interface 65535. I've tried the
config option for ipcad to map an interface directly to an SNMP interface
ID, but that option of the config file seems to be ignored.

 

Ntop functionally does exactly what I need, but it's extremely buggy. It
segfaults after a few minutes, regardless of Linux distro or Ntop version.
So..any ideas on what I can do to get good flow information from our Linux
routers?

Re: How do you do rDNS for IPv6 ?

[Jay Ashworth]

 Original Message -
> From: "Jared Mauch" 

> Anyone done this dynamic synthesis w/ bind? dnssec thoughts as well? i
> know this isn't namedroppers, but perhaps someone can post some code
> or examples, or a link to a webpage with them?

Earthlink, I believe; DENTS has a module for doing this for reverse DNS.

I think it was called DENTS; there's a white paper on it, but it's pretty
rough to Google, as you might expect.

So far as I can see, they still use it; my sis is an EL cablemodem customer,
and her rDNS is algorithmically generated.

Cheers,
-- jra

Re: How do you do rDNS for IPv6 ?

[Jared Mauch]

On Dec 5, 2010, at 9:41 PM, Jima wrote:

> On 12/5/2010 4:13 PM, John Levine wrote:
>> In IPv4 land, it is standard to assign matching forward and reverse
>> DNS for every live IP, and a fair number of services treat requests
>> from hosts without rDNS with added scepticism. For consumer networks,
>> it's often something like 12-34-56-78.adsl.incompetent.net, with the
>> numbers being the IP address forward or backwards.
>> 
>> So if every customer gets a /64, what do you do?  You can use a
>> wildcard to give the same rDNS to all 2^64 addresses, but you can't do
>> matching forward DNS, since a DNS response with 2^64  records
>> would be, ah, a little unwieldy.
> 
> I thought the same thing, actually, which is why I made my own solution.  I 
> ended up writing a DNS server in perl (using Net::DNS::Nameserver) that 
> replies to reverse queries with a reproducible PTR -- generated by encoding 
> the IP in base32.  (Or the second half of the IP, in the case of a few 
> "known" networks.)  Forward queries for the matching name decode the base32.
> The host-specific part of the DNS is kind of long (26 characters, or 13 for 
> known networks), but it's marginally shorter than the full IP (which would be 
> 32/16 characters, without separators).  I'm pretty happy with the results, 
> but I'd love to hear if anyone's come up with more elegant solutions.

Anyone done this dynamic synthesis w/ bind?  dnssec thoughts as well?  i know 
this isn't namedroppers, but perhaps someone can post some code or examples, or 
a link to a webpage with them? 

- Jared

Multipoint VPLS mapping to MEF E-TREE

[Francois Menard]

Is there anyone out there who has a position on whether it is worth the effort 
to map Multi-root EVPL (E-TREE) atop VPLS or to await for PBB-TE and MEF to 
come up with somekind of a common roadmap ?

F.

On 2010-12-03, at 10:26 AM, Manu Chao wrote:

> I have only GRT and L3VPN traffic and would like to use MPLS forwarding only
> for L3VPN.
> 
> Is it possible?
> 
> Thanks & Best Regards,
> Manu

Re: Cloud proof of failure - was:: wikileaks unreachable

[Jack Bates]

On 12/6/2010 9:29 AM, Nathan Eisenberg wrote:


How is it more or less unattractive than having one's own servers in
one's own office?  Lieberman and Co would simply have leaned on Mom's
Best BGP (r) and Pop's Fastest Packets (r) instead of on Amazon, and
the result would have been the same.



That is a possibility, though it also depends on the business mentality 
and AUP. The problem is, it didn't necessarily require any *leaning* and 
the AUP may have been enforced anyways.



That's the catch with this here series of tubes - you don't control
all of the tubes, even if you're Amazon, or Giant National ISP Co, or
Massive National Fiber Plant Co.  The server infrastructure is the
least interesting part of what happened to WikiLeaks.



Anytime you are dealing with something highly controversial, you open 
yourself up for technical and social attack. Your business dependencies 
may be inclined to disassociate themselves with you on any grounds 
possible; not that they disagree with you, but perhaps they don't want 
to be that closely associated.


It does not require any leaning, notification, or even noticeable 
service effect for me to decide to shutdown a site/location which is 
controversial in nature and causing a DOS. If I sold a 'bulletproof' 
service, I'd have a different through process, but that's because I'd be 
selling such a service. I don't sell 'bulletproof', and so I'm quickly 
inclined to request/takedown anything which causes technical/social 
issues for the network per the AUP.


What the Senators did was wrong, but what Amazon did may have not been 
due to the pressure, but strictly based on "oh, we didn't notice that, 
and it's violating our AUP." I'm not saying it's the case, but it does 
happen. I've had to have others tell me of AUP violations from time to time.



Jack

Re: (wikileaks) Fwd: [funsec] And Google becomes a DNS..

[Ken A]

On 12/5/2010 9:50 AM, Gadi Evron wrote:

I withhold comment... "discuss amongst yourselves".

Best,

Gadi.


 Original Message 
Subject: [funsec] And Google becomes a DNS..
Date: Sun, 5 Dec 2010 17:34:50 +0200
From: Imri Goldberg 
To: funsec 


Found on reddit:
http://i.imgur.com/Q5SVu.png



Google has access to historical DNS, and end users, so they could assist 
end users in also reaching VHosted web sites that did not have current 
or reachable DNS, if that is the goal. Something as simple as a browser 
addon that modified the http host header. There are manual ways of doing 
this now, using the Modify Headers Add-on for Firefox, for example.


Ken

--
Ken Anderson
Pacific Internet - http://www.pacific.net

Re: Want to move to all 208V for server racks

[Lamar Owen]

On Saturday, December 04, 2010 05:52:09 pm Kevin Oberman wrote:
> Lead-acid batteries can deliver way over 100 amps of current and a
> conductor across "safe" voltage will get hot and, if not heavy enough,
> will vaporize. 

Our smallish 540Ah -48VDC plant has a 35,000A short circuit rating; important 
to know when sizing the disconnect breaker, as 50,000AIC breakers are required 
for that.  The A and B side rectifiers are Lorrain 200A three phase units, 
built like tanks.

We have a secondary 12V plant at one solar location that is using six 2,320Ah 
cells which required two disconnects in series to meet AIC ratings, since the 
nearly 100,000A short circuit current makes it difficult to get small (<100A) 
breakers with 100,000+AIC ratings.

We're doing the solar thing for our optical telescopes, using Xantrex 
inverter/chargers and Outback solar charge controllers, 24VDC nominal strings.  
Works great; DC input switches make it even nicer, although you then need low 
voltage cutoffs to prevent battery damage when there have been several days in 
a row of dark skies.

At the 5ESS in Buckhead/Brookhaven I recall seeing an operating A buss current 
of >20KA years ago; the AIC on that plant has to be huge (of course, that's 
been 25+ years, and that's my memory, which could be mistaken as to the exact 
current value).  A technician there told me he had seen an 18 inch adjustable 
wrench totally vaporized when it bridged from B- to ground.

Yeah, not something to play with.

Re: Pointer for documentation on actually delivering IPv6

[Dobbins, Roland]

On Dec 6, 2010, at 10:49 PM, Jack Bates wrote:

> So does NAT add to security? Yes; just not very much. 

It adds nothing which can't be added in another, better way, and it subtracts a 
great deal in terms of instantiating unnecessary DoSable stateful chokepoints 
in the network, not to mention breaking traceback.

NAT <> security.  NAT is a net security negative.

---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

Re: How do you do rDNS for IPv6 ?

[Jack Bates]

On 12/5/2010 4:25 PM, Felipe Zanchet Grazziotin wrote:


There are other useful tips too, including ideas for PowerDNS and Bind.



Yeah, PowerDNS already supports generating /PTR on the fly. I'm more 
of the opinion that generic hosts shouldn't have rDNS, but that will 
depend on banks and other institutions who sometimes make it a requirement.



Jack

Re: Pointer for documentation on actually delivering IPv6

[Joe Greco]

> First, let's clarify things a bit. I don't think unintended routing is =
> what concerns your IT guys. Afterall, even with the NAT
> box today, there's routing from the outside to the inside. It's just =
> controlled by stateful inspection.

It might be better stated differently.

With NAT, routing from the outside to the inside is controlled by
stateful inspection and also by internal policy.  In what we usually
mean as IPv4 NAT in today's usage, there is not supposed to be a way
for an outside attacker to target a particular inside destination,
even if its address were known.  1918 space isn't globally routed
and the "real" external IP address is the only thing your firewall
has to go on; internal policy controls what happens to unsolicited
traffic.

With IPv6 and a stateful firewall, an outside attacker gains the
ability to address devices within your network, even if he is unable
to actually cause packets to arrive at that target thanks to your
firewall.

There's a fundamental difference here that scares some people.  They
fear an inadvertent dropping of their stateful firewall ruleset, for
example, or maybe even bypassing of the firewall through misconfig or
other perils at the network level.

You won't make much progress on these fears because there's genuinely
something to them.  What we really need are killer IPv6 apps that
can't easily be NAT'd.  :-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Pointer for documentation on actually delivering IPv6

[Jack Bates]

On 12/6/2010 9:07 AM, Owen DeLong wrote:

Seriously, though, you're welcome to use fd00::/8 for exactly that
purpose. The problem is that you (and hopefully it stays this way)
won't have much luck finding a vendor that will provide the NAT for
you to do it with.



Corporate IT community *expects* a broken Internet. They aren't doing 
their jobs if they haven't broken everything and it's dog. Vendors will 
provide what their customers demand, so there will be NAT on the 
corporate firewalls.


What I don't want to see is NAT on home routers.


There are multiple easy ways to solve this problem that don't require
the use of NAT or the damage that comes with it.



Corporations thrive on damaging traffic, and many prefer NAT. Every 
instinct in their body screams that removing NAT is bad, and you won't 
win that argument.



First, let's clarify things a bit. I don't think unintended routing
is what concerns your IT guys. Afterall, even with the NAT box today,
there's routing from the outside to the inside. It's just controlled
by stateful inspection.


1918 space generally isn't routed to their firewall from the outside, so 
some mistakes that leave the inside vulnerable are actually somewhat 
protected by using 1918 space which isn't routed. It's a limited 
scenario, but what every corp IT guy I know points to.



So strong that people on this very list who I generally respect and
consider to be good competent professionals tell me that I'm flat
out wrong about it.


It's not superstition that the IP addresses assigned to the inside 
aren't routed from the upstream to to outside interface of the firewall. 
ie, when NAT/SPI is broken, the traffic itself breaks, not a sudden "We 
are wide open!" event.


This is not about *proper* security. It is about the extra gain when 
someone screws up and kills the firewall ruleset. In a 1 to 1 NAT 
environment, losing your SPI would be bad. In a 1 to N NAT environment, 
a majority of the machines can never be reached if the SPI/NAT engine 
dies (unless the upstream suddenly adds a 1918 route to reach them).




However, not one of them has been able to produce an argument that
actually stands up to scrutiny. The closest they can come is what
happens when someone misconfigures something. However, I've always
been able to show that it's equally easy to make fatal
misconfigurations on the NAT box with just as dire consequences.


It is possible, yes. However, in the case of an overloaded NAT without 
port forwarding, there is no way to reach the backend hosts unless the 
upstream adds a route to the 1918 space behind the firewall. This is 
what people object to. A single route. That's it. If NAT doesn't work, 
the route is required. Without NAT, if your SPI doesn't work, the route 
is already there and you may have defaulted open.


So does NAT add to security? Yes; just not very much. It covers one 
condition; that is all. For that condition, you have a huge amount of 
service breakage. For a corporate network, this may be perfectly fine 
and acceptable.



Jack

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

[Patrick W. Gilmore]

On Dec 6, 2010, at 10:34 AM, David Ulevitch  wrote:
> On Mon, Dec 6, 2010 at 6:10 AM, Patrick W. Gilmore  wrote:
>> On Dec 6, 2010, at 4:07 AM, Jonas Frey (Probe Networks) wrote:
>> 
>>> Besides having *alot* of bandwidth theres not really much you can do to
>>> mitigate. Once you have the bandwidth you can filter (w/good hardware).
>>> Even if you go for 802.3ba with 40/100 Gbps...you'll need alot of pipes.
>> 
>> There is a variation on that theme.  Using a distributed architecture 
>> (anycast, CDN, whatever), you can limit the attack to certain nodes.  If you 
>> have 20 nodes and get attacked from a botnet China, only the users on the 
>> same node as the Chinese use will be down.  The other 95% of your users will 
>> be fine.  This is true even if you have 1 Gbps per node, and the attack is 
>> 100 Gbps strong.
> 
> I think this is only true if you run your BGP session on a different
> path (or have your provider pin down a static route).

You are assuming many things - such as the fact bgp is used at all.

But yes, of course you have to ensure the attack traffic does not move when you 
get attacked or you end up with a domino effect that takes out your entire 
infrastructure.


> But as you and others have pointed out, not a lot of defense against
> DDoS these days besides horsepower and anycast. :-)

Not just anycast.  I said distributed architecture.  There are more ways to 
distribute than anycast.

Not everything is limited to 13 IP addresses at the GTLDs, David. :-)

-- 
TTFN,
patrick

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

[David Ulevitch]

On Mon, Dec 6, 2010 at 6:10 AM, Patrick W. Gilmore  wrote:
> On Dec 6, 2010, at 4:07 AM, Jonas Frey (Probe Networks) wrote:
>
>> Besides having *alot* of bandwidth theres not really much you can do to
>> mitigate. Once you have the bandwidth you can filter (w/good hardware).
>> Even if you go for 802.3ba with 40/100 Gbps...you'll need alot of pipes.
>
> There is a variation on that theme.  Using a distributed architecture 
> (anycast, CDN, whatever), you can limit the attack to certain nodes.  If you 
> have 20 nodes and get attacked from a botnet China, only the users on the 
> same node as the Chinese use will be down.  The other 95% of your users will 
> be fine.  This is true even if you have 1 Gbps per node, and the attack is 
> 100 Gbps strong.

I think this is only true if you run your BGP session on a different
path (or have your provider pin down a static route).  If you are
using BGP and run it on the same path, the 100Gbps will cause massive
packet loss and likely cause your BGP session to drop which will just
move the attack to another site, rinse / repeat.  I don't think very
many people run BGP over a separate circuit, but for some folks, it
might be appropriate.

I also recommend folks anycast with a /22 or /23 and then use BGP for
the /23 or /24 announcements and have their provider pin down the /22
at a few sites so that if all hell breaks loose and the /23 or /24 is
flapping and being dampened then you still have reachability with the
covering prefix.  It also lets you harden and strengthen a few smaller
sites that have the /22 statically pinned down.  I'm not sure if
people think the "cost" of doing this is worth it, jury still out for
us.

But as you and others have pointed out, not a lot of defense against
DDoS these days besides horsepower and anycast. :-)

-David

RE: Cloud proof of failure - was:: wikileaks unreachable

[Nathan Eisenberg]

> In a cloud hosting environment, you typically don't know where your
> data and servers are, and thus you don't know what legal and political
> pressures they may be subject to. If that means that in practice you
> are subject to the combination of any pressure that can be applied to
> any one of the hosting centers maintained by your hosting provider,
> then "the cloud" indeed would seem pretty unattractive to anyone with
> politically or socially controversial content.

How is it more or less unattractive than having one's own servers in one's own 
office?  Lieberman and Co would simply have leaned on Mom's Best BGP (r) and 
Pop's Fastest Packets (r) instead of on Amazon, and the result would have been 
the same.

That's the catch with this here series of tubes - you don't control all of the 
tubes, even if you're Amazon, or Giant National ISP Co, or Massive National 
Fiber Plant Co.  The server infrastructure is the least interesting part of 
what happened to WikiLeaks.

Nathan

Re: Pointer for documentation on actually delivering IPv6

[Owen DeLong]

On Dec 6, 2010, at 6:55 AM, Jared Mauch wrote:

> 
> On Dec 6, 2010, at 8:35 AM, Jeff Johnstone wrote:
> 
>> Speaking of IPV6 security, is there any movement towards any open source
>> IPV6 firewall solutions for the consumer / small business?
>> 
>> Almost all the info I've managed to find to date indicates no support, nor
>> any planned support in upcoming releases.
>> 
>> Any info would be helpful.
> 
> Honestly (and I'm sure some IPv6 folks will want me injured as a result) 
> there should be some '1918-like' space allocated for the corporate guys who 
> "don't get it", so they can nat everyone through a single /128.  It would 
> make life easier for them and quite possibly be a large item in pushing ipv6 
> deployment in the enterprise.
> 
Yes... Those of us who would like to see sanity return to the internet would 
prefer to have you lynched for such heresy. ;-)

Seriously, though, you're welcome to use fd00::/8 for exactly that purpose. The 
problem is that you (and hopefully it stays this way)
won't have much luck finding a vendor that will provide the NAT for you to do 
it with.

> I don't see our corporate IT guys that number stuff in 1918 space wanting to 
> put hosts on 'real' ips.  The chances for unintended routing are enough to 
> make them say that v6 is actually a security risk vs security enabler is my 
> suspicion.
> 
There are multiple easy ways to solve this problem that don't require the use 
of NAT or the damage that comes with it.

First, let's clarify things a bit. I don't think unintended routing is what 
concerns your IT guys. Afterall, even with the NAT
box today, there's routing from the outside to the inside. It's just controlled 
by stateful inspection.

It's trivial to implement an IPv6 default-deny-inbound stateful inspection 
policy that provides exactly the same security
model as is afforded by the current NAT box in IPv4 without mangling the packet 
headers. The rest is superstition.
Admittedly, superstition is powerful among IT professionals, especially in the 
enterprise world. So strong that people
on this very list who I generally respect and consider to be good competent 
professionals tell me that I'm flat out
wrong about it.

However, not one of them has been able to produce an argument that actually 
stands up to scrutiny. The closest they
can come is what happens when someone misconfigures something. However, I've 
always been able to show that
it's equally easy to make fatal misconfigurations on the NAT box with just as 
dire consequences.

Owen

Re: Pointer for documentation on actually delivering IPv6

[Jared Mauch]

On Dec 6, 2010, at 8:35 AM, Jeff Johnstone wrote:

> Speaking of IPV6 security, is there any movement towards any open source
> IPV6 firewall solutions for the consumer / small business?
> 
> Almost all the info I've managed to find to date indicates no support, nor
> any planned support in upcoming releases.
> 
> Any info would be helpful.

Honestly (and I'm sure some IPv6 folks will want me injured as a result) there 
should be some '1918-like' space allocated for the corporate guys who "don't 
get it", so they can nat everyone through a single /128.  It would make life 
easier for them and quite possibly be a large item in pushing ipv6 deployment 
in the enterprise.

I don't see our corporate IT guys that number stuff in 1918 space wanting to 
put hosts on 'real' ips.  The chances for unintended routing are enough to make 
them say that v6 is actually a security risk vs security enabler is my 
suspicion.

- Jared

Re: Cloud proof of failure - was:: wikileaks unreachable

[Marshall Eubanks]

On Dec 6, 2010, at 4:49 AM, Nathan Eisenberg wrote:

>> The cloud is a failure. Too easy to get it down.
>> I guess wikileaks returning to dedicated hosting proofs that.
> 
> No, it just proves that organizational decisions are made by human beings 
> that have values.  Whether or not those values are 'right' isn't the point - 
> the point is that the technology isn't what failed here.
> 
> There are plenty of dedicated server hosts that would have shut off wikileaks 
> under political pressure - and there are plenty of 'cloud' hosts who would 
> have kept them up.  I don't think we can draw any pass/fail conclusions WRT 
> cloud computing (defined here as virtualization-as-a-service) from the 
> removal of Wikileaks from S3.

I do, but not because of Amazon specifically. (As far as I know, Amazon's 
decision depended not at all on where its servers were located or that they 
were decentralized.)

In a cloud hosting environment, you typically don't know where your data and 
servers are, and thus you don't know what legal and political pressures they 
may be subject to. If that means that in practice you are subject to the 
combination of any pressure that can be applied to any one of the hosting 
centers maintained by your hosting provider, then "the cloud" indeed would seem 
pretty unattractive to anyone with politically or socially controversial 
content.

Regards
Marshall

> 
> Nathan
> 
> 
> 

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

[Patrick W. Gilmore]

On Dec 6, 2010, at 4:07 AM, Jonas Frey (Probe Networks) wrote:

> Besides having *alot* of bandwidth theres not really much you can do to
> mitigate. Once you have the bandwidth you can filter (w/good hardware).
> Even if you go for 802.3ba with 40/100 Gbps...you'll need alot of pipes.

There is a variation on that theme.  Using a distributed architecture (anycast, 
CDN, whatever), you can limit the attack to certain nodes.  If you have 20 
nodes and get attacked from a botnet China, only the users on the same node as 
the Chinese use will be down.  The other 95% of your users will be fine.  This 
is true even if you have 1 Gbps per node, and the attack is 100 Gbps strong.


> Spoofed attacks have reduced significally probably because the use of
> RPF. However we still see these from time to time.

I disagree.  Spoofed attacks have reduced because the botnets do not need to 
spoof to succeed in some attacks.  RPF is woefully inadequately applied.

For attacks which require spoofing, it is still trivial to generate 10s of Gbps 
of spoofed packets.


> I do not see a real solution to this problem right now...theres not much
> you can do about the unwilligness of users to keep their software/OS
> up2date and deploy anti-virus/anti-malware software (and keep it
> up2date).
> Some approaches have been made like cutting of internet access for users
> which have been identified by ISPs for beeing member of some
> botnet/beeing infected.
> This might be the only long-term solution to this probably. There is
> just no patch for human stupidity.

Quarantining end users sounds like a good idea to me.  But I Am Not An ISP. :)

The idea of auto-updates at the OS level like in iOS (as opposed to big-I 
"IOS") may be a solution for many people.  Supposedly OSX is going that route.  
But there will be those who do not want to get their software -only- through a 
walled garden like iTunes.

Fortunately, the motivations do have some alignment.  The users who do not need 
full access to their machines are the ones who are more likely to get confused 
& infected, and the ones who want someone to "protect" them more, which makes 
OS-level auto-update more appealing.  So that may help, even if it is not a 
panacea.

Wish us luck!

-- 
TTFN,
patrick

Re: Cloud proof of failure - was:: wikileaks unreachable

[Joe Greco]

[peter's theory]
> > The cloud is a failure. Too easy to get it down.
> > I guess wikileaks returning to dedicated hosting proofs that.

> No, it just proves that organizational decisions are made by human beings t=
> hat have values.  Whether or not those values are 'right' isn't the point -=
>  the point is that the technology isn't what failed here.
> 
> There are plenty of dedicated server hosts that would have shut off wikilea=
> ks under political pressure - and there are plenty of 'cloud' hosts who wou=
> ld have kept them up.  I don't think we can draw any pass/fail conclusions =
> WRT cloud computing (defined here as virtualization-as-a-service) from the =
> removal of Wikileaks from S3.

The question would appear to be whether attacks outside the technical 
space should be considered a failure.

It should be obvious that if I can attack your site with a blast of IP
traffic and deny others access to it, that's an effective takedown.  I
believe that someone DDoS'ed EveryDNS hosting of Wikileaks DNS.  On the
other hand, EveryDNS appears to have *chosen* to stop supplying service
to Wikileaks, so this was not a purely technological takedown.

The neat thing about cloud computing is that it is, to borrow Amazon's
term, "elastic."  I'm not sure we've seen scalable computing that can
be scaled rapidly in this manner for largely arbitrary purposes in the
past, and a cloud the size of Amazon's is probably able to cope with a
DDoS of virtually any size, assuming a willingness to throw sufficient
resources at it.

>From that perspective, I cannot see cloud computing as a failure, but
instead a massive success.

However, I can see outsourcing as a potential failure.  When you allow
a third party (Amazon, EveryDNS, whoever) to become involved in your
operation, you are essentially allowing them a veto over your continued
technical operations.  This makes the outsourcing provider an attractive
target for interference of the legal/political type.  How tolerant 
would your webhosting provider be of continuous DMCA complaints being
submitted about your web site, for example, even if they were without
merit?

>From that point of view, cloud computing may be inherently a bit more
vulnerable, because clouds tend to be resources being rented to third
parties.  With dedicated servers and/or your own IP space/servers, you
have increasing amounts of control over the response to certain threats
outside the technical realm.

A risk analysis of these factors is, therefore, suggested when deploying
services.  On average, the benefits of being able to rapidly provision
and scale resources in the cloud probably vastly outweighs the risks to
the average operation of political/legal pressures on the cloud hosting
provider; that computation necessarily changes for something like 
Wikileaks.

Of course, if one views the Internet itself as a sort of meta-cloud, it
should be obvious that meta-cloud computing is proving to be very
resilient.  But that brings us to a Tron-like mentality about the whole
Internet...  how apropos.  :-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

Re: Google mail admin contact needed (STARTTLS capabilities issue)

[William Allen Simpson]

On 12/6/10 6:58 AM, Michael Wildpaner wrote:

PIPELINING and STARTTLS are unrelated issues, and both are currently
working as intended.

   - STARTTLS on MX is in the process of being rolled out and not visible
 from all client locations at this point.

   - PIPELINING is not offered under all circumstances.

Hope this helps, maw


Much appreciated.  Could you let operators know where to look for the
status as it's rolled out?  Or keep us updated here?

Since the client TLS (port 995) has been working for a long time, and the
https is becoming the default (we used to have to specify it ourselves),
getting MX transport secured is a good idea.

Re: Pointer for documentation on actually delivering IPv6

[Jeff Johnstone]

On Mon, Dec 6, 2010 at 5:27 AM, Dobbins, Roland  wrote:

>
> On Dec 6, 2010, at 6:43 PM, Chris Nicholls wrote:
>
> > I found the following very helpful, Hardest thing for me was nailing
> DHCPv6-PD without an DHCP server :)
>
>
> This is the best/most complete work on IPv6 security to date, IMHO:
>
> 
>
> ---
> Roland Dobbins  // 
>
>   Sell your computer and buy a guitar.
>
>

Speaking of IPV6 security, is there any movement towards any open source
IPV6 firewall solutions for the consumer / small business?

Almost all the info I've managed to find to date indicates no support, nor
any planned support in upcoming releases.

Any info would be helpful.

cheers
Jeff

Re: Pointer for documentation on actually delivering IPv6

[Dobbins, Roland]

On Dec 6, 2010, at 6:43 PM, Chris Nicholls wrote:

> I found the following very helpful, Hardest thing for me was nailing 
> DHCPv6-PD without an DHCP server :) 


This is the best/most complete work on IPv6 security to date, IMHO:



---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

Re: ARIN space not accepted

[Robert E. Seastrom]

"Kevin Oberman"  writes:

>> From: valdis.kletni...@vt.edu
>> > From: valdis.kletni...@vt.edu
>> Date: Fri, 03 Dec 2010 20:00:15 -0500
>> 
>> On Fri, 03 Dec 2010 14:24:16 PST, Leo Bicknell said:
>> 
>> > It is speculated that no later than Q1, two more /8's will be allocated,
>> > triggering a policy that will give the remaining 5 /8's out to the
>> > RIR's.  That means, prior to end of Q1, the bogon list will be:
>> > 
>> > 0/8
>> > 10/8
>> > 127/8
>> > 172.16/12
>> > 192.168/16
>> > 224/3
>> 
>> Oh. And don't forget to do *bidirectional* filtering of these addresses. ;)
>
> Ahh, not quite. Blocking 224/3 bi-directionally might cause a few issues
> if you accept multicast traffic from anyone.

You mean like other routers that are speaking OSPF?  :-)

(people should understand the side effects of filtering before they conf t).

-r

Re: Google mail admin contact needed (STARTTLS capabilities issue)

[Michael Wildpaner]

On Fri, 3 Dec 2010, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 03 Dec 2010 17:30:38 PST, Brent Jones said:
> > For example, below shows the same MX at Google responding with and
> > without TLS. I attempted about a dozen times over a few minutes to the
> > same MX until I got STARTTLS listed in the capabilities list, but the
> > next attempt to the same MX would no longer show STARTTLS
> 
> Equally troubling is the similarly random nature of PIPELINING, which doesn't
> even match the STARTTLS appearing or not. Definitely bad juju.

PIPELINING and STARTTLS are unrelated issues, and both are currently
working as intended.
  
  - STARTTLS on MX is in the process of being rolled out and not visible
from all client locations at this point.
  
  - PIPELINING is not offered under all circumstances.

Hope this helps, maw

-- 
m...@{dont.,}beevil.org

Re: How do you do rDNS for IPv6 ?

[Owen DeLong]

On Dec 5, 2010, at 5:28 PM, Franck Martin wrote:

> 
> 
> - Original Message -
>> From: "Owen DeLong" 
>> To: "John Levine" 
>> Cc: nanog@nanog.org
>> Sent: Sunday, 5 December, 2010 2:54:43 PM
>> Subject: Re: How do you do rDNS for IPv6 ?
>> On Dec 5, 2010, at 2:13 PM, John Levine wrote:
>> 
> 
>>> When hosts self-configure their low 64 bits, do you install a
>>> suitable
>>> PTR and  into your DNS? If so, how? Do you use DHCPv6 and have
>>> it
>>> install the DNS? Do you do something else?
>>> 
>> If you care, you probably need to use DHCPv6 for this and it should be
>> able
>> to build both the  and PTR records.
>> 
> Unless you use, privacy extensions, the advantage of IPv6 over IPv4 is that 
> the IP address is built based on your network and the mac address of the 
> interface, so it is not a random number changed at every connection
> 
> I guess when you provision the machine, you can install the  and PTR 
> record and then also put the mac address in your access lists...

That answer presumes an enterprise environment. The question was from the 
perspective of a residential ISP.

I don't think most residential ISPs would regard provisioning individual 
customer machines as a scalable solution.

Owen

Re: Pointer for documentation on actually delivering IPv6

[Chris Nicholls]

On Saturday,  4 December 2010 at K:40:50 -0500, Mark Radabaugh wrote:
> Probably a case of something being blindingly obvious but...
> 
> I have seen plenty of information on IPv6 from a internal network 
> standpoint.  I have seen very little with respect to how a ISP is 
> supposed to handle routing to residential consumer networks. I have seen 
> suggestions of running RIPng.  The thought of letting Belkin routers (if 
> you can call them that) into the routing table scares me no end.
> 
> Is this way easier than I think it is?   Did somebody already write the 
> book that I can't find?
> 
> -- 
> Mark Radabaugh
> Amplex
> 
> m...@amplex.net  419.837.5015
> 
> 
---end quoted text---

I found the following very helpful, Hardest thing for me was nailing
DHCPv6-PD without an DHCP server :) 

Deploying IPv6 in Broadband Access Networks
By: Adeel Ahmed; Salman Asadullah
Publisher: John Wiley & Sons
Pub. Date: August 17, 2009
Print ISBN: 978-0-470-19338-9
Web ISBN: 0-470193-38-7

Deploying IPv6 Networks
By: Ciprian Popoviciu; Eric Levy-Abegnoli; Patrick Grossetete
Publisher: Cisco Press
Pub. Date: February 10, 2006
Print ISBN-10: 1-58705-210-5
Print ISBN-13: 978-1-58705-210-1

-- 
Chris Nicholls
Timico Network Operations
ch...@timico.net

Re: Cloud proof of failure - was:: wikileaks unreachable

[Suresh Ramasubramanian]

On Mon, Dec 6, 2010 at 3:08 PM, Peter Dambier 
wrote:
> The cloud is a failure. Too easy to get it down.
> I guess wikileaks returning to dedicated hosting proofs that.

I haven't used this sign in nearly a decade.  And certainly not on nanog.
Anyway .. I'll end this thread now.  And folks ..

   .:\:/:.
+---+ .:\:\:/:/:.
|   PLEASE DO NOT   |:.:\:\:/:/:.:
|  FEED THE TROLLS  |   :=.' -   - '.=:
|   |   '=(\ 9   9 /)='
|   Thank you,  |  (  (_)  )
|   Management  |  /`-vvv-'\
+---+ / \
|  |@@@  / /|,|\ \
|  |@@@ /_//  /^\  \\_\
  @x@@x@|  | |/ WW(  (   )  )WW
  \/|  |\|   __\,,\ /,,/__
   \||/ |  | |  jgs (__Y__)
   /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: Cloud proof of failure - was:: wikileaks unreachable

[Simon Waters]

On Monday 06 December 2010 09:47:43 Jay Mitchell wrote:
>
> "The Cloud" went down? I think not.

It did for at least one customer.

> Having ones account terminated as opposed to an outage caused by DDoS are
> two very different things.

Although not for all DNS providers.

There are operational lessons here. But do they boil down to technical issues 
may not be the limiting factor on your uptime. As commented already by 
someone, perhaps time to review plans for responses to non-technical threats 
to availability.

RE: Cloud proof of failure - was:: wikileaks unreachable

[Nathan Eisenberg]

> The cloud is a failure. Too easy to get it down.
> I guess wikileaks returning to dedicated hosting proofs that.
 
No, it just proves that organizational decisions are made by human beings that 
have values.  Whether or not those values are 'right' isn't the point - the 
point is that the technology isn't what failed here.

There are plenty of dedicated server hosts that would have shut off wikileaks 
under political pressure - and there are plenty of 'cloud' hosts who would have 
kept them up.  I don't think we can draw any pass/fail conclusions WRT cloud 
computing (defined here as virtualization-as-a-service) from the removal of 
Wikileaks from S3.

Nathan

RE: Cloud proof of failure - was:: wikileaks unreachable

[Jay Mitchell]

"The Cloud" went down? I think not.

Having ones account terminated as opposed to an outage caused by DDoS are
two very different things.

I'm certainly not an advocate of public cloud computing (I love it inside my
own private network though :) ), but in this case asserting that the cloud
is a failure is just plain wrong.

--jm

-Original Message-
From: Peter Dambier [mailto:pe...@peter-dambier.de] 
Sent: Monday, 6 December 2010 8:38 PM
To: nanog@nanog.org
Subject: Cloud proof of failure - was:: wikileaks unreachable

Hi,

there has been a lot of ethics and religio, ...

but what is really important for operation:

The cloud is a failure. Too easy to get it down.
I guess wikileaks returning to dedicated hosting proofs that.

Next time the board wants to convince me of cloud computing, I'll propose a
botnet is cheaper and more reliable.

Besides - outsourcing the directors might be a good idea.
GM proofs that :)


Cheers
Peter


--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48

Cloud proof of failure - was:: wikileaks unreachable

[Peter Dambier]

Hi,

there has been a lot of ethics and religio, ...

but what is really important for operation:

The cloud is a failure. Too easy to get it down.
I guess wikileaks returning to dedicated hosting proofs that.

Next time the board wants to convince me of cloud computing,
I'll propose a botnet is cheaper and more reliable.

Besides - outsourcing the directors might be a good idea.
GM proofs that :)


Cheers
Peter


-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48

Re: (wikileaks) Fwd: [funsec] And Google becomes a DNS..

[Simon Waters]

On Sunday 05 December 2010 15:50:32 Gadi Evron wrote:
>
> I withhold comment... "discuss amongst yourselves".

Since it is an uncommon but occasional complaint that someones site is indexed 
in Google by IP address not domain name, I assume simply that since wikileaks 
were redirecting to URLs with IP addresses in, Google assumed this is what 
they wanted indexed.

I share their pain, we had disk and a botnet issue with one of our sites, and 
Google's contribution was to drop our ranking (presumably speed penalty 
because it was now slower and less reliably than normal).

Frustrating but Google now reflects the reality of the web experience. They 
are "lucky" not to have a speed penalty, or perhaps they do but they are 
still ranked 1 for the term "wikileaks" even with the relevant penalties.

I dare say in a few iterations Google will spot DDoS attacks, and other forms 
of abuse, and bump up your ranking on the basis you are clearly notable 
enough to attract that sort of attention.

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

[Dobbins, Roland]

On Dec 6, 2010, at 2:50 PM, Sean Donelan wrote:

> Other than buying lots of bandwidth and scrubber boxes, have any other DDOS 
> attack vectors been stopped or rendered useless during the last 
> decade?


These .pdf presos pretty much express my view of the situation, though I do 
need to rev the first one:







The bottom line is that there are BCPs that help, but which many folks don't 
seem to deploy, and then there's little or no thought at all given to 
maintaining availability when it comes to server/service/app architecture and 
operations, except by the major players who'd been through the wringer and 
invest the time and resources to increase their resilience to attack.

Of course, the fundamental flaws in the quarter-century old protocol stack 
we're running, with all the same problems plus new ones carried over into IPv6, 
are still there.  Couple that with the brittleness, fragility, and insecurity 
of the DNS & BGP, and the fact that the miscreants have near-infinite resources 
at their disposal, and the picture isn't pretty.

And nowadays, the attackers are even more organized and highly motivated (OC, 
financial/ideological) and therefore more highly incentivized to innovate, the 
tools are easy enough for most anyone to make use of them, and tthe 
services/apps they attack are now of real importance to ordinary people. 

So, while the state of the art in defense has improved, the state of the art 
and resources available to the attackers have also dramatically improved, and 
the overall level of indifference to the importance of maintaining availability 
is unchanged - so the overall situation itself is considerably worse, IMHO.  
The only saving grace is that the bad guys often make so much money via 
identity theft, click-fraud, spam, and corporate/arm's-length governmental 
espionage that they'd rather keep the networks/services/servers/apps/endpoints 
up and running so that they can continue to monetize them in other ways.

---
Roland Dobbins  // 

   Sell your computer and buy a guitar.

Re: ARIN recognizes Interop for return of more than 99% of 45/8 address block

[Florian Weimer]

* John Curran:

> I agree with Chris; this (and any other returns) won't change the IPv4
> depletion/IPv6 deployment timeline substantially,

I guess there are a lots of unused assignments within
provider-dependent address space.  In my experience with a couple of
LIRs, none of them was very eager to reclaim address space after the
contractual requirement to provide it disappeared, and only some of
them reclaimed it after I asked them to.  All that unused address
space adds up, too.

On the other hand, it's probably more efficient to switch to an
addressing architecture which will not require proper resource
management for the forseeable future.

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

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

[Jonas Frey (Probe Networks)]

Besides having *alot* of bandwidth theres not really much you can do to
mitigate. Once you have the bandwidth you can filter (w/good hardware).
Even if you go for 802.3ba with 40/100 Gbps...you'll need alot of pipes.

Spoofed attacks have reduced significally probably because the use of
RPF. However we still see these from time to time.

TCP SYN attacks are still quite frequent...these can push alot of pps at
times.

The attack vectors have changed. Years ago people used hacked *nix boxes
with big pipes to start their attacks as only these had enough
bandwidth. Nowadays the consumers have alot more bandwidth and its
easier than ever to setup your own botnet by infecting users with
malware and alike. Even tho end users usually have less than 2mbps
upstream the pure amount of infected users makes it worse than ever.
Most of the time (depending on the attack) its also hard to
differentiate which IP addresse are attacking and which are legitimate
users. 

I do not see a real solution to this problem right now...theres not much
you can do about the unwilligness of users to keep their software/OS
up2date and deploy anti-virus/anti-malware software (and keep it
up2date).
Some approaches have been made like cutting of internet access for users
which have been identified by ISPs for beeing member of some
botnet/beeing infected.
This might be the only long-term solution to this probably. There is
just no patch for human stupidity.





Am Montag, den 06.12.2010, 02:50 -0500 schrieb Sean Donelan:
> February 2000 weren't the first DDOS attacks, but the attacks on multiple 
> well-known sites did raise DDOS' visibility.
> 
> What progress has been made during the last decade at stopping DDOS 
> attacks?
> 
> SMURF attacks creating a DDOS from directed broadcast replies seems to 
> have been mostly mitigated by changing defaults in major router OS's.
> 
> TCP SYN attacks creating a DDOS from leaving many half-open connections 
> seems to have been mostly mitigated with SYN Cookies or similar OS 
> changes.
> 
> Other than buying lots of bandwidth and scrubber boxes, have any other 
> DDOS attack vectors been stopped or rendered useless during the last 
> decade?
> 
> Spoofing?
> 
> Bots?
> 
> Protocol quirks?
> 


signature.asc
Description: This is a digitally signed message part

Looking for security/abuse contact at EGIHosting

[John Adams]

Contact me off list please.

Thanks,

-john

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

[Blake Dunlap]

On Mon, Dec 6, 2010 at 01:50, Sean Donelan  wrote:

>
> February 2000 weren't the first DDOS attacks, but the attacks on multiple
> well-known sites did raise DDOS' visibility.
>
> What progress has been made during the last decade at stopping DDOS
> attacks?
>
> SMURF attacks creating a DDOS from directed broadcast replies seems to have
> been mostly mitigated by changing defaults in major router OS's.
>
> TCP SYN attacks creating a DDOS from leaving many half-open connections
> seems to have been mostly mitigated with SYN Cookies or similar OS changes.
>
> Other than buying lots of bandwidth and scrubber boxes, have any other DDOS
> attack vectors been stopped or rendered useless during the last decade?
>
> Spoofing?
>
> Bots?
>
> Protocol quirks?
>
>
If anything, the potential is worse now than it ever has been unless you
have just ridiculous amounts of bandwidth, as the ratios between leaf user
connectivity and data center drops have continued to close. The finger of
packety death may be rare, but it is more powerful than ever, just ask
Wikileaks, I believe that they were subject to 10Gbit+ at times.

At least the frequency has dropped in recent years, if not the amplitude,
and I am thankful for that, due to in no small part to what you list above,
as it mostly requires compromised bots to preform major attacks now, instead
of having many available unwitting non-compromised assists spread across the
internet like previously.