[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
common issues in BEHAVE and V6OPS
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:
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
Here's the relevant section:
Available for: AirPort Extreme Base Station with 802.11n*
Impact: AirPort Extreme Base Station with 802.11n* allows incoming
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:
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://
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
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
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
+ 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-
- 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@example.com>