Subject: [OPSEC] IPv6 firewalls reqs: Rationale

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Feb 2014 02:09:11 -0300

Folks,

As noted in my previous email, this is a request to discuss the first
item listed in my previous email:

1) Agree on a rationale to write this spec.

For example, one possible rationale is "aim at providing parity of
features with IPv4". Another one could be that "should should aim a
little higher". For example, in the light of
draft-farrell-perpass-attack we may aim at requiring some privacy
features that might not be that common in IPv4 firewalls.

Thoughts?

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

---

From: Cb B <[email-masked]>
Date: Tue, 18 Feb 2014 21:17:11 -0800

> features that might not be that common in IPv4 firewalls.

Why would you look to a middle box to add privacy or any feature at all?

AFAIK, "firewalls"  are in a unique position to be a single point of
failure for confidentiality , availability , and integrit.

data point - https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633

Is there an IPv4 document that is similar in nature at the IETF?  Or
is spec'ing firewalls a novel thing that for some reason is only
relevant to IPv6

CB

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Feb 2014 02:37:03 -0300

> Why would you look to a middle box to add privacy or any feature at

Yep, sloppy terminology, sorry. -- I meant confidentiality, and I was
referring to e.g. the VPN requirements in the current version of the
document.

*And*, I wasn't really arguing in favor. Just posing the question.

> data point -
> https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633
>
>  Is there an IPv4 document that is similar in nature at the IETF?

No. Firewalls have been mostly ignored in the IETF series.

> Or is spec'ing firewalls a novel thing that for some reason is only 
> relevant to IPv6

I wouldn't call it novel. And it's certainly also relevant for IPv4,
too. We probably left the IPv4 stuff out on the reasoning that it's
probably rather late for that.

The goal of specifying the requirements for v6 is because we have heard
from many operators that whenever they want to purchase an IPv6
firewall, they have to come up with the requirements themselves, and
then what they get from vendors is usually "not that nice" (so to speak
:-) ).

Please see e.g. the IPv6 firewalls talk(s) from the ipv6hackers meeting
in Berlin 2013 (http://www.ipv6hackers.org).

P.S.: Bottom-line: I posted this request for feedback for folks to make
their point, not to necessarily agree with what's currently in the I-D! ;-)

Thanks!

Cheers,

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Wed, 19 Feb 2014 18:00:58 +0000

Hi Fernando,

I am not sure that is within scope. http://tools.ietf.org/html/draft-ietf-opsec-v6-04 covers many of the IPv6 issues and concerns that someone would need to evaluate its vendors against. 

Why don't we write a doc on IPv4, as CB mentioned? Why not one for application firewalls? Why not one for security features at L2 all products should support. I am not sure such mandates fall under OPSECs goals or are practical to write since requirements and concerns always change based on case and network design.

Just my thoughts.

Panos

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: Wednesday, February 19, 2014 12:09 AM
To: [email-masked]'
Subject: [OPSEC] IPv6 firewalls reqs: Rationale

Folks,

As noted in my previous email, this is a request to discuss the first item listed in my previous email:

For example, one possible rationale is "aim at providing parity of features with IPv4". Another one could be that "should should aim a little higher". For example, in the light of draft-farrell-perpass-attack we may aim at requiring some privacy features that might not be that common in IPv4 firewalls.

Thoughts?

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

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 19 Feb 2014 18:42:38 +0000

(coffee != sleep) & (!coffee == sleep)
 [email-masked]

>       From: OPSEC [[email-masked]] on behalf of Cb B [[email-masked]]
>       Sent: Tuesday, February 18, 2014 10:17 PM
>       To: Fernando Gont
>       Cc: [email-masked]
>       Subject: Re: [OPSEC] IPv6 firewalls reqs: Rationale
>
>
At least parity but given what I have read so far I would say a bit higher.

>       Why would you look to a middle box to add privacy or any feature at all?
That is a common expectation of middle boxes. That is why most people have firewalls, IPSes etc...

>       failure for confidentiality , availability , and integrit.
Absolutely agree. But only when incorrectly managed.

An UNMANAGED or user managed device is frequently ignored and frequently improperly managed leaving it open to all kinds of attacks.

>       data point - https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633

Not a firewall:)

>       Is there an IPv4 document that is similar in nature at the IETF?
Tons :) But most were written w/o specifying ipv4. They were generally written from a ipv4 pov.

http://www.ietf.org/rfc/rfc2979.txt

http://www.ietf.org/rfc/rfc3093.txt

http://tools.ietf.org/search/rfc3511

There is even a IPv6 "not quite firewall" rfc.
https://tools.ietf.org/html/rfc6092

>  Or
I think this work is valid and valuable but am not aware of a direct correlation in IPv4 rfcs. Many rfcs reference firewalls, talk to some of the issues etc... but I have never read a rfc for IPv4 that matches what Gont and company are trying to do here.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Feb 2014 22:37:29 +0100 (CET)

> Thoughts?

