Subject: [BEHAVE] 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]>

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Apr 2007 16:35:54 +0200

james woodyatt skrev:
>> 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.)
>>

There are two pending solutions within the IETF for opening pinholes in 
NATs. There is one in the MIDCOM WG using SNMP and a MIB.
http://tools.ietf.org/html/draft-ietf-midcom-mib-09.txt

Then there is anpther solution developed by the NSIS WG:
http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-14.txt

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 Apr 2007 10:57:08 -0700

On Apr 12, 2007, at 07:35, Magnus Westerlund wrote:
> james woodyatt skrev:
>>> As far as I know, there is no current or pending IETF standard  
>>> for nodes to use in requesting open pinholes through the stateful  
>>> 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.)
>
> There are two pending solutions within the IETF for opening  
> pinholes in NATs. There is one in the MIDCOM WG using SNMP and a MIB.

This seems to support IPv6 well enough, but I'm not enthusiastic  
about using SNMP for this protocol, particularly with the  
recommendation that SNMP be used in conjunction with authPriv.   
That's human interface nightmare waiting to happen.

> http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-14.txt

Alas, this one would need to be amended for use with IPv6 stateful  
packet filters.

----

A more pressing problem is simply identifying the recommended  
behavior of IPv6 stateful packet filters, particularly with respect  
for ISAKMP and IKE.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Apr 2007 11:11:00 -0700

> behavior of IPv6 stateful packet filters, particularly with respect  

Could you encapsulate over UDP (RFC3948), and use a STUN-like 
technique to both (a) open the incoming permission and (b) to 
learn your UDP port?

To your earlier thread:  a problem with UPnP or NAT-PMP is 
opening permissions if you're behind multiple NATs (in IPv4) 
or behind multiple stateful packet filters (in IPv6 and in IPv4).  

In IPv6, I could imagine an upstream Ipv6 provider (your
enterprise or your ISP) might deploy a stateful packet filter
to protect your access link from saturation.

(In IPv4, ISPs and enterprises often provide NATed IP addresses
to their users, creating a similar layered stateful packet 
filtering situation, which also breaks UPnP and NAT-PMP).

-d (as individual contributor)

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 Apr 2007 11:33:59 -0700

On Apr 12, 2007, at 11:11, Dan Wing wrote:
> [I wrote:]

