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

From: [email-masked] (Alain Durand)
Date: Mon, 4 Apr 2005 12:59:53 -0700 (PDT)

I've been reading again section 2.2

2.2  Simple security due to stateful filter implementation

I think this section is a bit weak.

If someone install a NAT box at home, by default,
it will prevent incoming connections, and this
is widely percieved as a security function.

The point that trojan horses do exist and that the dynamic
mapping does not provide real security is true.
However, the classic counter arguments come in two flavor:
	- oh, but the NAT boxes are labeled security devices
	so it must be true.
	- "defense in depth" is what more knowledgebla people
	would answer.

So you expect to convince home user and IT department that
they should then give up on what they considered as
"state of the art security", you are facing an uphill
batttle and you will need much more than the current
text in section 2.2.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Apr 2005 14:24:52 +0200

I've never understood why a non-NAT domestic router can't be set
up with exactly the same default behavior by having default port
filtering in place (just like "personal firewall" software that
most people run on their PCs). A domestic IPv6 router should indeed
be shipped with port filtering on by default, imho. We can write this.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Apr 2005 08:31:25 -0700

On Apr 5, 2005, at 5:24 AM, Brian E Carpenter wrote:
> I've never understood why a non-NAT domestic router can't be set up  
> with exactly the same default behavior by having default port  
> filtering in place (just like "personal firewall" software that most  
> people run on their PCs). A domestic IPv6 router should indeed be  
> shipped with port filtering on by default, imho. We can write this.

At the risk of sounding proprietary, Cisco has a rather nice capability  
for this. You might read
	http://www.cisco.com/en/US/products/sw/secursw/ps1018/ 
products_tech_note09186a0080094e8b.shtml
	http://www.cisco.com/en/US/products/sw/secursw/ps1018/ 
products_white_paper09186a0080094658.shtml
	http://www.cisco.com/en/US/products/sw/secursw/ps1018/ 
products_configuration_example09186a0080094111.shtml

Simply stated, it defines an "inside" and an "outside" interface (and  
in that last, a DMZ). The "outside interface" is configured with an ACL  
of what to allow to cross, which one might expect to include a pretty  
limited configuration. The for my home office allows for dynamic  
creation of a VPN among the home workers on my network at Cisco, which  
uses DMVPN and IPSEC, and also runs NTP and derives its IP address from  
the ISP.

	ip access-list extended fw_acl
	 remark ---- DMVPN Firewall ----
	 permit udp any any eq isakmp
	 permit udp any eq isakmp any
	 permit udp any eq non500-isakmp any
	 permit esp any any
	 permit gre any any
	 permit udp host 192.5.41.40 eq ntp any
	 permit udp host 192.5.41.41 eq ntp any
	 permit ip 10.34.250.96 0.0.0.31 10.32.244.216 0.0.0.7
	 permit tcp 128.107.0.0 0.0.255.255 any eq 22
	 permit tcp 128.107.0.0 0.0.255.255 any eq telnet
	 permit udp any any eq bootpc
	 deny   icmp any any packet-too-big
	 permit icmp any any
	 deny   ip any any

The one on my home router (Cisco information security guidelines  
require a home office to be on a separate network from the home) I use  
a much simpler one:

	access-list 105 deny   ip 192.168.1.0 0.0.0.255 any
	access-list 105 deny   icmp any any packet-too-big
	access-list 105 permit icmp any any
	access-list 105 permit udp any any eq bootpc
	access-list 105 permit udp any any eq bootps

If this were sitting in front of a SOHO, one could readily imagine also  
application-specific holes for incoming traffic.

     access-list 105 permit tcp  any  host www.example.com   eq http
     access-list 105 permit tcp  any  host smtp.example.com  eq smtp
     access-list 105 permit tcp  any  host ftp.example.com   eq ftp

Now, in addition to packets permitted by the ACL, the "inside"  
interface notes new packets sent out and adds their response to a  
dynamic ACL added to that "outside" ACL, which permits devices beyond  
the firewall to respond to sessions initiated from behind the firewall.

This is a very simple port-specific firewall that requires a minimum of  
management - I configured it once and basically forgot it - that  
provides most of what one would want at layer 3 in a SOHO solution. I  
would suggest that this is a pretty strong basis for the solution you  
suggest.

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Tue, 5 Apr 2005 19:06:47 -0700

This is a good discussion - I'm refining my views on this based on all your
comments.

-------- on edge firewalls and proxies ...

If you are proposing that an edge firewall running a stateful protocol
filter provides a good alternative to NAT, I completely agree.  By
advocating using stateful edge firewalls or port filtering, you are also
proposing breaking end-to-end, or peer-to-peer, because you are preventing
the "protected" systems from being reachable from the Internet.  Of course -
that's what you want.  Only an unprotected IPv6 node is truly peer-to-peer -
capable of being contacted by any process from any other node - which would
be crazy on today's public network.  Even with distributed (host) firewalls,
breaking end-to-end is actually a goal - just a selective goal.  I break
end-to-end for some connection types and call it "protection" - other
peer-to-peer services I allow.

IMHO, what we want to provide is "managed peer-to-peer".  With NAT, I simply
cannot provide internal nodes with peer-to-peer - I do not have enough
addresses.  With NAP, I can allow peer-to-peer selectively for any node,
allowing me to "protect them", but also "selectively expose them" - where I
expose them to be peers for other nodes I specify or specific services I
authorize.

