Subject: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt

From: Marco Ermini <[email-masked]>
Date: Tue, 18 Feb 2014 14:57:00 +0000

Hi everyone,

a new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is about defining requirements for IPv6-capable Firewalls. You are welcome to have a look and contribute.

	Title		: Using Only Link-Local Addressing Inside an IPv6 Network
	Authors	: F. Gont
			  M. Ermini
			  W. Liu
	Filename	: draft-gont-opsec-ipv6-firewall-reqs-00.txt
	Pages		: 12
	Date		: 2014-02-14

Abstract:

   While there are a large number of documents discussing IP and IPv6
   packet filtering, requirements for IPv6 firewalls have never been
   specified in the RFC series.  When it comes to IPv6, the more limited
   experience with the protocols, and reduced variety of products has
   made it rather difficult to specify what are reasonable features to
   be expected from an IPv6 firewall.  This has typically been a problem
   for network operators, who typically have to produce a "Request for
   Proposal" (from scratch) that describes such features.  This document
   specifies a set of requirements for IPv6 firewalls, marked as
   "mandatory", "recommended", or "optional".

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Kind regards,

Marco Ermini - PhD CISSP CISA CEH ITIL MCP
Senior IT Security & Compliance Analyst | Compliance Europe
ResMed Germany Inc.
Geschäftsführer: Frank Rebbert, Eric Paffrath, Michael Taube
Sitz der Gesellschaft: München
Registergericht: München, HRB 156206

 ----------------------------------------------------------------------
Warning:  Copyright ResMed.  Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those
materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient.  This communication is confidential and may contain legally privileged information.  By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in, the content of the email and of any attachments.  If the recipient of this message is not the intended addressee, please call ResMed immediately on  1 (800) 424-0737 USA.
 ----------------------------------------------------------------------

---

From: "Smith, Donald" <[email-masked]>
Date: Tue, 18 Feb 2014 23:39:29 +0000

Just a nit initially.
"This document
   specifies a set of requirements for IPv6 firewalls, marked as
   "mandatory", "recommended", or "optional"."

That isn't the language we use.
In fact in terminology Mr Gont uses the right language.
"
3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119]."

This is hard very hard I don't know of a single v4 firewall that can do full proxies for all tcp applications.

REQ GEN-3:
      MUST support full-proxy for the TCP [RFC0793] connections (the
      handshake is validated on the firewall before reaching the target
      system).
I think what you want is proxies for common layer 7 protocols (like http, ftp etc...)
So maybe something like this:

REQ GEN-3:
      Should support full-proxy for common TCP [RFC0793] layer seven protocols.

However if what you really want is TCP three ways proxied that is a little different.
Would a tcp cookie implementation meet this requirement? Or do you want the three way done with the firewall then thrown away and you add the src to a whitelist for the next attempt or replay one side or do you want the fw to proxy the syn in, syn/ack out and ack back in? If so what is the benefit if it keeps all the state in two places now (host and firewall)?

Time outs are generally used mostly for UDP not TCP. I don't object to having a timeout ability on tcp connections too but their primary use is UDP today in v4.

REQ GEN-4:
      MUST be able to enforce timeouts on TCP connections based on
      specific protocols (e.g. enforce DNS timeout to a specific number
      of seconds, or FIN-WAIT, etc.).  In general, it MUST have
      different kind of timeout values and thresholds to be used to
      prevent idle established connections to saturate resources on both
      the device and the service that is defended.

So maybe "timeouts on UDP, TCP and other IP protocols" ...

This is sometimes referred to as policy routing.

REQ GEN-6:
      MUST be able to redirect specific traffic to a proxy server e.g.
      for HTTP/S protocols.

But by saying "redirect" in theory a FW could meet that requirement by just rewriting the MAC and replaying the packet. Not really routing a layer 2 redirect. Which did you mean or did you mean both?

REQ SPC-1 and 4 are the same.

It says here that we want to match icmpv6 errors to tcp and udp you should include "and other ipv6 protocols" and won't this bring on new icmp blind tcp reset issues?

REQ SPC-6:
      MUST be able to statefully match ICMPv6 errors to TCP [RFC0793],
      UDP [RFC0768], and ICMPv6 [RFC4443] communication instances.

Split tunneling is almost always a concern on the client side not on firewalls.

REQ VPN-5:
      MUST be able to disable or enable split-tunnelling feature on VPN
      as required.

I have never seen that applied to a firewall but can't say it couldn't be:)
In general you allow in a vpn remote access client and DON'T want them also connected directly to the internet as that punches a whole in your firewall (potentially anyways).