How will the packet filter learn which inbound IPsec ESP packets to  
pass without inspecting the ISAKMP exchange and filtering on the SPI  
in the ESP header?  Or consider this: how will it decide when to  
*stop* passing packets?  This problem is analagous to the one in IPv4/ 
NAT for IPsec VPN passthrough prior to the adoption of NAT-traversal  
extensions.  (Those extensions won't work in the absence of NAT, so  
they're not a suitable template for extending to IPv6.)

More importantly, what behavior can an IPv6 node expect in the  
stateful packet filter in its default gateway.  What does it have to  
do to keep the state for its IPsec SA alive in the gateway?  I don't  
think any of that is well defined.  It should be.

> or behind multiple stateful packet filters (in IPv6 and in IPv4).

We deliberately designed NAT-PMP so that it could be applied  
recursively, much like NSLP does.  None of Apple's current  
implementations of NAT-PMP do that, but we've considered it as  
possible future direction.  At the moment, we're still trying to  
teach our customers that they should use only one NAT at a time in  
residential networks, c.f. the following thread on the Apple  
Discussions forum:

	<http://discussions.apple.com/thread.jspa?threadID=921507>

If this strategy doesn't work, we're going to have to try something  
more radical.  As I've said before, we mistakenly thought NAT-PMP was  
merely a transition mechanism, and nothing like it would be necessary  
with IPv6.  Oops.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Apr 2007 11:54:22 -0700

> in the ESP header? 

If it's all over UDP, the packet filter only knows it's a UDP flow
that was initiated from the 'inside'.

> Or consider this: how will it decide when to  
> *stop* passing packets? 

A timeout.

> This problem is analagous to the one in IPv4/ 
> extensions. 

"NAT-traversal extensions" = RFC3948?

> (Those extensions won't work in the absence of NAT, so  

RFC3948 doesn't work without a NAT?

> think any of that is well defined.  It should be.

I agree it isn't defined at all.  The IETF has long considered 
describing firewall (stateful packet inspection) behavior out of 
scope because they interfere with IETF's end-to-end principle.  

> possible future direction. 

I wasn't aware of that; sorry for my misunderstanding.

> At the moment, we're still trying to  

It is my understanding that Microsoft makes a similar 
recommendation to NAT vendors -- they encourage NAT vendors to 
have their devices bridge (rather than NAT) if the NAT obtains a 
DHCP address that is an RFC1918 address (because that implies there 
is an upstream NAT).  This sounds similar to what that URL 
describes the Apple Airports are doing.

This recommendation seems suitable for the case of a home (or
fraternity) with nested NATs.

However, with IPv6, it's not possible to discern if there are
multiple stateful packet filters upstream of you (you can't use
RFC1918 addresses to make that determination like you can with
NATs).  So I don't know how IPv6 could recover from this 
situation.

Additionally, subscribers cannot control what their ISPs do.  
One of the large cable companies in Germany NATs their subscribers 
(although last I heard, you could request a non-NATed IP address 
from them without additional cost).  I understand it is routine 
for ISPs in South Korea to NAT their subscribers.  In those cases, 
I expect only STUN (RFC3489/draft-ietf-behave-rfc3489bis) will
be effective at traversing those layered NATs; UPnP and NAT-PMP
won't be able to learn about the layered NAT or will make an 
inaccurate suggestion that NATing should be disabled (if the
ISP provides an RFC1918 address to the subscriber).

> If this strategy doesn't work, we're going to have to try 
> something more radical.  As I've said before, we mistakenly 
> thought NAT-PMP was merely a transition mechanism, and 
> nothing like it would be necessary with IPv6.  Oops.

If you haven't already, you might look at 
draft-wing-behave-nat-control-stun-usage-01.txt.  We are
interested in moving this forward if there is industry 
support for the idea raised in that I-D.  This won't be
done inside of the BEHAVE working group, though; rather,
we would have a BoF at the upcoming IETF in Chicago.  

-d

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 Apr 2007 12:02:49 -0700

> RFC3948 doesn't work without a NAT?

I guess it could work without a NAT.  However, it's an encapsulation  
for IPsec ESP only.  What about AH?  This works for IPsec ESP tunnel  
mode, but transport mode is still broken, isn't it?

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 Apr 2007 12:09:31 -0700

On Apr 12, 2007, at 12:02, james woodyatt wrote:
> I guess it could work without a NAT.  However, it's an  
> encapsulation for IPsec ESP only.  What about AH?  This works for  
> IPsec ESP tunnel mode, but transport mode is still broken, isn't it?

My mistake.  Both tunnel and transport mode ESP work.  We can  
probably forget about AH, because the packet filter will probably  
just jump through to the next header when it sees an AH extension  
header.

So that would mean we would see packets that look like this a lot:

	[ IPv6 | AH | UDP | ESP | payload... ]

Yuck, but it works.  Okay, I think we can do without having to  
implement the ISAKMP proxy now.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 13 Apr 2007 10:24:45 +0300

> That's human interface nightmare waiting to happen.

Yup. I'd rather the system piggybacks on the IPv6 ND autoconf & trust model, 
than require any extra configuration or credentials: trust everybody on link. 
This can be enforced by only sending and receiving packets with HopLimit=255 
and ICMPv6 (which non-privileged applications cannot use on most systems).

This means transmitting data upstream is done from inside to outside, contrary 
to STUN NAT control. I reckon STUN control is designed with backward 
compatibility and NAT traversal in mind, which should be non-issues here. 
Also, while there's certainly some stuff to keep from STUN, there are two 
reasons why it should not be MUXED with the actual data:

1/ it's going to get very tricky if the actual media flow uses STUN (e.g. 
ICE-TCP) on top of the pinholing mechanism,
2/ use of ICMPv6 rather than UDP allows (but does not require) implementation 
lower in the stack, so it can more easily be commoditized across a running 
system - in fact it can become transparent to the BSD socket API.

Back to security, if better than trust-link is ever required, perhaps it could 
piggyback on the IPv6 SEND stuff.

-- 
Rémi Denis-Courmont

---

From: Bryan Ford <[email-masked]>
Date: Fri, 13 Apr 2007 10:39:50 -0400

> and ICMPv6 (which non-privileged applications cannot use on most systems).

Unfortunately this latter property (that non-privileged applications
cannot use ICMP) is also a disadvantage to an ICMP mechanism at least in
terms of near-term deployment.  Applications would have to wait for
their host OS to be upgraded with support for this mechanism (or else be
distributed with kernel patches that have to be installed by a
privileged user) in order to take advantage of it.  Whereas applications
that use an ordinary UDP-based protocol like NAT-PMP can just request
the pinholes they need directly from their unprivileged application
contexts.

This issue wouldn't necessarily be a major concern, as long as the
hypothetical ICMPv6-based hole punching mechanism becomes a MANDATORY
component of IPv6 protocol stacks (with its use subject to local
security policies of course) by the time IPv6 firewalls start really
proliferating.  But that would add considerable time pressure to the
design and standardization process for such an ICMPv6 extension, given
that as we can see this proliferation has already begun.  And I for one
don't have too much confidence in the ability of the IETF working group
process to design, standardize, and deploy anything NAT/firewall-related
"quickly".  If it takes too long for the ICMPv6-based pinholing
extension to become standardized and widely implemented and usable by
applications, then applications and middlebox vendors will just use
something else, such as an IPv6 adaptation of UPnP or NAT-PMP, or else
applications will simply avoid supporting IPv6 at all for now because
IPv4 works for them and IPv6 doesn't.

Bryan

---

From: james woodyatt <[email-masked]>
Date: Fri, 13 Apr 2007 11:58:09 -0700

On Apr 13, 2007, at 07:39, Bryan Ford wrote:
>
> Unfortunately this latter property (that non-privileged  
> applications cannot use ICMP) is also a disadvantage to an ICMP  
> mechanism at least in terms of near-term deployment.  [...]

This is true, but we're not talking about a transition mechanism  
anymore.  Whatever we do to solve this problem will be with us for  
the next thousand years.  Short-term considerations *must* be  
prioritized accordingly.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 17 Apr 2007 14:10:27 +0300

> technique to both (a) open the incoming permission and (b) to

I have been thinking about STUN, STUN NAT control and so...

I believe STUN NAT control is unfortunately something completely different. 
STUN NAT control is really -currently- biased toward controlling NATs rather 
than firewalls... In particular, it's guessing the middlebox address from the 
MAPPED-ADDRESS attribute of a request to an external STUN server, and then 
chain requests to "more inner" NATs until MAPPED-ADDRESS = socket address.

In the IPv6 firewall case, the problem is supposedly reversed. First, you 
probably do not want to depend on an external STUN server; second, you cannot 
assume that each firewalling middlebox will be a NAT (in fact, they should 
probably NOT be NATs). That's not to say STUN message cannot be used, but it 
would be yet another usage. In particular, it would probably go from inner to 
outer box rather than from outer to inner box (??).

There are other reasons why handling IPv6 would be fairly different on the 
middlebox:
- It has to handle/skip IPv6 extensions headers properly; it cannot simply 
extract the transport protocol from the IP header as in IPv4,
- Also, learning from the mistakes of IPv4 NATs and firewalls, it should 
probably handle protocols that do not have ports numbers (so that, e.g. the 
client node can ask for ESP to pass through),
- Similarly, it probably should have a generic UDP/timer-based handling for 
transport protocols which it does not know how to properly track (UDP-Lite, 
DCCP and SCTP are the current ones, but better make this generic anyway). At 
least in the unmanaged case, this ought to work.

So the request could probably look like something with:
 - one byte for the transport protocol (with ext headers IANA values 
explicitly forbidden),
 - an optional port parameter (e.g. used for TCP, but not ESP),
 - hole refresh timer,
 - an optional allowed remote address (not specified = requesting that any 
peer traffic be transmitted, though local policy might deny the request).

A successful response would need to specify the accepted hole refresh timer, 
and an optional "upstream" firewall to also be notified.

I am not sure how to give notification if a middlebox reboots... if it's the 
first hop, it can send a multicast message (as with NAT-PMP).

> to protect your access link from saturation.

Yes. So you then you actually need to tell the ISP what you want to receive.

-- 
Rémi Denis-Courmont

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 13:42:39 -0700

On Apr 17, 2007, at 04:10, Rémi Denis-Courmont wrote:
>
> Yes. So you then you actually need to tell the [firewall] what you  
> want to receive.

This is one of the peculiar parts of the problem.

I was discussing this matter with Stuart Cheshire yesterday  
afternoon, and he agreed with me that a straightforward adaptation of  
NAT-PMP to IPv6 is a very bad idea.  He reiterated to me that NAT-PMP  
was always regarded as a very limited protocol, suitable only for  
allowing us to limp along with IPv4/NAT until the glorious  
restoration of end-to-end connectivity could be achieved with the  
transition to IPv6.  Now that IPv6 end-to-end connectivity has been  
crippled by the commercial rollout of residential gateways that block  
inbound flow initiations in their factory default configurations, we  
need a new mechanism designed from the ground up that we can live  
with happily for all time.

But, there's a problem.  You actually need to tell the firewall what  
you want to receive.

Let me explain why we have that problem.  The interesting thing about  
NAT-PMP (and UPnP, too) is that applications written to the proper  
API will automatically solicit the state required in the firewall to  
pass inbound flow initiations to them just by calling the moral  
equivalent of listen() on a socket.  So, why not extend the IPv6  
stack so that when listen() is called on an IPv6 TCP socket (or a UDP  
socket is bound, or or or), it results in the request to create the  
state in the firewall to allow connections to be received?

Some people I've talked with have said, why not dispense with the  
requests and just have the firewall send the initiating packets  
encapsulated in an ICMP header after they pass the static portion of  
the firewall rule set?  The answer turns out that the security  
concern is only addressed when the endpoint node is the one  
soliciting the creation of state in the firewall.

When we shipped AirPort Extreme 802.11n earlier this year, the  
factory default configuration was 1) NAT-PMP enabled and serving  
requests, and 2) IPv6 stateful packet filter disabled.

