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

[JORDI PALET MARTINEZ <jordi.palet@consulintel.es>]

Hi Jim,

Fully agree. This is what we are doing in the distributed security work
(some I-Ds being updated now). We call it instead of security manager
"security policy manager". The function is to provide a policy for the nodes
in the network, either a default one or a case by case one, or mixture of
both, and act as the master lock, in case anything is broken.

Regards,
Jordi




> De: "Bound, Jim" <jim.bound@hp.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Wed, 25 May 2005 16:33:50 -0400
> Para: Fred Baker <fred@cisco.com>, "Gunter Van de Velde (gvandeve)"
> <gvandeve@cisco.com>
> CC: "John Spence, CCSI, CCNA, CISSP" <jspence@native6.com>,
> <v6ops@ops.ietf.org>, Mark Smith
> <ipng@69706e6720323030352d30312d31340a.nosense.org>
> Asunto: RE: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]
> 
> Just as note I agree with Fred but with one caveat, that is again just
> my opinion and not clear it is relative but will share it.  I believe
> end-to-end security will be the norm in the future and believe it to be
> a requirement for true end-to-end trust model. But, I do believe the
> network must remain secure too.  I envision the Firewall to become a
> Security Manager and a set of nodes being routers and servers at the
> network edge that will be able to watch the network for attack and know
> what is legal end-to-end secure traffic and when an attack happens.
> When the attack is obvious end-to-end is shut down and the Security
> Manager becomes similar to traditional firewall. I am not the only one
> with this view though and it is being discussed and prototypes will
> happen to analyze this thought further in both the public and private
> sectors.
> 
> NAP is a useful spec but lets not make it the holy grail here and keep
> it simple folks and not over indulge in trying to predict or tell the
> market what to do, because that is not our IETF job IMO.
> 
> thanks
> /jim 
> 
>> -----Original Message-----
>> From: owner-v6ops@ops.ietf.org
>> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
>> Sent: Wednesday, May 25, 2005 11:59 AM
>> To: Gunter Van de Velde (gvandeve)
>> Cc: John Spence, CCSI, CCNA, CISSP; v6ops@ops.ietf.org; Mark Smith
>> Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]
>> 
>> 
>>> 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.
>> 
>>> 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.
>> 
>> 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:
>> 
>>> 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.
>>> 
>>> 
>>> 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.
>>> 
>> 
>> 
> 




************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.