Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Mon, 4 Jul 2005 17:05:15 -0700 (PDT)

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Paul Hoffman
> Sent: Monday, July 04, 2005 7:33 PM
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] FW: I-D 
> ACTION:draft-ietf-behave-nat-udp-02.txt
> 
> At 4:07 PM -0700 7/4/05, Senthil Sivakumar (ssenthil) wrote:
> >Disagree as well. Using the resources for longer than 
> necessary is not 
> >good engineering either.
> 
> We agree there. However, no one has defined "longer than necessary". 
> Picking a length of time without any backing from either the 
> RFCs or experimentation can't answer that.
> 
> >In this case we are talking about ICMP mappings and you are going to 
> >let the ICMP mappings stay and consume the resources of the 
> box until 
> >the box runs "close to full"?
> 
> No, that's now what I said. I explicitly said "when a 
> resource gets close to full". You don't toss all the 
> resources into one memory
> heap: different mappings have different buffers, and when you 
> put something into a buffer, you check if that buffer is 
> getting close to full. This is a completely common 
> programming technique used by nearly every network device vendor.

Really? I have worked on two implementations neither of them use a
different buffer for each protocol. 

> 
> >We have defined
> >timeouts through out the behave drafts
> 
> I'm not sure who you mean by "we". See section 4 of 
> draft-hoffman-behave-tcp-00.txt for a counter-example.
> 

The draft here in question defines timeouts for udp mappings. The
draft-sivakumar-behave-nat-tcp-req-01.txt has recommendations for tcp
mappings. Another reason why I believe the above draft you mentioned is
not detailed enough for TCP behavior.

Senthil

> >- basically those are all
> >unnecessary?
> 
> Correct, unless they match a timer in the RFC that defines 
> the protocol in question, or they are taken from some 
> research that people agree is complete and well-founded.
> 
> --Paul Hoffman, Director
> --Cybersecurity Association
> --www.cybersecurity.org
> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: "Dave Hudson" <[email-masked]>
Date: Tue, 12 Jul 2005 14:40:10 -0700 (PDT)

* -----Original Message-----
* From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] 
* Sent: 12 July 2005 22:30
* To: Dave Hudson
* Cc: Pyda Srisuresh; ietf-behave@xxxxxxxxxxxxxxxxxxx
* Subject: RE: [Ietf-behave] FW: I-D 
* ACTION:draft-ietf-behave-nat-udp-02.txt
* 
* On Mon, 2005-07-11 at 12:16 -0700, Dave Hudson wrote:

* > FWIW there's at least one commercial testsuite used by a 
* lot of SOHO 
* > router manufacturers that current expects that sessions 
* will timeout 
* > due to inactivity.
* 
* Interesting. Could you point me to more about this testsuite. Thanks.

Sure - the testsuite is called CDRouter.  You can get more info from
www.qacafe.com.  We've been using it for about 12 months now.  Aside
from testing basic NAT behaviours (including hairpinning - complete with
a reference to one of this WG's drafts) it also includes tests for quite
a large number of common ALGs.

Regards,
Dave