It wasn't long before security experts reviewed the device and raised  
an unholy ruckus about the IPv6 filter not being enabled.  They  
didn't care at all about the NAT-PMP service, and they still don't.   
(Few people seem to regard UPnP IGD as an unacceptable security risk  
when it's enabled by default in residential gateways.  Earlier  
versions of AirPort Extreme shipped with NAT-PMP configured to refuse  
mapping requests, but this drew complaints when compared against the  
similar UPnP IGD function in competing products.)

The distinction that makes all the difference in both these cases is  
that endpoint nodes are required to solicit the firewall before  
inbound flow initiations will be delivered.  With unfiltered IPv6,  
those flow initiations pass unimpeded whether the endpoint nodes  
requests them or not.  It's the presence of *unsolicited* traffic on  
the local network that raises all the security concerns.  Strange,  
but true.

So, yes-- you actually need to tell your firewalls what you want to  
receive.  Firewalls want to know about all your listening sockets,  
and they expect you to comply with policy.  If they don't approve of  
what you're doing, then you don't get service.  That's how the world  
works, bunky.  Cope.

As a result, the design for an IPv6 functional equivalent of NAT-PMP  
and UPnP IGD will have to rely on endpoint nodes explicitly  
soliciting firewalls when they initiate a passive communication  
endpoint.  Now, I think that endpoint nodes should do this by sending  
unicast ICMP messages to firewalls they learn about using a multicast  
discovery protocol, but others are still resisting the idea.  They  
think the discovery part is too complicated, and that firewalls  
should just encapsulate inbound flow initiations in ICMP messages  
that would otherwise be dropped for being unsolicited.  I think  
encapsulation will peeve network administrators who are expecting  
firewalls not to pass unsolicited inbound packets.  Accordingly, I'm  
proceeding with designs for an application listener discovery  
protocol, that allows endpoints to discover firewalls and solicit the  
state required to pass inbound flow initiations.

It's a curious problem.  What do people here think?

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Apr 2007 14:27:36 -0700

> But, there's a problem.  You actually need to tell the firewall what  

Yes, that is a real problem. There are two classes of solutions:
requiring port openings though an explicit signaling protocol between
the host and the firewall; or using a side effect of the firewall design
to let the connection go through without explicit exchange. 

STUN/ICE is an example of the second class of solutions. Hosts can use
STUN to determine their external IPv4 address and UDP port numbers. They
can then exchange these addresses through some external service, e.g. a
SIP exchange or an IM service. Then, they send a couple of sacrificial
packets to open the firewall or NAT at each side. After that, UDP
packets flow freely. It is fairly easy to see how the same solutions
could apply to IPv6/UDP, without even a need for STUN. In fact, with
IPv6, you might even be able to use simultaneous connect and set up TCP
connections.

You still need to explicitly open holes if you want to provide generic
servers, e.g. open port 80 if you want to run a web server in your home
network. But my experience is that solutions that don't involve
signaling protocols are much easier to deploy.

