Subject: [v6ops] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Sep 2015 22:04:39 -0300

Folks,

We have published an I-D entitled "On Firewalls in Internet Security".
The I-D is available at:
<https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-00.txt>.

Our I-D covers a broad range of topics (ranging from operations to
internet and transport area topics) -- hence the crosspost of this
announcement to multiple mailing-lists.

While we (co-authors) are subscribed to most of the lists to which this
announcement is being crossposted, we expect (for the sake of unifying
the discussion in a single place) the discussion to happen in the
[email-masked] mailing-list.

Your feedback will be very welcome.

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-opsawg-firewalls-analysis-00.txt
Date: Mon, 14 Sep 2015 17:49:41 -0700
From: [email-masked]
To: Paul E. Hoffman <[email-masked]>, Fernando Gont
<[email-masked]>, Fernando Gont <[email-masked]>, Fred
Baker <[email-masked]>, Fred Baker <[email-masked]>, Paul Hoffman
<[email-masked]>

A new version of I-D, draft-gont-opsawg-firewalls-analysis-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-opsawg-firewalls-analysis
Revision:	00
Title:		On Firewalls in Internet Security
Document date:	2015-09-15
Group:		Individual Submission
Pages:		17
URL:
https://www.ietf.org/internet-drafts/draft-gont-opsawg-firewalls-analysis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-opsawg-firewalls-analysis/
Htmlized:
https://tools.ietf.org/html/draft-gont-opsawg-firewalls-analysis-00

Abstract:
   This document analyzes the role of firewalls in Internet security,
   and suggests a line of reasoning about their usage.  It analyzes
   common kinds of firewalls and the claims made for them.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Sep 2015 11:38:10 -0700

On Sep 14, 2015, at 18:04, Fernando Gont <[email-masked]> wrote:
> 
> […] While we (co-authors) are subscribed to most of the lists to which this

I can’t subscribe to the opsawg list. Here’s my feedback.

— There are many things I don’t like about the style of this draft, but I shall confine my feedback to constructive technical criticisms. In particular, there is one criticism leveled at the end of this message, which has me quite exercised, so please read that one if you read nothing else.

— Section 2, Terminology: "All modern firewalls allow an administrator to change the policies in the firewall” is not true. There is an important and very common exception: RFC 6092 residential gateways simple security firewalls, which makes no recommendation allowing administrators to change policies.

— Section 3.3, Building a communication: "Attacks on infrastructure occur when message volume overwhelms infrastructure or uses infrastructure but has no obvious receiver.” Normal communications are possible when one or both of the sender and receiver are not obviously identifiable to a third part, including the network operator. I hope I don’t need to defend that assertion to the authors of this draft. Recommend: “…uses infrastructure but has no authorized receiver."

— continuing… "to drop traffic sent by an unauthorized or inappropriate sender or which has no host or application willing to receive it as close as possible to the sender” is problematic. Recommend: “to drop traffic with no authorized sender or receiver.”

— On the topic of authorized senders and receivers… It may be worth pointing out that some firewalls, e.g. Context or Zone-based Firewalls, operate on the principle that hosts inside a protected perimeter are authorized by solely virtue of their network location to send and receive, by default with exceptional policies applied to deny sending and receiving to specifically identified hosts.

— Section 4.3, Intrusion Management. "Reputation databases have a bad reputation for distributing information which is incorrect or out of date…” or compromised by attackers.

— Section 10, Recommedations. "Zone-based firewalls, when used, SHOULD exclude all session initiation from outside the zone regardless of attributes such as the use of IPsec.  They SHOULD also facilitate the use of a protocol such as PCP by hosts to identify traffic (IPsec AH, IPsec ESP, transports in general, or transports using specified destination port ranges) that they are willing to receive, and interpret that into rules permitting specified traffic to those specific systems.”

