Subject: [OPSAWG] "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: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 17 Sep 2015 05:10:15 +0000

Hi Fernando,

I am struggling to understand the gap this draft fills.

We read "In many cases, as a result, deployments have been underwhelming in both quantity and quality, and the Internet is noted for its problems with security.", but I wouldn't say firewall deployments are underwhelming in quality and quantity. I believe FW are very ubiquitous in today's networks. Were you referring to something else?

Also I am not sure about what the "bickering on the topic" refers to. 

Finally, with all the "NGFW" products and features out there that section 4 could include many more kinds of fws. Same for section 5. 

In general, I think that the draft covers legacy firewalls mostly, not all the modern fw features that exist today and I am not sure if it tries to convince readers about their need (because I don't think in today's world firewalling functionality can be rejected as unnecessary by anyone)

Panos

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Monday, September 14, 2015 9:05 PM
To: [email-masked]
Cc: Internet Area; [email-masked]'; TSV Area; tsvwg; IPv6 Operations
Subject: [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

Folks,

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.

Thanks!

Best regards,
Fernando

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

Abstract:

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

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 17 Sep 2015 21:15:02 +0000

I am also not sure of the intent of this draft. Is the intent of the draft to provide the guideline on configuring Firewall?

Comment to the first paragraph in Section 10 Recommendation:

      Most deployed FWs are usually not "single purposed" as characterized as "Zone-based" FW, or "Rule based" FW.  A FW that has rules on zones can also have rules to allow session originated from outside to some applications.

Comment to the second paragraph in Section 10 Recommendation:
      In order to achieve the recommendation described by the second paragraph of the Section 10 Recommendations, the router has to install all the host routes for "Bob, Alice, etc". It doesn't scale.

      Role-based firewalls can be implemented using routing technology. For example, if Alice should not be able to send a message to Bob, Alice's routing system might not have a route to Bob, or Bob's routing system might not have a route to Alice.

Comment to "FW SHOULD NOT attempt to perform any kind of DPI":
      Many modern FWs do perform DPIs. Are you saying they should be strip off the network? They all had legitimate reasons to be deployed, and they are running fine.

Linda Dunbar

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Panos Kampanakis (pkampana)
Sent: Thursday, September 17, 2015 12:10 AM
To: Fernando Gont; [email-masked]
Cc: [email-masked]'
Subject: Re: [OPSAWG] [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

Hi Fernando,

Panos

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Monday, September 14, 2015 9:05 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Internet Area; [email-masked]'; TSV Area; tsvwg; IPv6 Operations
Subject: [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

Folks,

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]<mailto:[email-masked]> mailing-list.

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]<mailto:[email-masked]>
To: Paul E. Hoffman <[email-masked]<mailto:[email-masked]>>, Fernando Gont <[email-masked]<mailto:[email-masked]>>, Fernando Gont <[email-masked]<mailto:[email-masked]>>, Fred Baker <[email-masked]<mailto:[email-masked]>>, Fred Baker <[email-masked]<mailto:[email-masked]>>, Paul Hoffman <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

_______________________________________________
OPSEC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Sep 2015 13:49:18 -0800

> Also I am not sure about what the "bickering on the topic" refers to.

At one time this was an opsawg deliverable but was dropped
because of the inability to come to consensus on some basic
questions about the document, including the question of what
problem it's intended to solve.  I don't particularly look
forward to another slugfest or the inevitable involvement of
ideologues.

That said, I do think there's value in such a document, for
several reasons.  One is that over the years there have been
a number of efforts to abstract firewall behavior as input
to the design of IETF protocols.  It's a challenge because
firewall behavior does tend to be highly vendor-specific, and
we've published several specifications that try to do it
(nsis's NAT and firewall layer, midcom, etc.).  It would be
(and would have been useful) to have a document describing
where we can reasonably expect to have firewalls in the network
and what we can reasonably expect from their behavior, to
be able to make better protocol design decisions.  Note that
this is distinct from a document making deployment
recommendations (or at least explicit ones).

I also think that there's value in reasoning about architecture,
and publishing a document describing that reasoning.  I suspect
that having it come from the IAB might reduce some of the
friction in moving the document along, but it might not reduce
it enough.  But it's quite clear to me that because nearly any
discussion related to middleboxes has erupted into ideological
warfare we've been hampered in producing particularly thoughtful
architectural work on what it means to have them in the network,
instead knocking out stopgap workaround protocols here and there,
and that's unfortunate.

This should particularly be a concern given the possibility
that i2nsf is going to be chartered, where there will be some
serious issues around trust, authority, and delegation.  It
very likely would have been useful to have this document as
those discussions progressed.

That said, I expect that if this is adopted again by opsawg,
it will not be a fun ride.  But it might be worthwhile to do it
anyway.

Melinda

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Sep 2015 20:03:17 -0300

Hi, Melinda,

>> Also I am not sure about what the "bickering on the topic" refers to.
[...]
> recommendations (or at least explicit ones).

FWIW, while there are some *very general* recommendations in our
document, our plan is to move such recommendations out into a separate
document. One one hand, to keep the I-D more focused, and on the other
because any recommendations deserver a document on their own.

> instead knocking out stopgap workaround protocols here and there,

That's certainly part of the intent of this doucment.

Thanks so much for chimming in!

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Sep 2015 20:23:52 -0300

Hi, Linda,

On 09/17/2015 06:15 PM, Linda Dunbar wrote:
> I am also not sure of the intent of this draft. Is the intent of the
> draft to provide the guideline on configuring Firewall?

Certainly not. Please see Melinda's comments.

> Most deployed FWs are usually not “single purposed” as characterized as
> “Zone-based” FW, or “Rule based” FW. A FW that has rules on zones can
> also have rules to allow session originated from outside to some
> applications.

We didn't mean that firewalls are single purposed. Certinly, a given
device can implement different kinds of firewalls. That doesn't make our
analysis on the kinds of firewalls incorrect, though.

> In order to achieve the recommendation described by the second paragraph
> of the Section 10 Recommendations, the router has to install all the
> host routes for “Bob, Alice, etc”. It doesn’t scale.

I guess that depends on a number of factors... among others, on the
granularity that you talk about.

> Comment to “FW SHOULD NOT attempt to perform any kind of DPI”:
> Many modern FWs do perform DPIs. Are you saying they should be strip off
> the network? They all had legitimate reasons to be deployed, and they
> are running fine.

You seem to have cut off part of the sentence. It says:

   firewalls of any type SHOULD NOT
   attempt to perform the kind of deep packet inspection and surgery
   that is common with Network Address Translators [RFC2993]

And what we mean s not that FWs should not perform the kind of surgery
that NAT devices perform (e.g., modifying the application data stream).

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Sep 2015 21:30:59 -0300

Hi, Panos,

Thanks so much for your feedback! Please find some responses in-line
(more coming...)

> I am struggling to understand the gap this draft fills.

Please see Melinda's comments...

> Finally, with all the "NGFW" products and features out there that
> section 4 could include many more kinds of fws. Same for section 5.

Would you mind elaborating on the kind of features that you're referring to?

> In general, I think that the draft covers legacy firewalls mostly,
> not all the modern fw features that exist today and I am not sure if
> it tries to convince readers about their need (because I don't think
> in today's world firewalling functionality can be rejected as
> unnecessary by anyone)

Please check many discussions in IETF circles. Many deem firewalls as evil.

Thanks!

Best regards,

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 18 Sep 2015 03:22:43 +0000

Sorry I didn't see Melinda's response. Maybe because I am not subscribed in opsawg.

> Would you mind elaborating on the kind of features that you're referring to?
Vendors have multiple. Some are:
- File inspection, Application visibility and control
- TLS proxying
- IPS
- Malware protection
- DNS blackholing
- Botnet protection, similar to reputation filtering
- Web protection and filtering
- behavioral analysis, event correlation
- Vulnerability analysis
- Traffic control (policing etc)
- Threat protection (top talkers, DoS etc)
Firewalls and their managements platforms have so many functions nowadays especially with so many vendors, that it is very tough to account for them in one document I think.

> Please check many discussions in IETF circles. Many deem firewalls as evil.

Could be, I wasn't aware. The industry doesn't seem to do so. Maybe the draft serves to address some concerns of the IETF community.

Panos

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, September 17, 2015 8:31 PM
To: Panos Kampanakis (pkampana); [email-masked]
Cc: [email-masked]'
Subject: Re: [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

Hi, Panos,

Thanks so much for your feedback! Please find some responses in-line (more coming...)

> In general, I think that the draft covers legacy firewalls mostly, not 
> all the modern fw features that exist today and I am not sure if it 
> tries to convince readers about their need (because I don't think in 
> today's world firewalling functionality can be rejected as unnecessary 
> by anyone)

Thanks!

Best regards,

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 18 Sep 2015 03:43:04 +0000

Fernando, 

Thank you very much for the reply. 

The section 4 & 5 of the draft are really good. 

Linda

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Thursday, September 17, 2015 6:24 PM
To: Linda Dunbar; Panos Kampanakis (pkampana); [email-masked]
Cc: [email-masked]'
Subject: Re: [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

Hi, Linda,

> Most deployed FWs are usually not "single purposed" as characterized 
> as "Zone-based" FW, or "Rule based" FW. A FW that has rules on zones 
> can also have rules to allow session originated from outside to some 
> applications.

We didn't mean that firewalls are single purposed. Certinly, a given device can implement different kinds of firewalls. That doesn't make our analysis on the kinds of firewalls incorrect, though.

> In order to achieve the recommendation described by the second 
> paragraph of the Section 10 Recommendations, the router has to install 
> all the host routes for "Bob, Alice, etc". It doesn't scale.

I guess that depends on a number of factors... among others, on the granularity that you talk about.

> Many modern FWs do perform DPIs. Are you saying they should be strip 
> off the network? They all had legitimate reasons to be deployed, and 
> they are running fine.

And what we mean s not that FWs should not perform the kind of surgery that NAT devices perform (e.g., modifying the application data stream).

Thanks!

Cheers,

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 18 Sep 2015 03:46:59 +0000

Melinda, 

Thank you very much for explaining the intent of the draft. I find the rule categories described by  Section 4 and 5 are very useful. As you mentioned the possibility of I2NSF WG to be created, I think the Section 4&5 provides a good design consideration for the types of rules to FW. 

As the line between today's FW and IPS are getting blurred, those rules can apply to IPS/IDS as well. 

Linda 

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Thursday, September 17, 2015 4:49 PM
To: [email-masked]
Subject: Re: [OPSAWG] [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)

> Also I am not sure about what the "bickering on the topic" refers to.

At one time this was an opsawg deliverable but was dropped because of the inability to come to consensus on some basic questions about the document, including the question of what problem it's intended to solve.  I don't particularly look forward to another slugfest or the inevitable involvement of ideologues.

That said, I do think there's value in such a document, for several reasons.  One is that over the years there have been a number of efforts to abstract firewall behavior as input to the design of IETF protocols.  It's a challenge because firewall behavior does tend to be highly vendor-specific, and we've published several specifications that try to do it (nsis's NAT and firewall layer, midcom, etc.).  It would be (and would have been useful) to have a document describing where we can reasonably expect to have firewalls in the network and what we can reasonably expect from their behavior, to be able to make better protocol design decisions.  Note that this is distinct from a document making deployment recommendations (or at least explicit ones).

I also think that there's value in reasoning about architecture, and publishing a document describing that reasoning.  I suspect that having it come from the IAB might reduce some of the friction in moving the document along, but it might not reduce it enough.  But it's quite clear to me that because nearly any discussion related to middleboxes has erupted into ideological warfare we've been hampered in producing particularly thoughtful architectural work on what it means to have them in the network, instead knocking out stopgap workaround protocols here and there, and that's unfortunate.

This should particularly be a concern given the possibility that i2nsf is going to be chartered, where there will be some serious issues around trust, authority, and delegation.  It very likely would have been useful to have this document as those discussions progressed.

That said, I expect that if this is adopted again by opsawg, it will not be a fun ride.  But it might be worthwhile to do it anyway.

Melinda

[email-masked]

---

From: "Black, David" <[email-masked]>
Date: Sun, 20 Sep 2015 22:00:47 +0000

> Could be, I wasn't aware. The industry doesn't seem to do so. Maybe the draft
> serves to address some concerns of the IETF community.

That might be useful - I can supply one such concern ;-).

During TSVWG work on the port usage draft that became RFC 7605, what
seemed like a simple question - Should the secure and insecure variants
of a protocol use different (UDP/TCP/etc.) ports? - generated a long debate
with a high heat/light ratio whose conclusion was effectively "it depends":

   However, there
   is no IETF consensus on when separate ports should be used for secure
   and insecure variants of the same service [RFC2595] [RFC2817]
   [RFC6335].  The overall preference is for use of a single port, as
   noted in Section 6 of this document and Section 7.2 of [RFC6335], but
   the appropriate approach depends on the specific characteristics of
   the service.

(quoted from https://tools.ietf.org/html/rfc7605#section-7.4)

Firewalls were a consideration in that debate, in that being able to block
the insecure variant of a protocol at the boundary of a zone and allow the
secure variant through in a network-operations-controlled fashion can be
useful, but (as can be seen from the above text) firewall considerations
were not an overriding factor that drove the outcome.

This firewalls draft could be a useful place to discuss the interaction
of operational security policy, firewall functionality and service
characteristics - it would be helpful to shed a bit more light on the
operational security characteristics in general (and firewall-related
considerations in particular) of using separate ports for secure vs.
insecure protocol variants.

Thanks,
--David

> Sent: Thursday, September 17, 2015 11:23 PM
> Subject: Re: [OPSAWG] [OPSEC] "On Firewalls in Internet Security" (Fwd: New
> Version Notification for draft-gont-opsawg-firewalls-analysis-00.txt)
> 
> Firewalls and their managements platforms have so many functions nowadays
> especially with so many vendors, that it is very tough to account for them in
> one document I think.
> 
> Could be, I wasn't aware. The industry doesn't seem to do so. Maybe the draft
> serves to address some concerns of the IETF community.
> 
> Panos
> 
> 
> Subject: Re: [OPSEC] "On Firewalls in Internet Security" (Fwd: New Version
> Notification for draft-gont-opsawg-firewalls-analysis-00.txt)
> 
> Hi, Panos,
>