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

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 25 May 2005 14:02:00 +0200

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" <[email-masked]> 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.

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 May 2005 08:59:19 -0700

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

As stated, not quite (at least in my opinion), but pretty close. Note  
that in this note I am merely stating my own opinions.

Regarding disruptiveness, when we talk about disruptive technologies,  
it is not that the network ceases working that is disruptive;  
businesses are disrupted. In the IPv6 deployment, the disruptive  
aspects for ISPs are that they have to upgrade equipment (perhaps  
hardware, surely software), which involves a testing effort and  
involves figuring out the best configurations for what they are trying  
to do. That deployment, even if the software is free and no hardware  
changes are required, can be pretty expensive. This is why the ISPs  
have been so willing to slow-roll the roll-out - they want to know that  
the money they expend is going to result in adequate ROI. And frankly,  
something that deploys in parallel and gives no added benefit is not  
going to convince consumers to buy, and therefore has limited ROI. So  
for the IPv6 roll-out to succeed, there actually has to be a disruption  
of some kind - either new services available as a result, or a change  
in the ISP cost model, or new applications available to consumers that  
would not otherwise be available, or something.

The extra level of security of a simple stateful firewall is, I agree,  
a good thing. I wouldn't describe it as NAT-like; I think of it the  
other way around, that a NAT is stateful and provides some functions  
similar to a firewall, and therefore a NAT is in some respects like a  
firewall. Cisco's CBAC firewall  
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/ 
121cgcr/secur_c/scprt3/scdcbac.htm) is a pretty good example of what  
you're describing; it allows into a network responses to queries  
generated from within the network plus configured accesses from  
outside, such as mail to the mail server and web traffic to the web  
server.

I think it is important to state in the NAP draft the purpose of such a  
firewall, both in terms of what it does and what it doesn't. A firewall  
doesn't secure a network, because many attacks come from inside or are  
at a layer higher than the firewall can protect against. In the final  
analysis, every system has to be responsible for its own security, and  
every process running on a system has to be robust in the face of  
challenges like stack overflows and so on. What a firewall does is  
prevent a network administration from having to pay for bandwidth to  
carry unauthorized traffic, and in so doing reduce the probability of  
certain kinds of attacks across the protected boundary.

> A distributed security mechanism, only on the end-systems will  
> probably not be there in the next couple of years for organizations.

Personally, I doubt that an end-system-only security mechanism will  
*ever* be widely deployed, for the reason above. End-system-only  
security mechanisms don't protect the network administration from being  
used as transit, or against ddos attacks against individual systems  
inside.

> 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.

I agree that it would be good to recommend that vendors provide a  
simple way to configure a stateful firewall, including ways to easily  
bypass it such as enabling simple access lists to allow stated  
application traffic to access stated systems, building a SIP Proxy or  
other application support tools into such a firewall system, perhaps  
providing a subscription service in which an authorized user could  
subscribe to let certain applications come to his/her machine, etc.  
Such controls should of course be user user control, and in the last  
case, with appropriate AAA support.

On May 25, 2005, at 5:02 AM, Gunter Van de Velde (gvandeve) wrote:

> 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
> 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
> 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
> A distributed security mechanism, only on the end-systems will  
> probably not be there
> real 'none-filtered peer-2-peer communication between inside and  
> outside an organization.
> 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.
>
>
> Groetjes,
> G/
>
>
>
>> > to suggest, at this stage, that even the stateful firewalls should  
>> be pulled

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 May 2005 21:46:38 +0930

Hi Gunter, Fred,

On Wed, 25 May 2005 08:59:19 -0700
Fred Baker <[email-masked]> wrote:

<snip>

<snip>

Fred covered well a number of the other "non-technical" disruptiveness
factors that deploying new technologies like IPv6 creates. My
"disruptiveness" is a subset of Fred's business costs. 

To clarify the disuptiveness I was trying to describe, network
administrators will have to put some effort into learning IPv6, to learn
things such as the formatting and structure of addresses, ICMP based
neighbour discovery etc. - the technical details of IPv6. Because effort
has to be put into learning IPv6, while the network administrator is in
"learning new-stuff mode", it can also be a good opportunity introduce
or re-introduce broader conceptual ideas such the benefits of
end-to-end, etc. Opportunities to start with a "clean conceptual slate"
are relatively rare, so when they occur (as it will with IPv6), I think
it is good to try to take as much advantage of them as is possible and
practical. IPv6 is both similar and different to IPv4. The similarities
help to learn IPv6, the differences need to be explained well so that
people can see the advantages in deploying IPv6 and therefore also learn
and understand why leaving behind the "warts" of IPv4 today (e.g., NAT)
are part of IPv6's advantages. I certainly think the NAP draft is
covering these topics, my interest is just to try to ensure that the
"warts" of IPv4 are hopefully fully "explained" away from being deployed
in IPv6.

Regards,
Mark.