Subject: Re: Time to move beyond the 32 bit Internet.

From: Fernando Gont <[email-masked]>
Date: Tue, 01 Jul 2014 07:45:17 -0300

Hi, Fred,

On 06/25/2014 04:03 PM, Fred Baker (fred) wrote:
[....]
> has had trouble. I installed a surveillance system for her. One of 
> the really nice things is that the computer in her home can use 
> Dynamic DNS to enable and application on her phone or laptop to 
> access the current camera or stored footage from somewhere else. 
> There are several systems that allow that. 
> https://www.google.com/search?q=surveillance+dynamic+dns. It works 
> through a NAT by configuring the NAT appropriately. In her case, 
> however, she has the NAT in her router and a NAT somewhere
> upstream (in her modem, probably, or perhaps CGN if the provider is
> using that), so that the service doesn’t actually WORK. IPv6 would
> solve that issue cold, although it would perhaps highlight security
> issues (so who is looking at her surveillance footage?).

In this particular case, what's preventing the app from working
properly is not the "address translation" part of the device, but the
fat that such address translation implicitly results in a diode
firewall (a firewall that only allows outgoing connections).

IPv6 with a diode-firewall on the perimiter would essentially face the
same challenge/problem. I seem to recall folks noting that that's hw
they deploy v6 to the home...

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 1 Jul 2014 16:55:09 +0000

> they deploy v6 to the home...

Well, sort of. A zone-based firewall (NAT or otherwise) primarily allows in responses to traffic it has sent out, and https://tools.ietf.org/html/rfc6092 is an example of that. However, just as NATs do, such firewalls usually allow for a firewall rule that will allow specified traffic to go to a specified address. That’s the purpose of PCP, for example. 

That is a place I have well and truly scratched my head regarding the firewall discussion in the IETF. There’s a set of people, including me, that think that firewalls have a certain levee of utility and in any event are a business requirement. There’s another set of people who “don’t want no stinkin’ firewalls”, and argue their case on the basis of the end to end principle. No aspersions here; I understand their point, and my daughter’s surveillance service would be a case in point of the kind of service they want to enable.

Where my head tips is this. I see three kinds of traffic across that divide. One is sessions originated from the network - I sent something to Netflix, Facebook, or whoever, and it replied. The vast majority of residential traffic, I would guess, falls in that category, and apart from electric mail and traffic to business services to customers, I would guess that the vast majority of legitimate enterprise traffic does as well. A second is sessions originated from outside the network to services that the network intends to offer - web access to www.example.com, incoming SMTP, my daughter’s surveillance service (which is a web access), and so on. The third is “everything else” - traffic that wasn’t invited and has no application, and perhaps no host, to respond to it.

The first works in almost any case - a firewall that prevents you from running an application you want to run isn’t going to last very long. The second is trivially allowed for by a firewall rule or PCP/UPnP exchange, and if there is an application (set-top box or whatever) in the home that wants to allow for such a service, it can fire off the request. The third - what is the argument for letting that into my home or enterprise network? 

And I tend to think that the conversation breaks down at that point. Everyone agrees on the first and second. When someone says “I want to block the third”, the response is “but I want to allow the second” without acknowledging or commenting on the third. And I just find myself shaking my head in disbelief. Wouldn’t it be nice of both speakers in the conversation would address the same subject?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 1 Jul 2014 18:06:55 +0000

> And I tend to think that the conversation breaks down at that point. Everyone agrees on the first and second. When someone says “I want to block the third”, the response is “but I want to allow the…

I should have included one more aspect in the third set. That is traffic disallowed by policy. Current top-of-mind in security circles includes NTP attacks - someone sends a message with a spoofed source address to an NTP server, which now sends something to that address every mumble time units. In a home, the counterpart might be a media server - something I have and intend to be used by people in my home. In such cases, while the application and server it runs on exist, it is not intended for use by folks “outside”. So once again, traffic to it “from outside”  is uninvited and has no application, and perhaps no host, *intended* to respond to it.

And again I ask - sure, we all agree on category 1 and 2 - accesses to services from within and permitted access to services from without - but what’s the argument for allowing the third category into the network?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 1 Jul 2014 19:19:48 +0000

> I should have included one more aspect in the third set. That is 
> traffic disallowed by policy. Current top-of-mind in security
> circles includes NTP attacks - someone sends a message with a 
> spoofed source address to an NTP server, which now sends 
> something to that address every mumble time units...

Presumably, your firewall could have some kind of source address verification that takes care of such spoofing. 

As for "diode firewalls," they can be bypassed trivially using ICE, STUN, etc. That is, as long as the application is using UDP. Which means that instead of applications running over TCP, they will need to use some reliable transport over UDP. There are plenty of those...

Now, we can debate whether the Internet will be a better place with diode firewalls instead of routers and transport over UDP instead of TCP.

-- Christian Huitema

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Jul 2014 09:07:24 +1000

Part of the issue is that a firewall doesn't actually do much to
help a properly secured host and they just makes applications harder
to develop as they need to start punching holes in multiple firewalls.

It just drops a little traffic which would otherwise be rejected
immediately or dropped after timeout by the host.

Additionally firewall developer do not keep up to date with protocol
changes (how many firewalls, 15 years after EDNS was developed,
still think that DNS/UDP packets are 512 bytes).  They are often
used to incorrectly to block legitimate traffic (icmp PTB, fragments)
associated with "wanted" flows.

They are themselves a attackable DoS point due to table exhaustion.

They also don't encourage other manufactures to take security of
their products into proper consideration.  Just because they are
inside a "firewall" doesn't mean that they are in a safe environment
yet that is the attitude some manufactures seem to take.

