[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

common issues in BEHAVE and V6OPS

everyone--
An issue with the NAP draft in the V6OPS group arose recently, and Christian Huitema suggested that the BEHAVE group is a better place to hold the discussion about it. Having read the BEHAVE group's charter and all of its documents, I'm not so sure he's right, so I'm now posting this to both V6OPS and BEHAVE. Hopefully, the distribution of the discussion will be narrower once everyone agrees on the appropriate venue.
For those who haven't been following the discussion in V6OPS, I recommend beginning with my message here: 

	<http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00225.html>

Here's an edited version:
Today, Apple released the following article "About the security content of Firmware Update 7.1 for AirPort Extreme Base Station with 802.11n" 

	<http://docs.info.apple.com/article.html?artnum=305366>

Here's the relevant section:


CVE-ID: CVE-2007-1338

Available for: AirPort Extreme Base Station with 802.11n*
Impact: AirPort Extreme Base Station with 802.11n* allows incoming IPv6 connections
Description: The default configuration of an AirPort Extreme Base Station with 802.11n* allows incoming IPv6 connections. This may expose network services on hosts connected through an AirPort Extreme Base Station with 802.11n* to remote attackers. This update addresses the issue by changing the default setting to limit inbound IPv6 traffic to the local network. This issue only affects AirPort Extreme Base Station with 802.11n*, and not other versions of the Base Station. 
[...]


[...]
One concern I've been asked to think about is that the product doesn't offer any mechanism for nodes on the local network to request the opening of a pinhole in the stateful packet filter. This function is performed in the IPv4 case by NAT-PMP (which Apple has tried to advance within IETF without much success), but there is no equivalent function for IPv6. This was a deliberate decision on our part, but now we're left reconsidering it. 
[...]
As far as I know, there is no current or pending IETF standard for nodes to use in requesting open pinholes through the stateful packet filter in a residential IPv6 gateway. In light of the IETF consensus noted earlier in this thread, doesn't that seem like a serious oversight? Isn't this function something that rightfully belongs in ICMP6? If not, do we really think extending NAT-PMP and UPnP IGD to support IPv6 network boundary filters is a good idea? (A month ago, I would have found that hard to believe, but I've made some embarrassing mistakes lately, so I'm gun-shy about what I don't believe anymore.)
Incidentally, for those interested in the IPv6 behavior of this product, be advised that most IPv6 applications won't work in the default mode, i.e. with the stateful packet filter turned on. For example, active mode FTP from the local network won't work, because the inbound TCP connection for the data will be blocked by the filter. We haven't written any application layer gateways for the IPv6 filter in the AirPort Extreme base station, so things like SIP, RTSP, IPsec/IKE, etc. simply will not work at all. I can't say when enhancements to support any of those application protocols will be available. They'll have to be written one by one, and until recently, we mistakenly thought that the whole point of IPv6 was to make that unnecessary. (Yeah, that'll teach me not to stay abreast of developments in the IETF.) 

This message is the start of a thread in which I later wrote this:

	<http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00237.html>


On Apr 10, 2007, at 12:13, Rémi Denis-Courmont wrote:

[...]
I am not so sure there is a "consensus" around the use of stateful firewalls for SOHO CPEs. As I understand v6ops-nap, it says: "if you want security equivalent to that of a NAT, you can use a stateful firewall, and hence you should not be afraid of IPv6". It does not say "you shall use a stateful firewall in any case". [...]
As I noted earlier in this thread, section 4.2 of <http:// tools.ietf.org/wg/v6ops/draft-ietf-v6ops-nap-06/> says:
To implement simple security for IPv6 in, for example a DSL or Cable Modem connected home network, the broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state). There should also be an easy interface which allows users to create inbound 'pinholes' for specific purposes such as online-gaming.
At first, I thought this recommendation belonged in a BCP (i.e. that "may" would be better here than "should"). I was mistaken.
We have now heard from a member of the IESG that the paragraph quoted above represents the hard-fought consensus opinion of the IETF community, and I see no reason to question his authority on the matter. Especially, since that opinion is completely in concurrence with similar recommendations from Microsoft, the U.S. Department of Homeland Security, and now my employers as well. In addition, I have searched the last six months of mail archives of the V6OPS and IPV6 working groups, as well as the archive of the IETF discussion group, and I have seen no sign of any controversy on this issue.
As far as I can see, the debate has concluded and the issue is settled.
Residential IPv6 gateways *will* implement stateful packet filters in their default configurations. I'm not interested in reopening a debate over that proposition. It's done. All I need now is to figure out how to make IPv6 do what IPv4/NAT can do today by using either NAT-PMP or UPnP. 