>>>> Wait, WHAT? Where was the discussion in this draft about making firewalls break IPsec? This would be a major walk-back on the discussion of IPsec and Internet Key Exchange in section 3.2.4 of RFC 6092, which we arrived at by a long and arduous discussion in V6OPS. We expressly carved out an exception for IPsec in simple security because it is understood that protecting hosts with a zone-based firewall shouldn’t prevent them from taking responsibility for their own end-to-end network security by using IPsec and Internet Key Exchange. What happened to make us change our minds about that?

—james

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Sep 2015 20:33:05 -0300

Hi, James,

Thanks so much for ou feedback! -- Please ind my comments in-line....

On 09/15/2015 03:38 PM, james woodyatt wrote:
>> […] While we (co-authors) are subscribed to most of the lists to
>> which this announcement is being crossposted, we expect (for the
>> sake of unifying the discussion in a single place) the discussion
>> to happen in the [email-masked] mailing-list.
> 
> — There are many things I don’t like about the style of this draft,
> but I shall confine my feedback to constructive technical criticisms.
> In particular, there is one criticism leveled at the end of this
> message, which has me quite exercised, so please read that one if you
> read nothing else.

FWIW, I'll read all :-)

> — Section 2, Terminology: "All modern firewalls allow an
> administrator to change the policies in the firewall” is not true.
> There is an important and very common exception: RFC 6092 residential
> gateways simple security firewalls, which makes no recommendation
> allowing administrators to change policies.

That doesn't necessarily invalidate our claim: do you know of any
firewall that does not allow the fw policies to be changed?

In any case, would s/all/most/ address your concern?

> — Section 3.3, Building a communication: "Attacks on infrastructure
> occur when message volume overwhelms infrastructure or uses
> infrastructure but has no obvious receiver.” Normal communications
> are possible when one or both of the sender and receiver are not
> obviously identifiable to a third part, including the network
> operator.

Not sure what you mean by "normal communications"... In the ase of a DoS
scenario, that's certainly not true.

> I hope I don’t need to defend that assertion to the authors
> of this draft. Recommend: “…uses infrastructure but has no authorized
> receiver."

The term authorization tends to have a specific meaning which I'm not
sure it's applicable here.

> — continuing… "to drop traffic sent by an unauthorized or
> inappropriate sender or which has no host or application willing to
> receive it as close as possible to the sender” is problematic.
> Recommend: “to drop traffic with no authorized sender or receiver.”

So: please define "authorized".

> — On the topic of authorized senders and receivers… It may be worth
> pointing out that some firewalls, e.g. Context or Zone-based
> Firewalls, operate on the principle that hosts inside a protected
> perimeter are authorized by solely virtue of their network location
> to send and receive, by default with exceptional policies applied to
> deny sending and receiving to specifically identified hosts.

Will do.

> — Section 4.3, Intrusion Management. "Reputation databases have a bad
> reputation for distributing information which is incorrect or out of
> date…” or compromised by attackers.

Will add this. Thanks!

> — Section 10, Recommedations. "Zone-based firewalls, when used,
> SHOULD exclude all session initiation from outside the zone
> regardless of attributes such as the use of IPsec.  They SHOULD also
> facilitate the use of a protocol such as PCP by hosts to identify
> traffic (IPsec AH, IPsec ESP, transports in general, or transports
> using specified destination port ranges) that they are willing to
> receive, and interpret that into rules permitting specified traffic
> to those specific systems.”
> 
>>>>> Wait, WHAT? Where was the discussion in this draft about
>>>>> making firewalls break IPsec? 

This has nothing to do with breaking IPsec. The fact that a flow is
authenticated doesn't mean, per se, that you have to let the traffic
through. -- that's all this I-D is saying.