Also once the application punches holes in the firewall may as not
be there as the service is exposed.

What I do want to see in a firewall is outbound BCP38 style filters
by default.  Hosts will get compromised with or without a firewall.
They will emit spoofed traffic.  Most NAT boxes are pretty good at
turning spoofed traffic into legitimately sourced traffic when it
appears on the Internet.

Firewalls should be protecting the Internet from the home as they
don't do much to protect the home from the Internet.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Jul 2014 05:30:28 -0300

On 07/01/2014 01:55 PM, Fred Baker (fred) wrote:
> 
> That is a place I have well and truly scratched my head regarding 
> the firewall discussion in the IETF. There’s a set of people, 
> including me, that think that firewalls have a certain levee of 
> utility and in any event are a business requirement.

FWIW, I'm in this camp.

> Where my head tips is this. I see three kinds of traffic across 
> that divide. One is sessions originated from the network - I sent 
> something to Netflix, Facebook, or whoever, and it replied. The 
> vast majority of residential traffic, I would guess, falls in that
>  category, and apart from electric mail and traffic to business 
> services to customers, I would guess that the vast majority of 
> legitimate enterprise traffic does as well. A second is sessions 
> originated from outside the network to services that the network 
> intends to offer - web access to www.example.com, incoming SMTP, my
> daughter’s surveillance service (which is a web access), and so on.
> The third is “everything else” - traffic that wasn’t invited and
> has no application, and perhaps no host, to respond to it.
> 
> The first works in almost any case - a firewall that prevents you 
> from running an application you want to run isn’t going to last 
> very long. The second is trivially allowed for by a firewall rule 
> or PCP/UPnP exchange, and if there is an application (set-top box 
> or whatever) in the home that wants to allow for such a service,
> it can fire off the request. The third - what is the argument for 
> letting that into my home or enterprise network?

Could you provide an example of this "third" traffic?

> And I tend to think that the conversation breaks down at that 
> point. Everyone agrees on the first and second. When someone says 
> “I want to block the third”, the response is “but I want to allow 
> the second” without acknowledging or commenting on the third. And
> I just find myself shaking my head in disbelief. Wouldn’t it be
> nice of both speakers in the conversation would address the same 
> subject?

I guess the fos arguing "but I want to allow the second" really mean
"I want to allow the second with no manual configuration or
upnp-kind-of-thing"?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Jul 2014 05:38:52 -0300

On 07/01/2014 04:19 PM, Christian Huitema wrote:
>> spoofed source address to an NTP server, which now sends something
>> to that address every mumble time units...
> 
> Presumably, your firewall could have some kind of source address
> verification that takes care of such spoofing.
> 
> As for "diode firewalls," they can be bypassed trivially using ICE,
> STUN, etc. 

Does that really count as "the firewall being bypassed"? -- If it
requires collaboration from the inside, I wouldn't count that as
"bypassing".

A simple diode firewall essentially prevents e.g. trivial
address-scanning from the outside. And in the light of IoT, where you
might have devices with buggy code (including "default passwords that
were never changed") that maybe never get patched/updated, even such a
simple policy is probably useful.

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Jul 2014 05:49:50 -0300

> to develop as they need to start punching holes in multiple firewalls.

Maybe the question is "how many of the hosts out there are properly
secured"?

> immediately or dropped after timeout by the host.

Not sure what you mean...

> associated with "wanted" flows.

This could be an indication of room/need for advice.

> They are themselves a attackable DoS point due to table exhaustion.

Agreed. But that really depends on the type of firewall (stateless vs.
statefull) and other assumptions such as "the good folks are in the
internal network, the bad ones on the outside" -- and even then
firewalls can limit the number of state table entries based on source
address or user.

> their products into proper consideration.  

Well, they guy deploying the firewall is most likely not the vendor. --
i.e., he probably has deployed products that "might not have taken
security seriously", and ends the firewall at least possibly blocks some
attacks against them.

> Just because they are

This seems to be an argument against "diode" firewalls rather than
against firewalls in general?

Cheers,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 09:35:53 -0400

> FWIW, I'm in this camp.

reluctantly, I am still in this camp, but I regret a lot of things that
companies I was involved in did in the 1990s...

    > "I want to allow the second with no manual configuration or

I agree with Fred's description of the conversation, but it isn't complete.
The "I" in the sentence is not singular.  It has many different roles,
and they are often in conflict and they are often not empowered to actually
enact change.  Firewall problems in an enterprise are a symptom of a much
larger (society) scale systematic problem we have with bureaucracies.
(Imagine if the Vogons ran the Internet... some people, perhaps don't need to)

In the home, firewalls were never planned, and are the unintended result of
ISPs pushing NAT on end users.  (Either directly by giving them the box,
or indirectly by making multiple IP addresses unaffordable/unobtainable)

As for the "IoT with default password", that's exactly the security problem
that firewalls have *CAUSED*; and it's this part that I really regret.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Jul 2014 13:44:31 -0300

On 07/03/2014 10:35 AM, Michael Richardson wrote:
> 
> In the home, firewalls were never planned, and are the unintended
> result of ISPs pushing NAT on end users.  (Either directly by
> giving them the box, or indirectly by making multiple IP addresses
> unaffordable/unobtainable)

I could agree with this view.

> As for the "IoT with default password", that's exactly the security
> problem that firewalls have *CAUSED*; and it's this part that I
> really regret.

I'd argue that this has been caused by vendors being lazy/sloppy than
by firewalls. Poor practices/choices are just that: "poor
practices/choices". -- when you start making bad decisions on the
assumption that there's "something there" that prevents your poor
choices from being exploited, eventually you realize that "assumptions
are the mother of.. many of the problems" :-)

Cheers,