And, to return to the "proxies" point, that is another "peer-to-peer
management tool".  I can allow a protected node to get HTTP access via a
proxy (for example), where I can use my proxy device tools (content
inspection, topology hiding, caching, policy enforcement) to enhance
security for that node.  I can also, since I have IPv6 and plenty of
addresses, implement my edge firewall rules to allow it to be a true peer of
some other nodes on the network when peer-to-peer is the way the application
works best.

Managed protection for internal nodes, use of proxies for some types of
connections, when they provide advantages, and true peer-to-peer where
that's the right connection type for a given application.

Seems like the best of both worlds to me.  

Spence

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Apr 2005 12:33:22 +0930

Hi John,

On Tue, 5 Apr 2005 19:06:47 -0700

> -------- on edge firewalls and proxies ...

<snip>

  Even with distributed (host) firewalls,
> peer-to-peer services I allow.

(not sure if this is off topic for the list, apologies if it is)

While it might appear to be a semantic argument, I don't think host
firewalls are breaking end-to-end. 

In simple terms, I think that end-to-end is another way of expressing the
classic cliche, "If you want something done properly, you need to do it
yourself."

When it comes to reliable data delivery, trustworthy security, or
service availability limitations (e.g., firewalling) the node which "wants
the job done properly" the most is the end-node itself. Intermediary
devices, such as routers, usually service more than one end-node, and
therefore generally can't be trusted to have the same interest "in the
job being done properly" as each of the end nodes themselves.
Additionally, they usually don't have enough information to be sure that
they are doing the "proper job".

In the case of host based firewalling, the host itself is the most
knowledgable regarding what its firewalling requirements are, and
therefore is the best device to perform that firewalling. An additional
advantage of host based firewalling is that it is network topology
independant. This is going to matter more and more as mobile devices,
such as laptops, have multiple wired and wireless interfaces.

This may sound theoretical; interestingly, host based firewalling
capability is pretty much already a reality today. All major OSes (*nix,
MS, Apple, etc.,) are coming with a firewalling capability out of the
box, commonly defaulted to "on". Additionally, it is in every "desktop"
OS, rather than just special nodes such as servers, as the OS
"manufacturer" couldn't be sure that there would be an upstream,
intermediary firewalling device. OS manufacturers have decided that each
and every individual device has to be responsible for its own
firewalling. Firewalling is already evolving towards the end-to-end
model.

(Arguably, even host based firewalling isn't true end-to-end. In
reality, it is the applications themselves that have more knowledge of
their security requirements than the Host OS, and therefore they should
be executing security functions themselves. For example, SSH implements
security within the application, and therefore host or network
firewalling, based on network IP(v4|v6) identity or location and
transport layer port numbers, isn't really that necessary for SSH)

Regards,
Mark.

-- 

    The Internet's nature is peer to peer.

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Tue, 5 Apr 2005 20:15:10 -0700

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.

Spence

----------------------------

> While it might appear to be a semantic argument, I don't 
> think host firewalls are breaking end-to-end. 
> 
> In simple terms, I think that end-to-end is another way of 
> expressing the classic cliche, "If you want something done 
> properly, you need to do it yourself."
> 
> When it comes to reliable data delivery, trustworthy 
> security, or service availability limitations (e.g., 
> firewalling) the node which "wants the job done properly" the 
> most is the end-node itself. Intermediary devices, such as 
> routers, usually service more than one end-node, and 
> therefore generally can't be trusted to have the same 
> interest "in the job being done properly" as each of the end 
> nodes themselves.
> Additionally, they usually don't have enough information to 
> be sure that they are doing the "proper job".
> 
> In the case of host based firewalling, the host itself is the 
> most knowledgeable regarding what its firewalling requirements 
> are, and therefore is the best device to perform that 
> firewalling. An additional advantage of host based 
> firewalling is that it is network topology independent. This 
> is going to matter more and more as mobile devices, such as 
> laptops, have multiple wired and wireless interfaces.
> 
> This may sound theoretical; interestingly, host based 
> firewalling capability is pretty much already a reality 
> today. All major OSes (*nix, MS, Apple, etc.,) are coming 
> with a firewalling capability out of the box, commonly 
> defaulted to "on". Additionally, it is in every "desktop"
> "manufacturer" couldn't be sure that there would be an 
> upstream, intermediary firewalling device. OS manufacturers 
> have decided that each and every individual device has to be 
> responsible for its own firewalling. Firewalling is already 
> evolving towards the end-to-end model.
> 
> (Arguably, even host based firewalling isn't true end-to-end. 
> In reality, it is the applications themselves that have more 
> knowledge of their security requirements than the Host OS, 
> and therefore they should be executing security functions 
> themselves. For example, SSH implements security within the 
> application, and therefore host or network firewalling, based 
> on network IP(v4|v6) identity or location and transport layer 
> port numbers, isn't really that necessary for SSH)
> 
> Regards,
> Mark.
> 
> -- 
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Apr 2005 13:27:24 +0930

Hi John,

On Tue, 5 Apr 2005 20:15:10 -0700

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

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Apr 2005 13:40:51 +0930

On Wed, 6 Apr 2005 13:27:24 +0930

<snip>
 
> part of a migrationary path to "new thinking".

To clarify, I'm making broad statements about IPv6 deployment, rather
than specifically the NAP draft. Some of my comments would apply to the
NAP Draft though.

Regards,
Mark.

--