[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]

Hi Mark, All,

I'm just falling back to this thread.

<snip> 
Yes, because I think that as the move to IPv6 is relatively disruptive
("disruptive" in the sense that deploying a new technology on a large
scale is usually disruptive no matter how well it is done - it is always
a significant change) it is a good opportunity also (re)introduce ideas
that we know in the long term will be beneficial. I think the
introduction of IPv6 is also an opportunity to change the way people
think and do things with and in their network.

<end snip>

I'm not sure that i fully agree with the disruptive aspect of adding IPv6 services to
a network infrastructure from technical perspective. One can add IPv6 as protocol
in addition to IPv4 of an IP network without interrupting the network too much by use
of the already planned and existing maintenance windows. In most cases the end-users
won't even notice a difference or the glitches in the network when the ISIS or BGP
experience sessions flaps due to capability exchanges. In this case there would be
a nice coexistence of existing IPv4 services and additional IPv6 services can be provided
after the migration. The next steps could be done step-by-step.

For the end-systems, they can be made IPv6 aware if they are not already.
This should/will be a none issue with most of the current existing OS's, not?

To come back at the NAP aspects of the thread, these systems may or may not have their
own protection against external influences and the network may exist out of different
OS's (and potentially different flavors or releases of the OS's) which each implement
their own version of a security model. This sounds like a nice way to create complexity
and confusion about the existing security model used. For the home-user this could be
sufficient, however i do like the idea that for home-users there should be some direction
or statement that by a simple <click-on-a-button> configuration he must be able to
enable the state-full filtering mechanism in a NAT-like manner, this not to break the
end-to-end model, but more to have this extra level of security.

A distributed security mechanism, only on the end-systems will probably not be there
in the next couple of years for organizations. The question is also if there is need for
real 'none-filtered peer-2-peer communication between inside and outside an organization.
However, a stateful filter placed at the boundary between inside and outside can limit these
kind of connections based on certain configurable rules. The principle would be the same as
when using a stateful address translator.

To conclude, it would be good to have a recommendation for the easy enabling of
a stateful filter to establish NAT like session security and control, and in addition to that
(as result of the peer-2-peer potential of IPv6) the end-system OS's should have a similar
recommendation.

Would the above be a good summary to place in the next revision of the NAP draft?

Groetjes,
G/



At 13:27 6/04/2005 +0930, Mark Smith wrote: 
Hi John,

On Tue, 5 Apr 2005 20:15:10 -0700
"John Spence, CCSI, CCNA, CISSP" <jspence@native6.com> wrote:

>
> Mark;
>
> Good points all. I agree, host firewall is evolving fast, and will be more
> and more commonly deployed in the future.
>
> But are you suggesting that the NAP draft, in an effort to push peer-to-peer
> "all the way", advocate removing edge firewalls and ACL in favor of only
> deploying distributed firewalls? I think that would be going way to far.
> The best way to pry NAT out of the hands of IPv4-oriented security managers
> is to make the case *for* stateful firewalls over NAT routers - not to try
> to suggest, at this stage, that even the stateful firewalls should be pulled
> in favor of having the end nodes use host firewalls to support peer-to-peer
> networking in the purest sense.

Yes and no :-)

Yes, because I think that as the move to IPv6 is relatively disruptive
("disruptive" in the sense that deploying a new technology on a large
scale is usually disruptive no matter how well it is done - it is always
a significant change) it is a good opportunity also (re)introduce ideas
that we know in the long term will be beneficial. I think the
introduction of IPv6 is also an opportunity to change the way people
think and do things with and in their network.

For example, as I mentioned, modern OSes have firewalling out of the
box. From what I'm aware of, the only component missing, at least in the
commercial space i.e., products you can buy, for scalable host based
firewalling is mechanisms to deploy the (corporate) firewalling policy
to the host. I think it just may be around the corner though - server
based authentication services obviously exist, user "login scripts" that
are pushed to the users host after authentication have been around a for
a long time, its just a matter of a commercially available mechanism to
push firewall policy to the user host in a similar manner to login
scripts.

No, because I realise that people don't necessarily like change, and
also like to apply existing and understood models of operation to new
environments or technologies.

Summarising, I'd like to see IPv6 used as an opporunity to introduce and
promote new thinking (well old, but new to most IPv4 people), and
provide "new" models of deployment. However, for those who are more
resistant to new thinking, identify "old" IPv4 mechanisms and how they
can work with IPv6 as a "fall back" alternative to new thinking or as
part of a migrationary path to "new thinking".

Regards,
Mark.
--

The Internet's nature is peer to peer.