Subject: [BEHAVE] RE: Endpoint-independent filtering is the way to go.

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

> -----Original Message-----
> From: Bryan Ford [mailto:[email-masked]]
> 
> 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.

Cullen -- Is it safe to say that the consensus of the BEHAVE group is the benefit offered by decentralized overlay networks (eg, DHTs) are outweighed by the security risks of endpoint-independent mapping?

Given that the IETF-chartered P2P-SIP folks are actively building a DHT that requires a high fraction of endpoint-independent filtered nodes, shouldn't we inform them that we're on a collision course and they need to redesign as a result?

-david

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 17 Apr 2007 22:09:31 -0400

I just posted a similar reply to the same topic on the p2psip list,
but since it's in two places, here is the actual text from 4787:

   REQ-8:  If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address-Dependent
      Filtering" behavior.

      a) The filtering behavior MAY be an option configurable by the
         administrator of the NAT.

For one proposed solution for p2psip (or similar) applications, see
draft-matthews-p2psip-dsip-nat-traversal

(I personally prefer endpoint independent filtering, but there are
lots of ways for protocols to work with dependent filtering.)

Bruce

---

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

On Tue, 2007-04-17 at 18:55 -0700, Barrett, David wrote:
> Is it safe to say that the consensus of the BEHAVE group is the
> benefit offered by decentralized overlay networks (eg, DHTs) are
> outweighed by the security risks of endpoint-independent mapping?

No. You are presupposing the solution -- that in the future no global
rendezvous service exists.

I would say, there exists at least one way where developers can achieve
*BOTH* decentralized networks *AND* secure connections. Global
rendezvous service (e.g. a SIP infrastructure much like the DNS
infrastructure today) is one such way, there may be others.

However, requiring endpoint independent filtering would be to admit
defeat / condemn the network by saying that security simply cannot be
achieved if decentralized networks is a goal. Obviously, that is wrong.

-- 
Saikat

---

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

>> independent filtering behavior.  So I gave up and let the group do

I am pretty sure that the room had people from at least three  
different companies that were doing P2P work and wanted NATs to work  
- but to agreeing with Bryan's point, they were probably not a large  
part of the people in the room. My view would be that most of the  
people in the room thought that 1) P2P stuff will work better than  
Bryan thinks it will work with endpoint dependent filtering (but they  
understand we have to have endpoint independent mapping) 2) the  
security provided by endpoint dependent filtering in firewalls is  
more important to them than it is to Bryan.

>
> Cullen -- Is it safe to say that the consensus of the BEHAVE group  
> is the benefit offered by decentralized overlay networks (e.g.,  
> DHTs) are outweighed by the security risks of endpoint-independent  
> mapping?

No - I don't think that was exactly what was happening. I think the  
group believed that the security was achievable at the same time as  
DHTs.

We have lots of examples of P2P applications, some of them DHT based,  
that work fine with endpoint-dependent mappings. Christian posted  
about Microsoft work earlier on this thread, Skype would be another  
well known example, the dsip protocol draft in P2PSIP WG. It's hard  
to go back in time and guess what people were thinking but I know  
what several people argued and what I suspect most people were  
thinking was that they could build P2P application without endpoint- 
independent mapping.

I suspect that many of them were also thinking that for anywhere  
where a firewall functionality was required, endpoint-independent  
mapping would be the death nail of behave being implemented. The bulk  
of residential NATs todays include "SPI" which usually means endpoint  
dependent filtering. I will note that apple is an exception to this -  
but I don't envy the role of the apple engineering folks that have to  
explain to the marketing folks that CNET and other reviews are wrong  
and it is good that the Airports don't have SPI. And I hope Apple can  
turn this into enough of a feature for the environments it is  
suitable for - the Behave UDP specs are written such that something  
that works like the Apple could be behave complaint and so could  
something that include SPI.  I think firewalls are one of the  
defensive in depths techniques that help security - particularly  
given what seem to be the general state of end host security today  
where every major OS includes a stream of security patches. Certainly  
some people at IETF will argue SPI firewalls are useless -  however,  
even theses people will agree that an pragmatic view of the future is  
that a large percentage of endpoints are going to be behind them.  
Even if the world moves to IPv6, and all NATs go away, the v6ops  
people are still assuming firewalls will be in use that do SPI.

All of this is why Behave does not specify firewall behavior but  
tries to make sure that it is possible to be a behave complaint NAT  
and still do the things a minimal firewall often does. Greg Lebovitz  
explained this very clearly in the BOF before Behave was chartered  
and had strong consensus behind this - I think he has explained it  
again in many of the Behave meetings including the last one in Prague.

>
> Given that the IETF-chartered P2P-SIP folks are actively building a  
> DHT that requires a high fraction of endpoint-independent filtered  
> nodes, shouldn't we inform them that we're on a collision course  
> and they need to redesign as a result?

No - I don't think there is a collision course here - the people  
doing NAT work in the P2PSIP group are very aware of what Behave is  
recommending and are designing applications that work in that  
environment.

> -david

Cullen < with my individual hat on>

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Apr 2007 11:03:31 -0700

On Apr 22, 2007, at 19:58, Cullen Jennings wrote:
>
> [...] The bulk of residential NATs todays include "SPI" which  
> usually means endpoint dependent filtering. I will note that apple  
> is an exception to this - but I don't envy the role of the apple  
> engineering folks that have to explain to the marketing folks that  
> CNET and other reviews are wrong and it is good that the Airports  
> don't have SPI.

AirPort base stations have always implemented SPI filtering.  State  
created by outbound UDP flow initiations has always been subject to  
endpoint-independent filtering, and this has never been a source of  
customer dissatisfaction.  Nobody from product marketing has ever  
brought up the subject with AirPort engineering.

Future products may implement endpoint-dependent SPI filtering for  
outbound UDP flows.  It wouldn't be difficult to do if market demand  
for BEHAVE-compliant NAT gateways emerges, but I can't say anything  
about what Apple plans to do.

Note: UDP mappings created by NAT-PMP are always unfiltered-- and  
this is required by the NAT-PMP specification.  The proposal I am  
currently drafting for extending the concept of PMP for use with IPv6  
firewalls will certainly contain a similar requirement.

--
j h woodyatt <[email-masked]>