Subject: RE: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01

From: "Francois Audet" <[email-masked]>
Date: Mon, 23 May 2005 16:22:45 -0700 (PDT)

> -----Original Message-----
> From: yutaka_takeda@xxxxxxxxxxxxxxxxxxxx 
> [mailto:yutaka_takeda@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Monday, May 23, 2005 15:37
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: Re: [Ietf-behave] comments on draft-ietf-behave-nat-udp-01
> 
> 
> 
> I had a discussion with our engineering team on
> the new proposal by Francois on REQ-7 this morning.
> We basically agree with his proposal.
> 
> First off, some typos we found on the new REQ-7: 
> "transperencyIt" -> "transparency, it" "ti was lucky" -> "it 
> was lucky" "could infere" -> "could interfere" "one than one 
> port" -> "more than one port"

Thanks. Will fix.

> I am not confident if I understand following statement 
> correctly. Could you please elaborate for me?
> 
> "however, such a policy could interfere with applications 
> that use more 
> than one port."

This is verbatim from the existing text. It is meant to the case
of an application behind a NAT, which would pierce a pinhole
by sending some packets from a source port, but where the remote
application may send packets to more than one local UDP port.

Perhaps the text should say "however, such a policy could
interfere with applications that expect to receive UDP
packets on more than one UDP port."

> Besides the security point of view, avoiding endpoint
> address port dependent filtering has another significant 
> benefit. If the two hosts (A and B) are behind different NATs where:
> 
> - Host A is behind Full-cone or Restricted-cone NAT.
> - Host B is behind Symmetric NAT.
> (sorry for the use of old terminology)
> 
> ICE can find connectivity between the two in this case,
> where if Host A is behind a Port-restricted cone NAT, ICE
> will not be able to find a direct connectivity between them. 
> This could be mentioned in the REQ-7 justification section 
> for more specific clarification..?

Can you elaborate on this last point? I can't seem to make sense
out of it. Do you mean find connectivity without a Media Relay?
If so, can youd describe why, because it seems to me that you will
require a media relay if one end has a address/port dependendent
mapping.

Thanks.

---

From: [email-masked]
Date: Mon, 23 May 2005 17:56:18 -0700 (PDT)

> out of it. Do you mean find connectivity without a Media Relay?
Yes.

> require a media relay if one end has a address/port dependendent
Correct. That is what I meant.
Let's say host A is behind a symmetric NAT (External IP 
address=X)(address/port dependent) and host B is behind a port 
restrected cone NAT (External IP address=Y) (address/port dependent). 
Each hosts performs binding request with a STUN server and obtain STUN 
derived addresses, X:p and Y:q respectively, and then exchange the 
addresses via a proxy server.

The, host A and B performs connectivity check against the transport 
address obtained from the other host. However, packets sent from host A 
will have a different source port number 'p2' than 'p1', consequently, 
the packets will be discarded by the host B's NAT even host B performs
connectivity check against X:p1. (port must match to receive)

If the host B is behind an address dependent or independent NAT, the 
packets from host A will be eventually received regardless of what 
source port number it has, and then the host A will receive a response 
from host B. Host A, then detects a new MAPPED-ADDRESS (X:p2) in the 
response, and performs an update (see section 9.3 in ICE document) to 
modifiy the media transport address for host B. Finally, host B also 
finds connectivity to the X:p2 and terminates the session initiation 
process.

So, from what I understand, by avoiding address/port dependent to be 
behave compliant NAT, the behave compliant NAT possibly removes the 
requirement of a media relay (like TURN) in the case where the remote 
host is behind a Symmetric NAT.

Hope this helps.

- Yutaka

Thanks. Will fix.