Subject: RE: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt

From: "Francois Audet" <[email-masked]>
Date: Thu, 19 May 2005 22:05:05 -0700 (PDT)

Hi Yutaka,

Thanks for your input.

I'm not sure I understand why you think you need to do ICE with
Address dependent (or Address and port dependent as a matter of
fact). In both cases, you don't but in both cases, you need to
send some outgoing packets before you can start receiving any.

With Endpoint Independent you have to have sent packets outside
of the NAT from the source port to anywhere to start receiving
from anywhere.

With Address dependent, you have to have sent packets outside
of the NAT to the IP address that is sending you packet to the 
source.

With Address and port dependent, you have to have sent packets
outside of the NAT to the IP address and port that is sending you
packets to the source.

None of these options requires ICE: just sending some probes, without
even waiting for responses. 

In all cases you need to send a probe. The difference is do you
have to send it to 1 IP address, or to all IP address (and possibly
port) you want to communicate with.

Does the application you have in mind requires receiving packets 
from "unknown" places? I assume the application then has to have
it's own way of securing itself based on some other criteria than
the source of the packets?

Anyways, some clarification would be appreciated.

Thanks.

> -----Original Message-----
> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Thursday, May 19, 2005 21:08
> To: Bryan Ford
> Cc: Cullen Jennings; Behave; audet@xxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] Re: Req-7 draft-ietf-behave-nat-udp-01.txt
> 
> 
> 
> I agree with Bryan's opinion with following three reasons:
> 
> 1) NAT should do just what it is supposed to do. If the
> port overloading is not required, then the "external
> filtering" is no longer a NAT's job.
> "It sounds more secure.." as more of a sales talk
> just does not sound right to be a basis of a decision
> made by IETF. Filtering behavior should have something
> to do with users' security policy, which is exactly what
> Bryan is suggesting.
> 
> 2) Endpoint independent maintains full UDP functionality. 
> Endpoint address dependent filter compromises natted node's 
> ability to receive packet from anyone. This seems to be a 
> huge loss for the Internet community, for the sake of halfway 
> security measures. Probably this is likely a thing that 
> people who only has VoIP in mind do not care about.
> 
> 3) Avoid ICE to be an requirement for traversing NAT
> As a programmer, the simplest solution is preferable.
> ICE is way far from 'simple'. Endpoint dependent filter 
> behavior requires ICE connectivity check process or 
> equivalent (UDP hole punching by knowing the other end's 
> transport address). Just for a reminder for us...
> 
> So, I strongly support:
> 
>  >     REQ-7: NATs MUST implement Endpoint-Independent
>  >            Filtering in their default configuration.
>  >            NATs SHOULD be configurable to support
>  >            Address-Specific Filtering or Endpoint-Specific 
> Filtering
>  >            at the option of the system administrator.
> 
> - Yutaka
> 
>

---

From: [email-masked]
Date: Fri, 20 May 2005 11:40:16 -0700 (PDT)

What I meant by saying "ICE or equivalent" is a system that
operates:
1) Initiator grabs external transport address on the NAT on
   every event of session initiation.
2) Inform the other end of the address via a proxy server.
3) The other end (Acceptor) grabs its external transport
   address on the Acceptor's NAT.
4) Inform the initiator of the external address.
5) Preform UDP hole punching from both ends to the transport
   addresses obtained. (This is done by connectivity check
   in ICE.)
and this operation is required to every node including
ability to use the proxy server.
Imagine, if a node behind an Endpoint Independent NAT
wishes to receive packets from anywhere (like a server),
the node simply sends a binding request to STUN server
to grab an external port on the NAT, and the port is
available ahead of time for anyone without the above
operation.
> from "unknown" places?
Yes, hopefully with a simple way. Currently UPnP is the
only way that allows this.
> I assume the application then has to have
Yes, as well as the application used to have a global
address needed to do, and as an UDP/IPv6 application
that likely does not require a NAT.
- Yutaka

Francois Audet wrote:
Hi Yutaka,

Thanks for your input.

Thanks.

 >  >     REQ-7: NATs MUST implement Endpoint-Independent
 >  >            Filtering in their default configuration.
 >  >            NATs SHOULD be configurable to support
 >  >            Address-Specific Filtering or Endpoint-Specific
 > Filtering
 >  >            at the option of the system administrator.
 >
 > - Yutaka
 >
 >