Zone Based Firewall Design for IPv6 Tunnels?

[glgersc]

I am working with a common home router configuration on an 881, and adding an IPv6 tunnel for native IPv6 on the inside. This is the design I'm working from:

https://supportforums.cisco.com/docs/DOC-15565

I am trying to come up with a zone based firewall config, and I am trying to determine the best overall design.  I am not interested in the particular rules for the zone-pairs.  There are working examples of both designs I'm outlining below.  I am more interested in whether one design is better than the other, and why, and if there are other alternatives that should be considered.

Both designs also assume common Inside-Outside zone-pairs for IPv4 NAT traffic.

Working with the IPv6 Tunnel interface is a bit odd, since it one side of the Self interface.  They are functionally the same interface.  Traffic flows through them without restriction, but they present different faces depending on which way the traffic is flowing.  It is native IPv6 between the Inside and Tunnel interfaces.  But, it is mixed IPv6 and Protocol 41 IPv6 tunnel traffic between Self and Outside interfaces.

The simplest is what I'll call a 'three zone' model.  The Inside and Tunnel interfaces are both in the same zone.  The zone-pair rules are applied between the Self and Outside interfaces.

A detailed description of this model is described in this thread:

https://supportforums.cisco.com/message/3194864#3194864

However, this model bothered me a bit.  The traffic from Self to Outside is different from Outside to Self.  Because the traffic is IPv6 in one direction, and Protocol 41 tunneled IPv6 in the other, the rule sets will always be different.  There is also no good way to provide any inbound IPv6 rules with this design that I can see.  And there are order of operation issues to consider. But it is simple.

These log entries show the different traffic types (addresses partially obfuscated):

*Mar  5 14:11:59.790: %FW-6-DROP_PKT: Dropping Unknown-l4 session [2001:55C:1876:xxxx:8D2D:27F:8D20:C33B]:0 [2001:4860:800F::68]:0 on zone-pair ccp-zp-self-out class class-default due to  DROP action found in policy-map with ip ident 0

*Mar  5 14:46:14.298: %FW-6-DROP_PKT: Dropping Unknown-l4 session 69.252.80.66:0 24.118.xxx.xxx:0 on zone-pair ccp-zp-out-self class class-default due to  DROP action found in policy-map with ip ident 0

After pondering a bit, I decided to create a 'four zone' design.

This design treats the Tunnel/Self interfaces as two separate security zones.  Traffic still flows freely between Tunnel and Self.  But, it is easier to create distinct rule sets.

The Self to Outside allows any IPv6 out.  The Outside to Self allows Proto 41 traffic in (and is restricted to the far tunnel endpoint).  These are simple ACL rules.

The Inside to Tunnel zone-pair can layer on any normal inspect rules for the IPv6 traffic.  This design also makes it easy to allow incoming Tunnel to Inside inspect rule creation if desired.

So, what are the arguments for or against either design?

Am I missing something in comparing them?

Is there a third option?

Would the type of IPv6 tunnel have any impact?  The three zone example uses an 'ipv6ip' tunnel.  The four zone is using a '6RD' tunnel.  What if it was a '6to4' tunnel?

Is there some best practice document from Cisco that would have an opinion on this?

If you also had VPN tunnels, how would that alter the design?

Please bring your critiques and comments.  Thanks.

[Rama Darbha]

glgersc,

I want to start off by stating, that the questions you pose are really well thought out and wonderfully challenging. The hard part here is that it looks like we're trying to drive towards best practices which can be a difficult and elusive subject.

Your "four-zone" solution is a solution we see a lot in VPN deployments. See the following documentation:
http://www.cisco.com/en/US/prod/collateral/vpndevc/ps5708/ps5710/ps1018/prod_white_paper0900aecd8062a909.html
What you see there is that "decrypted VPN traffic" falls into its own "VPN" zone. As a result, encapped VPN traffic traverses the outside-to-self zone while the decapped real traffic traverses the VPN-to-inside zone.

Essentially, that is what you are doing, but instead of referencing VPN traffic we're talking about IPv6 traffic. Which changes the game a bit because the IPv6 traffic is being initiated from internal dual stacked hosts, whereas VPN traffic is coming from remote users. From my perspective, that means that the VPN traffic would possibly have more "filtering" and "restrictions" on it than the IPv6 traffic which is truly (and geographically) coming from the inside.

At my home I'm running a Ipv6ip tunnel to a tunnel broker. We don't run any ZBFW on our IPv6 router, but if we did we'd probably be inclined to put the Tunnel interface on the "inside" zone. Essentially, all inside traffic and IPv6 tunnel bound traffic would not have to traverse a zone pair. The reason we would opt for this is because, in my mind, the IPv6 traffic and the "inside" traffic are one in the same. Just different protocols.

I think our Ipv6ip tunnel uses IP protocol 41 in both directions, but clearly your testing as concluded otherwise. As a result, we may hit the same issue as you, where the "outside-to-self" and "self-to-outside" zone would see different traffic in each direction.

Please let me know your thoughts on this matter. I haven't had a chance to test this out on my IPv6 tunnel router at home, but I hope to have some ZBFW testing done by next week.

Regards,
Rama

[glgersc]

Hi Rama,

Thanks for the reply.  I had hoped to spark some discussion on this topic, but as you noted, this is a 'best practices' kind of question, and this forum seems be more more focused on point problems.  (Is there a better forum for this quesion?)

Thanks for the link to the VPN solution.  That validates my 'four zone' solution is not an odd approach.

I should clarify that the IPv6 traffic is encapsulated in a proto 41 tunnel in both directions on the Internet.  It's only in transiting the zone rules that I see it as proto 41 one way, and unencapsulated IPv6 in the other.  I'm sure it's just an order of operations thing, but I hate having to treat each direction differently.  And, as I said, I'm not sure how you would properly inspect inbound traffic if the router sees it as encapsulated.

Have you had any luck testing this in your environment?  (Or have you been sidetracked by spring fever, like me?)

Thx,

Greg

[Rama Darbha]

Greg,

I haven't had a chance to test this in my environment yet. I have the spring fever, as you predicted. = )

Hopefully I can get around to it over the next few weeks.

Regards,

Rama