>From: Greg Hudson <[EMAIL PROTECTED]>
>
>> But anybody clear understand that if your internal hosts do not have
>> a public address then all attacks may be only static - wait until
>> internal host open TCP to somewhere.
>
>This is a naive understanding. Source-routing would let me get
>packets
> From: "Eliot Lear" <[EMAIL PROTECTED]>
> It's also completely naive that source routing is your only threat. One
> can break into a NAT. One can forge packets and address them
> appropriately. Firewalls prevent this, not NATs.
That statement is just as naive, unless you qualify the word "fi
It's also completely naive that source routing is your only threat. One
can break into a NAT. One can forge packets and address them
appropriately. Firewalls prevent this, not NATs.
> From: Greg Hudson <[EMAIL PROTECTED]>
> > But anybody clear understand that if your internal hosts do not have
> > a public address then all attacks may be only static - wait until
> > internal host open TCP to somewhere.
>
> This is a naive understanding. Source-routing would let me get
> pac
> But anybody clear understand that if your internal hosts do not have
> a public address then all attacks may be only static - wait until
> internal host open TCP to somewhere.
This is a naive understanding. Source-routing would let me get
packets through to an internal address unless your NAT
>From: "Steven M. Bellovin" <[EMAIL PROTECTED]>
>
>In message <001501bfaf43$127e4d00$[EMAIL PROTECTED]>, "Eliot Lear" writes:
>>It is a complete fallacy that NAT provides any sort of security. It does
>>no such thing. Security is provide by a firewall, and (more importantly)
>>by strong security
In message <001501bfaf43$127e4d00$[EMAIL PROTECTED]>, "Eliot Lear" writes:
>It is a complete fallacy that NAT provides any sort of security. It does
>no such thing. Security is provide by a firewall, and (more importantly)
>by strong security policies that are policed and enforced.
Eliot is abs
groups: cisco.external.ietf
Sent: Tuesday, April 25, 2000 10:11 PM
Subject: Re: NAT->IPv6
> >From: John Stracke <[EMAIL PROTECTED]>
> >
> >"J. Noel Chiappa" wrote:
> >
> >> So, you're the CIO for Foondoggle Corp, and you're trying to figu
>From: John Stracke <[EMAIL PROTECTED]>
>
>"J. Noel Chiappa" wrote:
>
>> So, you're the CIO for Foondoggle Corp, and you're trying to figure out
>> whether to spend any of your Q3 funds on IPv6 conversion. Let's see, benefits
>> are not very many (autoconfig may be the best one), and the cost is
>
>From: "Charles E. Perkins" <[EMAIL PROTECTED]>
>
>If we get to a model where large new domains use IPv6 addressing
>with NAT to global IPv4 address space, that would be quite useful.
>Before too long, services will appear on the IPv6 network that
>can't get the IPv4 global addresses they need.
"J. Noel Chiappa" wrote:
> So, you're the CIO for Foondoggle Corp, and you're trying to figure out
> whether to spend any of your Q3 funds on IPv6 conversion. Let's see, benefits
> are not very many (autoconfig may be the best one), and the cost is
> substantial.
Sure. Then you buy out Moondogg
Hello Matt,
I probably shouldn't tread into these waters, but...
>> Now, if you have a site which has more hosts than it can get external IPv4
>> addresses for, then as long as there are considerable numbers of IPv4 hosts a
>> site needs to interoperate with, *deploying IPv6 internally to the s
> From: Matt Holdrege <[EMAIL PROTECTED]>
>> The basic key *architectural* problem with NAT ... is that when you
>> have a small number of external addresses being shared by a larger
>> number of hosts behind some sort of "address-sharing" device, there's
>> no permanent assoc
At 12:55 PM 4/25/00 -0400, J. Noel Chiappa wrote:
>The basic key *architectural* problem with NAT (as opposed to all the
>mechanical problems like encrypted checksums, etc, some of which can be
>solved with variant mechanisms like RSIP), as made clear by Keith's comments,
>is that when you have a
14 matches
Mail list logo