-- Christian Huitema

---

From: Bryan Ford <[email-masked]>
Date: Tue, 17 Apr 2007 18:53:59 -0400

On Apr 17, 2007, at 5:27 PM, Christian Huitema wrote:

> STUN/ICE is an example of the second class of solutions. [...]

Unfortunately, this "second class of solutions" (implicit hole  
punching) is and will forever be inadequate to solve the needs of  
many applications, because of the BEHAVE group's decision a while ago  
to recommend endpoint-dependent filtering behavior (Restricted Cone  
NAT in the old terminology) as the default behavior for all NATs.

Some may remember me fighting tooth and nail some time ago, both on  
the BEHAVE mailing list and at the IETF meeting in Paris, in favor of  
recommending endpoint-independent filtering behavior (Full Cone NAT)  
as the default filtering behavior unless local security policy  
dictates otherwise.  Doing so would have given applications the  
functionality they need through implicit hole punching - namely, the  
ability to open a firewall pinhole through which they may accept new  
incoming connections without the (further) help of an external third  
party.  But by deciding in favor of endpoint-dependent filtering, the  
BEHAVE group effectively castrated the usefulness of implicit hole  
punching (STUN/ICE) techniques for any application that actually  
needs a public network port on which it can accept new incoming  
connections without help from an external third party.  Many such  
applications exist - including practically all self-organizing P2P- 
style protocols such as distributed hash tables for example.

(Some smart applications like Skype can and do get by - for now - by  
dividing the participating nodes into "first-class" (e.g.,  
supernodes) that can accept incoming connections, and "second-class"  
nodes that cannot.  But as the percentage of nodes behind BEHAVE- 
compliant middleboxes with endpoint-dependent filtering behavior  
tends toward 100% in the future, the small set of "first-class" nodes  
available to help the increasingly numerous "second-class" nodes  
punch the connections they require will diminish toward zero,  
gradually overloading the first-class nodes and eventually causing  
even these smart  protocols to fail unless someone bolsters the  
network with a bunch of dedicated first-class servers.)

Since self-organizing applications cannot now, and because of the  
BEHAVE group's decision, will never be able to rely on implicit hole  
punching to get the type of firewall pinholes they need, their only  
alternative is to rely on some form of explicit communication with  
the firewall - i.e., something like NAT-PMP.  So unless this group  
wants to reverse that decision (I know, fat chance), an IPv6  
functional equivalent to NAT-PMP is needed now and will continue to  
be needed forever (or at least as long as firewalls continue to  
exist), so we might as well get comfortable with the idea.

Bryan

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 15:57:27 -0700

On Apr 17, 2007, at 14:27, Christian Huitema wrote:
> network.

Yes.  The STUN/ICE class of solutions depends on there being a well- 
defined behavior for stateful IPv6 packet filters.  They also require  
peer-to-peer applications to rely on some external 3rd-party service  
to participate in the signaling required to exploit the side effect  
in firewalls.

> But my experience is that solutions that don't involve signaling  
> protocols are much easier to deploy.

I might be in a better position than you to deploy something that  
does what I'm proposing.

Also: I disagree with the characterization of my proposal as a  
"signaling" protocol.  It's an "application listener discovery"  
protocol for firewalls.  I contend that application endpoints  
receiving inbound flows ought to be just as visible to the policy  
enforcement engines in firewalls as those that initiate outbound  
flows.  I don't see why this should be a controversial proposal.

It needn't even be a required feature of IPv6 nodes.  Nodes that  
don't support "application listener discovery" will simply not be  
able to receive inbound flows on networks where one or more firewalls  
require nodes to solicit them explicitly.  They will still continue  
to function normally on networks where no such discovery is necessary  
(in the increasingly unlikely event such networks ever exist in the  
real world).

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Apr 2007 16:33:23 -0700

> -----Original Message-----
> From: Bryan Ford [mailto:[email-masked]]
> 
> ... because of the BEHAVE group's decision a while ago

Oh, wow, seriously?  I completely agree with Bryan on this one.
Endpoint-independent is the only sensible solution, unless BEHAVE is
actively seeking to make the internet inhospitable to self-organizing P2P
clouds (like Skype or P2P-SIP).

Can anyone summarize for me (off list) why we made this disastrous decision?
Alternatively, can anyone offer any pointers back into the list archive as
to when this decision was made so I can catch up on the reasoning?  The best
I can find is this, from 2005:

http://list.sipfoundry.org/archive/ietf-behave/msg00696.html

In that thread, at least, it doesn't sound like a decision was made, though
everybody but Cullen seemed in favor of endpoint-dependent.  Indeed, I've
yet to see any actual P2P developer come out against endpoint-independent
(and as the lead P2P developer at Akamai, I can unquestionably say I support
endpoint-independent filtering by default).
  
-david (hoping to not derail the discussion)

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 16:44:08 -0700

On Apr 17, 2007, at 16:33, David Barrett wrote:
> clouds (like Skype or P2P-SIP). [...]

Apple's AirPort base station products have always done endpoint- 
independent mapping since their first generation was introduced over  
five years ago.  This was quite deliberate, and I doubt Apple will  
reverse that decision unless it receives pressure from the community  
of Internet security experts.

---

From: Bryan Ford <[email-masked]>
Date: Tue, 17 Apr 2007 20:53:26 -0400

> http://list.sipfoundry.org/archive/ietf-behave/msg00696.html