>>>>> This would be a major walk-back
>>>>> on the discussion of IPsec and Internet Key Exchange in
>>>>> section 3.2.4 of RFC 6092, which we arrived at by a long and
>>>>> arduous discussion in V6OPS. We expressly carved out an
>>>>> exception for IPsec in simple security because it is
>>>>> understood that protecting hosts with a zone-based firewall
>>>>> shouldn’t prevent them from taking responsibility for their
>>>>> own end-to-end network security by using IPsec and Internet
>>>>> Key Exchange. What happened to make us change our minds about
>>>>> that?

I wasn't involved in such discussion, so I'll let Fred respond to this one.

That said,

1) I personally disagree with the aforementioned advice, at least for a
general zone-based firewall. Use of IPsec has a different intent that
packet filtering. Use of one need not preclude the use of the other. For
instance, use of IPsec need not prevent DoS attacks -- atually, in some
cases it may even enable it.

2) We plan to split the "recommendations" section into a separate document.

Thanks!

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Sep 2015 12:30:44 -0700

[this is the first of my responses. another specifically discussing IPsec will come later.]

> firewall that does not allow the fw policies to be changed?

Yes. They’re actually pretty common in the United States. Many ISPs provide customers with home gateways that perform RFC 6092 simple security functions without any provision for changing the policy rules. In some cases, there are mechanisms for changing the policy rules, but it’s very rare that customers are actively made aware of them, and they are always strongly counseled against using them. The effective result is that firewall policies are unmanaged.

> In any case, would s/all/most/ address your concern?

Yes.

>> obviously identifiable to a third party, including the network
>> operator.
> 
> Not sure what you mean by "normal communications"... In the case of a DoS scenario, that's certainly not true.

Of course, I accept that denial of service attacks are not “normal” communications.

Nevertheless, it is certainly possible for a sender and a receiver to establish normal communications, i.e. not denial of service attacks, over clear channels that are monitored by the third parties where neither the sender nor the receiver intend for them to have the capability to identify who is communicating.

If you want to argue that such communications cannot ever be “normal” communications, expressly because the parties in communication are not identifiable to the operator of an on-path firewall, then I’d like you to elaborate your thoughts in light of the following phrase in RFC 7258: “...or through correlation with other communication events, reveal information the parties did not intend to be revealed."

> sure it's applicable here.

Then please add some language that attempts to clarify what “authorization” means in the context of a zone-based firewall. I’ll admit to having rather woolly-headed thoughts on the matter, so I’ll leave it to you how best to illustrate it.

—james

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Sep 2015 16:44:26 -0300

Hi, James,

Thanks so much for your prompt response! -- Please find my comments
in-line...

On 09/16/2015 04:30 PM, james woodyatt wrote:
> On Sep 15, 2015, at 16:33, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> Yes. They’re actually pretty common in the United States. Many ISPs
> provide customers with home gateways that perform RFC 6092 simple
> security functions without any provision for changing the policy rules.
> In some cases, there are mechanisms for changing the policy rules, but
> it’s very rare that customers are actively made aware of them, and they
> are always strongly counseled against using them. The effective result
> is that firewall policies are unmanaged.
> 

I've applied this change in my working copy of the I-D.

> Nevertheless, it is certainly possible for a sender and a receiver to
> establish normal communications, i.e. not denial of service attacks,
> over clear channels that are monitored by the third parties where
> neither the sender nor the receiver intend for them to have the
> capability to identify who is communicating.

What we meant here is that at times DoS attacks can be launched with
packets that e.g. target non-existing addresses. So, if you're receiving
a flood od packets to an address in your network that you know that
doesn't exist, you can filter such traffic.

> If you want to argue that such communications cannot ever be “normal”
> communications, expressly because the parties in communication are not
> identifiable to the operator of an on-path firewall,

No. That's certainly not what we meant.

> Then please add some language that attempts to clarify what
> “authorization” means in the context of a zone-based firewall. I’ll
> admit to having rather woolly-headed thoughts on the matter, so I’ll
> leave it to you how best to illustrate it.

Point taken. Will try to improve this.

Thanks!

Cheers,