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

["Bound, Jim" <jim.bound@hp.com>]

Hello Jordi, Security Policy Manager is a far better connotation.  I
also like the ITU x.805 Security Model very much too, contributed by
Bell Labs to ITU. What security will be will not be driven by vendors or
a standards body but by the user community I also believe.

thanks
/jim 

> -----Original Message-----
> From: JORDI PALET MARTINEZ [mailto:jordi.palet@consulintel.es] 
> Sent: Wednesday, May 25, 2005 5:34 PM
> To: v6ops@ops.ietf.org; Bound, Jim; Fred Baker; Gunter Van de 
> Velde (gvandeve)
> Cc: John Spence, CCSI, CCNA, CISSP; Mark Smith
> Subject: Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]
> 
> 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.
> 
> 
> 
>