That was indeed part of this very long discussion thread - it might  
be a bit difficult to trace, because the discussion of this topic was  
mixed with discussion of several other issues that I and others  
brought up in response to the (first) "last call" for the BEHAVE UDP  
draft.  The message you point to is actually pretty late in the  
discussion, after I had already given up hope that the working group  
would agree to a direct recommendation that NATs "SHOULD implement  
endpoint-independent filtering behavior" and fell back on fighting  
for a recommendation that NATs at least "SHOULD _allow the user_ to  
configure them to enable endpoint-independent filtering behavior".   
But others in the group objected strongly even to that, and it  
finally came down to the August 2005 IETF meeting in Paris, whose  
minutes you can find here:

http://www3.ietf.org/proceedings/05aug/index.html

Basically, I ended up being the only one in the whole (pretty fully)  
room advocating even that relatively weak language, recommending that  
users even be allowed to configure their NATs for endpoint- 
independent filtering behavior.  So I gave up and let the group do  
what they wanted to.

In retrospect, I should have asked for a show of hands indicating who  
in the room represented (a) a NAT/firewall vendor, (b) a vendor of  
centralized VoIP infrastructure, and (c) a developer of self- 
organizing P2P applications or protocols.  I suspect practically  
everyone there was in either category (a) or (b).  Or if anyone else  
there was representing category (c), they didn't understand the  
practical implications of the decision being made.

I agree, I still think the decision was disastrous, but what could I do?

Bryan

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Apr 2007 18:04:58 -0700

> I agree, I still think the decision was disastrous, but what could I
do?

Design your applications for the network you have, not the network you
wish you have.

-- Christian Huitema

---

From: Bryan Ford <[email-masked]>
Date: Tue, 17 Apr 2007 21:08:35 -0400

On Apr 17, 2007, at 7:44 PM, james woodyatt wrote:

> independent mapping since their first generation was introduced  
> over five years ago.  This was quite deliberate, and I doubt Apple  
> will reverse that decision unless it receives pressure from the  
> community of Internet security experts.

Bravo.  I have yet to see one anyone come up with single shred of  
concrete evidence that endpoint-dependent filtering actually  
increases security in any practical way.  For example, if someone in  
the security community could point out ONE SINGLE real security  
vulnerability that EVER existed in ANY application/OS combination at  
ANY time in the past, which WAS remotely exploitable if the host was  
behind a firewall with endpoint-independent filtering, but WAS NOT  
exploitable if the firewall had implemented endpoint-dependent  
filtering, then I might be tempted to rethink my position.  Given the  
number of Windows exploits in the history of the world, one would  
imagine an example could be found if there was one.  But as far as I  
have been able to tell the case for endpoint-dependent filtering is  
nothing but FUD.

And so instead of trying to fulfill its charter and do something to  
defend the basic principles the Internet was built on, the BEHAVE  
group just rolled over and played dead.

Bryan

---

From: Bryan Ford <[email-masked]>
Date: Tue, 17 Apr 2007 21:15:17 -0400

> Design your applications for the network you have, not the network you

That's what I do, and what any intelligent P2P application/protocol  
designer does.  The problem is that the BEHAVE group's decision, if  
followed by the industry, makes that task ever more difficult over  
time, asymptotically approaching impossible (as we run out of first- 
class nodes able to accept incoming connections).  The right  
decision, in contrast, would have made the task easier over time,  
asymptotically approaching trivial.

Bryan

---

From: james woodyatt <[email-masked]>
Date: Tue, 17 Apr 2007 18:32:22 -0700

On Apr 17, 2007, at 18:04, Christian Huitema wrote:
>
> Design your applications for the network you have, not the network  
> you wish you have.

I wish IETF could keep from designing new and interesting ways for  
the Internet to break the applications we have, not to mention the  
applications we wish we could have.

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Apr 2007 19:31:46 -0700

Actually, now that I read the RFC as suggested by Bruce, REQ 8 doesn't
appear to recommend endpoint-dependent filtering by default.

Bryan -- Am I misreading this?  Why are you saying that it's recommending
endpoint-dependent filtering by default?

-david

> Sent: Tuesday, April 17, 2007 5:53 PM
> To: David Barrett
> Cc: 'Christian Huitema'; 'IETF BEHAVE WG'
> Subject: Re: Endpoint-independent filtering is the way to go.
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 Apr 2007 23:41:22 -0700

> applications we wish we could have.

Yep. The problem, however, is not so much the IETF as the lack of
industry agreed rules on what constitutes a "good" router. We
(Microsoft) are trying to address that. The test program available at
http://www.microsoft.com/windows/using/tools/igd/default.mspx checks for
common bugs in home routers (aka Internet Gateway Devices, IGD).
Endpoint independent mapping would be considered one such bug. Routers
are supposed to pass these tests if they want to show the "designed for
Vista" logo. A router that exhibits endpoint independent mapping or
"symmetric NAT" behavior would not get this logo.

-- Christian Huitema

---

From: "David Barrett" <[email-masked]>
Date: Tue, 17 Apr 2007 23:55:15 -0700

Just curious, what sort of requirements does your tool make for filtering?
Does it allow for both endpoint-dependent and -independent filtering?

-david

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, April 17, 2007 11:41 PM
> To: james woodyatt; IETF BEHAVE WG
> Subject: RE: [BEHAVE] RE: Endpoint-independent filtering is the way to go.
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Apr 2007 00:01:41 -0700

> Does it allow for both endpoint-dependent and -independent filtering?

We allow for both. Our P2P apps work through endpoint-dependent
filtering routers. Some use ICE like mechanisms, other use IPv6 over
Teredo.

-- Christian Huitema

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 18 Apr 2007 10:36:21 +0300

> filtering routers. Some use ICE like mechanisms, other use IPv6 over

But then there is always the need for some rendez-vous point that is not 
firewalled (SIP registrar, Teredo server...). Not that I consider this a 
problem myself, but I cannot see this working in a DHT typeof network, if all 
nodes are behind stateful firewalls.