This:
   REQ VPN-6:
      MUST be able to work indifferently on IPv4 and IPv6, and also
      offer both protocol in dual-stack in the same VPN connection.

Should be this:
   REQ VPN-6:
      MUST be able to transit IPv4 and IPv6 packets providing full parity for services, and also
      offer both protocols in dual-stack in the same VPN connection.

I am thinking tunnel instead of connection but do not feel strongly about it.
The use of indifferently isn't technically wrong but isn't the common use of that word.

This is really ip stack specific attacks (not really os specific).
I have run non-native ip stacks on some OSes in the past (win3.1...)

REQ DoS-1:
      MUST be able to protect against OS-specific attacks: nuke, ping-
      of-death (NOTE: this list should be expanded, and references
      added).

And all of those pretty much died out. Having said that in there isn't bad.
Here are a few more of those ip stack attacks.

ICMP Fragments based attacks (this would include POD) and you include fragement based attacks in the next requirement.
Smurf Attack
Xmas Tree Attack
LAND Attack
Teardrop Attack

This one probably needs some expansion.

   REQ DoS-4:
      MUST be able to protect against TCP resource exhaustion attacks:
      zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP])

So for syn flooding do we want proxied tcp cookies, or simple tcp ratelimiting and do you expect grey, white and blacklisting to be done based on some form of authentication (completes the hand shake or gets the cookie right ...)?
Or can any or all methods be treated the same?

Wrong RFC :)
  REQ DoS-8:
      MUST be able to participate to a blackhole/sync hole routing
      infrastructure as per [RFC5635].

You probably want this one https://tools.ietf.org/rfc/rfc3882.txt as it talks about sinkholing (and it is sink hole not sync hole :)
The other one is about doing urpf with BHF and being able to do src based BHF.

Also we may need to define what "participate" means. I generally don't expect firewalls (FW) to talk bgp and BHF is generally done with BGP.

I will stop here for now to allow you to think about it and the next section is going to take more thought.

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

From: OPSEC [[email-masked]] on behalf of Marco Ermini [[email-masked]]
Sent: Tuesday, February 18, 2014 7:57 AM
To: [email-masked]
Subject: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt

Hi everyone,

Abstract:

Kind regards,

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

---

From: Marco Ermini <[email-masked]>
Date: Wed, 19 Feb 2014 13:32:09 +0000

Apologies for my crap quoting, I am stuck to Outlook :-(

> From: Smith, Donald [mailto:[email-masked]] 
> Sent: Mittwoch, 19. Februar 2014 00:39
> To: Marco Ermini; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt
>
[...]
> I think what you want is proxies for common layer 7 protocols (like http, ftp etc...) So maybe something like this:
> REQ GEN-3:

Hi Donald,

Almost every IPv4 firewall today can do it. Even certain NIPS can do it. I am pretty certain about all of the Juniper SRX series, including the Juniper IDP NIPS - they do full TCP handshake on behalf of the clients, and CheckPoint can do that too I think.

Cisco ASA do the same, they just call it "TCP Intercept and Limiting Embryonic Connections" but practically they do TCP proxy, verify syn-cookies, rate limits, and so on.

It is pretty much a standard feature, so I see no reason to lower the bar.

Actually being that at the TCP level, I would expect it to work equally for IPv4 and IPv6 easily. It should be low hanging fruits for firewall vendors.

> Would a tcp cookie implementation meet this requirement? Or do you want the three way done with the firewall then thrown away and you add the src to
>  a whitelist for the next attempt or replay one side or do you want the fw to proxy the syn in, syn/ack out and ack back in? If so what is the benefit if it
>  keeps all the state in two places now (host and firewall)?

The benefit of a TCP proxy is to normalize the connection, and as you correctly mentioned, check if a source (which can be spoofed) has too many TCP-SYN without acting on TCP-ACK, or syn-cookies are not set, or even add a sequence randomization for the response port in place of an incapable host.

Generally firewalls are even smart enough to avoid applying randomization in certain cases (e.g., eBGP peers using MD5 checksum would be broken by randomization applied by the firewall, so it will not apply it to this kind of traffic. Or at least, the documentation says an administrator should apply it in that case ;-)).

Do not underestimate the power of these appliances, especially if you haven't really used them in large scale environment. They are very effective and proven on IPv4 - the real problem is to have these features on IPv6 too; this is where vendors are lazy, mostly because of the usual adoption issues that generally affects IPv6 (vendors go where they can smell the money, unless "encouraged").

