If I'm not wrong, you could get some service from MCI and AT&T, tunnels only
from SPRINT. Global Crossing provides service, as I believe Level3 and
Abovenet do.
You may want to do a free search for "ISP" at
http://www.ipv6-to-standard.org
Regards,
Jordi
> De: "Krichbaum, Eric" <[EMAIL PROTEC
Jared Mauch wrote:
On Fri, Jun 01, 2007 at 02:28:34PM +0100, Jeroen Massar wrote:
Hi,
As more and more cool IPv6 applications and services are becoming
available, I converted the former FAQ entry we had on this into a more
easily found/remembered page.
I was doing some search
On Mon, Jun 04, 2007, Sam Stickland wrote:
> Personally I hate NAT. But I currently work in a large enterprise
> environment and NAT is suprisingly popular. I came from a service
> provider background and some of the attitudes I've discovered towards
> private addresses in enterprise environme
Sander Steffann wrote:
Hi,
In fact, and call me crazy, but I can't help but wonder how
many enterprises
out there will see IPv6 and its concept of "real IPs for all machines,
internal and external!" and respond with "Hell No."
Anyone got any numbers for that? I'm happy to admit I don't.
In fact, we have two tunnels, one with MCI and one with SPRINT.
They're in "beta" state now, but we are getting 682 prefixes from MCI and
703 from SPRINT.
Regards,
Nicolas.
On Mon, 4 Jun 2007, JORDI PALET MARTINEZ wrote:
jordi. >
jordi. >If I'm not wrong, you could get some service from MCI an
On 4-jun-2007, at 17:37, Donald Stahl wrote:
I want NAT to die but I think it won't.
Far too many "security" folks are dictating actual implementation
details and that's fundamentally wrong.
A security policy should read "no external access to the network"
and it should be up to the net
In fact, and call me crazy, but I can't help but wonder how many
enterprises
out there will see IPv6 and its concept of "real IPs for all
machines,
internal and external!" and respond with "Hell No."
That's an education problem. There's no security gain from not
having real
IPs on machines
Owen DeLong <[EMAIL PROTECTED]> writes:
> There's no security gain from not having real IPs on machines.
> Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liable to start believing it's true :-).
*No* security
On 4-Jun-2007, at 14:32, Jim Shankland wrote:
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidence that they've
succ
On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:
Owen DeLong <[EMAIL PROTECTED]> writes:
There's no security gain from not having real IPs on machines.
Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liabl
Joe Abley wrote:
On 4-Jun-2007, at 14:32, Jim Shankland wrote:
Shall I do the experiment again where I set up a Linux box
at an RFC1918 address, behind a NAT device, publish the root
password of the Linux box and its RFC1918 address, and invite
all comers to prove me wrong by showing evidenc
Jim Shankland wrote:
Owen DeLong <[EMAIL PROTECTED]> writes:
There's no security gain from not having real IPs on machines.
Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people
are liable to start believin
Jim Shankland wrote:
> Owen DeLong <[EMAIL PROTECTED]> writes:
> > There's no security gain from not having real IPs on machines.
> > Any belief that there is results from a lack of understanding.
>
> This is one of those assertions that gets repeated so often people
> are liable to start believi
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
> *No* security gain? No protection against port scans from Bucharest?
> No protection for a machine that is used in practice only on the
> local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over a
I'm sure everyone understands the underlying principle, but I'm constantly
making the point that even the best firewall is not a total security
solution. Forget antivirus, IDS, host authentication, etc., and just look on
the perimeter.
At least four device types lead inside from the DMZ:
NAT
Also, it is good to control the Internet addressable devices on your network
by putting them behind a NAT device. That way you have less devices to
concern yourself about that are directly addressable when they most likely
need not be. You can argue that you can do the same with a firewall and
[EMAIL PROTECTED] writes:
> On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
> > *No* security gain? No protection against port scans from Bucharest?
> > No protection for a machine that is used in practice only on the
> > local, office LAN? Or to access a single, corporate Web site?
>
>
Well, give the junky little NAT boxes their due. Grubby little home
networks running windoze on one or a few computers cause a lot less trouble
in the world when there is a junky little NAT box between the house LAN and
the big world outside. Better ways to do it? Absolutely! Easier,
cheaper a
On Mon, Jun 04, 2007 at 08:04:23PM +0100, Leigh Porter wrote:
> Jim Shankland wrote:
> >Owen DeLong <[EMAIL PROTECTED]> writes:
> >
> >>There's no security gain from not having real IPs on machines.
> >>Any belief that there is results from a lack of understanding.
> >>
> >
> >This is one of
At 03:20 PM 6/4/2007, Jim Shankland wrote:
[EMAIL PROTECTED] writes:
> On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
> > *No* security gain? No protection against port scans from Bucharest?
> > No protection for a machine that is used in practice only on the
> > local, office LAN? O
On Mon, Jun 04, 2007 at 12:20:38PM -0700, Jim Shankland wrote:
> But NAT *requires* stateful inspection; and the many-to-one, port
> translating NAT in common use all but requires affirmative steps
> to be taken to relay inbound connections to a designated, internal
> host -- the default ends up b
Sure, NAT can't prevent users from running with scissors, but sometimes it
does block the scissors thrown at the back of their neck whilst they are
sleeping :)
On 6/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Mon, 04 Jun 2007 12:20:38 PDT, Jim Shankland said:
> I can't pass over Vald
On Monday 04 June 2007, [EMAIL PROTECTED] wrote:
> Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly
> configured stateful *non*-NAT firewall should be doing for you already.
Since when are CPE devices 'properly' configured?
--
Lamar Owen
Chief Information Officer
Pisgah Astr
Sorry, Owen, but your argument is ridiculous. The original statement was
"[t]here's no security gain from not having real IPs on machines". If
someone said, "there's no security gain from locking your doors", would you
refute it by arguing that there's no security gain from locking your doors
th
Jim Shankland wrote:
But NAT *requires* stateful inspection;
No, NAT does not require this.
Port NAT mapping one IP to many does, but there are other
kinds of NAT.
this lack of precision can lead to nasty results when
clueless middle managers demand things they don't understand
(which is, aft
I made an announcement today during the ISP Security session (at NANOG40)
about the release the following publication from NIST:
Special Publication 800-54 Draft Version 2, Border Gateway Protocol Security
http://csrc.nist.gov/publications/drafts/800-54/Draft-SP800-54-version2-Jun2007.pdf
This is
> I posit that a screen door does not provide any security. A lock and
> deadbolt provide some security. NAT/PAT is a screen door.
> Not having public addresses is a screen door. A stateful inspection
> firewall is a lock and deadbolt.
It's tedious getting in and out with a lock and a deadbolt
> I posit that a screen door does not provide any security. A lock and
> deadbolt provide some security. NAT/PAT is a screen door.
> Not having public addresses is a screen door. A stateful inspection
> firewall is a lock and deadbolt.
This is a fine piece of rhetoric, but it's manifestly fals
But NAT *requires* stateful inspection;
No, NAT does not require this.
In the context of this discussion it does.
Port NAT mapping one IP to many does, but there are other
kinds of NAT.
This is exactly the NAT that is being spoken of though.
this lack of precision can lead to nasty result
Leigh Porter wrote:
Additionally, NATing services on separate machines behind a single NATed
address anonymises the services behind a single address.
Agreed. It can be very useful to not expose the internal topology
through address assignment so as to not expose which
subnets/desktops/users
On Mon, Jun 04, 2007 at 11:34:30PM +0100, Sam Stickland wrote:
>
> Matthew Palmer wrote:
> >I can think of one counter-example to this argument, and that's
> >SSL-protected services, where having a proxy, transparent or otherwise, in
> >your data stream just isn't going to work.
>
> Not so. Loo
On Mon, Jun 04, 2007 at 03:31:00PM -0500, Larry Smith wrote:
>
> On Monday 04 June 2007 13:54, [EMAIL PROTECTED] wrote:
> > On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
> > > *No* security gain? No protection against port scans from Bucharest?
> > > No protection for a machine that is u
On Mon, Jun 04, 2007 at 04:27:14PM -0700, David Schwartz wrote:
> > I posit that a screen door does not provide any security. A lock and
> > deadbolt provide some security. NAT/PAT is a screen door.
> > Not having public addresses is a screen door. A stateful inspection
> > firewall is a lock an
On Mon, Jun 04, 2007 at 08:12:45PM +0100, Colm MacCarthaigh wrote:
> The argument can go either way, you can spin it as a benefit for the
> network operator ("wow, user activity and problems are now more readily
> identifiable and trackable") or you can see it as an organisational
> privacy issue
DS> Date: Mon, 4 Jun 2007 16:27:14 -0700
DS> From: David Schwartz
[ snipped throughout ]
DS> I can give you the root password to a Linux machine running telnetd
DS> and sshd. If it's behind NAT/PAT, you will not get into it. Period.
DS>
DS> I can give you the administrator password to a Window
Surely that second quote should be "crap, now macrumors can tell that one
person in our office follows them obsessively"? Unless there's
publically-available information that indicates that IP address is your
CEO's (which is a whole other topic -- publically available rDNS for
company-internal
On 6/4/07, David Schwartz <[EMAIL PROTECTED]> wrote:
I can give you the root password to a Linux machine running telnetd and
sshd. If it's behind NAT/PAT, you will not get into it. Period.
Just because it's behind NAT, does not mean it's unreahcable from the internet:
Fenrir:~% telnet ipv4.
I can give you the root password to a Linux machine running telnetd and
sshd. If it's behind NAT/PAT, you will not get into it. Period.
I'll give you root password to a half a dozen directly connected Linux
boxes and you still won't be able to get in.
I can give you the administrator passwor
I figured SMB would chime in...but his research says it's not so anonymous.
http://illuminati.coralcdn.org/docs/bellovin.fnat.pdf
jas
Colm MacCarthaigh wrote:
On Mon, Jun 04, 2007 at 11:47:15AM -0700, Owen DeLong wrote:
*No* security gain? No protection against port scans from Bucharest?
On 4/06/2007, at 9:52 PM, Sam Stickland wrote:
Jared Mauch wrote:
http://www.icann.org/meetings/lisbon/presentation-doering-
ipv6-25mar07.pdf
In answer to two questions at the end of this document:
• what are enterprises waiting for?
• should we ditch IPv6, and live with IPv4 + N
At 09:07 PM 6/4/2007, Jason Lewis wrote:
I figured SMB would chime in...but his research says it's not so anonymous.
http://illuminati.coralcdn.org/docs/bellovin.fnat.pdf
Give or take NAT boxes / firewalls that specifically have features to
mess with the IP ID. The SonicWALL products have,
On Mon, Jun 04, 2007, Iljitsch van Beijnum wrote:
>
> On 4-jun-2007, at 17:37, Donald Stahl wrote:
>
> >>I want NAT to die but I think it won't.
>
> >Far too many "security" folks are dictating actual implementation
> >details and that's fundamentally wrong.
>
> >A security policy should rea
On Jun 4, 2007, at 12:22 PM, Dave Israel wrote:
[EMAIL PROTECTED] wrote:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from
Bucharest?
No protection for a machine that is used in practice only on the
local, office LAN? Or to acc
On Mon, Jun 04, 2007, Donald Stahl wrote:
> >Won't stateful firewalls have similar issues? Ie, if you craft a stateful
> >firewall to allow an office to have real IPv6 addresses but not to allow
> >arbitrary connections in/out (ie, the "stateful" bit), won't said stateful
> >require protocol track
Won't stateful firewalls have similar issues? Ie, if you craft a stateful
firewall to allow an office to have real IPv6 addresses but not to allow
arbitrary connections in/out (ie, the "stateful" bit), won't said stateful
require protocol tracking modules with similar (but not -as-) complexity
t
45 matches
Mail list logo
