Subject: common issues in BEHAVE and V6OPS

From: james woodyatt <[email-masked]>
Date: Thu, 12 Apr 2007 05:43:25 -0700

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 <[email-masked]>