> Time outs are generally used mostly for UDP not TCP. I don't object to having a timeout ability on tcp connections too but their primary use is UDP

Connection limits are pretty common on UDP too, and are necessary to limit UDP DoS/DDoS. I do not think removing them for UDP is really a smart move.

Of course, the only kind of UDP connection limits are maximum number of simultaneous connections and per client connections; you cannot define how many proxied connection can be done as this is a TCP-only feature.

> This is sometimes referred to as policy routing.

Donald, I agree with your comment.

> But by saying "redirect" in theory a FW could meet that requirement by just rewriting the MAC and replaying the packet. Not really routing a layer 2
> redirect. Which did you mean or did you mean both?

They should divert the traffic to a proxy. They should take the traffic, send it to an inspection engine, receive it back and forward it. It should be completely transparent to the users. Users won't even require setting up a proxy in their browser.

JunOS does it with WebSense, although it could be any kind of HTTP filter in theory; with Cisco, it is not possible with an ASA, so you create two VRFs and forward the traffic through an "in" and "out" ports and have an inline filter connected; with the Microsoft TMG firewall, it's point and click :-)

> REQ SPC-1 and 4 are the same.

Well spotted Donald.

> It says here that we want to match icmpv6 errors to tcp and udp you should include "and other ipv6 protocols" and won't this bring on new icmp blind

I agree on the principle; could you elaborate more on the issue this would bring?

>       MUST be able to disable or enable split-tunnelling feature on VPN

Split tunneling is generally enabled by policy on the concentrator. I agree that technically the client could not obey... but it is nevertheless configured as a policy, and the clients and server would agree on a policy during handshake.

> I have never seen that applied to a firewall but can't say it couldn't be:) In general you allow in a vpn remote access client and DON'T want them also
> connected directly to the internet as that punches a whole in your firewall (potentially anyways).

Daniel, in an enterprise environment, VPN behavior is controlled centrally. It is a required feature and pretty normal on IPv4. Of course, if you just use some kind of open source VPN client and there is no cumbersome proprietary set up server side, you can have your client doing what it wants; however normally the administrators will try to avoid that.

The reason is not just because of punching holes in the firewall (although that is correct), but more simply company compliance, necessity to have all of the traffic filtered, and so on. Read like "prevent stupid to be stupid" as much as possible.

> The use of indifferently isn't technically wrong but isn't the common use of that word.

I do not mind either formulation. I feel this is a good contribution.

> This one probably needs some expansion.

Maybe we could simply reference rfc4949 ("Internet Security Glossary, Version 2"). The only one missing is the Xmas Tree Attack/scan.

I would also add generic sweeps, scans, and so on. Also, probably mentioning that the firewall should be able to understand the meaning of a specific IP option in a certain context and act accordingly (that would cover Xmas Tree attacks).

If you look from page 906 of this guide: http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/security/software-all/security/junos-security-swconfig-security.pdf you have a very detailed list of reconnaissance attacks that can be perpetrated just setting up the right IP options. As a minimum, there should be the possibility to sanitize obsolete options - I have seen some firewalls require to enable a NIPS license/card to be able to do it.

> So for syn flooding do we want proxied tcp cookies, or simple tcp ratelimiting and do you expect grey, white and blacklisting to be done based on some form > of authentication (completes the hand shake or gets the cookie right ...)?

> You probably want this one https://tools.ietf.org/rfc/rfc3882.txt as it talks about sinkholing (and it is sink hole not sync hole :) The other one is about
> doing urpf with BHF and being able to do src based BHF.

RFC5635 is an expansion to 3882. The latter is old, and it can only "blackhole" the DoS to an RFC1918 (private) address. With the former, you can redirect the traffic to a destination where the traffic can be scrubbed. (You are right about the "sink" thing - sorry).

Maybe better references could be https://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 and https://tools.ietf.org/html/rfc5575 which specifies a new kind of BGP NLRI called "Flowspec", which allows this scrubbing to happen.

> Also we may need to define what "participate" means. I generally don't expect firewalls (FW) to talk bgp and BHF is generally done with BGP.

First of all, firewalls can do BGP since ages. On JunOS, routers and firewalls have the same software; CheckPoint can also do all of the routing protocols. Cisco firewalls can only do "BGP stub" routing with the purpose of route injection.

In many situations, firewalls are required to speak BGP; the classical instance is to manage route leakages (e.g. they do OSPF on an internal interface, and inject matching BGP rules in the external interface). Therefore, they are required to understand BGP, and it is even more important when it's a security feature.

