Subject: [Ietf-behave] NAT behavior not mentioned thus far.

From: Alan Hawrylyshen <[email-masked]>
Date: Mon, 13 Sep 2004 14:33:31 -0700 (PDT)

All;

There is a notion of inbound traffic and outbound traffic.  For a 
single packet, these concepts are quite easy to understand.
However, I've noticed a few NAT implementations that characterize a 
particular UDP 'stream' as being principally inbound or outbound based 
on the temporal duty-cycle of the packets travelling between the peers 
in the stream.

Specifically, for a node (A)  behind a NAT (N), sending data via the 
NAT to a Peer (P). I see the NAT behave as though it calculates 'duty 
cycle' for the 'stream' and refuse to refresh the binding for those 
with duty cycles over 50%.

Perhaps an illustration would help, consider that the 'edges' in these 
two timelines represent a packet being sent.
A is the baseline (represented by '.') and P is the upper edge 
(represented by ').

.......'''.......'''.......'''.......'''.......'''....... (duty-cycle 
30%) [1]

...'''''''...'''''''...'''''''...'''''''...'''''''...''''''' 
(duty-cycle 70%) [2]

You could imagine that in a situation where the peer-P processing is 
quicker than the node-A processing (or rate of generating requests) 
that we would see something like line [1] above.  In the case where the 
server has much work to do in order to calculate a response, then we 
would see [2].  However, NATs that implement this algorithm will close 
the binding after a short (30s) period of time if the timing looks like 
[2].  The intent, I would guess, is to prevent the 'peer side' from 
maintaining the binding on the NAT by sending requests that solicit 
responses from node A.

Since we cannot distinguish the true 'direction' of a session based 
only on timing analysis -- this mechanism is flawed and I feel that we 
should have some text that points this out in the document. If only to 
discourage NAT implementors  from outsmarting themselves.

I might not have the most concise text above to describe the problem, 
but I think I've managed to illustrate the problem, don't hesitate to 
request clarification if I'm off my rocker here.

Thanks.

Alan Hawrylyshen
Jasomi Networks Inc.
http://jasomi.com/
a l a n a t j a s o m i d o t c o m

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Sep 2004 08:26:47 -0700 (PDT)

Interesting 

Seems like one could test for this using STUN. First create a binding to the
STUN server, call that A. Then create a binding to the alternate IP address,
call B. Now send 1 request every 15 seconds on B while at the same time send
1 request every 5 seconds on A that has the change IP set so the response
will come back on B.

A NAT that does this should have binding B close after 30 seconds of
whatever the time is and the requests sent on A that return on B should stop
working. 

Cullen

On 9/13/04 2:35 PM, "Alan Hawrylyshen" <alan@xxxxxxxxxx> wrote:

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Sep 2004 11:40:09 -0700 (PDT)

There are two things here.

One, is I agree with Cullen it would be good to document a STUN-based 
test to check for this kind of behavior.

More importantly, though, is to try and understand the underlying 
problem/requirement that the implementor was trying to address with 
this, and make sure that the underlying problem is handled by the 
behaviors we recommend.

In this case here, its not clear to me why the vendor went with this 
more complex definition of inbound/outbound, rather than doing the 
simpler "refresh the binding on outbound packet" that we have been 
discussing.

-Jonathan R.

Cullen Jennings wrote:

Interesting 

Cullen

All;

Alan Hawrylyshen
Jasomi Networks Inc.
http://jasomi.com/

_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave
--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Harald Welte <[email-masked]>
Date: Tue, 14 Sep 2004 12:29:52 -0700 (PDT)

> simpler "refresh the binding on outbound packet" that we have been 

Maybe because there are undocumented proprietary protocols (mostly for
online gaming, but IIRC also the original RealAudio protocol) that break
when using a outbound-only refresh :(

We would really need an expert on gaming protocols to join this
dicsussion.  I assume that those protocols currently have a 
considerable share of UDP unicast traffic on the net.  Does anybody know
some expert in this area?

-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
Attachment:
signature.asc