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 08:06:25 -0700 (PDT)

> -----Original Message-----
> From: Saikat Guha [mailto:sg266@xxxxxxxxxxx] 
> Sent: Sunday, July 03, 2005 5:13 PM
> To: Senthil Sivakumar (ssenthil)
> Cc: Francois Audet; Behave
> Subject: RE: [Ietf-behave] FW: I-D 
> ACTION:draft-ietf-behave-nat-udp-02.txt
> 
> On Sun, 2005-07-03 at 10:58 -0700, Senthil Sivakumar (ssenthil) wrote:
> >  > REQ-11: It is RECOMMENDED that a NAT support ICMP Processing.
> > >     a) The ICMP timeout SHOULD be greater than 2 seconds.
> >
> > The above is vague, it does not specify exactly what the 
> requirement is.
> > IMO, the requirement is that NAT should not delete any mapping as a 
> > result of seeing Destination unreachable.
> 
> The requirement actually is much stronger -- the NAT 
> shouldn't delete the mapping as a result of any ICMP packet; 
> the details being in section 9. But I agree with you and 
> would prefer something similar to the long form with the 
> explicit sub-bullets. 

Me too. 

> 
> > BTW, how was the timeout of 2
> > secs derived?
> 
> *shrug* What's the timeout for, even?
> 

I was just curious to understand if the 2 secs was based on some
data/testing. Timeouts are definitely needed otherwise you would be
consuming the resources of the box. The question is what is a reasonable
timeout for ICMP.. Two seconds seem awfully low to me.

Senthil

> --
> Saikat

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Jul 2005 15:02:38 -0700 (PDT)

At 8:06 AM -0700 7/4/05, Senthil Sivakumar (ssenthil) wrote:
Timeouts are definitely needed otherwise you would be
consuming the resources of the box.
Fully disagree. Timeouts are completely unnecessary on a system that 
watches its resources and, when a resource gets close to full, starts 
to discard based on a sensible algorithm (which could be "oldest" in 
almost all cases).

Trying to guess what a good/reasonable time for a timer without a lot 
of research is not engineering.

--Paul Hoffman, Director
--Cybersecurity Association
--www.cybersecurity.org

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 5 Jul 2005 01:25:11 -0700 (PDT)

Francois,

What is the timeout you are refering to in this requirement (Req#11)? Why do
you need to time anything when forwardign an ICMP error message? 

Also, the text in section 9 refers to "UDP mapping" and labels the NAT that
forwards ICMP error messages as "UDP Support Destination Unreachable". Why do 
you believe, this is a UDP-only support characteristic? Is this not applicable
to both TCP and UDP? Further, do you believe, a NAT is considered to support
ICMP Destination unreachable messages if it simply forwarded error messages
between domains? Shouldnt a NAT be capable of generating ICMP error messages as
well? 

cheers,
suresh

--- "Senthil Sivakumar (ssenthil)" <ssenthil@xxxxxxxxx> wrote:

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 5 Jul 2005 01:40:16 -0700 (PDT)

Francois,

You have section 4.3 refering to "Mapping Refresh" behavior and a req-6 that
follows it. And, section 5.2 refering to "Filter refresh" with no requirement
that follows it. 

Why does section 5.2 have no requirement associated with it? Also, w.r.t.
req-6, why is the refresh required only on the outbound?

cheers,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 5 Jul 2005 02:00:42 -0700 (PDT)

Francois,

Req-13 (A NAt must support receiving in-order fragments) is not the WG
consensus, AFAIK. Fragement processign is not limited to in-order fragments. 

As for Req-12, why is NAT support of fragmentation restricted to link MTU
criteria? Are you referign to immediate link MTU? The discussion we had on
outbound fragmentation addressed much more than you mention here. Also, what is
the "ICMP section" you refer to in section 10.2?  

cheers,
suresh