Also for non-UDP transports, I am slightly suspicious... For TCP simultaneous 
open to work, there is the requirements that the firewall does not send ICMP 
errors (c.f. BEHAVE-TCP)... and that's not specified in IPv6 case, as far as 
I know.

That being said, I can only agree with the notion that apps should 
use "side-effect" of firewalling rather than depend on a signaling protocol 
that is likely not implemented by the gateway. But I do not see these as 
contradictory either; signaling has some advantages such as support for 
detecting firewall reboots or requesting real pinholing that hole punching 
will never support.

Another good thing with signaling is the ability to negociate the refresh 
timer, which is known to matter for mobile devices, as sending refresh 
packets every so often drains the battery.

-- 
Rémi Denis-Courmont

---

From: Saikat Guha <[email-masked]>
Date: Wed, 18 Apr 2007 05:18:24 -0400

On Tue, 2007-04-17 at 21:08 -0400, Bryan Ford wrote:
> > independent mapping 
    ^^^^^^^^^^^^^^^^^^^
> concrete evidence that endpoint-dependent filtering 
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
endpoint independent mapping is not the same as endpoint dependent
filtering.

Infact, there is nothing called "endpoint-dependent filtering". There is
"address dependent filtering" and and "address-and-port dependent
filtering". Conflating the two glosses over some important subtleties.

Finally, behave MANDATES *endpoint independent mapping*  (that which
james is referring to I believe). Second, behave RECOMMENDs endpoint
independent filtering for NATs that wish to be P2P friendly (that which
brian is refering to I believe). Lastly, it RECOMMENDs "address
dependent filtering" but NOT address and port dependent filtering for
security conscious NATs. 

If you think the security concern is not justified, refer to a comment
made by a Junier engineer in the Paris meeting (check the audio
transcript). To paraphrase the comment, anything where talking to ONE
internet host leaves the NATed host vulnerable to ANYONE and EVERYONE on
the Internet is unacceptable.

-- 
Saikat

---

From: Saikat Guha <[email-masked]>
Date: Wed, 18 Apr 2007 05:30:31 -0400

On Tue, 2007-04-17 at 21:15 -0400, Bryan Ford wrote:
> The problem is that the BEHAVE group's decision, if  
> class nodes able to accept incoming connections).

This is analogous to saying if everyone uses DNS names all the time
then, over time, it'll be impossible to reach any host on the Internet
because we'll all just have DNS names.

But that is not true now is it? In addition to DNS names, we have the IP
addresses of root servers. Those root IPs *cannot* change. 

Asymptotically, I for one expect to see rendezvous providers just like
the DNS root. Rendezvous providers will be required to be non-NAT'ed
just like DNS roots are required to operate at a fixed IP.

If you are behind a "address dependent filtering" NAT but "endpoint
independent mapping" NAT (the most secure config recommended by behave),
you must first rendezvous with your peer at the rendezvous service,
exchange ICE messages, and then establish the connection.

As for the scalability of such a rendezvous service, that would be the
topic of discussion for a SIP mailing list.

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 Apr 2007 09:00:30 -0400

> > > Apple's AirPort base station products have always done endpoint- 

Oops, sorry, just a typo - I meant "filtering" in both places, not
"mapping".

> the Internet is unacceptable.

But it doesn't leave the NATted host vulnerable to ANYONE and EVERYONE -
at most it is vulnerable to an external host that has the resources to
scan systematically for the public port - which is typically in the
large upper range well clear of standard port assignments.

As I said, show me just ONE actual, documented, working historical
exploit and I might reconsider.  But you might have a tough time - as
has been pointed out already, practically all attacks have already
migrated up the protocol stack to higher layers that aren't protected by
any basic firewall with either filtering behavior.

Bryan

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 Apr 2007 09:11:59 -0400

> endpoint-dependent filtering by default?

Oops, you're right - sorry, I forgot that the final language actually
did end up more or less permitting either option.  So it's not quite as
bad as I remembered.  But it still disturbs me greatly that the BEHAVE
group ended up officially "blessing" the anti-connectivity
endpoint-depending filtering behavior based on absolutely no evidence of
added security other than FUD.

Bryan

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 Apr 2007 09:28:09 -0400

> just like DNS roots are required to operate at a fixed IP.

But Internet standards REQUIRE that every ISP provide DNS service to
their clients, and in particular to run _enough_ DNS servers to handle
the the everyday load their clients produce without hammering the
upstream or root DNS servers.

If the IETF were similarly to REQUIRE that every ISP provide working
STUN servers to their clients, which those clients can easily locate
through fully automatic mechanisms (e.g., DHCP), and which can handle
all the rendezvous load that the clients may generate even when they are
running connection-intensive protocols like DHTs, then I would be happy
with that strategy.  Until then, though, you're using the existence of
something that doesn't exist - either "de facto" or "de jure" - as an
excuse for not defending the Internet's original connectivity paradigm.

Bryan

---

From: Bryan Ford <[email-masked]>
Date: Wed, 18 Apr 2007 09:30:50 -0400

> Oops, sorry, just a typo - I meant "filtering" in both places, not

Re-oops - I thought the first instance was my writing, but it was
James's, which I had misread.  But the rest of the statement stands.

Bryan

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 06:53:09 -0700

At Wed, 18 Apr 2007 09:00:30 -0400,
> large upper range well clear of standard port assignments.

http://insecure.org/nmap/

> any basic firewall with either filtering behavior.

And yet packet filters are incredibly common.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2007 06:53:15 -0700

-Ekr

---

From: Saikat Guha <[email-masked]>
Date: Wed, 18 Apr 2007 10:42:09 -0400

On Wed, 2007-04-18 at 09:00 -0400, Bryan Ford wrote:
> But it doesn't leave the NATted host vulnerable to ANYONE and EVERYONE
  ^^^^

Most NATs are port-number preserving. If an application uses local port
x, translated packets will appear to come from the same port x on the
external side. So no port-scan is necessary.