[...]
I wasn't involved in the drafting of the original NAT-PMP specification, but I was present for the reviews before it was published. At the time, we didn't envision NAT-PMP as anything more than a transition mechanism for use only with IPv4. To that end, we deliberately avoided making the protocol easily extended to support more than the limited functionality we felt was necessary to facilitate an orderly transition toward IPv6. 

See section 4.2, which says:
Any client making use of this protocol SHOULD implement IPv6 support. If a client supports IPv6 and is running on a device with a global IPv6 address, that IPv6 address SHOULD be preferred to the IPv4 public address using this NAT mapping protocol. In case other clients do not have IPv6 connectivity, both the IPv4 and IPv6 addresses SHOULD be registered with whatever form of directory server is used. Preference SHOULD be given to IPv6 addresses when available. By implementing support for IPv6 and using this protocol for IPv4, vendors can ship products today that will work under both scenarios. As IPv6 is more widely deployed, clients of this protocol following these recommendations will transparently make use of IPv6.
Alas, we are now revisiting whether this was a realistic transition plan in light of the consensus that IPv6 gateways will encompass stateful packet filters that need to be solicited for pinholes just like an IPv4/NAT gateway does.
If extending NAT-PMP to support IPv6 is what needs to be done, then deliberately crippling the extensibility of the protocol to prevent it from being useful with transports and extension header types not currently defined is an obviously bad idea. I feel safe assuring the working group that Apple is committed to the IETF process for advancing a standard protocol that the entire community supports.
This is why I am starting in the V6OPS working group. If the membership here agrees that an operational problem exists that needs a standards effort to solve, then this is the place to make the basic decisions about where to begin. Perhaps, extending ICMP is the right choice, in which case we should go to the IPV6 working group to begin. Otherwise, perhaps NAT-PMP could be used as a template for devising a new and separate IPV6-PMP specification. I'm not sure what working group would be the best choice for that work.
If IETF doesn't think a standard protocol is necessary, then Apple will probably be left to do something non-standard. I hope that won't be necessary. 
[...]
That covers the parts of the thread that I think are worth highlighting for the members of the BEHAVE group.
Given that stateful packet filters (which interfere in IPv6 flows in almost the same way as the stateful translating filters of IPv4/NAT) will be as ubiquitous in IPv6 as NAT is today in IPv4, the following questions remain open:
+ Of probably the highest and most immediate concern, how can we keep the stateful packet filters in IPv6 gateways from completely destroying the utility of IPsec in IPv6. We need to specify the behavior of an ISAKMP proxy immediately.
+ Where is the appropriate venue for this discussion? BEHAVE or V6OPS? Does BEHAVE need a new charter to deal with this?
+ Do we really expect that deploying new applications on IPv6 should require field upgrades to the stateful packet filters throughout the Internet?
+ Or, do we instead want to explore alternatives that allow nodes to solicit the creation of filtering state automatically? 

+ If so, how do we wish to proceed?
- Start with an existing non-standard protocol, e.g. UPnP IGD, NAT- PMP, etc. 
  - Extend ICMP.
  - An original design not using ICMP.
I have some other, more controversial problems to explore with both BEHAVE and V6OPS, later, when the discussion moves on to scaling the stateful packet filtering function up from small residential gateways to large enterprise deployments. I'll leave those hanging in the air for now, because I think the problems I'm surfacing here are enough trouble for the next year or two. 


--
j h woodyatt <jhw@apple.com>