In the past, it was considered inappropriate to have a firewall work as a router, since they lack the fast forwarding plane that allowed a router to crunch packets without doing deep inspection. Today, there is a general convergence on both hardware and software of both router and firewalls, more and more we are moving towards virtualization (and SDNs) and there is also a differentiation between Internal and External BGP, so that companies with huge networks actually use BGP as an internal routing protocol.

Some companies like Cisco still think as BGP as a "service provider" protocol, but that is mostly a marketing issue (in fact they actually license their useless BGP stub implementation in their PIX/ASA), or a difficulties in having the same software base for routers and firewalls. The majority of the other companies have overcome this already.

> I will stop here for now to allow you to think about it and the next section is going to take more thought.
[...]

Thank you very much for your useful contribution and keep on doing it!

Marco

ResMed Germany Inc.

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 19 Feb 2014 22:13:12 +0000

>        Cisco ASA do the same, they just call it "TCP Intercept and Limiting Embryonic Connections" but practically they do TCP proxy, verify syn-cookies, rate limits, and so on.
In that case I with draw my objection. But when I hear "tcp proxy" I generally think of a http or ftp full tcp proxy. Can we call it something else or add some clarification to that requirement?
We probably should also mention syn-cookies ratelimiting and such other "actions".

>        The benefit of a TCP proxy is to normalize the connection, and as you correctly mentioned, check if a source (which can be spoofed) has too many TCP-SYN without acting on TCP-ACK, or syn-cookies are not > set, or even add a sequence randomization for the response port in place of an incapable host.
>
>        Generally firewalls are even smart enough to avoid applying randomization in certain cases (e.g., eBGP peers using MD5 checksum would be broken by randomization applied by the firewall, so it will not apply it   > to this kind of traffic. Or at least, the documentation says an administrator should apply it in that case ;-)).
>
>        Do not underestimate the power of these appliances, especially if you haven't really used them in large scale environment. They are very effective and proven on IPv4 - the real problem is to have these features on  > IPv6 too; this is where vendors are lazy, mostly because of the usual adoption issues that generally affects IPv6 (vendors go where they can smell the money, unless "encouraged").
>
>
I agree!

>        They should divert the traffic to a proxy. They should take the traffic, send it to an inspection engine, receive it back and forward it. It should be completely transparent to the users. Users won't even require   settingup a proxy in their browser.
>
Understood. My question is around layer 2 redirects vs layer 3 policy routing. I would rather have policy routing as it is more flexible you don't have to have the proxy on the same collision domain as you would with a layer 2 redirect. So would a layer 2 redirect count as compliance?

>        I agree on the principle; could you elaborate more on the issue this would bring?
This   http://tools.ietf.org/html/rfc5927

>        The reason is not just because of punching holes in the firewall (although that is correct), but more simply company compliance, necessity to have all of the traffic filtered, and so on. Rea…
Right so it still sounds like a client management issue not a firewall vpn issue?

>        RFC5635 is an expansion to 3882. The latter is old, and it can only "blackhole" the DoS to an RFC1918 (private) address. With the former, you can redirect the traffic to a > destination where the traffic can be scrubbed. (You are right about the "sink" thing - sorry).
No problem about sync vs sink:) 

And I worked on 5635 and am listed as a contributor :)
It really is about combining urpf with BHF to get src based BHF. It also allows for other ips addresses to be used but there is no mention of sinkholing it it.

rfc3882 is the rfc that described the sinkholing tunnel approach.

So maybe you want both in there:)

>        Maybe better references could be  https://tools.ietf.org/html/draft-simpson-idr-flowspec-redirect-02 and  https://tools.ietf.org/html/rfc5575 which specifies a new kind of BGP NLRI called "F…

Yes that would be another good one to list.

>        In many situations, firewalls are required to speak BGP; the classical instance is to manage route leakages (e.g. they do OSPF on an internal interface, and inject matching  > BGP rules in the external interface). Therefore, they are required to understand BGP, and it is even more important when it's a security feature.
>

I have worked on firewalls that did BGP. Generally they don't do it well. The issue being your asking a firewall team to test the bgp implementation. Router vendors have HUGE bgp testing plans and tools. I don't object to the firewall doing BGP but would like to see them test it a lot better. I do still think it is probably better to use your routers for stuff like this but if firewall vendors supported it WELL I would reconsider.

>        Thank you very much for your useful contribution and keep on doing it!
Thank you for the quick response!