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

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Sep 2004 13:59:28 -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.

Correct. I assume this is not to be included in the BEHAVE draft.

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

If anybody is able to let us know the why of the offending behavior, it
would be helpful.
 
> -Jonathan R.
> 
> Cullen Jennings wrote:
> 
> > 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:
> > 
> > 
> >>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
> >>
> >>_______________________________________________
> >>Ietf-behave mailing list
> >>Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> >>https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> > 
> > 
> > 
> > _______________________________________________
> > 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 
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinf> o/ietf-behave
> 
>