When I read this document, it feels very much like requirements for an 
enterprise style firewall. This is not defined in the document, but it 
just says "firewall". I believe the requirements for a host based 
firewall, a residential CPE based firewall, and a full-blown enterprise 
firewall are quite different (considering the amount of complexity both 
in implementation and configuration required).

So while I think this is a worthwhile document for enterprise firewalls, I 
think it should be clearly stated that this is the indended application.

I read some ND validation requirements, which then reminded me that some 
people run firewalls in L2 mode, and some run in L3 mode. The requirements 
for these deployment scenarios are different, and the document should 
probably reflect that.

Another requirement that would be beneficial, is that the firewall warns 
the operator if a policy is to be applied that violates RFC 4890, for 
instance paragraph 4.3.1. This would mean fewer firewall admins would 
hopefully filter essential ICMPv6 packets.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Feb 2014 19:17:31 -0300

Hi, Mikael,

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

On 02/19/2014 06:37 PM, Mikael Abrahamsson wrote:
> So while I think this is a worthwhile document for enterprise firewalls,
> I think it should be clearly stated that this is the indended application.

This is a really good point. Thanks for raising it! We will try to make
this point clear in the next rev.

> people run firewalls in L2 mode, and some run in L3 mode. The
> requirements for these deployment scenarios are different, and the
> document should probably reflect that.

Agreed.

> hopefully filter essential ICMPv6 packets.

Not sure if compliance of firewall rules with the whole RFC4890 might be
"too much". For instance, if you filter ND packets, you'll find it very
easily. Probably the one that'd be worth warning is filtering ICMPv6 PTB....

Thanks so much!

Cheers,

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Mon, 24 Feb 2014 11:03:28 +0000

Hi Fernando,

Firewall technology is implemented based upon usage case and may be very differently for each implementation (centralized, distributed, L3-only, L4-only, L3-L4, Session, Services, Applications, 
etc...)... loads of interpretations on what is the most secure and scalable method for each usage-case.

If a Firewall document would exist, then I believe it must document both IPv4 and IPv6 technology. 
You should document all usage cases and agreement on the security risks imposed, together with a balanced view on how to address those risks. 

G/

-----Original Message-----
From: OPSEC [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: 19 February 2014 06:09
To: [email-masked]'
Subject: [OPSEC] IPv6 firewalls reqs: Rationale

Folks,

Thoughts?

Yours,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Feb 2014 13:15:45 -0300

Hi, Gunter,

Thanks so much for your feedback! Please find my coments inline...

On 02/24/2014 08:03 AM, Gunter Van de Velde (gvandeve) wrote:
> 
> Firewall technology is implemented based upon usage case and may be
> very differently for each implementation (centralized, distributed,
> L3-only, L4-only, L3-L4, Session, Services, Applications, etc...)...
> loads of interpretations on what is the most secure and scalable
> method for each usage-case.

Base on the feedback so far, it seems there's agreement to narrow down
what we mean by firewall. So far the idea is to work on "L3-and-up
Enterprise IPv6 firewall".

> both IPv4 and IPv6 technology.

Me, I have no issues with documenting IPv4 technology. Although some
folks have argued "forget about IPv4". I'll ask this question in a
separate thread to get more input.

> You should document all usage cases
> and agreement on the security risks imposed, together with a balanced
> view on how to address those risks.

This seems to be out-of-scope. i.e., our document is on capabilities as
opposed to discussing security architectures (i.e., this document is not
meant to answer "centralized or distributed?", "what's the most secure
architecture", etc.).

Thoughts?

Thanks!

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Feb 2014 11:33:42 -0500

Agreed.

Personally, I'd be interested in a document for firewall implementers
explaining how to do it correctly and how to cause minimal breakage. A
little bit like the BEHAVE guidance for NAT implementers. For firewalls,
you could talk about how to use ICMP / TCP RST / drop correctly and what
the tradeoffs are, how to do L2 stuff, how to do stateful stuff, how to
inspect packets and deal with extensions headers intelligently, what are
good timeout values, etc. The goal being to define a filtering function
that behaves well on the Internet. Ideally that guidance would apply to
all kinds of settings: ISP, enterprise, CPE, single host, etc. That RFC
could be used as a baseline for RFPs as well.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 24 Feb 2014 13:44:43 -0800

Hi Gunter,

I fully concur with you here.

$.02,

- - ferg

On 2/24/2014 3:03 AM, Gunter Van de Velde (gvandeve) wrote:

> L3-only, L4-only, L3-L4, Session, Services, Applications, 
> If a Firewall document would exist, then I believe it must document
> both IPv4 and IPv6 technology. You should document all usage cases
> and agreement on the security risks imposed, together with a
> balanced view on how to address those risks.
> 
> G/
> 
> -----Original Message----- From: OPSEC
> [mailto:[email-masked]] On Behalf Of Fernando Gont Sent: 19
> February 2014 06:09 To: [email-masked]' Subject: [OPSEC] IPv6
> firewalls reqs: Rationale
> 
> Folks,
> 
> Yours, -- Fernando Gont e-mail: [email-masked] ||
> [email-masked] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
> 3945 96EE A9EF D076 FFF1
> 
> 

- -- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2