Combine this with MS SQL Slammer worm, and the following scenario
emerges.

Normal operation:
  SQL1 ---- NAT1 ---- Internet ----- Firewall --- SQL2

SQL1 is configured to send daily log backups to an offsite SQL2. MS SQL
server uses the UDP port on SQL1 to contact the UDP port on SQL2.

Slammer day operation:
   SQL1 ----- NAT1 --------- Slammer1

Slammer1 can now send a single packet to SQL1 through the SQL1-SQL2 hole
that was left open on the NAT. Game over.

---

From: Saikat Guha <[email-masked]>
Date: Wed, 18 Apr 2007 10:52:14 -0400

On Wed, 2007-04-18 at 09:28 -0400, Bryan Ford wrote:
> their clients

Can you point me to such an ISP requirements document? 

AFAIK, ISPs are not *required* to provide a recursive resolver. Any
third-party service (at a well-known IP) can provide a recursive
resolver the entire world can use.

> STUN servers to their clients

No need to "REQUIRE that every ISP" provide a STUN server; just that
_some_ STUN servers exist, perhaps third-party. 

> which those clients can easily locate through fully automatic mechanisms 
> (e.g., DHCP)

Now you are talking about (non-insurmountable) configuration hurdles.
Completely tangential to NAT filtering.

> , and which can handle
> all the rendezvous load 

... and performance. More engineering.

>  then I would be happy
> with that strategy.  

I, for one, wouldn't be happy if asked to surrender a secure network for
one that requires a touch more configuration and engineering.

---

From: "Barrett, David" <[email-masked]>
Date: Wed, 18 Apr 2007 11:20:11 -0700

Thanks for the clarification.  So in effect, BEHAVE makes no recommendation regarding restricted/full-cone (ie, recommends both equally), but instead just outlaws all forms of symmetric NATs.  That's a step in the right direction, though I agree, not as far as I'd like.

-david

-----Original Message-----
From: Bryan Ford [mailto:[email-masked]]
Sent: Wed 4/18/2007 6:11 AM
To: David Barrett
Cc: 'IETF BEHAVE WG'
Subject: [BEHAVE] RE: Endpoint-independent filtering  is the way to go.

Bryan

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 11:33:50 -0700

On Apr 18, 2007, at 00:01, Christian Huitema wrote:
> filtering routers. Some use ICE like mechanisms, other use IPv6  
> over Teredo.

Does the tool check that Teredo is properly blocked when the router  
is advertising a global scope IPv6 prefix?

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Apr 2007 13:31:03 -0700

> is advertising a global scope IPv6 prefix?

No. In fact, we expect routers to not block Teredo, regardless of their
IPv6 configuration. For example, even if a host does have native IPv6
connectivity, it might want to run a "host based" Teredo relay in order
to communicate with other Teredo hosts. 

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 13:54:17 -0700

On Apr 18, 2007, at 13:31, Christian Huitema wrote:
> No. In fact, we expect routers to not block Teredo, regardless of  
> their IPv6 configuration. [...]

For the "Designed for Windows Vista" certification, do you require  
Teredo *not* to be blocked by IPv6 routers offering prefixes derived  
from, for example, 6to4 tunnels?  Apple communications engineering is  
in the middle of discussions about how to secure the local network  
against unsolicited traffic embedded in Teredo tunnels.

I'm currently advocating blocking all Teredo if an native IPv6 prefix  
is advertised on the local network.  It's easier than trying to apply  
the stateful packet filter to the traffic embedded in the UDP flows.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Apr 2007 22:54:54 -0700

> from, for example, 6to4 tunnels?  

That is correct, we require Teredo to not be blocked, even if the IGD
offers 6to4 or other IPv6 services.

> Apple communications engineering is

We expect that protection to be performed in the host. Teredo is only
enabled on Windows if there is an active host firewall, that explicitly
controls IPv6 traffic.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Apr 2007 23:55:50 -0700

On Apr 18, 2007, at 22:54, Christian Huitema wrote:
>> Teredo *not* to be blocked by IPv6 routers offering prefixes  
>> derived from, for example, 6to4 tunnels?
>
> That is correct, we require Teredo to not be blocked, even if the  
> IGD offers 6to4 or other IPv6 services.

Interesting.  That seems like a curious design choice.

>> Apple communications engineering is in the middle of discussions  
>> about how to secure the local network against unsolicited traffic  
>> embedded in Teredo tunnels.
>
> We expect that protection to be performed in the host. Teredo is  
> only enabled on Windows if there is an active host firewall, that  
> explicitly controls IPv6 traffic.

That expectation may be unrealistic.  Teredo is an IPv6 transition  
mechanism, not a virtual private networking application.  It cannot  
be allowed to be a method for circumventing the stateful packet  
firewall in residential IPv6 gateways for the establishment of  
communications counter to policies defined by network  
administrators.  As such, I'm pretty confident that the Teredo  
requirement will go on Apple's list of reasons not to seek the  
"Designed for Windows Vista" certification.

I also think the BEHAVE working group should explicitly recommend  
blocking Teredo in dual-IPv6/IPv4-NAT gateways.  Such gateways should  
implement their own Teredo relays for forwarding to and from the  
2001::/32 prefix subject to the filtering policy configured at the  
gateway.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 17:43:41 -0700

> large upper range well clear of standard port assignments.

I think if you go an look at serious botnet code you will find that  
lots of it does exactly that

Cullen < with my individual hat on>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 18:02:26 -0700

I'm curios about what you are suggesting here - let's say two nodes  
both behind different NAT want to communicate and there is no  
rendezvous server. I'll assume the NATs have Endpoint-independent  
filtering. How does this work without a rendezvous server? What  
address do they use.

