Subject: RE: [Ietf-behave] Re: draft-ietf-behave-nat-udp-01, REQ-7

From: "Francois Audet" <[email-masked]>
Date: Thu, 23 Jun 2005 14:04:00 -0700 (PDT)

I think it is time for closure on REQ-7a.

I have opted for the MAY in 7a because it doesn't look like we
can get consensus for the SHOULD.

However, I did add a sentence at the end of the justification
section touting the merit of having a configuration option.

I think this is the best compromise we can achieve, and I would
like the group to achieve "rough consensus" on this requirement.

----------------------------------------------------------------

   REQ-7: 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.

   Justification for REQ-7: The recommendation to use Endpoint
      Independent Filtering is aimed at maximizing application
      transparency, in particular for applications that receive media
      simultaneously from multiple locations (e.g., gaming), or
      applications that use rendezvous techniques.  However, it is also
      possible that in some circumstances, it may be preferable to have
      a more stringent filtering behavior.  Filtering independently of
      the external endpoint is not as secure: an unauthorized packet
      could get a specific port while the port was kept open if it was
      lucky enough to find the port open.  In theory, filtering based on
      both IP address and port is more secure than filtering based only
      on the IP address (because the external endpoint could in reality
      be two endpoints behind another NAT, where one of the two
      endpoints is an attacker): however, such a policy could interfere
      with applications that expect to receive UDP packets on more than
      one UDP port.  Using Endpoint Independent Filtering or Address
      Dependent Filetering instead of Address and Port Dependent
      Filtering on a NAT (say NAT-A) also has benefits when the other
      enpoint is behind a non-BEHAVE compliant NAT (say NAT-B) which
      doesn't support REQ-1.  When the endpoints use ICE, if NAT-A uses
      Address and Port Dependent Filtering, connectivity will require a
      Media Relay.  However, if NAT-A uses Endpoint Indepent Filtering
      or Address Dependent Filtering, ICE will ultimately find
      connectivity without requiring a Media Relay.  Having the
      filtering behavior being an option configurable by the
      administrator of the NAT ensures that a NAT can be used in the
      widest variety of deployment scenarios.

---

From: Bryan Ford <[email-masked]>
Date: Sun, 26 Jun 2005 15:03:46 -0700 (PDT)

> can get consensus for the SHOULD.

I still don't see any consensus on the MAY version either.  I am not the only 
one who has spoken for promoting EF=I filtering or configurability.  With 
MAY, that item says absolutely nothing and is useless.  Absolutely anything 
MAY be configurable; no one needs to be told that.

I continue to have STRONG OBJECTIONS to the publication of a BEHAVE document 
that further legitimizes the existing trend toward NATs having "hard-coded" 
EF=A filtering behavior and which seriously reducing Internet connectivity 
for all users, regardless of whether they or their NAT administrator feels 
the functionality/security tradeoff is justified.  While the existence of 
EF=A filtering may be unavoidable for the moment, hard-coding it into NATs is 
by no means necessary, and doing so runs counter to the basic connectivity 
principles the Internet was built on and which this working group was 
intended to promote.

The ONLY objections I have heard to my proposal are based on arguments that 
NAT implementors will find the proposed SHOULD recommendation seriously 
troublesome, and that they would use that one "troublesome" recommendation as 
an excuse not to adopt the BEHAVE specification at all.  Yet the _ONLY_ NAT 
vendor who has actually spoken up on this topic on the list (Suresh) 
confirmed my claim that making filtering behavior configurable, as proposed, 
should be easy for any NAT that has already implemented EF=A filtering.

If a NAT vendor actually exists who will vehemently resist making filtering 
behavior configurable, then please get them on this list and let's hear their 
objections.  Otherwise, I'm frankly tired of listening to and refuting long 
arguments about what objections some other people _not_ participating on this 
list _might_ have and what they _might_ do.  So please write the 
configurability recommendation as a SHOULD for now, and let's see if any NAT 
vendor actually resists.

Thanks,
Bryan

---

From: David Barrett <[email-masked]>
Date: Sun, 26 Jun 2005 16:10:33 -0700 (PDT)

Bryan Ford wrote:
> So please write the configurability recommendation as a SHOULD for
> now, and let's see if any NAT vendor actually resists.
Here here.