If the plan is to manually configure port forwarding in one of the  
NATs then use something like dyndns to find the port then I don't  
think you should be worried. Every NAT i have seen that supports   
static port forwarding has done independent filtering on that NAT  
(though the NAT may be doing address dependent filtering on all the  
dynamically allocated ports). Doing anything else would be sort of  
crazy and require entry of the specific address from which to accept  
packets in the static port forward rule. I'll also note this is using  
dyndns as a rendezvous server.

Cullen <with my individual hat on, and confused on top of that>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 23 Apr 2007 07:58:01 +0300

On Monday 23 April 2007 04:02:26 ext Cullen Jennings wrote:
> filtering. How does this work without a rendezvous server?

I would assume that DHTs would be significantly harder to deploy if only a 
limited subsets of the nodes have endpoint-independant filtering if at all. 
However, not being involved in that kind of stuff, I am in no position to 
propose anything in that regard. As far as I am concerned (i.e. being 
selfish), Rendez-vous servers are fine.

-- 
Rémi Denis-Courmont

---

From: Bryan Ford <[email-masked]>
Date: Mon, 23 Apr 2007 08:41:09 -0400

> filtering. How does this work without a rendezvous server? What  

Let's be more specific: say they're two nodes participating in a DHT.
They can learn each others' address/port from any third node already
participating in the DHT (which may also be behind a NAT).  Any node
already in the DHT with endpoint-independent filtering will do, and if
the DHT is big and endpoint-independent filtering is widespread, there
should be many such nodes - even if practically all of the nodes in the
DHT are behind NATs.  The same applies if a node is already in the DHT
but it is just searching through the DHT for a particular key - it
typically has to contact log(N) nodes to find the key it wants, and if
these nodes have endpoint-independent filtering, it just finds the next
target node's address/port from the previous one.  This all falls out
naturally from any DHT's join/maintenance protocol.

But if nodes with endpoint-independent filtering are rare, then the DHT
algorithm breaks down because all the NATted DHT node have to hammer on
one or a very few "true" public rendezvous servers whenever they need to
talk to ANYONE new.  That's O(log(N)) separate runs of STUN or something
similar through the central STUN server whenever ANY node wants to join
or lookup ANYTHING - i.e., O(N log(N)) overall load.  DHT nodes with
endpoint-dependent filtering can't help out other nodes - they're truly
"second-class citizens".  You know, 3/5ths of a person and all that.

And if DHT nodes can't help each other out, there's probably no benefit
of having a DHT at all anymore.  Since you have a server big enough to
handle the demands of all the clients at once anyway just to handle the
hole punching load, you might as well just run a centralized hash table
on that big server in the first place.

> think you should be worried.

The plan is very much NOT to have to manually configure port forwarding
- most users don't have the foggiest clue what a port is and definitely
don't want to have to learn.

That's why self-organizing distributed apps really need either
endpoint-independent filtering by default, or SOME way to punch
endpoint-independent filtering holes explicitly (assuming local security
policy permits) with no manual configuration, via something like UPnP or
NAT-PMP.

Bryan

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Apr 2007 09:08:14 -0700

> on that big server in the first place.

Ok - I get where the disconnect is now ... Let's as-sum *every* node  
in the DHT is behind an address dependent filtering NAT except the  
boot strap nodes - clearly we don't want all the traffic in the DHT  
flowing thought the bootstrap nodes - that would not scale as you  
point out. I think you and I have the same requirements here and I  
think that they can be meant in this case - I will explain how below.

Say B is bootstrap node, A is some node in the DHT, and C wants to  
join and C's finger table causes it to want to have a connection to  
A. C contacts B to join the ring and uses it to route messages while  
it builds it's finger table. When it wants to build a connection to  
A, the A and C nodes do the normal NAT whole punching thing (either  
with UDP or TCP) to form a direction connection - while they are  
doing this the roue messages via the DHT (which is the rendezvous  
service) to bring up the connection. But once they have done this,  
they can send messages directly to each other.

So in the case above, the first few nodes would route messages via  
the bootstrap node until their finger tables are up but after that  
they don't.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 23 Apr 2007 12:16:19 -0400

> on that big server in the first place.

Let me repost here an e-mail that I posted to the P2PSIP mailing list a
week ago.  In a nutshell, I believe that DHTs _CAN_ be made to work
when all peers are behind address-dependent filtering NATs,
and the documents below describe how to do this in the specific case
of Chord.

---- Message sent to P2PSIP on April 18th ----
I just want to second what Enrico and Bruce are saying: I believe we  
can live with
NATs and Firewalls that have endpoint-dependent filtering.

The basics of the idea for how to deal with these are described in  
three drafts
     draft-matthews-p2psip-bootstrap-mechanisms, and
     draft-matthews-p2psip-dsip-nat-traversal      (which Bruce  
already mentioned)
     draft-matthews-p2psip-nats-and-overlays

The first draft describes how a node that wishes to join a peer-to- 
peer overlay
can establish a connection to ONE peer in the overlay.
The second draft describes how the node can then leverage this  
connection
to establish a partial mesh of connections to other peers, and then  
use this
partial mesh to route messages through the overlay.
The third draft attempts to explain this idea and compare it with  
other approaches
to NAT Traversal for peer-to-peer networks.

There is still more work to do flesh out all the details, but I  
believe the drafts
adequately describe the core of the idea.

There was a hot debate in the BEHAVE group on the filtering issue.
However, the key fact is that there are many, many NATs today
that already implement endpoint-dependent filtering for "security"  
reasons,
and it was felt that many manufacturers would just ignore the  
recommendation
if the document said "NATs MUST have endpoint-independent filtering".

--- End of message ---

I believe that most people active in P2PSIP today believe that we can  
live
with address-dependent filtering on NATs. It is not ideal, but it is  
not the end
of the world either.

- Philip